Using Alternative Runtimes

So far, you’ve seen what advantages and benefits the Node.js ecosystem offers to create great web applications. However, as with almost everything, there are a few downsides to the design decisions forming what we refer to as Node.js.

One of the biggest challenges in Node.js is the so-called dependency hell – where many small packages are put together to create a slightly larger package. Another challenge is that Node.js is not guarding any of these dependencies from accessing system resources. As such, importing anything from a third-party package may have unwanted side effects.

While ecosystem reliability and security can help us guard against dependency hell, improving performance is also an important strategy. Overall, the performance of Node.js can be regarded as decent; however, certain areas such as package resolution or processor core utilization could be improved by a fair share. Hence, performance is another area that could be...

Technical requirements

The complete source code for this chapter is available at https://github.com/PacktPublishing/Modern-Frontend-Development-with-Node.js/tree/main/Chapter11.

The CiA videos for this chapter can be accessed at https://bit.ly/3Uqi9aq.

Exploring the Deno runtime

While Node.js is a tremendous success story, not everyone is a fan. Some critics say that the huge fragmentation combined with the lack of system controls offers too great an attack surface. In the past, we’ve seen countless attacks that have abused the vulnerabilities introduced by exactly this problem.

Another issue is that Node.js did have to invent a lot of APIs – for example, to interact with the filesystem. There was no API available in the browser that looked similar to what was desired. Of course, as we now know, the browser APIs kept improving and even things such as filesystem access are implemented there. However, the APIs never aligned, mostly because the variants for Node.js are neither controllable nor fully asynchronous.

Surely, the aforementioned problems were all known for a while, but it took several years until an alternative implementation to solve these issues appeared. Again, it was Ryan Dahl – the original...

Using Bun for bundling web apps

While Deno seems quite different from Node.js on first glance, it also offers a lot of similarities. After all, both runtimes use V8 and can work with ESMs, but what if you want to be even more compatible with Node.js? Another approach is to be Node.js-compatible without using libuv or V8 at all. Enter Bun.

Bun is an alternative to Node.js that follows the approach of Deno in terms of developer friendliness. Here, tooling such as a npm client or an application bundler is also included out of the box. However, to speed things up significantly, Bun does not use libuv and V8. Instead, Bun is created using the programming language Zig and uses JavaScriptCore as its JavaScript runtime. JavaScriptCore is also the runtime behind the Webkit browser engine, empowering browsers such as Safari.

The main benefits of Bun are as follows:

• It comes with useful utilities out of the box, such as a bundler, a transpiler, a package manager, and a task runner...

Summary

In this chapter, you learned why alternatives to Node.js exists and what the most popular options are. You’ve explored what Deno is all about and how it distinguishes itself from Node.js. You’ve also seen an up-and-coming alternative with Bun.

Equipped with this knowledge, you are not only capable of writing tools that might be able to run in other runtimes than Node.js but you are also capable of deciding where your existing tools should run. Overall, this does not constrain you to the disadvantages of Node.js and gives you freedom to make the right choice aligned with the problem you want to solve.

Epilogue

In general, it makes sense to view Node.js as a great helper for getting the job done. The whole ecosystem – from its module system to its command-line utilities and from its libraries to its frameworks – is vast. Almost every problem has been cracked and a solution has been published.

I hope that with this book, you have a proper guide to walk you through the jungle of available helpers, making you not only a more efficient user of Node.js but also a contributor. While the existing tools are all helpful and powerful, they are certainly not the end of the line. Everyone has a unique view and things progress all the time. Don’t wait for somebody else to solve a problem – tackle it yourself and share your solution.

All the best!