When to Use TypeScript – A Detailed Guide Through Common Scenarios

> Paper does not tell you when something you draw is wrong.

With some things it does. At least better than your brain does. Typesystem does it even a bit better. But you end up with a picture not a program nonetheless, before you start writing implementation.

> What is no different from learning that something you implemented is wrong [...]

What is different is that with all the types you wrote, the process of problem discovery that happens during implementantion is stifled by what you wrote so far. Also you have additional temptation to contort your types and to leave it in a bad state because you wrote so much already and you'd very much want to avoid tossing that out.

My point is that you discover problem through experimentation and types make experimentation harder because they make the code in some ways harder to change. TypeScript avoids that by allowing you to use as much types as you want at any stage of problem/solution discovery but not forcing you to.

Recent Typescript convert here: I find Typescript a GREAT tool for those experimental projects. They are the ones that need constant refactoring as you build, which is where Typescript shines.

Babel's designed first and foremost with extensibility in mind. Of course an opinionated build tool with no extensibility to speak of (tsc), is going to be easier to set up and get started with than one that designed with extensibility as a core principle.

That doesn't mean one's necessarily fundamentally better or worse than the other, but the great thing about extensible tools is that they can often be used as building blocks for other more opinionated tools that abstracts away configuration details from the user by providing an opinionated set of defaults, and still offer the ability to customize when users' needs are not adequately met by the defaults.

Case in point - Parcel actually uses babel under the hood:

https://parceljs.org/javascript.html#default-babel-transform...

All it does is configures a default set of plugins & presets for you. You can override any and all compilation behavior Parcel provides by default simply by adding the appropriate babel config files.

TypeScript could have done the same with their build tooling, by extending babel with plugins/presets and providing the exact same set of functionality to users as what tsc's is capable of currently in terms of compilation features (which is currently afaik a strict subset of what babel + its plugin ecosystem is able to provide).

That would give users the exact same out-of-the-box experience as tsc does currently, and offer them the opportunity to extend compilation behavior with additional plugins and presets when the need arises.

That extending the compilation behavior of tsc, after so many years of development and wide adoption, is still not even on the roadmap right now is the core of my disappointment with them choosing to develop their own _non-extensible_ compilation tooling vs just extending babel, where they would have been able to offer extensibility for free from day 1.

Your remarks apply only to cranking out new code. Static typing prohibits making fundamental changes to an existing body of code, like changing a core, widely-used data structure. To make such a change, you have to be extremely sure that you want it and that you're doing it right. Then you can commit to the days and weeks of refactoring at the end of which you once again have a program you can run.

Under dynamic typing, you just do a small part of the job, yet the program builds; you can get in there and try things. Decisions about how to proceed can be guided by errors you run into when you step on the things broken by the partial refactoring. Seeing things working right away can be a motivator to get the whole thing done. Or it can help you see that, oops, the change is not worth doing or bad for whatever reason: you dodged a bullet with a small amount of sunk cost (the few changes you made that you can throw away without a whole lot of regret).

Static typing helps with small refactoring where the ripple effect is small. The compiler pinpoins things that have to change; they happen to be few in number, and don't have too many ripple effects of their own. If your change breaks everything, then it's moot; the compiler tells you there are breaking changes everywhere.

There is another angle: under dynamic typing, changes can be done in ways that things continue to work. You can write modules that have "absolute genericity": they work with objects of any type without being recompiled. Such things are bullet-proof against all conceivable refactoring.

Don't like pedantic attitude just because some recent paradigm matches that of a while ago. Back then, you don't know dynamic types won't be too welcomed.