Image by andreas160578
I recently find this wonderful post against TS: Why I hate TypeScript. I even write my own version of that, This is why I hate TypeScript, but seems like I ain't as funny as I though, and many people dislike it, some of them even got really angry because of that. Maybe it's worth to say the post didn't include the first disclaimer, and I temporally remove TS from my bio. However, I want to write properly about TS, and this is it.
Typescript is not standard
This is actually true. Typescript itself is not a standard, it's a superset of JavaScript. What means, that any valid program written in JavaScript is a valid program for the Typescript compiler. Also, Typescript will try to follow any valid standard in the ECMAScript spec, that is the stage 3 or higher.
Sure, when TS was first created designers took their chances and implement their own kind of modules, now named namespaces, and their own kind of public and private members and properties, and several other things. But that was almost 5 years ago. That's a life time in web development. Almost the same time as Node 0.12 was released. Does any one remember the problems with that Node?
With the same release TS introduce decorators, that is an actual proposal for the TC39. When they were introduce, decorators were at stage 1, and the suffer a major spec rewrite from that stage to the next. So, the implementation that TS has of decorators is now a legacy one that is never going to make it.
They now have the requirement for a proposal to be in stage 3 to be implement, and this is just to avoid that kind of situations when the implementation in TS is different from the final spec, as when a proposal is in stage 3 the spec can't change.
I will give the example of two proposals that I've been followed since they first reach stage 1.
- Nullish Coalescing Typescript Issue #26578
- Optional Chaining Typescript Issue #16
Both are expected to be introduced in Typescript in version 3.7, just months after they finally reached stage 3.
No, Typescript is not a standard, but it does however, follow the JavaScript spec has best as they can, introducing with every version support for new features in JS.
Not community driven
This one is the one I could find more controversial. I know it's not strictly a community group those whom decide where TS is going, but the TS team takes really serious community feedback, and many of the features they developed are based on that. Also, I consider the roadmap of Typescript to be clear and consistent, most of the time. They even move from a 2 months release cycle to a 3 months release cycle, after getting feedback from the community that we would like more stable versions of TS, even if that means fewer versions.
The TS takes the community feedback with great responsibility and they have probe they listed for features and improvements.
Types in a non-typed language is hard
I would like to extract here an argument about that statement:
It probably doesn't help that the main people that wrote this weren't big JavaScripters before they started but thats just my personal thought.
How does he know that? I don't know. Please, if you do know the people behind TS, please, I would like to meet them too.
There is not such thing as a non-typed language. All languages have a typing system. What he means is having a strict type language in a dynamic typing language. But, even if it is what he means, Typescript only adds optional static typing. And the optional part is really important. However, I don't think someone would use TS as a transcompiler only, but they could. Also, understanding static typing is also important. There is not, and there will be not, a strict type checker, as it would require a runtime type checker and that's a Non-goal for the TS team.
If you read the list of goals, and non-goals, you will be surprise how the TS is willing to make the static typing work. They don't want soundness, but instead strike a balance between correctness and productivity. Personally, I think this is where TS really shines.
The static typing system used by the Typescript compiler maybe hard to understand, but it's not hard to implement. Even then, we shouldn't care that much about it's implementation, as for us most of the time it would just work.
Babel is way better
Babel doesn't have any type checking system, so it's really a different thing. When comparing transpilation between Babel and TS, I like TS better, but I won't use that either, so I don't think it's really important.
If you consider Babel better because it's plugin system, the plugin system is mostly used to implement new proposals into the transpiler. And as we see, that's not always a good thing. You should always use proposals in stage 3 or higher in production.
There are different tools, with different goals, so I don't think one is better than the other. Both have their use cases. Babel 7 can transpile TS source code, and TS can transpile JS source since 1.8, however, Babel won't type check TS source code, and TS can type check JS source code, if it have type annotations.
TypeScript Definitions
You now have automatic type acquisition in the Typescript server, so if you have an IDE that relies on the TS server, it can use that to improve your coding experience. However, that only applies on JS files. For TS files, you still need to install the type definition, but most of the time TS would tell you the module you would need to install to make it work, and it's likely to be the same package you are using with the @types/ prefix. So, no typings, or anything else to be installed. They are now plain npm modules.
Typescript Definitions acquisition have improve since the introduction of
@types/scoped packages.
No idea what language features I can use
As I already said, JS proposals in stage 3 or higher are likely to have been implemented already, or be in the roadmap to be implemented. Other early proposals could have been implemented, but the implementation is likely to be different to the current spec, as in the case of decorators. However, in order to use such features, you would need to add an explicit setting in for the Typescript compiler.
You are probably safe using features in stage 3 or higher. If you can't use it yet, there is nothing to do about it. (Type safely speaking).
They lie
So, I don't really know what the author point in this one. I have to say, you can really put as little or as much as you like, if you know how to configure the options for the compiler. If you don't, the compiler by default will have some strict settings turned on, that in most cases are to help you.
If you find yourself writing any anywhere, I don't think the problem is TS. You should consider to avoid the usage of any by using static linters, such as TSLint. Instead, you could use unknow, that is the type safe equivalent of any, or better yet, just expend sometime expressing better the intended usage of the object.
What about flow?
While Flow is an outstanding project, and I have to say that several ideas Flow introduced was latter introduced in TS as well, I think the best argument of Flow vs Typescript is the usage, Typescript usage is improving while Flow is reducing.
I do have my own opinion about TS vs Flow, and that is when you are writing TS, you know you are just by looking at the file extension. But Flow is just like a static plugin on top of regular JS. However, TS have some features that Flow lacks, and likewise. If you want a better comparation between them, check Typescript vs Flowtype.
That covered the arguments of the main writer, but if you look the comment section, it have several others against TS.
Is JavaScript for people who know Java and C
I don't think TS have been made as JS for programmers that are used to working with Java or C#, but sure they find in TS an alternative of the complicated concepts in JS. What they don't know, and I would really like to give an emphasis on this:
Typescript is not a strict language, and only if you really understand JS you will take all the advantage of using TS. Else, you are just playing in the edge of a really high climb, and sooner or latter you will fall.
If you want to learn Typescript, learn JavaScript first. Then, you will be able to tell that is actually TS doing for you. SPOILER: It's not magic. Sorry.
Will last as long as Angular lasts
That maybe true. But, you should really consider to expand your confort zone. TS is now being using by several projects, including Vue, Nest, and even Jest was migrated from Flow to Typescript this year.
Have ESLint to catch type errors, and PropTypes to catch type errors at runtime
I won't say you can't create a considerable good type checking system with ESLint, but if you does, then you are admitting you need a static type checking system, and also you are creating your own version of it. The same if you use PropTypes. Funny story, I worked in a project using PropTypes to Typescript, even when the React support for Typescript was not great by then, it was an incredible improvement in developing time.
There are others. I'm sure there are, and I'm sure there will be others as well. However, I just wanted to explain in the right way what taking those arguments as the absolute true is plain wrong.
Typescript is to help you
As any other tool in the large JS ecosystem. You have several other tools to help yourself to improve coding experience. If are just complaining about what TS can't do, instead of seeking what TS can do for you, I don't think that's TS issue in the first place. If you are trying to do one thing with TS, and you found yourself that you can't even do it in JS, but you think TS will do better, idem, not TS fault.
Don't just hate something because you don't understand it, or you underestimate it. Instead take time to really learn how a static type system can help your team to improve the coding experience.
Top comments (2)
This is IMO also a point of view often exacerbated by the misconception that "TypeScript only works for Angular", or even "TypeScript is built for Angular".
In reality, TypeScript had existed years before Angular 2 came out. In fact, earlier versions of Angular depend on AtScript, a superset of TypeScript which adds decorators, which became baked in with TypeScript when initial proposals for decorators were released.
Despite that, TypeScript also works on all of the major frameworks, with Vue (as you mentioned) and React, and the TS team really have been working hard on making TS better support them over the past few years. I'd even argue that the React developer experience in TS to be even better than the Angular DX in TS. Adding support for JSX in TS was really the tipping point that started the whole adoption train going.
Love your post(s), by the way!
Thanks! :)