Node.js is certainly not dead, but the hype is over. As of 2019, all of Node’s innovations (non-blocking I/O, same language on front-end and backend) are copied and even made better by other languages. It is hard to find any use cases where there are no better alternatives
Deno is a new platform for writing applications using JavaScript and TypeScript.
Both platforms share the same philosophy – event-driven architecture and asynchronous non-blocking tools to build web servers and services. The author of Deno is Ryan Dahl, original creator of Node.js. In 2018, he gave the famous talk “10 Things I Regret About Node.js“ and announced his new project – Deno. Deno aims to fix Node.js design mistakes and offers a new modern development environment
What’s wrong with Node.js?
The most important thing first: Nothing is wrong with Node.js. You can use it and you should not switch to Deno just because it’s there.
Node.js is getting used by thousands of (very large) companies, it has huge ecosystem and a highly active community - Node.js isn’t going anywhere!
You don’t have to take this from me by the way - you can also listen to Ryan.
"But there are a couple of weaknesses in Node.js which could potentially be improved (side-note: Those weaknesses of course don’t necessarily have to matter to you)."
- Node.js is focused on JavaScript and doesn’t (natively) use static types The import syntax is very specific to Node.js and not what we know from the browser (ES modules, URL imports)
- Node.js does not embrace modern JavaScript features like Promises
- Node.js is not “secure by default” The last point is a tricky one though. “not secury by default” sounds horrible and it’s easy to get this point wrong.
Node.js absolutely allows you to build secure applications. Period!
BUT: A Node script doesn’t have a built-in security model. To be precise, by default, every Node script has full access to your file system, your network and your entire environment.
This is by design and makes Node.js very flexible. But it also means that tools like ESLint, which are just “big Node.js scripts” under the hood, theoretically could do anything with your files on your system.
How does Deno fix those problems?
Deno generally can be used for the same things as Node.js. You can use it to build web servers, you can use it to build utility scripts etc.
But Deno:
- By default supports TypeScript - hence it’s a JavaScript and TypeScript runtime
- Uses ES modules (with URL support) imports instead of its own module system
- Embraces modern JavaScript features like Promises or async iterables
- Is “secure by default”
Let’s take a closer look at those points then.
TypeScript Support
You can absolutely write normal JavaScript code with Deno - but if you want, you can also switch to TypeScript at any point as the TypeScript compiler is built right into Deno.
For example, this code would fail when executed with Node.js but works with Deno:
The usage of TypeScript of course gives you extra type safety and might help you avoid a lot of unnecessary bugs.
As mentioned, it’s optional but if you want to use it, you don’t have to set up your own custom TypeScript project and compilation flow first.
ES Modules Imports
Node.js brings its own modules system:
We got used to it but it’s very different from what we know in the browser:
or - directly in HTML of course:
In the browser, we use relative or absolute URLs. We don’t sometimes use module names and sometimes file paths (both is done in Node).
In addition, in Node projects, we use npm to manage our local packages. This tool downloads them and stores them (as well as their dependencies) in the node_modules folder.
This folder can easily become very big and it’s actually an important part of Node’s module resolution system. Indeed, the following code relies on express existing as a package in node_modules - it would fail if it would be a simple express.js file or anything like that.
Deno simplifies this. You simply work with ES Module imports (i.e. the syntax you know from browser-side JavaScript) and it doesn’t need a package managing tool or folder like npm/node_modules.
Instead, your Deno code looks like this:
This imports the serve function from the server.ts package which is stored on some web server.
Deno automatically downloads and caches this package (and its dependencies) when your code runs for the first time.
Modern JavaScript Features
Node.js works a lot with callback functions - simply because at the point of time it was created, modern JS functionalities like Promises weren’t as important and big (and common) as they are today.
Deno, being very new, of course is able to work around that and leverage all those modern features.
Hence you can for example spin up a very simple web server with the following code snippet that leverages “async iterables” What is that
Just as a comparison, here’s pretty much the same server, built with Node.js:
Security
As mentioned, Deno has “security built in”.
And this does not mean that your Deno applications are always secure, no matter what you do!
This just means that Deno scripts can’t do everything on your computer by default.
For example, if you run the above server script, you’ll get an error message:
The script only executes successfuly once you use the right permissions:
In this case, --allow-net provides network access to the script. Similar permission flags exist for writing (--allow-write) and reading (--allow-read) files for example.
So … should you switch?
This doesn’t sound too bad, does it?
But it’s also very possible, that you have a look at this list of new features and you think: “This is nice but I don’t hate those things about Node.js”.
And that would be understandable, too.
Either way: Deno is extremely new. Version 1.0 was released on May 13th 2020. And just because it’s v1.0 does not mean that it’s finished and you should use it for your production apps.
It’s still very new and under active development. And it’s also way too early to tell whether it’ll ever be a “big thing”.
You can of course play around with it, dive into it and its ecosystem of packages and use it in your side projects or in demos and smaller apps.
The goal of Deno is not to replace Node.js, but to offer an alternative. Some of the differences are quite controversial and it’s hard to predict if they will format in a correct way. I recommend that all Node.js programmers keep an eye on this project. I’m not sure if this project will be a success, but it’s a great opportunity to observe how Node.js could have been implemented differently.
But only time will tell if it’ll be adopted by bigger companies and projects and if the problems, which it fixes, are really problems with Node.js for the majority of other developers as well.
What are your Thoughts About Deno
Top comments (15)
Interesting article! I must say, I'm on the other side of the fence though. Whilst I think it's interesting and worth developing, I really don't think that it's worth getting too excited about just yet. Yes there are some things, such as native TypeScript support and a secure runtime, but I personally don't think that there's enough features that differentiate itself from NodeJS.
NodeJS also has an exorbitant amount of modules behind it, that won't work out of the box with Deno. There is such a reliance on these modules, and it's impossible to expect developers to rewrite their modules for Deno. Module development won't be at the same rate of Node modules, as Deno is directly competing with Node, no matter how you put it. When NodeJS was coming about, there was no JavaScript runtime that runs on the command line, which allowed it to fill a hole and gain support very quickly. Deno on the other hand doesn't have the same advantage.
Deno does, however, have such an advantage in terms of Information Security. And, in that case, it has not so much a hole to fill as a gaping, Nietzchean abyss, complete with the staring back at you if you stare at it too long.
Would you be able to elaborate on the information security point? As far as I'm aware, Node is relatively good when it comes to security, aside from the permission aspect, which isn't a feature in many programming languages
Looks like you don't need me to expand on it. It's the permissions aspect. It's telling of the broken state of the modern web, and just general incompetence of engineers, that this is all it needs to be "ground breaking." And I'd like to get in touch with the Deno creators for ways to expand on it based on some more such "ground breaking" (does the obvious thing no one is doing) research in security focused languages like those used in Secrets Management, Encryption as a Service, and CryptoCurrency scripting.
"The hype is gone" - hehehe, like hype was important in my decision making process. ;-)
Deno doesn't have official semver support. I can only imagine the headaches that will happen on large Deno applications. Semver reduces problems. Deno is behind in that regard (similar to Go). Sure some people are trying to make semver tools, but these are community-based and non-standard, so things will be fragmented within Deno in terms of dependency management.
The example literally showed semver being used, I have no idea what you have against deno.
The URL used in the examples has some numbers in it that look like semver, yes. But Deno itself does not have any notion of semver; it does not have a tool that reconciles dependency versions based on version ranges like Node.js has (npm and npmjs.com).
Npm has algorithms that automate the process of handling version mismatches. Deno does not.
Any semver-related tooling that currently exists for Deno, is not official and not baked into the foundation of what Deno is in the way that NPM's version handling has been baked into the foundation of Node.js since the beginning with forethought of the problems it would solve.
In Deno, a developer is going to eventually indirectly import dependencies that are the same library, but from different URLs (maybe only the "semver" numbers in the URL will differ) and end up with unnecessary duplicates of the dependency with no clear way on how to handle the situation. That won't scale as well as an official versioning system would. GoLang has had the same problems.
I proposed in Deno's chat room that perhaps Deno's package registry (deno.land/x) should officially support semver in some way, similar to how unpkg.com has support for semver ranges, but the idea was taken lightly by the team (at least it didn't seem like something important to them).
Permissions are really an obvious thing in hindsight and often ignored or missing. So this is really great to see.
I have a hunch that it'll supersede Node eventually given a better foundation for a runtime.
I also wonder how this could affect Electron or a future Electron-like.
I mean, this is going to be fun when webpages go down and apps stop working (new deployments). That aside, Deno looks good
Why? The same could happen to GitHub or NPM if they go down as well.
Mind that:
Yeah I know, about the reload, that's why I said new deployments. Concerning the NPM going down, yes, it would happen, but it's more probable that an individual shutdowns their website (for any reason) than a corporation
What are your Thoughts About Deno???
Deno is still not production ready :( I think so
Nice article!