When it comes to JavaScript, we're all familiar with Node.js. For many years, it has been the runtime environment par excellence for working with the aforementioned web language, providing an asynchronous system through which events are used to build applications at runtime. It's reliable, recognized in the community, and fast, but not perfect. And its creator knows this. Therefore, over the last eight years, he has developed what he presents as the modern alternative to Node.js: Deno. In the following sections, we'll delve into this runtime environment and see if it can truly be a replacement for the long-standing Node.js.
Native TypeScript
Deno is a runtime that meets the same basic requirements as Node.js, but adds a few extras. One of the most important is its native support for TypeScript, something Node.js can only achieve through additional configuration. Below, we can see an example in each of these environments on how to initialize a TypeScript application:
Here we see that when compiling, the main difference is due to the need for Node.js to download a module in order to use TypeScript, while Deno supports it without any add-ons. In addition, Node.js has the added step of compiling TypeScript to JavaScript before the code can be executed.
While it's true that we can disable these security systems, at the very least they guarantee that from the start of the project, those who compile it will be encouraged to perform the relevant checks and therefore to adopt good cybersecurity practices, something that Node.js doesn't take into account unless explicitly specified through external modules.
What about my npm modules?
One of the biggest drawbacks that can arise when using Deno is having to migrate all the projects already created using Node.js, especially considering the number of modules we would depend on. To this end, Deno introduced the ability to also use npm modules natively, thus facilitating user integration with this runtime and allowing them to take advantage of its extensive library of tools:
I have used the node-emoji module and as we can see, it can indeed be used in Deno without any problem, allowing the use of the millions that have already been created by the Node.js community and therefore being able to take advantage of this great feature with just a few small changes in the import code.
Same integration with Front-End
One of the biggest questions that may arise when switching from Node.js to Deno is whether, when used as a backend tool, integration with the front-end will be the same or at least simple. In this case, it can be easily verified that Deno does not present any problems when integrating with frameworks like Angular or libraries like React, allowing you to run the same projects as with Node.js.
Performance improvements
Finally, it's worth noting that Deno is significantly faster at processing web requests. Below are the different results for time and number of requests per second in Node.js and Deno obtained from testing with JUnit:
We can see how Deno turns out to be faster than its Node.js counterpart, and if we look at existing benchmarks on the Internet, the results point to the same thing.
In short, after reviewing and comparing the different features and capabilities offered by each runtime, we find a notable improvement in Deno over Node.js. From native TypeScript support, to security and ease of testing, to increased efficiency, Deno is a significant and powerful alternative to consider.
Want to know more about Hunters?
Being a Hunter means accepting the challenge of testing new solutions that deliver differentiated results. Join the Hunters program and become part of a cross-functional group capable of generating and transferring knowledge.
Get ahead of the digital solutions that will drive our growth. Find more information about Hunters on the website.
Rubén Gadea
Software Technician
Altia
