Node.js + TypeScript = No More JavaScript

“No more JavaScript!”

Advertisement

.NET 9.0 Preview 7 brings AOT compilation for SignalR services

I have heard this phrase over and over again over the past fifteen years of working with Node.js. The list of accusations was long: JavaScript is not a real programming language. JavaScript is not suitable for complex projects in the enterprise sector. JavaScript is not this, JavaScript is not that. Of course, in fifteen years you will find some people who like JavaScript, but most developers reject JavaScript outright. Many people write it out of necessity, not out of conviction. Javascript is weirdThis is still a widespread opinion. If you agree, I have really good news for you today: it’s over, you’ll never have to write JavaScript again!

Maybe you are saying:

“Well, actually that’s not entirely true, because even today I don’t necessarily need to write JavaScript. After all, there’s TypeScript.”

And it’s true. Since Microsoft released TypeScript twelve years ago, it has practically become the de facto language in modern web development. And this is no coincidence, because TypeScript does a lot of things right: starting from a very good and well-thought-out optional static type system to a very reliable compiler. Many developers can no longer imagine their everyday work without TypeScript. If it weren’t for the tools, because where there is light, there is also shadow.

I know from personal experience that there are far more fun things to do than setting up a Node.js project with TypeScript. It’s not just a matter of installing and configuring TypeScript, but also everything around it that should work with TypeScript: from code formatting to linting to testing. It takes a lot of time to configure all the building blocks so that everything fits together and works in harmony with each other.

Why doesn’t Node.js support TypeScript natively?

I’m sure I’m not the only person who has asked themselves repeatedly over the past twelve years why Node.js isn’t TypeScript native Supports. Why do you as a developer in the Node universe always have to do this extremely annoying egg dance until TypeScript finally works the way it should? Wouldn’t it be a lot easier if Node.js natively supported TypeScript? Then you could save yourself the whole compiler, tests would work automatically with TypeScript, and all other tooling would probably be replaced quickly. Because once TypeScript worked properly in the fundamentals, the rest would probably work quickly. So: wouldn’t it be amazing if Node.js natively supported TypeScript? Wouldn’t that be a huge step forward?

And this brings us to the promised big news: starting in July 2024, Node.js includes native support for TypeScript!

Because many people are now probably curious to know how it works and, above all, how Good It works, I have some answers. First of all: support for TypeScript is still experimental, it is only available in nightly builds, and you need to specify an appropriate flag when starting Node.js, i.e. --experimental-strip-types.The whole thing will definitely be included in a regular release soon and maybe even in Node.js 23, which is expected to come out in October.

How type stripping works

The implementation is initially quite simple: type annotations in the code are simply removed at runtime. This means that no type checking takes place. This was a conscious decision by the Node team. If you want type checking, you still need the TypeScript compiler. So it will be the same with Node.js in the future Deno and Bun. In fact, this is no coincidence, because under the hood, Node.js uses the same mechanism as Deno for type stripping.

By the way, this type stripping should be taken literally: the code is not transformed, only the type annotations are removed. So everything that would theoretically convert from TypeScript to JavaScript to work will not work currently. These include features like enums or namespaces. This means that there is currently no full support for TypeScript. But one should not forget that we are still talking about a very early stage of development and a lot can change over time. But I will get to that in a moment.

Technically the whole thing is based on npm modules @swc/wasm-typescript.SWC is a Speedy Web CompilerWritten in Rust and therefore fast. The NPM module in question includes SWC’s TypeScript parser, not (as you might expect) as Rust code, but as WebAssembly code. This way, Node.js can easily run the whole thing without having to install Rust on the respective system. Personally, I think this is a very clever solution. And exactly the same mechanism is in Deno as well.

The way of the future

For the first version you will have to live with some limitations such as the lack of support for some language features. The files must also have the file extension .ts wear it, they are not allowed to .js be named. Additionally, TypeScript is only supported in your own project’s code, not in node_modulesThey wanted to prevent developers from simply publishing npm modules as pure TypeScript applications, which would destroy backward compatibility. So you still have to compile when publishing a module. By the way, I find it exciting that even after type stripping, errors can be specified at runtime with the correct line and column numbers in the source code. This might indicate that source maps are also supported – but the solution is actually very simple: with type stripping, type annotations are simply overwritten with spaces so that all state in the source code is kept intact.

In the near future, type stripping will be separated from Node.js so that you don’t have to depend on a specific Node version with a specific TypeScript version. You want to arrive at a model like npm, which is included with Node.js but can be updated independently. One challenge is that you want to install TypeScript per project, not globally, system-wide. How this will be resolved is still unclear. However there is already an npm module called Amarothat serves as a cover @swc/wasm-typescript tasks. However, the documentation for this module currently states that it must be installed globally. So this is all still in its early stages and will take time.

Once a solution is found at some point, steps three and four of the roadmap are followed: First, performance is improved and communication between Node and the TypeScript compiler is made more efficient. Finally, step four is about new features. Only then can it be expected that further language features will be supported by TypeScript that go beyond pure type stripping. One feature that should be included is support for tsconfig.json.I find it amazing that it took so long for all of these things to happen. But that’s OK: it is what it is.

Restrained pleasure

Overall, I have to admit that I am pleasantly surprised that this feature has now found its way into Node.js. Deno and Bun have gained a significant lead in recent years, which is now diminishing rapidly. I have always had a lot to criticize about the last few versions of Node.js, but this is a huge step in the right direction. Even if I am not happy with all the details, in principle it is still an excellent step. I just hope that this topic does not become as dirty as other topics, such as this one Single executable applicationwhich were introduced with Node 19.7. Or using V8’s own sandbox, To improve security for downloaded modulesWhich was based on Deno’s sandbox-based security model. However, nothing has happened since Node 20.

So I am positively surprised, but my enthusiasm is limited at the moment because I have doubts about how much of the announced roadmap will actually be implemented and, above all, when. Because it’s good when Deno and Bun make sure that a breath of fresh air comes to Node.js again. However, it’s only good as long as the features are actually implemented and do not remain as an unfinished construction site. I’m still a bit cautious. But: the future will show what the Node team will publish in version 23, for example in October. Until then we have to be patient and allow ourselves to be surprised.

(RME)