Article summary
For as long as I’ve been doing software development, NodeJS has been the dominant JavaScript runtime environment. In 2018, Ryan Dahl, the creator of Node, started releasing an alternative called Deno.
He gave this talk as JSConf where he unveiled features of the new runtime. He described 10 things he regrets about Node and essentially explained how he’s addressed them in Deno.
Side note: whether you care about Deno or not, I’d highly recommend his talk. I found it helpful to think about what could be different about Node.
Deno does a lot of interesting things like loading modules with URLs, supporting TypeScript out of the box, running in a sandbox (for maximum security), etc. Many resources on the internet can teach you about the features of Deno. I thought, instead, I’d share my first impressions after playing around with it for about a day.
Module Versioning
One major difference in Deno is the style of importing modules. Everything gets imported from a URL and, as a result, there is no package.json and no using NPM.
Rather than using a centralized package management system, Deno has https://deno.land/x. This directory “caches releases of open source modules stored on GitHub and serves them at one easy to remember domain.” This makes finding and importing libraries Deno-style super easy. However, I found correctly versioning these third-party modules difficult.
I was excited to experiment with Oak and Obsidian. I ended up spending a lot of time trying to get their (and Deno’s) versions compatible and very little time using them. These URL-loaded modules can select a specific version or just use the latest.
I tried various combinations of versioning for Oak, Obsidian, and Deno but never quite got everything working. I’ll admit, it’s possible I missed some documentation somewhere. Either way, getting these libraries to play well with Deno was more challenging than I would’ve expected.
Editor Compatibility
Lots of the developers at Atomic use VS Code as their editor, including me. When I started to do some development in a Deno application, I realized my current plugins weren’t compatible with several of the Deno syntaxes.
I tried out some Deno plugins while disabling current ones and eventually noticed this in the manual:
Because Deno requires the use of file extensions for module imports and allows http imports, and most editors and language servers do not natively support this at the moment, many editors will throw errors about being unable to find files or imports having unnecessary file extensions.
I love to have tools like automatic import when I’m developing (and I hate red squiggles), so this was a point of concern for me. Of course, that’s not to say Deno’s unusable. It’s just a tool I see myself using strictly for side projects until it’s matured.
Uses
At the moment, Deno seems really well suited for one-off tasks and AWS Lambdas. Running a script is as simple as pointing a piece of code to the URL of a script (even a GitHub link). Deno can download and run the script with just that information. It certainly has the power and sophistication to do much more complex tasks, but it’s not something I’d feel comfortable using on a client project. Because this tool is so new, the amount of support and documentation is just much smaller than that of Node. Node is over 10 years old while Deno just turned three.
Although many of its features are very attractive, Deno doesn’t have quite the “fanbase” or maturity yet that I’d prefer for production code. It’s certainly in its early development, but I bet I’ll be able to follow up this post in about five years, describing the use of Deno on a client project.