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
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
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 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.
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.
- Uses ES modules (with URL support) imports instead of its own module system
- Is “secure by default”
Let’s take a closer look at those points then.
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.
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.
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.
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
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.
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.
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