JavaScript Runtime Deno 2.0: Is the New Version Better Node.js?!

We’ve been publishing a new video almost every week for the last four years my company’s youtube channelAnd over time I have also given one or two assessments of some technology or the other. I don’t do this lightly, but think carefully in advance about which technologies may work in the future and which may not, what the market will respond to and what it will not, etc. Without praising myself, I would say that I have a good ability to recognize future trends and developments at an early stage and make predictions accordingly. Still, of course I’m sometimes wrong.

Advertisement

On the one hand, this can happen when, despite all my caution, I make a wrong decision because, for example, I did not see an important aspect. But it may also be because some technologies change so much over time that I really have to reevaluate them after a while and possibly revise my previous opinion. And that’s exactly the situation today: today we have to talk about the newly published Deno’s version 2 Speak.

a lot of show, less content

Anyone who has been following our videos for a while knows that the first Deno video was exactly four years ago today. The starting point was Ryan Dahl’s talk at JSConf EU 2018 with the title “Ten things I regret about Node.js“. That’s what I did then an initial assessment Present: Unlike many others, I couldn’t glean much from his argument. Nothing has changed till date: To be honest, I found his presentation weak in content and the arguments outlined were also poor.

JavaScript Runtime Deno 2.0: Is the New Version Better Node.js?!

At the time, Deno’s announcement seemed highly exaggerated to me. Yes, there were one or two interesting aspects, like the frequent use of the V8 sandbox, but there were many points that were already outdated, irrelevant or simply not considered at the time. I’ve often criticized Ryan Dahl’s behavior: if he was truly interested in making the world a better place for JavaScript developers, he should (in my opinion) have re-tooled Node.js instead of fragmenting the JavaScript ecosystem. Should have joined. Server too.

Furthermore, the whole ostensible remorse seemed to me like an excuse to build a company in the background – which is of course completely legitimate, but was not communicated transparently enough to interest me. Overall, the lecture was pretty miserable for me, too much drama, too much pretense and too little actual argument. In short: I thought Deno was mostly hot air at the time.

quickly there, quickly gone again

Well, what can I say? Deno has been a flop since its announcement six years ago. Yes, it definitely had a certain impact on the further development of Node.js, but it was probably manageable. However, in return, Deno has Fragmentation of JavaScript on the server Started, which has now become worse with the bun. Speaking of the bun: you don’t hear anything about it outside of a very small and manageable community, and even here there’s too much pretentiousness and too little delivery for me. So far, for me, Deno remains a lot of pretense, a lot of talk, very little substance and one thing above all – unnecessary.

Interestingly, what Ryan Dahl announced at the time ultimately wasn’t a particularly smart idea, like his big criticism of the supposedly extremely Wicked package.json-file in which dependencies are managed in Node.js. What isn’t said about what’s bad about npm, why it’s all a fundamental design flaw, etc. Now we have to do everything better (and “better” means something different). Turns out: npm is definitely not perfect, but it’s far better than Ryan Dahl portrayed it. Every approach Deno has tried since then to manage dependencies differently has resulted in the same thing: incompatibilities and – ironically – new problems.

Because at some point the team behind Deno realized that completely ignoring and excluding the existing JavaScript ecosystem was not a good idea, 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. Still, many things did not work. That is why compatibility with npm and Node.js was gradually expanded, because it was seen that the switch is unattractive if practically all the basic APIs are missing, have different names or perform different functions.

Deno 2 makes everything new

So Danno has slowly 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 with the release of Deno 2.0 in early October.

This was reason enough for me to re-examine my opinion. And I have to say, I would have to modify a few things: Deno 2 is the first version of Deno In fact Interesting because it ultimately represents much more than just an academic exercise, and offers a lot of interesting points that make it more relevant to Node.js. Could establish as a possible replacement for. The timing is really good for this, because the problems with Node.js are increasing: it is being developed further, but there are a lot of construction sites that have started and it is becoming more and more chaotic. That’s why one of our videos about six months ago was titled: “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 this is where the Deno 2 comes into play. What’s special about Deno 2 is that the team behind it has put a lot of effort into addressing 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: whatever runs in Node.js also runs in Deno. It applies to small and large applications and includes multiple frameworks like Next.js, Astro, Remix, Angular, SwellKit and more – everything runs out of the box. But Deno has not just become a 1:1 copy of Node.js, but in a certain sense is now “better Node”.

Deno compared to Node.js

Because Deno (and not only since version 2) brings many features that Node.js can only dream of: native TypeScript support (which is now available in Node.js, but it’s still very rudimentary), a Built-in formatter, an integrated linter, a type checker, a testing framework, a compiler, a sensible security concept in which all code from the Internet does not run with full trust without asking, etc. This is all that has been missing from Node.js for the last 15 years. And the whole thing is implemented very quickly and thoughtfully in Deno.

An example: In Deno, TypeScript code doesn’t need to be compiled by hand; Deno does this automatically as soon as the application starts. However, for performance reasons, TypeScript type checking is skipped unless it is explicitly specified with a parameter. –check the requested. However, when executing a test, type checking is active by default. This makes sense: during development, when the last bit of performance doesn’t matter, you have the desired type of security, while during execution you get the best possible performance. And the good thing is that the testing framework is already included in Deno, so there is no need to install anything additional.

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

simplicity in the foreground

All these functions of running tests, determining code coverage, and executing benchmarks are natively included in the Deno binary. So to use all these things you only need one device. In addition, a formatter is also integrated, which formats not only JavaScript and TypeScript, but also HTML, CSS, and YAML. Also includes a comprehensive linter, an integrated solution to execute tasks, a document generator, and a compiler to generate the actual binaries. The latter is with Node.js Although also possible in principleBut the solution is so complicated that using this feature is no fun at all.

Deno includes a web server, support for Jupyter Notebooks, and more – all in a uniform and coordinated form, whereas with Node you have to painstakingly find everything and configure it by hand. And in the end, that’s what makes Deno 2 different: simplicity and “it just works”.

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

Deno is like Node, just reimagined

The Deno 1 may have been merely a proof of concept for the last six years: a beautiful but necessary prototype to figure out where the journey should actually go, and the Deno 2 is now the real first version.

And I have to express my respect sincerely, because Deno 2 is a very successful second version. Developing with TypeScript suddenly becomes fun again because you don’t have to install and configure hundreds of different things, you just open an editor, write a few lines and execute them. And formatted. And testing. etc. And all this without installing anything.

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

(rme)