Microsoft proposed their breaking plans for TypeScript
There are strict regulations on software and software updates. For security reasons, many companies work with outdated software or surf with outdated browsers. This is a fundamental problem that also affects HTML and CSS, as well as programming languages that have to be interpreted by the respective browser and are therefore dependent heavily.
Nothing happened in the browser for a long time, and that’s why the bundler came along with the transpiler. And although you are actually working with a JIT (Just-in-time) compiled programming language that could actually be executed normally, you always had to deal with a kinda complex build process that turned the source code into actual code, which was then executed and interpreted in the browser.
That was the situation about ten years ago.
Now, in the past ten years, the world has also evolved. Browsers that aren’t up to date and don’t update themselves are still not extinct, but they play a much, much smaller role today than they used to.
This means that a bundler is no longer absolutely necessary, at least from a technical point of view. A bundler is just another step towards optimizing the HTTP requests so that fewer small individual files have to be loaded from the server, only a few large ones. This is simple at the end of the day can be done much more efficiently. Something you might use in frameworks such as React.js or Vue.js.
This means that Microsoft or TypeScript suddenly turns from an extremely practical tool to a rather annoying thing. According to Microsoft, they don’t want to stand in the way of developers, they want to inspire them and of course, you don’t do that by standing in their way.
There is an npm package available for Node.js called ts-node, which takes a similar approach as Deno. Compiling into memory when building/loading the application so that it might feel like TypeScript runs immediately, but in fact, it doesn’t.
In addition, TypeScript has now also become a way more complex programming language, and it is not so desirable for Microsoft to directly integrate all the features of the TypeScript compiler into the common web browsers. That would be a very complex mission and would require the cooperation of Google, Mozilla, etc., to integrate a new big standard.
Microsoft shuns all this effort, whether rightly so or not, that’s an open question, but the statement is simply that’s not what they want to do.
JSDoc as a (Previous) Middle Way
You have to write more code, everything is kind of cumbersome, and more complex typing becomes almost impossible, but it’s still better than no types at all.
So Microsoft’s suggestion is to follow the same approach as JSDoc in TypeScript because then you wouldn’t have to compile TypeScript anymore.
The TypeScript compiler would thus only be an optional addon, like a linter such as ESLint and all type annotations would be invisible in the executed code.
And that’s why the proposal is called “Types as Comments.”
When I first read this, I liked the idea. But now I’ve thought about it a bit and read through the proposal over and over and I have to admit that I’m very skeptical. It sounds great in theory, but I see some downsides.
We shouldn’t forget that TypeScript does not only consist of primitive types of function parameters, we are talking about Interfaces, Union Types, Type Keyword, very complex and nested types, “as” Keyword, public/private/protected Keywords, generic types and so on.
And that has to be written as a comment in the future, besides the actual comments we already write. And I don’t want to say that this is impossible, but instead of having two types of comments (single-line and block comments), you have many different new types of comments to express keywords at once.
And so I have to ask myself if this is a good way to go, because actually, I like the current solution, even if it’s not perfect.
Furthermore, you will have to code without enums because they are a mix of values and types. This also includes namespaces, JSX support of TypeScript, parameter properties, and so on. So if you want to use enums, you have to compile, but if you don’t use enums, you don’t have to compile.
Do you get my point?
In any case, I’m curious to see how this will develop over the next couple of months and years.