If Node was built today, the result would have been Deno. Does that mean that you should:
- Abandon Node?
- Never pick up Node?
- Migrate to Deno ASAP?
On 13th May, this happened:
Deno@deno_landv1.0.0 released! deno.land/v122:41 PM - 13 May 2020
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!
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?
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 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.
|Engine||Chrome V8||Chrome V8|
|Written in||C++ & Libuv||Rust & Tokio|
|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|
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.
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!
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 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 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? 🤩
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.
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.
Nope. Deno and Node are going to function parallel to each other with ongoing cross-transitions over time.
Yes. Deno currently supports a very nascent compatibility layer at this point which, will slowly become stable.
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. ❤️