I was excited about Deno precisely because it was a greenfield approach without backwards compatibility. Early on, they focused on reducing complexity and it worked. There were definitely some new pain points compared to Node, but I found them pretty manageable.<p>At some point, rather than coming up with native solutions to those pain points, they retreated and started leaning on backwards compatibility as a workaround.<p>Today, Deno feels more complex than Node does because it contains both approaches. And now there are lots of edge cases where a Node package ought to work, but doesn’t because of one unimplemented API or option or a bug that exists only in Deno. My favorite testing framework, AVA, still isn’t supported.<p>I used to just ignore the npm compatibility layer and target Deno itself, but that’s become more cumbersome to do over time. For example, look at `deno run —help` and look at how many command line options and env vars there are. It’s exploded in the past few years. A lot of that is for npm interoperability. For me, it’s just a lot of noise.<p>The one area of Node compatibility that I want the most is support for ESLint configs in the Deno linter. Yet they don’t seem to want to do that.<p>I really want Deno to succeed, if for no other reason than because it’s pushing Node to do things that they should’ve done years ago, such as adding a permission system. I just don’t think the current vision for Deno is very coherent or consistent with its original purpose.
> There’s been some criticism lately about Deno - about Deploy, KV, Fresh, and our momentum in general.<p>It seems like they never replied to the criticism against their momentum (something I haven't seen myself, what would the argument even be), was that intentional or just missed?<p>> Some of that criticism is valid.<p>Would have been great to also outline what criticism is/was valid, and how they're aiming to solve those things. Sure, maybe a bit "shoot yourself in the foot" but personally I really prefer companies that are upfront about the drawbacks, and makes it more likely I'll chose them. Migadu is a great example of this, where they have a pro/con page where they are upfront about the drawbacks of using Migadu (<a href="https://migadu.com/procon/" rel="nofollow">https://migadu.com/procon/</a>). Just the existence of that page is probably ~20% of why I chose Migadu in the first place.
The problem with Deno is that it has lost the plot. When it was first announced years ago, it was simply a safer, faster JS/TS runtime “written in Rust” which I assume it still is but now you go to the website and you click a “Products” drop down containing a bunch of other shit.<p>It’s like they looked at what Vercel did with introducing a deployment platform after their initial NextJS work and wanted to follow suit.
> Most developers weren’t deploying simple stateless functions. They were building full-stack apps: apps that talk to a database<p>Honestly that seemed really obvious from the start - it's hard to think of many use cases where this isn't the case. Glad they realised anyway.
This is likely in response to <a href="https://news.ycombinator.com/item?id=43863937">https://news.ycombinator.com/item?id=43863937</a>
I was super-excited about Deno right up until they threw away their earlier commitments and added backwards compatibility for node and all the shite that comes with it.<p>The <i>whole</i> selling point for me was that deno was node without the bullshit and baggage, but they dropped that and basically just turned it into node with built in typescript support and a few other minor things like the permissions.<p>Similar story with bun.sh - node backwards compatibility (although not using V8).<p>Does anyone know of a server-side typescript scripting engine that is <i>not</i> trying to be backwards compatible with node?
Doesn't inspire confidence.<p>I guess we’ll see soon enough what Deploy will become since that's "imminent".<p>KV is dead if they've no desire to develop it out of beta and are working on something new. No reason to ever use it for a new project now.<p>Fresh is being refactored with an alpha in "late Q3 2025 (likely September)". It was a fairly basic framework to being with. The no compilation/build step was the only interesting idea and that's going away.<p>The runtime is actively developed but I find this statement amusing:<p>> We’re not chasing feature parity with other runtimes.<p>The release notes on Node/NPM compatibility would suggest otherwise.
Post is by the CEO and doesn't really address the criticisms around Deno, just seems to justify their own internal decisions (or his?). Seems like Deno products work really well for Deno though!
> One of the biggest questions we’ve been hearing is about Deno Deploy — specifically, the reduction in available regions. While we understand the optics of this scaling back, it isn’t for the reasons often feared or accused.<p>> Rather, reality is: most applications don’t need to run everywhere. They need to be fast, close to their data, easy to debug, and compliant with local regulations. We are optimizing for that.<p>Why does this sound very odd? I chose to not use Deno Deploy because region was not close enough and it would have just make everything slower than using other means. (Because there are many options to host data closer to overall end-users, and some regulations also happen on country level)
Most developers weren’t deploying simple stateless functions. They were building full-stack apps: apps that talk to a database, that almost always is located in a single region.<p>I wonder if this is true in general for most people on serverless these days. If so, whether this is what the original intention of this movement and whether these people just don't want to deal with docker/k8s.
It might just be my perception, but I had the impression Deno got his ass whooped by Bun and Node.js.<p>While some people whine about the Node.js compat, I'd assume it's the main point that kept Deno on life-support in the long run.<p>Bun did it right from the start and it seems people love it. Being quite a bit faster than Node.js (even with the compat APIs) and Deno obviously helps too. If they keep that going, they'd enter Go level of performance.
When there's two competing technologies, and they're both solving the same problem, I always go with whatever's more popular, unless there's a compelling reason not to. This is mainly because of community support and having more companies/developers motivated to rapidly solve challenges that come up, and/or fix bugs.<p>But especially in the AI/LLM era it's even _more_ important to use what's most popular because the LLM will know more about it, and can pull information from vastly more resources, including it's most important "source" of all: The model weights.
Whenever I read a blog post assuring me that something is not how it looks, it turns out to be exactly how it looks at the end.<p>BTW, I don't use deno and haven't been following any news whatsoever so this is simply a shitty statement from an outsider. It is interesting that I tested deno a couple of times but kept using node until bun came around and I basically switched to bun. I can't say why exactly.
Deno ought to become an engine for the innovative development of web browsers. That is what we need, and what it could very well offer. Better permissions, protocol choices, simpler extensions, all around more options and control.<p>Business wise turn their deploy system into a resource for the browser base, for instance app store, for instance flash compute/rendering, for instance agent hosting services.
I’m seeing some debate on Deno’s decision to ensure Node compatibility, apparently as it gives up a core value prop of early Deno to try and hit the reset button.<p>Can someone help me understand what was lost here? Is there no longer a way to use Deno without using the Node ecosystem?
Mark Twain was born in 1835, made the quote in 97 and died in 10.<p>So the quote was done around 60 yrs old. And he perished roughly 1/4 of the of the time later.<p>Demo was released in 2018, it has now quoted the statement, 7 yrs later.
I guess the next 2 years are gonna be interesting?
I get the "earnest, 'authentic', 'responsible' engagement by the CEO", but this post and title is lifted straight out of media-playbook-fails-101. Post a title like this at your peril. The content doesn't "own" the missteps, it writes the epitaph of Deno. All this article does is validate the "reports" of "demise" and unavoidably presents as "doth protest too much". If you insist on engaging with a negative narrative there are more constructive ways to frame it. Don't talk about "committing" to anything, just DO. Ryan, if you do nothing else, think about changing the title. But this entire post should ideally get rewritten. There are some really positive things you're doing. But they're covered in stink.
This is really OT, but if I don't ask now I might never get an answer…<p>Someone mentioned to me "Deno-style event loops" / "Deno-style main loops". I asked what that is but they were gone. I've tried to look it up, to no avail.<p>I do quite a bit of work on low level event loops. I'm continually interested in how different projects are doing it and what ideas and tricks they come up with. It bugs me to no end that I can't find anything on what this "Deno style loop" is supposed to be.<p>Anyone know what's meant / have a pointer or two?
Personally I love what Ryan and the Deno team have done, if there is anything to really say its that incumbency in languages and software ecosystems is really strong- and its stronger the further down the stack you get.<p>I will say that I was disappointed when they added NPM into the project, I understand why they did it but I would have preferred they not do it.<p>With that said all of my blogs and client sites are all being happily built in lume with deno right now (hosted on cloudflare) and they have been great for years now. I am still very happy for having made that change.
I’m not sure why anyone would want their JS runtime to be their package manager, code formatter, compiler, bundler, web framework, KV store, and cloud provider(!) all at the same time. There’s just no way that they can ship the best product in all of those categories.
I’m sure a bunch of the criticism of Deno is exaggerated. But there’s something fundamental holding me back from investing my time in Deno, or Bun for that matter: they’re both VC funded.<p>The post is a good illustration of why that matters. Very little of it is about Deno itself, instead it’s mostly about the paid-for services Deno Inc offers. They have to prioritise and chase that because their investors want to see financial growth.<p>It’s the same reason they abandoned the idea of Deno being a fresh start in the JS ecosystem (an idea I loved) and instead started patching in Node compatibility layers. They had to reduce friction, not add to it. But for me that compromised the reason for using it in the first place.<p>Node has many flaws. And it’s boring. But its existence doesn’t depend upon the whims of random investors who might decide to pull the plug at any moment. So I’m just going to stick with it.