August 27, 2021 by Faisal Alghurayri
It is ignorant to dismiss Node JS.
Moreover, I attribute the recent influx of developers, startups, and boot camps to Node JS. It is powerful to learn one language and build apps for the web, mobile, desktop, and even TVs and other devices.
It is beautiful to see the barrier to entry lowered by technology, so folks from different backgrounds can join and collaborate in building software.
In his talk about the design flaws of Node JS, Ryan Dahl, the creator of Node JS, highlighted his opinions, learnings, and regrets about the framework after it has been out for some time.
I want to draw one of his points to highlight why I, day after day, find it hard to recommend Node JS (even with TypeScript) to deliver maintainable, concurrent, and secure systems.
node_modules is a bloated folder
One of the best features of Node JS is the rich ecosystem of libraries.
However, when coupled with design flaws in resolving, securing, and integrating these dependencies, such abundance is a recipe for software that is harder to maintain.
All modules must be locally installed and live next to your source code to develop and ship applications. The result is wasted network traffic, bloated disks, and additional complexity when you patch a library to fit your needs.
Richard Feldman showing how insecure is npm install command is
Moreover, there’s a unique dilemma in Node JS around keeping
package.json up to date or not, especially when there is no process for vetting third-party dependencies.
On one hand, you want to keep your software updated to get the latest features, bug fixes, and security patches.
On the other hand, thanks to the natural complexity in software development and how modules can run arbitrary code in your computer and network, you can’t trust authors not introducing breaking changes or new security vulnerabilities.
Ryan Dahl built Deno with security in mind. For example, by default, third-party scripts will run without access to the file system or the network unless the user gives permission, vastly minimizing the attack vector.
Moreover, installing dependencies is as simple as pasting the URL of the library at the start of the file. A cached version will be saved into the machine and never updated unless the user specifically asks for it.
A couple of nice things in Deno compared to Node is the stories around developer experience and production deployment.
To deploy and launch your Deno app, you only need to ship a single executable file, which bundles your whole app. No need for the bloated
Deno on MDN
Moreover, one of the principles of Deno, since it started, is to follow web APIs whenever there’s an overlap. So, for example, you can use
window.localStorage in your server, like documented in MDN! Here is a post from the Deno team expanding on why that is important.
Here is a great video by Surma published a couple of days ago showcasing Deno.
With the increased maturity thanks to lessons learned in the Node ecosystem, all these reasons make me believe that Deno is becoming a more sensible alternative when developing TypeScript applications.
Finally, I think every technical professional should continually adopt strong loosely held opinions.. I built this blog using Node JS because it’s a simple personal app with one developer! :D
Take it easy,