The problem
Deno stable version was introduced about 3-4 years ago. At that time, it received quite a bit of attention because none other than Ryan Dahl, the creator of Node.js, was also the patron of Deno. Huh! You heard that right. Why would he create a new tool to compete with his own "child"?
Ryan Dahl admitted that Node.js has critical weaknesses. Initially, Node.js was designed to focus on simplicity and flexibility. But over the years, everything has gone beyond control. Node.js has developed very powerfully, gaining more attention, and as people tried to pack everything into this rising star, it became more complicated than necessary.
Deno was born to address the weaknesses of Node. However, at the time of its launch, it did not showcase its strengths. Its performance was even inferior to Node.js, not to mention the lack of npm support – which was one of Node's biggest advantages. This made things increasingly difficult.
Being a curious person, I quickly experimented with some code snippets using Deno and realized the inconvenience regarding the library system. "Wow, it might take a long time for my favorite libraries to appear on this platform; everything looks both new and unfamiliar," I thought!
Everything changed when I started "Tear Down and Rebuild" my blog. After many times of hesitating and pondering over technology choices, the name Fresh appeared. However, Fresh requires Deno as its runtime environment. Having no prior deployment experience but thinking "it's just a JavaScript runtime environment!" gave me more confidence. The next story is this article.
Today, I will summarize 5 points that I feel "like" when working with Deno.
TypeScript support
Deno natively supports TypeScript. This means you can run a .ts file directly without going through a conversion step to .js like other libraries usually do. Many people wonder if this is different from using a tool to run TypeScript code like ts-node? The answer is definitely yes because ts-node requires TypeScript configuration files to work in complex cases, while Deno does not. The default support for TypeScript simplifies the process of running .ts code directly.
I often create scripts to handle some minor tasks for myself. Every time I create a new script, I always hesitate between choosing .js or .ts. And when Deno appeared, .ts became the default choice. Even in Node projects, when I need to write a script to perform a quick task, I still prefer choosing .ts and using Deno to execute that code.
No more multiple configuration files
The more I engage with JavaScript/TypeScript projects in general or Node.js in particular, one thing that I have always wondered about or even found annoying is... there are too many configuration files. Each different project has files with different names. From package.json, package-lock.js, and an additional tsconfig.js if the project uses Typescript... Not to mention if I need to configure a few more things like webpack, vite, tailwind, postcss... oh my! In the beginning, due to being unfamiliar, I had to read to understand the significance and usage of each configuration file that appears in the project, reading while silently cursing, "How on earth can you create hundreds of configuration files like this?"
When moving to Deno, I was amazed to find that there were no configuration files at all. That means you can run the project without any config – sounds surreal, right? If there is any, it is just a single deno.json file. Deno cleverly eliminated many complicated configurations or placed them into a single json file. What a relief to open a project without worrying about the appearance of a strange name again!
Support for Web APIs and Node APIs
Deno has been and is trying to support Web APIs as much as possible. Web APIs are a standardized set of APIs available in the browser. Good support for Web APIs can allow programs running in Deno to also run in the browser, following the write once – run anywhere paradigm. This opens up avenues for "Universal" libraries.
If you have ever worked with Serverless, especially with Cloudflare Workers, you would know that Workers are not completely compatible with Node.js, so using Node-specific libraries is likely to not work. On the other hand, if a library uses or is compatible with Web APIs, it runs smoothly. This also applies to Deno.
Support for Node APIs allows Deno to run most "packages" on npm. Thus, you can freely use npm packages without worrying about compatibility anymore.
New security mechanism
It's quite strange that there is an obvious fact that when starting a Node project, it will by default have all the user's permissions. This means the program can freely access files or execute commands in the system on behalf of the user. Quite dangerous, isn't it? Imagine if you accidentally "run" someone else's project without checking it first, and it scans all the data on your machine, sending it back to some server, or encrypting all files for ransom, then consider your life ruined, a mistake that cannot be corrected!
Deno addresses this flaw by adding flags to request permissions when running applications. Permissions can include file access, internet access... If the program wants to access the file system or connect to the internet, it must at least request permission. For example:
$ deno run --allow-read --allow-write --allow-net index.ts
There are many permissions that need to be "requested"; for more details, refer to Security and permissions | Deno Docs. The quickest way is to allow all permissions by using the -A or --allow-all flag.
Performance is continually improving
I remember the early days when it was just introduced; Deno seemed to lag behind Node.js in terms of program performance. Specifically, benchmark tests showed the difference between Deno and Node when running the same program; Deno always came up short. At one point, bun.sh suddenly appeared. Bun emerged as a phenomenon because it outperformed both Node.js in terms of performance. This made Deno seem even more dull.
In reality, when using bun to run some Node applications, I encountered quite a few issues and even bugs. It seems bun is not ready for "production." So at that time, I concluded that Node is still the go-to choice for those who love stability.
Recently, with the release of Deno 2.0, significant efforts have been made to improve performance and enhance the programming experience of this "black dinosaur." According to the latest documentation they released, Deno stands out in every aspect compared to the well-known names Node and bun.
Conclusion
Above are the points I like when working with Deno. There are a few more features, such as providing Deno Deploy for free to deploy applications. However, I still occasionally come across articles that "criticize" performance and the module system, as well as low compatibility with Node. These limitations have been addressed in the latest 2.0 version. My perspective on Deno has changed compared to when it was first launched, and I hope Deno will receive more attention from the community and make even more breakthroughs in the future.
What about you? Have you used Deno? Do you have any praise or criticism regarding this JavaScript runtime environment? Please leave your comments below!
Top comments (0)