Brought to you by engine.so - a tool to instantly create a public self-service knowledge base for your customers with Notion.
Deno is a Javascript / TypeScript runtime looking to take the place of Node.js as the status quo. It boasts a wide slew of features and has a lot of hype around the project with almost 68,000 stars on Github:
With so many great features, the question to ask is:
Why didn't Deno take off when it released it's official version 1.0?
This article looks to dive into that question…
So, what's Deno?
Deno is a secure JavaScript and TypeScript runtime created by Ryan Dahl (who's also the original creator of Node.js). It was created to fix some of the oversights made when first designing Node.js back in 2009. In my opinion this motivation makes a lot of sense because I'm sure every programmer would love to get a chance to rewrite their 10 year old code.
In this case, Deno boasts quite a few features over Node.js:
- Deno is secure by default. Access to the file system, network, or environment has to be opt-in
- Deno was built for TypeScript out of the box External files are explicitly referenced by a URL. No package.json.
- Import statements include file extensions (.ts,.tsx,.js,.json)
- Built-in dependency inspector and file formatter utilities And more…
And with these features in its arsenal combined with an enormous amount of developer hype, Deno had its official 1.0 release in May 2020.
And then…
Crickets.
Why Didn't Deno Take Off?
Deno looked like it had all the ingredients for success. It had a massive following, a solid batch of features, an experienced creator, and more, but it didn't really have the growth everyone expected. Why is that?
I think it's best to look at it from a business perspective. See, most of us forget that building open source software is really no different than building software for users. The standard economic principles of supply and demand still play a large role.
When someone is creating a new open source project, they're typically going to be competing with something that already exists. With that in mind, you have to consider not only how good your new project is, but also what it looks like compared to what's already available.
In Deno's case, what was already available was Node.js, and while Node.js might have its flaws, it's still very capable of doing its job. Now, if Deno came out with a blowaway feature that Node.js would never be able to replicate, that might change the game. But it didn't.
Deno only really sported "minor features" from a users perspective. It had a cleaner codebase, used up-to-date best-practices, and had better security, but those things are really only "features" to a user, not a product in themselves. You could make an email client exactly like Gmail except it has better security and a 50% speed improvement, but users still wouldn't switch to it because even the tiny amount of time it takes to create a new bookmark wouldn't be worth it.
So that's strike 1 against Deno: It has quite a few nice-to-have features, but there's nothing standout that inspires users to switch away from Node.js.
The other major strike against Deno is that it doesn't support NPM packages. If Deno were able to support NPM packages, that would change the game for them. Deno supporting NPM packages would make them much less of a "separate email client", and more like a better wrapper around the current client.
Supporting NPM packages would greatly reduce the barrier to entry. It would act as a good stepping stone for users to migrate their projects and libraries towards Deno.
Think of it as similar to TypeScript's "strict-mode". For users with a huge codebase of JavaScript, jumping directly into TypeScript would cripple your productivity for weeks while you sort through all the error messages. Because TypeScript has the ability to disable strict mode, it can act as a stepping stone for users to slowly migrate over to pure TypeScript. This gives them a much lower barrier to entry, and in turn has helped TypeScript rip away market share from JavaScript in recent years.
What's the Takeaway?
I think this an interesting case-study that exemplifies a larger methodology in business. The takeaway is that if you're going to release a new product into the market, you have to make sure it's something where the upside is so great that it overcomes the resistance from people switching from the status quo.
In Deno's case they had the initial allure, but when it came down to it Deno was really only offering a collection of small "fixes" at the price of losing the whole NPM ecosystem that Node.js had cultivated and this tipped the scales for them.
Where does Deno go from here?
Well they have a decision to make. They can either work on adding backwards compatibility to Node.js libraries, or they can increase their offering to make the compulsion to switch just that much more enticing. I personally think backwards compatibility is the way to go, and I think if that was added it would drastically alter the future of the project.
Either way, best of luck to the deno team and I hope the best technology wins in the end. I hope you enjoyed the article, thanks.
Top comments (11)
Dude, Deno exists for two years. It has a long way to go before being remotely mainstream. Don't judge it too soon. Do you remember where Node has been in 2011? Or React in 2015?
If you thought releasing v1 would make it explode - you are wrong. It's a small step in the right direction. Having played with it for a very small personal project, it is still far from production ready. But as more people rally around this technology, it will become more and more viable in large scale.
Dropping NPM was a design decision, and only the future will tell if it was the right decision. NPM suffers from a lot of issues in itself, and Deno takes an interesting new approach to solve those issues.
Lastly, even if Deno will never take off (although I personally hope it does), it shows us that there is another way, and that's always a good thing.
Ryan living in 2030+
If you take a look at their repo there's currently 608 issues and 60 open PRs. Lots of work to be done. It looks like they're focusing on that rather than the UX. If you look throughout the various repos under
denolandyou will see there are many roadmaps still in their early stages. Once these are addressed to a more reasonable degree I'm sure teams and companies will take a risk on deno, with or without NPM compatibility.I'd like to see deno become robust and intuitive enough to outlive node by a longshot.
Deno 1.0 has been out for only 5 months and you call it a flop. By that measure, languages like Python and Rust were flops too.
Regarding the absence of a central package management repository like NPM, Deno has taken that inspiration from Go, and Go is hardly unsuccessful. If you really want to, you can use easily NPM packages in Deno using tools like jspm.org/. The fact is NPM comes with a plethora of security issues, which Deno wanted to avoid. Deno will eventually support import maps (deno.land/manual/linking_to_extern...) which can act as your package.json if you like.
Also, one of the main goals of Deno, which you missed, is native Web APIs compatibility. Means, most of your Browser knowledge will just carry over to Deno, and vice-versa. So you don't have to juggle between two different sets of APIs. All non-web-standard APIs are namespaced under the Deno namespace. That means, remove all Deno namespace references and your code will run in a Browser. To me, that alone is a game-changer for Deno.
I think it's quite early to call a flop, as we can read from interviews with Ryan Dahl, Deno's creation is has many things to do with Ryan experimenting with Machine learning(Deno as not just another web server runtime). With native WebGL(or WebGPU in near future) available Deno will act something like go to scripting language for ML, Data science. I personally hope Deno/JS will have huge role in Data science, ML related future. Moving from largely python operated world of DS.
Same adoption challenges faced by every new product. A big boost to Deno would be a wide usage by one of the big corps.
I'm not quite following Deno development but what are some examples of codebases purely built on it?
I've a small event handler build with deno, mostly for calling telegram api, email, and some other services. I really like that with deno 1.5 or so you can actually bundle your app into a small bundle.js file, mine is about 600kb of pure js with all deps included, and you can read it very easily.
I don't agree with you, I'm a NodeJs developer and really want to use deno as fast as their ecosystem is being reliable, from the perspective of built in module stability, frameworks, community libraries, etc.
One of the advantages using deno is their module system, You've wrong place when you think this is a replacement for NodeJs, it's like super version of NodeJs, because like the module System without npm is a big win for me, nowadays NodeJs developers are struggling with the big amount of npm module (that's why pnpm so popular), also the security and bloated dependencies are the big issues.
So being able to have a smaller app within the container (like a docker) is a ++. Because npm_modules is not going to be anywhere without this breakthrough, also it is fun to have a small containerized app (with Deno) to scale fast and massively on the production server.
Have you ever heard about Deno is able to compiled as a Binary app? But, still needs an V8 runtime absolutely, and maybe one day that could be a possibility to run like a static binary (like Go)
Just adding to the discussion, without being any expert or even having ever developed anything in either Node or Deno.
Deno 1.0 was released in May 2020. In the middle of a health+economic crisis which virtually stopped economies all over the world. I don't know the effects of this in the developers community but I wouldn't analyze any indicator without taking this onto account.
First of all, in the Javascript world, the hype cycles are massive and unstoppable. By default, Deno should take off as a "better Node", especially since this is effectively Node 2 - from the same author.
Secondly, claiming that it does not have enough features to switch to does not check out. Businesses routinely choose to spend hundreds of hours and millions of dollars implementing and maintaining, say, Kubernetes, which the vast majority of companies has no business doing, as they simply don't have the type and scale of problems it was designed to solve.
Deno was being like rust. Gaining stability and sitting in the background. It never flopped.
And like you predicted, npm support is here in 2023.
The title here could change a little.
title is total clickbait and should be changed to stop the SEO