• Here’s Why Deno Didn’t Take Off: And what Deno needs to do to overtake node.js.
  • Spencer, Founder of Skiwise and NotionIntegrations
  • Translator: @ hylerrix
  • Article published at: 20200928/20210429
  • This article belongs to the “Deno study” series, the original translation has been authorized by the author.

The translator sequence

The text start

Deno is a JavaScript/TypeScript runtime designed to improve or even replace Node. It has a lot of features and a lot of attention, with 68K stars on Github so far:

Github.com/denoland/de…

With so many powerful features, there’s an important question to consider:

Why has Deno not been widely used since the 1.0 release?

This paper will attempt to address the issue…

So, what is Deno?

Deno is a secure JavaScript and TypeScript runtime written by Ryan Dahl (the original author of Node.js). Deno was born to address some of the omissions of the first design of Node.js in 2009. I think this motivation makes sense, because I believe every programmer wants the chance to rewrite their 10-year-old code.

With this in mind, Deno has introduced a number of new features as node.js has evolved so far:

  • Deno has a default security mechanism. Access to the file system, network, or operating environment requires authorization.
  • Deno supports TypeScript right out of the box;
  • External files are explicitly referenced by urls. There is no package. Json.
  • Import statements need to include file suffixes (.ts,.tsx,.js,.json)
  • Built-in dependency checker and file formatting tool library
  • And more…

With these features and an aggressive push from a large number of developers, Deno officially released version 1.0 in May 2020.

And then…

Hop…

Why didn’t Deno catch on?

Deno seems to have all the ingredients for success: lots of followers, lots of features, experienced founders and developers, etc., but it hasn’t really achieved the growth that everyone wanted. Why is that?

I think it’s best to look at it from a business perspective. Most of us probably forget that building open source software is really not that different from building software for users. Standard economic principles of supply and demand still play an important role.

When creating a new open source project, they often “compete” with what already exists. With that in mind, you need to consider not only whether your new project will be good enough, but what real advantages it will have over your existing project.

When the law comes to Deno, it is important to pay attention to the existing Node.js. While Node.js may have its flaws, it’s still capable of doing its job. If Deno did deliver powerful features that Node.js couldn’t replicate, it would be a game changer — but it didn’t happen.

** From the user’s point of view, Deno really only has some “minor features” : a cleaner code base, a newer best practices, and better security support, but these are really just “features” to users rather than a full-fledged product. ** You could develop an email client like Gmail with better security and a 50% speed improvement, and even if it takes very little time to bookmark your client to a new bookmark, not many users will want to switch.

So here’s Deno’s first trick: Deno has a lot of nice features, but nothing great that would motivate users to switch over from Node.js.

The second big thing Deno has to contend with is that it doesn’t support NPM packages. It would also be a game changer if Deno could support NPM packages. Deno’s support for NPM packages will make it a better container for existing mail clients, rather than a “stand-alone mail client”.

Support for NPM packages will greatly reduce the barrier to entry. This will be a good stepping stone for users to migrate their projects and libraries to Deno.

You can compare Deno’s NPM support to TypeScript’s “strict mode.” For users with a large JavaScript code base, going straight to a pure TypeScript remodel will take weeks off your productivity in resolving various error messages. But TypeScript’s support for disabling strict mode makes it a stepping stone for users to slowly migrate to pure TypeScript. This provides a lower barrier to entry for users, which in turn has helped TypeScript take much of the market share away from JavaScript in recent years.

So, at what cost?

I think it’s an interesting example of a business approach. The point is, if you need to launch a new product to market, you need to make sure that the advantages are big enough to overcome people’s resistance to moving from the status quo to the new approach.

There were a lot of unique attractions for Deno at first, but when you look back on Deno, you see that Deno was actually a small “fix” at the expense of the entire NPM ecosystem under Node.js.

Where will Deno go?

The Deno team had a decision to make. They could try to add backward compatibility with Node.js, or add more attractions to entice users to migrate. I personally think that backwards compatibility with Node.js is the next step, and adding more compatibility will change the future of the project dramatically.

Anyway, best wishes to the Deno team, and I hope the better technology will eventually become more marketable. I hope you enjoyed this article and thank you for reading.

© github.com/hylerrix/de… 2020 ~ 2021