Revisiting ‘Why I’m not a TypeScript fan’ one year later…

About one year ago, I published a blog post title Why I’m not a TypeScript fan. I had some strong opinions of why I didn’t use TypeScript. A few months after I published the post, Gaurav Seth reached out to talk about my post. He surprisingly agreed with many of the pain points I mentioned and said they were working on making this experience much smoother. Long story short, after that conversation I decided to give it a trial run on a side project before taking it to the big times with my project at work. Before I talk about that experience, I want to go through my points I had previously raised and talk about them shortly in retrospect.

Point #1 — Not the standard

I raised that TypeScript is not a standard. In the past there has been many variations of JavaScript come and go. I was worried about the longevity of implementing a large code base for TypeScript to just die in favor of a standard. Gaurav shared my thoughts here, he mentioned its on the top of their minds too. As you read on, you can see how they are addressing this.

Point #2 — You know its gonna happen

Microsoft has representatives on the board of the ECMAScript foundation and with the growing rise of popularity and interest of types in JavaScript, you can conclude that Microsoft’s implementation of TypeScript will likely be some sort of light variation of the official spec once it lands. Facebook’s Flow type actually resembles very similar syntax as TypeScript already. There is a current proposal in Stage 1 of ES8 for Static Types already so we know its coming soon!

Point #3 — Its been around and gotten no ❤

This is true but in hindsight I can conclude that JavaScript has been around for awhile too and gotten no ❤ either. I think with the growing popularity of JavaScript and the more things we build in it the stronger the case for a system like this.

Point #4 — Not Community Driven

This is somewhat true and not at the same time. Yes, Microsoft controls the outcome of this, however, they rely heavily on the community when building these new features into the language. Specs are drafted and posted long before any implementation is started. Microsoft’s position on the board helps them have intimate knowledge and inside details to arguments of why or not to do certain features.

Point #5 — A square in a circle hole (types in dynamic langs)

Adding a type system to any dynamic language is gonna be a tough mission. TypeScript surprisingly does an awesome job about type inference of the dynamic language. I think there is a sweet spot we need to find as a community and I think languages like TypeScript and Flow will help guide this path.

Point #6 — I’m a Babel fanboy

I still fancy Babel but after using it for about two years, the plugin system over complicates things and encourages you to write unstandard code. Its also surprisingly slower at compilation than TypeScript. Many of the plugins I used with Babel are available out of the box in TypeScript and the other things shouldn’t be at the compiler level and I’ve moved to Webpack plugins.

Point #7 — TypeScript Definitions

This still isn’t that great but its getting much better. The more type inference TypeScript can add to its language services the more it can rely less on types of non-typescript libraries. Today there is type libraries for almost any library you are using and the implementation of wildcards for modules makes it easier to just use non-typescript libraries and add the types later.

My experience to date

The first time I tried TypeScript it was version 1.8. During this re-evaluation phase I started with 2.1. The developer difference between 1.x and 2.1 is substantial and I give Microsoft HUGE props for that effort. There is so many advantages that using types can offer that you can’t do with a dynamic language, such as:

  • AoT — Angular can pre-compile code for optimization far beyond tools like Uglify. It can only do this because of the type system.
  • Testing — Mocking is a pain and an utter hack in JavaScript. With the introduction of types you can use systems like IoC (love it or hate it) it makes mocking and testing so much easier.
  • Refactoring — Webstorm and others tout the ability to refactor but to be honest I don’t trust it. With Types you can feel confident that it can do the introspection required to pull this off and during compilation be confident it worked.
  • Productivity— By adding types and type checking in your editor, you can feel more confident about the code you write working the first time, catch more errors before having to refresh thus improving your productivity. Yes, its a pain but it will pay off orders of magnitudes in the end.

I’m #ngPanda

I hope you enjoyed the post, if you liked it follow me on Twitter and Github for more JavaScript tips/opinions/projects/articles/etc!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.