Some projects moving away from TypeScript

I go faster in typescript, because my tools are able to be much more helpful. I think, and please excuse the bluntness, if typescript is slowing you down, you are using it wrong.

Computer languages have 3 environments. The syntax, static environment (what the code literally says) and the dynamic environment (what happens at runtime). The more you can tell by reading the code in the static environment, the easier everything is. JS is a “dynamic language” because it defers a lot of things to the dynamic environment (at runtime) like type marshaling, and property resolution (this). The problem with that is, you have to essentially run the program in your head to make sure all your code is right, and that’s just an error prone and slower (and more exhausting) way to code.

Think about typescript as a tool, rather than gospel. You shouldn’t have to write complex type - really ever. I almost don’t type anything, and instead simply learned to write code in a way that TS can infer almost every type. This makes things like refactoring a breeze.

I will note - I don’t do OOP. OOP is the problem 90% of the time, not typescript. OOP was a generational mistake in computer programming. Do FP (with objects) and free yourself.

Would be nice to see simple pragmatic comparison article without hype and OOP when you get time.

I’m extremely careful with anything that transpile and abstract JS. Coffee script, GWT, Dart and many attempts went to the grave and JS kept growing, I would rather have the code as close as possible to what is being executed on the browser. Once ESM modules become popular we might be able to get rid of transpiling anything and just ship the code as it.

I guess it is a matter of taste and liberalism, for small code bases I enjoy the wildness of pure JS, just “let” the variable be and call functions. Java and OOP was so formal and verbose you have to to navigate so many files, manager classes, factory, interfaces to eventually get to two lines of logic.

With that said, I am curious on how the experience of coding using react, webstorm and meteor could be enhanced with the introduction on TS.

I hear you in regards to Coffeescript. That one was just a light syntax abstraction, with some syntactic sugar. I always found it necessary to translate Coffeescript to straight JS in my head in order to understand what I was doing. That’s sort of the problem with it - it only really tried to address the syntax part of the language, which is not the weak part of JS (in fact, I like curly braces, and I’ll never understand why those Python people don’t).

Typescript is different - it adds a lot more pragmatism to the static environment, and that brings a lot of benefits. It also mostly tries to be “just javascript”. In a certain way it succeeds, but it can get a bit much, if you try to use every feature it has available (or try to do OOP with it).

A simple rule of thumb for using TS might simply be to understand that you are trying to move some of the dynamic reconciliation to the static environment. If you understand that, you can define your types in a way that keeps out of the way, and actively help you, rather than over complicate everything. I’m also not one of those purist - go ahead disable the rules that makes any an error - it’s often very helpful to use any, especially if you just don’t have to the time to find or define a complex type you don’t have any control over. Yeah, it’s not type safe - this is a tool, not a religion.


That’s well said, you convinced me to give it shot, thanks :slight_smile: .

Here is an interesting rant about Java/OOP and what actually got me to try JS. It is really an interesting read.

And this article pretty much summarizes how I feel about typescript in general

Furthermore, I feel once ESM modules pick up, TS usage might decrease in order to ship JS straight to the browsers, I might be wrong, just sharing my opinion.

OMG, I’m going to share “Execution in the Kingdom of Nouns” with EVERYONE I KNOW!

1 Like

One interesting thing from the “TypeScript is a waste” article - the author rejects even modern JS syntax, such as arrow functions, which I find remarkably useful, not just because they are shorter, and make it clearer that they are returning an allocated type (a normal function does too, with hoisting to the top of the inner function scope, and other magic) but they also lock the lexical scope (this) to the author time (static) scope, and don’t resolve that at runtime. That’s incredibly useful.

I get a strong whiff of “this is different, and change is bad” from that article.

I’ll also say that, I’ve tried to switch to TS a number of times, and generally understand where the frustration comes from. There’s a hurdle to learning enough about it for it to be useful. But I can also say, that the number of times it has saved my butt in critical situations is higher than than the number of times it was a pain in the butt - and each of those times, it was just because TS was trying to tell me about an error in my code/logic. Those would have cropped up at runtime - I just might not have noticed until later (or a user might have, which is even worse). I’ve been using it now long enough that I don’t generally have issues like these any more - I understand what the type checker is trying to tell me, and it no longer gets in my way at all. It was hard earned though - that did take a while to learn.


I get your point, but given how much hype there is the JS world, I personally tend to appreciate some healthy/rational skepticism and resistance. As you pointed out earlier, those ain’t ideologies but tools and I think it benefits everyone when we have balanced discussion highlighting the pros/cons so each of us can make a better decision. Meteor as tool had it share of scrutiny and it strength and weakeness are very clear and we’ll documented.

Take a look at this article that got posted recently about building a modern website :

It feels like building an operating system not a website! I recall the days where you would just open a text file, type some html/js, throw it at the server root and off you go. Perhaps I’m getting old :sweat_smile::thinking:

P.s I also find arrow functions to be extremely readable, in fact all ES6 changes were very well designed, I’d personally encourage new comers to master those before jumping to TS, and given the native browsers support to JS it is here to stay.

1 Like

Tables and dot spacers. The young ones will never know!

1 Like

At the start of Typescript, it was clearly an attempt to bring Java/C# to Javascript. They were doing Class when there weren’t available in JS, decorators, Enums…
After a few mishaps where the TS implementation was not compatible with the final JS implementation, they changed their strategy and now the TS project is never introducing a feature that is not stabilized in the JS roadmap.
The target of the project has also been redirected from classical OOP ala Java toward more idiomatic Javascript with all its pros & cons.
Most of the time TS is really JS with types. There are a few situations where it put limits on the “dynamicness” of JS but they are relatively rare, and most of the time it’s for the best.
However It has a steep learning curve if you want to use all of its power/security.

1 Like