On Deno And Node

July 11, 2020

So..... How you doing? Getting by? Trying to survive? That's good. Yep. All good.

...

Okay, lets talk about server side Typescript. Right now, most working days, I work with Typescript on the server. Which means I'm working with Node on the server. I deal with NPM lock files doing odd things in the build chain. I've dealt with transitive dependencies that conflict in weird ways when you go to static analysis. All the greatest hits.

Which should color my words when I say I'm looking forward to the Deno ecosystem maturing to the point that we can use it in production. Deno is great. Static modules, lowest permission by default security model, ES6 modules, Typescript+Rust, so many things to like and so many batteries included.

I've seen some rumblings lately where people try to make a direct jump from Node to Deno. And I can understand why, the mind behind both is the same wobbly mass of walnut textured jelly. But as I've written in other places, just because batteries are included doesn't mean you don't have to tell people that they need to pull the little plastic tab.

And while I don't think I've quiet mastered it enough to cover all the various topics that could do with covering, there are three I've seen over and over again that I do feel qualified to cover.

1: There is a build chain

Assuming that you use Typescript for you Node work, then you can skip this section. But for any one else who doesn't, then this is for you. Deno is a little more complex than Node in its presentation of the work required to get your code up and running. While Node uses the v8 engine to run your JavaScript code inside its runtime, Deno first makes the hop into a runtime in Rust.

This means there is the space in Deno for the included tooling to do all kinds of useful things. Things like grabbing the dependencies on first run and locking them. Things like shaking the tree and optimizing the memory. Things like watching code for changes. But this also means you are going to have extra steps to get your code ready for final deploy. You're going to need to bundle that code up so some of those little helpers steps don't happen each time your startup your process.

It also means that there is work for you to do to be a good steward of your project. You're going to need to tell deno that you have and need a lock file and to use it.

Sure, these are a few more steps. But, unlike in Node where you might need things like babel and gulp to do this, those are included. Just remember to pull the tab.

2: There is a restrictive security model and that's good

So, startup anything running Node and it has full access to the host environment. Done.

Startup something in Deno and... it understands itself and only itself.

This is another tripping point I see a lot of people just running over. Deno by default works on a model of least needed access to function. If your process doesn't need it, it won't have access. The issue arises for most people when they try to start groking around and forget what access controls they've granted their process. Sometimes they just end up giving them all.

The solution to this is painfully simple. Grok out your code by roughing out the various functions before first run. Give them descriptive names. Then guess as the bare minimum you'll need to run those functions. Start Deno with that and keep going until it breaks. I give vaguely similar advice to new engineers when they start with Node. Only with Node I tell them to start with no packages and only add them when you need too(The topic of when you need outside packages vs the included libraries is a whole different talking point)

3: There are its not perfect at

This is more to people like myself who are just drooling at the idea of a good replacement for Node. Deno is VERY young yet. Its got a good head of steam and a great vision but that doesn't mean its right for your use case just yet.

What I tell people is this: Would your code run better in Python, Rust, or Go? If they're answer is “I don't know”, I tell them to look there first. Nine times out of ten they just haven't done enough examination of their specific domain to know if they have the right tools v.s. the right programming approach.

If they say: “Yes, but...” then I would say try Deno, but be ready for those 'buts' to still apply. Deno is young and there are rough spots in there. If your requirements are more algorithmically limited, Deno might give you the wiggle room that need to fix them. If they are because the stdlib of Node is missing a certain kind of function, check. Deno might have that.

Just don't assume the dinosaur is packing silver bullets. And remember to pull the battery tab or he won't roar.