Why didn't Deno take off?

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 blow-away 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.