Deno - should you care?
Rishabh Singh
Posted on May 17, 2020
TL;DR
If Node was built today, the result would have been Deno. Does that mean that you should:
- Care?
- Abandon Node?
- Never pick up Node?
- Migrate to Deno ASAP?
Not necessarily.
Disclaimer
Before we begin, I'd like to inform you that I am assuming that you know about JavaScript, Node.js and have experienced their nitty-gritties to some extent. You have come across the Deno hype in the past few days and you are already wondering if you should care.
Introduction
On 13th May, this happened:
About time! I had been anticipating Deno's release since 2018, when I first saw Ryan Dahl's (creator of Node & Deno) presentation at JSConf. Ryan briefly talked about his goals when he set out to build Node in 2009, how things quickly spiralled out of his controls and the things he regrets about Node. If you haven't watched it, I highly recommend you to watch it first.
Let's give credits where due. Programmers generally do not admit their fault or the flaws in their code/approach very easily. Ryan sets the right tone at the start of his presentation and dearly apologises for the flaws in Node. It takes a lot of courage to do that publicly in front of the whole world, especially for something as mature and standardised as Node. Kudos to him!
The Birth of Deno
Change comes through acceptance. And well, that's exactly what happened with Deno. The flaws in Node were accepted by Ryan and he started building Deno. Wait! Is this why we're experiencing this dilemma? Is this why we're trying to learn Deno? Because a programmer did a few mistakes 11 years ago and is trying to fix it with yet another JS framework?
Not really. Of course, that's one piece of the bigger picture. But Deno is more than just being first-aid to Node. It is slowly progressing to be everything that Node was supposed to be in the first place. Node was created to introduce the concept of event-driven I/O & HTTP servers using JavaScript. And while Node may have been able to achieve that, in hindsight, it came with a lot of baggage (or package, literally!).
It started defying the principles of the very language it was built on top of. Eventually, Node reached a point of 'no return' and became too bulky and massive for the creator to just modify the core without breaking millions of Node projects.
Node vs Deno
Node and Deno were built to serve the same purpose. That provides us a foundational common ground for comparison. I'll keep adding to this as Deno progresses. Let me know if there's more.
| Features | Node | Deno |
|---|---|---|
| Engine | Chrome V8 | Chrome V8 |
| Uses | JavaScript | TypeScript |
| Written in | C++ & Libuv | Rust & Tokio |
| Security | full-access | explicit-access |
| Package Managing | npm | absolute url-based |
| Importing with Extensions | optional; non-explicit | mandatory; explicit |
| Module Ecosystem | CommonJS | ES moduling |
| Browser Support | ambiguous; vague | supported |
| Native Async Programming | Callbacks | Promises |
| Unhandled Promises | uncaught exceptions | dies immediately |
| ECMAScript Support | not built-in | built-in |
| TypeScript Support | not built-in | built-in |
| Code Formatting | not built-in | built-in |
| Top-Level Await | not built-in | built-in |
🤷 Should you care?
Glad you asked. Let's try to understand which category you fit in and then discuss the relevant steps. Be honest and place yourself accordingly.
😕 You're a beginner, and confused which one to pick up.
If you're a beginner, it's optional to care about Deno at this point. You might think that if Node and Deno serve the same purpose and if Deno is newer and better, then why learn Node at all? That's a great question. And for the most part, you're correct. You can actually dive into Deno without indulging in Node. But! - hear me out. You only get to appreciate the beauty of an upgrade, when you've experienced its predecessor. It makes you realise what you had been missing out on. It gives you perspective and enhances your sense of understanding and belonging. I personally feel that these things are crucial when you're serious about a language and see a future with it. It's an investment, of time, energy, efforts and so much more. Choose wisely!
😫 You recently picked up Node and were serious about it.
Seriously, keep going! You don't have to care about Deno. I'm sure you were enjoying Node and having a great time experimenting with it when suddenly Deno launched and you were bombarded with articles, tutorials, tweets and crash courses, resulting in you facing a dilemma and landing here. Avoid jumping aboard the 'Deno Hype Train' and keep following your original plan. Work with Node, understand it's nuances, build a few servers/projects etc. When you feel that the time is right, and you're capable of taking a sound decision without any hype or peer-pressure clouding your judgment, switch to Deno and be absolutely amazed!
🤔 You're an intermediate and have been working with Node for the past few years.
You're thoroughly aware of the ins and outs of Node. You've used Node to build college or hackathon projects. You've interned/freelanced somewhere, using Node to innovate and rapidly build prototypes, APIs, servers etc. Switching to Deno definitely deserves your consideration. Think about it, take your time. Retrospect whether you've learnt everything about Node that you planned to or whether you have achieved everything that you wanted to, when you started. If yes, you know what to do. Otherwise, hang in there.
🤓 You're an expert and you live/breathe in Node.
You have used Node in production. Built customer/developer facing APIs/SDKs and can solve Node bugs in your sleep. Chances are that you aren't reading this blog and you have already started working in Deno. Godspeed! You should definitely care about Deno. But! - even though Deno has released a stable version, it might not be the best time to do a full switch. The community still needs time to grow. If you run into an issue/error, you might be the first one to experience it. Even StackOverflow might not help. But that's exciting, isn't it? 🤩
Frequently Asked Questions
A few questions that you might hear a lot. Providing explicit closure to those questions here. I'll keep adding to this as well. Do your bit and comment relevant questions.
1. Is Deno going to replace Node?
Nope. Node is in a very stable state and there is a whole community dependant on it. Node is in it for the longer run. No need to worry.
2. Is Deno going to merge with Node or vice-versa?
Nope. Deno and Node are going to function parallel to each other with ongoing cross-transitions over time.
3. Is Deno going to support Node apps?
Yes. Deno currently supports a very nascent compatibility layer at this point which, will slowly become stable.
4. Is Deno better than Node?
Yes and No. Think of it this way. What TypeScript is to JavaScript, that is what Deno is to Node. A superset. There's no good or bad. Just a time, place and requirement to use either of them.
5. Do I have to learn TypeScript to work with Deno?
Not necessarily. It is optional. You can also use JavaScript to work with Deno. Although, that would be counter-productive.
Fin!
That's all folks. I hope this blog was able to help you understand your position in the Node/Deno ecosystem and provide you with some closure at the same time. I myself started working with Deno about a week ago and I have a lot of exciting Deno related content coming up very soon. I understand that I did not talk much about Deno, its features, how to get started etc, but that wasn't the point of this blog. We'll talk about that in the upcoming blogs. Watch this space for more. Follow me to never miss an update. If something feels off or wrong, do comment with your problems/concerns/suggestions. I'm happy to help. ❤️
Posted on May 17, 2020
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.
Related
