How Microsoft Wants to Destroy TypeScript

Microsoft proposed their breaking plans for TypeScript

Photo by Matthew Manuel on Unsplash

Last Wednesday, on 9th March 2022, Microsoft published a remarkable proposal for the further development of JavaScript and TypeScript, which shook the programming language to its foundation almost overnight.

So far, this is only a suggestion that is available as a so-called Stage 0 proposal, but Microsoft has already announced that they want to submit this proposal to the TC39 Committee in a timely manner. If this proposal is actually taken up and implemented, then it is by far the biggest upheaval that has ever occurred in JavaScript.

If we look back 20 years and compare the web development of now and then, it is noticeable that although JavaScript as a programming language has developed quite a bit, much greater progress has taken place in the ecosystem around the programming language.

These two points are required mutually because, on the one hand, the JavaScript community has become much more professional over the past two decades, and on the other hand, a fundamental problem of the internet is becoming increasingly important. As a developer, you have no control over what browsers are going to be used by the users.

That means you can only use new features of JavaScript if the user updates their browser regularly. This is probably the case for an individual by now since many browsers these days update themselves or indicate an update without being asked, but this is not the case in companies.

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.

As a web developer, you have faced the problem of having to decide between two ideologies: either you rely on modern JavaScript, CSS, or HTML features that simplify programming or lead to better results in usability and so on, or you go without these modern features because they aren’t available to everyone because of an updated browser. Upgrading could cause bugs for a certain amount of users.

Also, quite apart from that, there hasn’t been a decent module system for JavaScript for decades. Node.js got its own standard with CommonJS, but that was only limited to the server.

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.

Photo by Nate Grant on Unsplash

At this point, exactly ten years ago, Microsoft invented TypeScript. Microsoft figured that if you need a transpiler anyway to convert the JavaScript code before deployment, an additional step in this build process wouldn’t be a big deal anyway.

In return, you get a good transpiler that converts modern JavaScript into vanilla JavaScript. Also, TypeScript was a static type system that made JavaScript much more scalable, shipped new concepts, and made a significant contribution to being able to develop JavaScript efficiency in a team.

It is no wonder that TypeScript has established itself very quickly and has become the standard for enterprise JavaScript development today.

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 it is now quite possible to work without a transpiler if you only address the Evergreen Browsers, and with ESM (ECMAScript 2015 Modules), there is now also a native JavaScript-based module system available that works on both the server-side and client-side.

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 the build process will gradually become simpler or more irrelevant. Microsoft now expects a future where the only remaining necessary tool is the TypeScript compiler because web browsers and other JavaScript runtime environments just don’t understand TypeScript, only JavaScript.

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.

To break it down to the result Microsoft feared, sooner or later JavaScript development could actually be as fast, direct, and efficient as it was 20 years ago because sooner or later transpilers, etc., would no longer be needed if TypeScript were not used .

Now an obvious way to go would be to demand the integration of TypeScript as an alternative programming language to JavaScript in the web browser and other runtime environments. Theoretically, that’s not so far-fetched. Deno is already trying to do that in a certain 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

Instead, a different approach has now been considered, and this brings us finally to the suggestion made by Microsoft last week. Everyone who is familiar with TypeScript knows that there is a middle way between the approach of (a) writing vanilla JavaScript and, on the other hand, (b) completely switching to TypeScript.

TypeScript allows you to analyze code on JavaScript and you can even store types there without having to write TypeScript by simply writing appropriate JSDoc comments. For some companies, this is the way to get type support from the TypeScript compiler without having to migrate projects completely to TypeScript.

The big advantage is that the code, because it is still pure classic JavaScript, on the one hand, does not have to be compiled and that it is also very easy to turn away from TypeScript at any time by simply deleting all JSDoc comments. I’ve worked with JSDoc myself, but I have to say that it feels more like a cheap alternative to TypeScript.

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.

Type annotations and keywords (such as “public” or “private”) would just be defined as comments that would be ignored during JavaScript execution. That means you could write TypeScript without needing to compile your TypeScript into JavaScript code.

However, you could still use the TypeScript compiler to trigger a type check, but you wouldn’t have to compile the code to run it. The so-called “d.ts” files would then no longer be necessary since the types would then be available in the JavaScript code.

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.”

Photo by Wes Hicks on Unsplash

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?

I don’t see a real separation between JavaScript and TypeScript with this suggestion. And I have serious doubts if this should be the future of TypeScript. In my opinion, this will lead to confusion and a new two-tier society of TypeScript developers.

In my opinion, TypeScript should either remain completely self-contained even if you have to compile it, or JavaScript gets an optional static type system, as TypeScript does.

This means that TypeScript should become the new JavaScript, but Microsoft has already ruled that out. Therefore, I come to the conclusion that TypeScript should not be fundamentally changed in this way, especially not in the way it is currently proposed by Microsoft.

In any case, I’m curious to see how this will develop over the next couple of months and years.


Leave a Comment