Deno's Decline

I really want to like Deno. I started to watch "just a few minutes" of their keynote (I assume it was the most recent one, this was a month or so ago) and was intrigued by it and ended up watching the whole thing.

Then I went to go play with it add... I ran into odd compatibility issues (no, I don't remember them, I'm sorry) and tried Bun and everything "just worked". I'm sure Bun is not perfect but so far, every one-off script I've thrown at it has "just worked" which is amazing for me since I greatly prefer to work in TypeScript and (until recently with the type-stripping stuff in node) that was way harder than it needed to be.

If I never see an error about how I should change my "type" to "module" only to do it have it complain about 10 other things I will die happy.

I love Javascript, I love TypeScript, I feel like I'm primed to love Deno but all the parts of it felt half-baked. The comments in this article about things like Fresh and K/V store ring very true. I kept looking for things like "What backend framework should I use?" and the answers were all over the place and not very mature options. It felt like I was building on sand.

I hope I'm 100% wrong, I hope deno turns it around, I want more things like deno to exist, but the closing of data centers is not encouraging.

Issue with deno deploy specifically: they have Deno subhosting but the model is you create an end user script, push it, then can run it.

There's no concept of "run this once" or eval. So it's a very heavy, deploy per run, model of iteration which is not suitable for the main use case of giving end users an editor to iterate with

I use Deno all the time... but it might not be exactly how it's marketed...

Anytime I need to etl some data or transform a bunch of JSON or things of this nature - I use Deno.

It's like a glue language for me at this point. I don't need to focus on configuration or any setup like this - I just create a new dir and I'm off.

This article seems very hyperbolic to me - I still find a bunch of features within deno really helpful and there is still a ton of activity on Deno itself (Had a release yesterday) and many of the internal and community libraries in it's ecosystem like Postgres and Redis (which both had a release within the last week).

That's sad to see.

> If you sense some ire here it’s because I went all-in on Deno. I was fooled. I was rugged pulled.

I don't agree with the author's use of "rug pulled" here. Deno took a shot and not all businesses succeed — they did have unusually strong competition in Bun.

Them scaling down the number of regions might make them sustainable longer with their current customers who have deployments. That seems nicer than a hard shutdown.

Alternatively, this may be Deno’s “Dip”: A tough period of time before continued gains and small breakthroughs that build up over time to a new plateau. Maybe all new creative projects will have this as a part of their journey. I am confident Ryan Dahl is unlikely to give up, and is aware (and working to become more aware) of what is necessary to improve for deno to achieve the vision he has for it.

One major reason I still haven't switched away from Node and NPM is major stability and support, pretty much everywhere, e.g. full automatic VS Code support. Plus, even if it's ever so slowly, Node.js is legitimately keeping up to date with the latest ES features and always improving its stdlib, and V8 is still the king of performance and likely to remain so, unless, say, a court were to split up Chrome from Google funding by monopoly laws. That said, Node progress is slow. I'm not entirely sure why. I'd be glad to get paid to help make Node.js better if that were a job. And I'm still waiting on #57696 to avoid using async in a few places that I otherwise wouldn't need to.

I don't intent this to be mean to Deno, but did it ever really get traction? Hard to describe something as a decline if it never really held a significant position.

The rust reimplementation of the node modules is interesting to read. I took some ideas for the llrt runtime modules. As a comparison Bun Zig implementation is scarily ignoring a lot of edge cases.

At first I thought this was from a site called "DBUS Hell" and I was excited to read war stories about building the Linux desktop.

i use deno all day every day.

it’s really about taste. deno has insanely high standards, and the choices they make are great.

deno deploy subhosting seems unlikely to go anywhere, even if the serverless fad is coming to its plateau of productivity.

if you’re looking at node and think it’s great, you should use it.

node compat makes me like deno more, not less.

it’s fine to not use it, but most of the points are about deno the business, not deno the tech. postgres, rust, and a lot of other projects find a way out of the vc treadmill.

IMO in JS/TS world its atm Bun vs. Deno in replacing node, npm, pnpm, yarn whatever other package manager. What i see is, that Deno try to go the vercel way and want to make some money to finance all this open source development. IMO totally legit. And also, normal, when you spin up a (startup) idea, 19 of 20 will fail. So i don't get the point of the article actually. The Article points to all this ideas but forgets that deno's core is the runtime. In between the lines, a node / LAMP-Stack history blinks up.

I wired up some custom middleware on Bunny using Deno and it was the first time I really saw the value of it. It was really nice to just hot load dependencies via a URL, write my code, and go. Beyond that use case, though, not much has stood out.