JavaScript runtime Deno 2.0: Is the new version the better Node.js?!

We’ve been publishing a new video on my company’s YouTube channel almost every week for over four years, and over time I’ve given one or two opinions on one technology or another. I don’t do this lightly, but rather think intensively in advance about which technologies might work in the future and which ones might not, what the market will respond to and what it probably won’t, and so on. Without wanting to praise myself, I would say that I have a decent knack for recognizing future trends and developments at an early stage and predicting them accordingly. Nevertheless, of course I am occasionally wrong.

Advertisement

On the one hand, this can happen if, despite all my care, I make a misjudgment because, for example, I didn’t see an important aspect. But this can also happen because some technologies change so much over time that I actually have to re-evaluate them after a while and possibly revise my previous opinion. And that’s exactly the case today: Today we have to talk about the newly released version 2 of Deno.

Lots of show, little content

Anyone who has been following our videos for a while knows that the first Deno videos were almost exactly four years ago to the day. The starting point was Ryan Dahl’s talk at JSConf EU 2018 entitled “Ten Things I Regret About Node.js”. I made my first assessment of this at the time: Unlike many others, I didn’t find much to gain from his argument. Nothing has changed to this day: to be honest, I found his presentation to be weak in terms of content and the arguments mentioned were poor.

Deno’s announcement at the time seemed extremely exaggerated to me. Yes, there were one or two interesting aspects, like the consistent use of the V8 sandbox, but there were enough points that were already outdated, irrelevant or simply not thought through at the time. I have often criticized the way Ryan Dahl behaved: If he was really interested in making the world a better place for JavaScript developers, he should (in my opinion) have gotten involved in Node.js again instead of The JavaScript ecosystem now also needs to be fragmented on the server.

In addition, all the feigned remorse seemed to me like an excuse to build a company in the background – which is of course completely legitimate, but wasn’t communicated transparently enough for my taste. Overall, the lecture was too pathetic for me, too much drama, too much show and too few real arguments. In short: I thought Deno was mostly hot air at the time.

Quickly there, quickly gone again

Well, what can I say? Since it was announced six years ago, Deno has been a flop. Yes, it certainly had a certain influence on the further development of Node.js, but it was probably manageable. However, in return, Deno initiated the fragmentation of JavaScript on the server, which has since gotten worse with Bun. Speaking of Bun: You don’t hear anything about it outside of a very small and manageable community, and here too there is too much showmanship and not enough delivery for me. So far, for me, Deno remains a lot of show, a lot of talk, little substance and above all one thing – unnecessary.

The interesting thing is that a lot of what Ryan Dahl announced at the time ultimately turned out to be not a particularly smart idea, such as his big criticism of the supposedly oh-so “evil” package.json-File in which the dependencies are managed in Node.js. What hasn’t been said about what’s bad about npm, why it’s all a fundamental design flaw, and so on. All of this had to be done better (and “better” meant something different). It turns out: npm is certainly not perfect, but it is worlds better than Ryan Dahl made it out to be. All the approaches Deno has tried since then to manage dependencies differently have ended up with only one thing: incompatibility and – ironically – new problems.

Because at some point the team behind Deno realized that it wasn’t a good idea to completely ignore and exclude the existing JavaScript ecosystem, Deno did a U-turn and integrated provisional support for npm. And suddenly Deno was no longer a completely isolated solution, but you could at least work with it a little. Everything doesn’t work. That’s why the compatibility with npm and, incidentally, also with Node.js was gradually expanded, because it was noticed that the switch is unattractive if practically all basic APIs are missing, they are called differently or work differently.

Deno 2 makes everything new

Deno has also gradually turned away from many of his supposed ideals and is now trying to support 90 percent of everything that was supposedly so bad and flawed. This culminated in the release of Deno 2.0 in early October.

That was reason enough for me to re-examine my opinion. And I have to say, I have to revise a few things: Deno 2 is the first version of Deno that Really What’s interesting is that it finally represents more than just an academic exercise, and offers a lot of interesting points that could position it as a possible replacement for Node.js. The timing for this is actually good, because problems are piling up with Node.js: It is developing further, but there are too many construction sites that have already begun and it is becoming more and more chaotic. That’s why the title of one of our videos around six months ago was: “Node 22, let’s stay friends”. In plain English: I don’t want to be in a relationship with you anymore, I’m breaking up!

And that’s where Deno 2 comes into play. What’s special about Deno 2 is that the team behind it has put a lot of effort into overcoming the lack of compatibility with Node.js and npm. As of Deno 2, it is now possible to use Deno as a true drop-in replacement. The promise is: Everything that runs in Node.js also runs in Deno. This applies to small and large applications and includes many frameworks such as Next.js, Astro, Remix, Angular, SvelteKit and more – everything runs out of the box. But Deno has not simply become a 1:1 copy of Node.js, but in a certain sense is now “the better Node”.

Deno compared to Node.js

Because Deno brings (and not just since version 2) a number of features that Node.js can only dream of: native TypeScript support (which is now available in Node.js, but it is still very rudimentary), a built-in formatter , an integrated linter, a type checker, a test framework, a compiler, a sensible security concept in which not every code from the Internet runs with full trust without being asked, and so on. Node.js has been missing all of this for 15 years now. And the whole thing is implemented very quickly and thoughtfully in Deno.

An example: In Deno, TypeScript code does not have to be compiled by hand; Deno does this automatically as soon as the application is started. However, for performance reasons, TypeScript type checking is omitted unless it is explicitly specified with the parameter –check demanded. However, when running tests, type checking is enabled by default. This results in: During development, when the last bit of performance is not important, you have the desired type security, while during execution you have the best possible performance. And the nice thing is that the testing framework is already included in Deno, so nothing additional needs to be installed.

Node.js also offers some aspects of this, but it took a long time and it doesn’t come close to Deno in terms of scope or integration. And Deno doesn’t end there: The testing framework, for example, goes much further than Node’s, because Deno can also directly calculate code coverage, run benchmarks and more.

Simplicity in the foreground

All of these functions for running tests, determining code coverage and performing benchmarks are natively included in the Deno binary. You only need one tool to use all of these things. In addition, a formatter is also integrated, which not only formats JavaScript and TypeScript, but also HTML, CSS and YAML. A comprehensive linter is also included, an integrated solution for executing tasks, a documentation generator and a compiler to generate real binaries. The latter is theoretically possible with Node.js, but the solution is so complicated that it is absolutely no fun to use the feature.

Deno also includes a web server, support for Jupyter notebooks and much more – all in a unified and coordinated form, whereas with Node you have to collect everything and configure it by hand. And in the end, that’s what makes Deno 2 stand out: simple and “it just works”.

For example, if you have an application that uses npm modules, you no longer have to run “npm install” with Deno. Deno automatically downloads the required module when you first start the application and saves it locally. It works so well and transparently in the background that after half an hour of developing, you’ll forget that you ever had to run npm install and deal with a node_modules directory or lock file. And it all happens incredibly quickly – every package manager I’ve seen so far using Node.js can compare. This is solved really well, and that’s the impression that Deno 2 leaves: It looks like Node.js, but rethought.

Deno is like Node, just rethought

Maybe Deno 1 has been just a proof of concept for the past six years: an unpretty but necessary prototype to find out where the journey should actually go, and Deno 2 is now the real first version.

And I honestly have to express my respect, because Deno 2 is a very successful second version. Suddenly it’s fun to develop with TypeScript again because you don’t have to install and configure a hundred different things, you just open an editor, write a few lines and execute them. And formatted. And tested. And so forth. And all of this without even having to install anything.

Compared to how Node.js currently feels, this is a big step forward. It finally feels modern and contemporary again. And in this respect I have to say: As soon as the right runtime environment is there, TypeScript suddenly becomes a lot of fun again. Thanks, Deno2!

(rme)