Deno: Your Node.js Alternative
A new JavaScript runtime environment
We’re doing it wrong — Ryan Dahl
Yes! The founder of Nodejs, Ryan Dahl, did not feel too happy with his product overall. It helped millions of JavaScript developers to run their code outside the browser; however, he didn’t stop and attempted to make a better runtime environment for all JavaScript fans (including me, but I like Kotlin more xD).
If you take the first two letters from Node and place them at the end, you get Deno.
function ryanDahl() {
const str = "node";
const first = str.substring(0, 2);
const last = str.substring(2);
console.log(last + first); // Outputs: deno
}So what does Deno introduce that is better than Node.js?
Built-in TypeScript support
Everybody loves TypeScript. For your Node project to have TypeScript support, you need to configure your project and meddle with the tsconfig.json file explicitly. You must ensure you have your source and destination folders in the correct place. It makes your code split into your TypeScript and JavaScript section. Yuck — who wants that?
Ryan Dahl worked on Deno to allow TypeScript support to enable you to focus on development rather than TypeScript configuration.
Top-level await/async syntax
Do you still use the then and catch chaining syntax to carry out asynchronous tasks in JavaScript or TypeScript? If your answer is yes, then I hate to break it to you, but you’re a decade behind in development. There is nothing wrong with using that syntax; but in my opinion, the async/await syntax is cleaner and easier to comprehend.
Deno features top-level async and await, which means you do not need an asynchronous function to use the await keyword. You can freely use the await keyword wherever it’s required.
No more node_modules for your dependencies
Have you been irritated by the amount of space your 100 projects take just because of the node_modules folder present in every one of them? Ryan Dahl saw this problem with the growing popularity of Node and decided to work against it while building Deno.
All Deno dependencies are hosted on DenoLand — it features their standard library along with third-party libraries. The import syntax in Deno uses these cloud modules to run your code, and no memory is wasted on node_modules.
Security features
Node lacked security. You were allowed to execute certain codes when it should be prohibited. Ryan Dahl thought that it was a detrimental factor in Node and he must fix it.
By default, your Deno application is secure and permissions are provided when you execute your file. For example, your application cannot read any file on your system unless the execution commands pass the --allow-read flag. Similarly, you cannot make a REST API unless you pass the --allow-net flag.
Cleaner REST API code
So you’re developing a newer runtime environment. You ought to make the coding environment modern, right? There are many third-party libraries like ABC and Oak which work towards building a cleaner REST API.
My favourite development here is the chaining of routes and their respective HTTP method.
router.get('/', (ctx) => {
ctx.response.body = 'Hello from Deno'
})
.get('/rooms', getAllRooms)
.get('/rooms/:id', getRoom)
.post('/rooms', createRooms)
.put('/rooms/:id', updateRoom)
.delete('/rooms/:id', deleteRoom)// Code taken from LogRocket blog.
Conclusion
Will this replace Node? I think yes. However, it will take many years for this shift to occur. Deno is only a couple of years old. In May 2020, Deno was released as production-ready, however, some features were still experimental. Deno is a growing community and it’s worth looking into.
The fanbase for Node is big, despite the drawbacks. I appreciate the effort of Ryan to build this amazing runtime environment; but like every other technology, it is only a matter of time before Deno will be in demand in the industry. What do you think?
