Why I am NOT a TypeScript fan

Your attention is invited to the translation of the article, the opinion of the author of which I do not absolutely agree But the article has already collected a lot of comments, including supporting ones. It would be interesting to discuss it on Habré, since it is small.


Over the past week, several different people were interested in Twitter through my opinion on the development of TypeScript (knowing full well that I am not his amateur). Having collected my thoughts, I decided to arrange them in the form of this post.

Warning: This is my personal opinion, and I respect the TypeScript development team. Also note that I have only 3 weeks of experience in its practical use: two with Nodejs 5.x and one with Angular 2.

Non-standard

TypeScript is what Microsoft thinks JavaScript should look like. Such technologies, which oppose themselves to open / open source projects, have one pattern. They usually fail. Offhand: Flash, Silverlight, CoffeeScript.
')
If you have a large project, the choice of TypeScript is something you will have to live with for a long time. I bet on anything that in 3 years javascript will still be here. But about TypeScript, I say this, alas, I can not.

THIS will happen sooner or later ...

Sooner or later, JavaScript will acquire type support. It's unavoidable. In truth, given the speed of JavaScript development lately, I am surprised that type support is not yet announced as a “stage-0 proposal”. The moment this happens, TypeScript will immediately turn into a pumpkin technical duty.

Note that TypeScript used to have its own syntax for working with modules. And then ES6 came out and now TypeScript developers suggest everyone to switch to a new syntax. Feel the pattern?

TypeScript here for a long time, so what?

TypeScript is available from 2012 !!! I believe that his popularity is entirely due to Angular2. For me personally, this is a red box.

Developed by non-community

I do not see a strong community involvement in the work on the specification, grammar, language. In the development of ES *, the influence of developers from around the world is much more noticeable. Perhaps I’m not looking there, but, IMHO, they need to listen to the developers, and not implement C # in JavaScript ?!

Square in round plug

Adding types to a non-typed language is a challenge in itself. According to my feelings, TypeScript puts types ahead of JavaScript. This leads to oddities when using native JavaScript features.

I am babel fanboy

Babel - *****! If you asked me a year ago if I would use a transpiler, I would consider you crazy. Sourcemap, gulp / grunt / watch / build / etc sounded like a nightmare to me. And then once - and hooked.

Babel uses amazing plugin architecture. I really like to use the latest stage-0 features. Yes, I spoke above about “non-standard features”, but what Babel suggests will soon appear in JavaScript in one form or another. All you need to do is fix the syntax using search and replace. Plus, the use of stage-0 features in real projects allows you to test them in practice and share the results with the developers of the language. Also pleased with the opportunity to compile the project for different platforms: nodejs 4 or 5, or for the browser.

TypeScript supports compilation only for ES3 / ES5 / ES6. At the same time, nodejs 5.x only partially supports ES6, so when using TypeScript we hang in an incomprehensible “intermediate state”. And if you compile in ES5, you get a lot of polyfills that are difficult to debug.

Three letters: TSD

TypeScript requires definitions for all source files used in the application. It sounds logical, right? He needs to know the types in order to be able to compile the code. But what will happen if you use a library that is not written in TypeScript (and such, just a second, the vast majority)? If this is a popular library, then TSD will most likely be written for it. And if not, then you will have to write it. Or replace all its global identifiers. More work, more headache, and nothing can be done about it.

What is in the box?

I like to use the latest features. So, starting to use TypeScript, I expected to see already familiar “stage-1” and “stage-0” things from ES6. I was disappointed - some of them are still missing. Because developers have big problems cramming them into a framework of a typed language (ellipsis, destructuring, etc.). However, something is still there, decorators, for example. And it makes me constantly stand against the walls - what can I use and what not. Basically, the TypeScript command adds only stage-3 features to the language.

Use types only where necessary

I think I heard it more than a hundred times. But these guys do not tell you that some information about the types will have to be added anyway. And this will result in a big handful of any , smeared all over your “old” code. What makes the migration to TypeScript in a difficult task.

What about FlowType?

Given my negative opinion expressed above, you probably think that I also do not like FlowType? Not guessed. It seems to me that the developers of FlowType put JavaScript at the forefront, neatly building on it types. For me, the use of this language is felt more natural. Plus - the compiler as a plug-in for Babel.

You will probably say that this is still a non-standard extension? Yes, but types will land sooner or later in javascript. But even if this does not happen, there is always a strip-flow-types plugin for Babel :)

The work of artist Sergey Korsun “Kashchey hides a duck into a hare”