Excellent post!

Well, to be honest I don’t have much experience with Typescript, but I always had that feeling that in most cases for me it simply don’t worth the trouble. I never had clear in my mind all those details you shared in this post, but I always wondered myself why to bother with Types in Javascript since the majority of all my daily issues was not about type errors, so I’d rather to spend my efforts on things that would bring more value.

I learned through my experience in Javascript that there are things you can do that can save a lot of headaches like using some functional technics, by thinking in better architecture for your system, using common practices to decouple the many parts of your application and removing completely any this keyword from the code as Douglas Crockford suggested a long ago.

It’s interesting when you said that you might use again Typescript but in a smaller project, because the common argumentation I hear is that you should use Typescript if you want to build a large and scalable app.

I rather bet always on Javascript, that path kept me away from distractions before ( flash, coffeescript, etc ), I always expect that compilers, editors, browsers and language itself to evolve and most of those features will be no more necessary.

I’m trying to use Typescript either way using ts-check mode using one-line jsdoc comment in order to get some benefit of typing without messing with the code, but I guess I’ll suffer from being inexperienced as you mentioned to be one of the many consequences of using Typescript.

Is it wrong to say that Elm could be the same case of Typescript? I know that they are different things but I often see a lot of sentences like “No more runtime errors in production” in many Elm talks, so I wonder if they are focused on that 20% detectable public errors when they said that.

Again, Excellent post! Thanks for sharing.