Member-only story
What I Love (and Don’t Love) About Deno
The good, the not-so-great, and the undecided
In 2018, Ryan Dahl, founder of the Node runtime environment for JavaScript gave a talk at JSConf —10 Things I Regret About Node.js. It’s not often that you hear from the founder of a technology turned paradigm that he regrets some of the major features of his own invention. If you haven’t watched the talk, I highly recommend it. He highlights the deficiencies that exist in Node, some of which we, as developers, consider features.
In the talk, he also introduces Deno, a new runtime environment that uses V8 but is built in Rust. At the time, he called it his side project, because Ryan Dahl makes a hobby out of tinkering with entirely new runtime environments. Nevertheless, the introduction of Deno almost immediately spawned a thousand tech articles asking the question: will Deno replace Node?
The short answer is… maybe.
The Five Features I Love In Deno
I spent a long time in the Deno ecosystem while developing an open-source tool with a small team of engineers. We contributed to the community in part because we found it exciting. Our tool helps developers identify memory leaks in production-level applications. These are the kinds of tools that Node has had for years at this point. By the end of the first release, these were the features that stood out to me that Deno provides.
No package.json and No node_modules
Say goodbye to npm, package.json, and the bulky node_modules folder. If you’re a Node developer, you may be thinking — but aren’t those things features of Node? No, actually npm and package.json were created separate from Node to handle easily sharing application dependencies. In reality, node_modules caused a lot of problems.
For instance, if you write in full-stack JavaScript or TypeScript, say with React and Node, you may have node_modules folders installed all over your computer’s filesystem, many of which contain the exact same modules.
