The ever-changing landscape of web development can be both cruel and kind. In May 2009, Ryan Dahl introduced Node.js to the world, and it didn't take long before developers flocked to it like ants on a large pile of sugar. Ryan left the Node project in 2012.

Node continued to increase in popularity and, front-end tooling started to build on Node.js, further propelling the popularity even further. To this day, most front-end tooling is built on Node, and Npm underpins the package ecosystem for both browser-based packages and Node.js packages.

And, then in 2018, Ryan announced something new he had been working on called Deno. However, before Deno became available, Ryan famously did a JSConf EU talk called "10 Things I Regret About Node.js."

There is a good chance you have already seen this. If you haven't, I highly recommend you watch it. In this talk, he raises several good points and downsides of Node.js that are systemic. Most notably, how heavy the node_modules directory becomes once you start installing packages.

You've probably seen this highly accurate meme about Node.js

When Ryan did reveal Deno in 2018, the hype was inescapable. YouTube, Reddit, Medium, Twitter and even LinkedIn were all buzzing with fanfare and excitement. Voices were echoing the halls that Deno would kill Node.js. I was even excited when I heard what Deno was promising.

One such feature that Deno was promising was out-of-the-box is native TypeScript support without a compile step (like you need with Node.js). But, its most anticipated and exciting feature was no package.json file and the ability to work with files (like you would include a script in a web page).

Despite the hype and promised features and Ryan (the original Node creator) behind it, Deno had its 15 minutes of fame, and you stopped hearing about it. Unless you have used Deno in the last year, you might have missed Deno shipping version 1.0 in May 2020.

One of Deno's most incredible features is running local scripts and being able to run remote scripts. In the getting started section, you can run the following: deno run https://deno.land/std/examples/welcome.ts

When you run the above command, this is what it looks like run in a PowerShell window:

Even though Deno is incredible and a step in the absolute right direction, I don't know anyone using Deno in production, nor have I heard my developer circle talk about Deno (not in a long time). If you reframed the question from, "Are you using Deno" to "What do you think of Deno?" most developers who have worked with Node would tell you they think it's incredible.

Ryan, from the start, seems to have had particular goals in mind for Deno. But, Deno is not Node.js. There is no package system and no backwards compatibility with Node or Npm modules. What Deno offers is something quite vanilla that makes very few assumptions about what you want and need.

Where Node.js has the upper hand is its ecosystem. There is an Npm package for everything ranging from web servers to encryption libraries and everything in between. If you use a framework or library with a server-side rendering (SSR) feature, the server will be Node.js based. Front-end tooling and bundlers (Webpack) all are built on top of Node too.

To many developers who want to install a library and be done with it, this instant access to a treasure trove of packages is a HUGE advantage of Node.js and one that Deno cannot currently compete with right now. If Node and Deno started at the same time as one another, there is no doubt Deno would have won out.

Right now, it seems most developers and companies are taking a wait and see approach to Deno. There is not much of an ecosystem. Most front-end tooling still uses Node.js and probably will continue to use Node for the foreseeable future.

I believe that there will come a time when Deno will have the spotlight shone back on it. Right now, it is still early days in its development. With continual improvements and hopefully a package solution that appeals to developers who like the current npm install approach (maybe an independent effort like Npm originally was), Deno has so much potential for greatness.

The consensus is that while Deno is fantastic and offers an incredible developer experience, it is not quite production-ready just yet.