I know on HN we don’t always love CEOs, and that’s okay… the ethos of startups has changed over the past 10 years, and tech has shifted away from tinkerers and more toward Wall Street. But Ryan Dahl isn’t doing that; he’s a tinkerer and a builder.
I dunno, I just don’t like this vibe of “what have you done for me recently” in this post, especially given he skipped over the company and is calling out Ryan directly for some reason. Ryan is responsible for many of our careers; Node is the first language I really felt at home with.
Comparing him to Nero is gross.
I don't use Fresh. Serverless is kind of a weird offering that forces developers to do a lot of work to adjust their programs to running all over the place. I even wish Deno had never supported NPM because that ruined their differentiator.
I'm going to keep using Deno and I hope they use this opportunity to refocus on their core product offering so that I can move back to using it from this VPS that is hosting all of my Deno servers right now.
If Dahl had posted the typical layoff announcement people would be criticising that too.
Just an historic curiosity: Nero setting Rome on fire is just a legend. At the time, there was a fire every other day due to wooden houses and poor to nonexistent safety. I even heard somewhere that Nero actively tried to help some people escaping from the fire by opening his residence's doors. So the comparison with Nero could still be correct, but for another reason: someone being wrongly blamed.
In my opinion, FOSS and VC have opposite goals and attitudes: openness, organic growth, staying free vs moat, meteoric growth fueled by marketing, turning a huge profit. I don't see how they could be compatible in the long term, unless the FOSS project is a gateway drug into a proprietary ecosystem.
Accountability starts and stops at the top. Many CEOs (CxOs) get called out. Personally, I want to write something similar about Bluesky leadership, who have fumbled hard multiple times since peaking, and have now "raised funding" from Bain Capital (private equity).
i will begin to care about a CEOs feelings when they put the wellbeing of their employees before their own. not saying that the Deno CEO has done anything on the order of the raw aggression we see from other CEOs in our industry but, as they say, if you cant take the heat stay out of the kitchen.
That is the problem.
FWIW, it worked for Bun (at least for the VCs and employees), so there is a model there that works.
So what does Deno offer now, exactly? The free parts just sound like a pretext to pull you into some paid solutions.
It can be hard to run a company, even harder to make a buck, but at the same time we can still be allowed to say how much they suck at it.
I'll say it.
This author is being an asshole and punching good people when they're down.
We live in a land of goddamned hyperscalers and megacorps trying to minimize how much they pay us (or get rid of us). Trillion dollar Zeuses that skirt by antitrust regulations for decades on end, crushing any would-be competition. Pilfering from open source while encrusting it in proprietary systems that cost an arm and a leg. Destroying the open web, turning every channel into an advertising shakedown, monitoring us, spying on us, cozying up to the spy apparatus in every country they do business in...
How dare anyone throw rocks at an open source effort?
I don't even like JavaScript, but I applaud what these folks are trying to do.
At least they're trying.
Can't even get a decent round of applause.
> How dare anyone throw rocks at an open source effort?
According to the article, Deno raised over $25 million from venture capital. Unless you're disputing that, it seems a bit disingenuous to criticize corporations but call this an "open source effort"
Decimation has been commonly used as a synonym for absolute destruction for a long time, being annoyed by it is wasted energy, better to let it go and accept the new meaning.
Deno might not succeed as a project, especially with strong competition from Bun as an alternative to Node, but I would say that Deno has been more a force for bettering the ecosystem than not.
Many of those at Deno, including Ryan as well as some of those who have apparently left or been let go have been major contributors to the web development ecosystem. Thank you all for your work — we’re better off for your contributions.
Content marketed at wannabe startup founders tends to be encouraging and panglossian. It's good to see here what you're signing up for if you succeed with some degree of traction.
I work at Cloudflare on Workers (but infrequently work on our runtime) and I've always been pretty impressed with Deno. Their recent-ish support for built-in OpenTelemetry is something we've been wanting to do for a while and have been working on, but Deno was able to build a good implementation of that in that time.
Zig is yet to be 1.0, and who knows what anthropic will make out of it.
They can even pivot yet again back into node, as most acquisitions go.
Bun to Deno is what Zig i to Rust: a much simpler, much easier way to overcome its common predecessor's shortcomings. Not nearly as thoroughly and revolutionarily, but still.
AFAIK the biggest users of Deno are using their subhosting service (Netlify, Slack, etc) to allow third parties to execute TS code.
For those out of loop: https://github.com/mikeal/cancer-diaries
Ryan tweeted he was "crushed" when Mikael died: https://x.com/rough__sea/status/1932667147605717130
For the rest, I can't comment on, all the best.
As a founder who built all my prototypes and side projects on Deno for two years, I personally think Deno’s execution was just horrible, and avoidably so. Head-scratchingly, bafflingly bad decision-making.
I was the first engineering hire at Meteor (2012-2016), and we made the mistake of thinking we could reinvent the whole app development ecosystem, and make money at it, so I have the benefit of that experience, but it is not really rocket science or some insight that I wouldn’t expect Ryan Dahl and team to have, in the 2020s.
They were stretched thin with too many projects, which they were always neglecting or rewriting, without a solid business case. They coupled together runtime, framework, linting, docs, hosting, and packaging, with almost all of these components being inferior to the usual tools. The package system became an absolute nightmare.
If the goal was to eventually replace Node and NPM with something where TypeScript was first-class, there was better security, etc, they could have done a classic “embrace and extend.”
While they’ve been doing that void 0 made a significantly better linter & formatter that can replace eslint, a perfect embrace and extend. Nodes improved and a lot of annoyances have been ironed out (at a user level at least), each passing day the benefits of deno reducing.
Fresh is close to abandonware despite being a framework that could be the middle ground between htmx and js framework insanity with even 1 man-day a fortnight dedicated to it.
JSR seems like it’s going nowhere and only exists to install @std.
This was the final straw for me, if they bounce back in a few years hell yeah I’m in but I’m begrudgingly back to node for now.
I came to Deno because I needed a break from Node/NPM. I don’t agree with all of Node’s decisions (particularly the ES module debacle), but Node/NPM have improved over the years.
A big problem with JSR was no private packages. All your code has to be open source. But JSR is the only way to get constraint solving in Deno, besides using NPM.
Yes, it comes with batteries included, but a big node project already has setups handling things like testing, linting, formatting, and dependencies. Moving to Deno for any of those might actually be easy, but migrations in the JS ecosystem never end up being easy, so people who could sway the company to change tools don’t have the appetite to tell leadership about migration projects with minimal upside and unknown duration. And under a startup with an unknown future.
NodeJS succeeded at undermining existing server toolchains, because web devs were easily sold on writing JS for their servers, so tons of successful startups built with Node, and when Node got pretty well established, it was easier to adopt for greenfield projects in the enterprise.
Deno is Node, but better. So it’s not giving a whole market of devs access to a tool that is way easier to write for. It’s marginally easier to manage and you could maybe drop some other toolchain dependencies. But again, those toolchain things are automated/hidden away from developers directly… like they don’t care we use eslint, they just care CI catches problems before they hit prod and that the linter throws an error early in the process. It’s already easy for them to run locally. So it’s not like Deno lint changes anything about the dev user experience, it just changes what DevOps/platform teams have to manage.
We inherited a 10+ year old production system with node and react; it made by a succesful company that made it with vc money in a short time and then got acquired; the system has grown to 100s of 1000s of lines of js (no ts). It runs on a cluster of VPSs on ancient versions of everything.
It took me 3 days to rewrite it to typescript and deno with zero vulns by prompting cerebras glm 4.7 with basically 'port this to modern ts, drizzle and deno' and then opus in claude code to make it work and fix it. It uses playwright mcp to test all flows; it runs production now instead of the old version; no issues so far.
Also, the 3rd day was only on writing REST and Playwright tests on both versions so we could compare if everything works the same.
LLMs seem likely to kill or at least vastly weaken the support model.
And essentially one of the reasonings behind it was that people weren't taking support or buying templates etc. from tailwind because they were getting essentially both of these from LLM's.
And you really have to believe in open source and have the discipline to keep investing in it, otherwise the temptation is ever present to throw more and more effort and resources into the proprietary parts.
> I'm pretty confident that neither bun nor uv will stop existing anytime soon, and the makers got paydays out of it.
If OpenAI stocks let's say IPO and then fall 70% (because hey a business is well, a business at the end of the day), do you suppose they will still keep the folks at uv?
Sure, its good for the makers who get paydays but they are quite far and few and this doesn't feel like a strategy much to me to rely on.
If Open source needs to thrive, we might need a better strategy long term perhaps.
Their initial baffling stance about package.json was the first bad sign. I almost can't imagine the hubris of expecting devs to abandon such a large eco-system of packages by not striving for 100% support out of the gate. Of course they had to relent, but honestly the damage was done. They chose ideology over practicality and that doesn't bode well with devs.
I think they saw Rust and thought that devs were willing to abandon C++ for a language that was more modern and secure. By touting these same benefits perhaps they were hoping for similar sentiment from the JavaScript community.
Deno has some really good ideas (e.g. the library KV interface). I agree with a lot (but not all) of Dahl's vision. But the whole thing is just a bit too quirky for me to invest anything critical into an ecosystem that is one funding round away from disappearing completely.
Since then, I know that it's there and that it's more secure than Node in some applications, and I can see using it being a good option. But it sounds like it might be too little too late? Going by this article, at least.
Feel bad for them, they obviously just didn't capture a real userbase. I expect if yt-dlp hadn't started to require it they'd have just silently flamed out.
I wonder if the layoffs have a deeper connection to yt-dlp.
Eventually the reference implementation gets good enough, and that is it.
In JavaScript case, the first error was to ignore compatibility with native addons and existing nodejs modules.
The second was not providing a business value why porting, with the pain of compatibility, one because "it feels better" doesn't release budgets in most companies.
Also not everyone gets it right, only because they got lucky once, history is full of one hit wonders.
Seems so. All the breaks from the first system in the name of “we’re doing it right this time” probably killed the momentum.
https://en.wikipedia.org/wiki/Second-system_effect
Even the best and brightest of us are still human.
Everything else. Seems everyone and their mother are building "platforms", so they can properly lock you in, look at Vercel for example, to get some inspiration where the rest is probably at least aiming.
Not sure why people keep falling for it though, guess it's easy enough to get started that people don't really want to understand deeper, if you can pay someone $XXX/month to not have to think about it, many people tend to go that route, especially if VC-infested.
Thus platforms and SaaS products, seem to be the only way to make sustainable open source products.
That would be much more sustainable than VC rat fucking the commons to make a buck while suckering in devs that were once good community stewards into dry husks that are only formed to generate profit.
Hundreds of hours? I'm sorry but if you truly needed that much time to find your way around an incredibly straightforward runtime that's on you. Skills for Deno, Node.js, Bun, Cloudflare Workers, browser-based JS and all the rest are like 99% transferable. If Deno doesn't work for you then use something else. It would probably be simpler to switch than writing all these aggressive blog posts.
Got shanghaied into TS-land right around Node 16 when they and TypeScript imposed mutually incompatible handling of ESM modules (that extensions mess).
Not only the type checker fail to understand of the kind of JS I had been shipping (and testing, and documenting, and communicating) up to that point; both the immediate toolchain, and people's whole pattern language around the toolset, were entirely broken as soon as you were doing anything different from the kind of React.js that later became Vercel.
Not only I was able to do 10% of what I was able to do previously conditional on jury-rigging the billion dollar stack to work, I also had a little cadre of happy campers on my ass blatantly gaslighting me that it is all, in fact, working; and suggesting the most inane "solutions" once I'd bent over backwards to demonstrate how there is, indeed, a problem of absurd dimensions, straight outta nowhere.
Later I met more such people. Same people who would insist JS runtimes are not trivially interchangeable, having committed to not examine what they're doing beyond a meager level of abstraction.
I see it as a rather perverse form of "working to spec" (have had to pick up surreal amounts of slack after such characters), but with incentives being what they are you get a cutthroat environment (such as the author of this blog post imagines to be living in), and from a cutthroat environment you get the LLMs eating everyone's breakfasts -- because no matter how yucky a word "synergy" is, synergizin' is that "fake open source" is designed to preclude, throughout the JS ecosystem.
"Fake open source" is how I call MIT/BSD licensed devtools and frameworks from hyperscalers that don't need to do an opencore rugpull because they're a piece of a long-term ecosystem strategy. They benefit from immense decade-long marketing and astroturfing efforts, lending them "default status" in the mindshare; and ultimately serve to carry the vendor's preferred version of reality into unrelated downstream projects. Which is why they often spectacularly fail to respond to the community's needs: they are built to preclude, past a certain point, the empowerment of implementors as a community.
Mastering some of that shit, now there was a sunk cost for me, but in modern JS land all these churning agglomerations play the role of "pay to play" gatekeepers. Considering what that's made the playing field be like, I'm happy pivoting to more niche technology just to keep away from said churning agglomerations.
My choice ranking is Deno Deploy > Fly.io > AWS for new projects, depending on complexity and needs. They also have a new Deno sandbox feature which is great for running untrusted code, AI agents, etc.
The real question is can they adapt to customer feedback fast enough, focus priorities, adequately market & grow, make it profitable, etc. Bumpy road but definitely not doomed.
So here is what is going to happen:
Deno is going to 100% get acquired.
Ryan Dahl is obviously rare talent and any company that gets Ryan would be incredibly lucky.
He has already done a Google Brain Residency so it makes sense for him to go to OpenAI or another AI lab for developing AI agents.
> Despite the initial hype, Rome tools, Deno & Bun will be quasi abandoned as the ecosystem outpaces their release cycle and the benefits don’t merit the headache of migration.
- Bun just got acquired by Anthropic, which has seemingly accelerated development. Last release: 4 days ago.
- Deno is still kicking as a company, this blog post notwithstanding. Last release: 3 days ago.
- Rome was forked into Biome. Biome last release: 4 days ago.
Bun is in much better shape than it was in 2023 and its future is less uncertain today than it was back then.
> "I could continue but it would just be cruel to dissect further."
1) You acknowledge that you think you've already at least bordered on "cruel", why would you want this? It's not clever.
2) You have the arrogance to think your opinion means this much to the creator when they've achieved far more than you.
I agree with all the comments saying this is unnecessarily critical. We're getting an amazing tool totally for free. Quit complaining.
I would not be surprised if they get bought by one of the big AI players anyway, given the weird purchases of Bun and Astral.
They had the right ideas but it's like investors panicked midway and demanded a change in direction.
Setting aside the fact that the S3 built-in API is now neglected, I'm skeptical about the runtime providing such APIs. As Ruby on Rails does well, these are issues that should be handled by the framework, not the runtime. While these APIs may seem convenient at first glance, breaking changes to APIs integrated into the runtime are difficult. It's not impossible, but it would likely cause dissatisfaction among many users. Furthermore, constantly keeping up with updates to third-party products would result in immense maintenance costs.
Users should also reconsider the extremely high backward compatibility that JavaScript has maintained before jumping on such hype.
Well there's no Rails for JS and in case you're not aware there's an absolute security disaster going on with NPM.
For a typical Node project dozens if not hundreds of dependencies need to be used. Eg Platformatic needs 258 dependencies of which 97 depend on a single maintainer.
https://npmgraph.js.org/?q=platformatic#zoom=h
You only need a single dependency to become compromised. And as anyone who has maintained a Node app knows, with all those dependencies you're like 5 mins away from an incompat issue.
Maybe another solution would be for the runtime to provide like a versioned standard suite of deps that matches the runtime version. So these are secure and fully compatible with the runtime and with each other.
I only use deps that support Bun like Hono and Drizzle but so far my experience has been flawless.
And yeah Node sucks for TS in comparison to Deno or Bun.
hmm, blog author doesn't know about Anthropic's Bun acquisition, and consequently shouldn't comment on "the entire AI industry"
Drunk sports fans are more coherent than this.
Pray you never have a “good enough” competitor.
I felt it should have aimed to be a 100% drop in replacement for nodejs then innovated on top of that.
This house of cards is about to collapse and lot of "smart" devs are going to act shocked when the water recedes.
The same thing always happens: companies "adopt" open source then, unless you have monopoly, money problems eventually appear and leadership sees this lovely team with "bloated budget" in the bylines.
[1] https://www.reuters.com/commentary/breakingviews/anthropic-g...
I assume the author is aware that Ryan Dahl created that too?
Not that it would make him immune to criticism, but the author comes off extremely petty.
However Anthropic owns Bun now, so a different story will unfold.
I never heard of Deno until today. So perhaps this was a marketing failure.
At that point I was left wondering -- if Bun and Deno have essentially the same strategy/approach, why would I pick the less mature option?
And so I ported everything to Bun
But I need to have everything in a mono repo for agents to properly work on in.
Cloud functions and weak desperation between dev and prod is a mess, even more so with agents in the loop.
Why was this a problem with Deno? Up until recently you had to use package.json and npm/pnpm for it to work, but even then it was better than Bun or Node since you could use import map to avoid compiling packages for testing etc (Node and Bun's type stripping doesn't work across local monorepo dependencies, and tsx produces mangled source maps making debugging a hassle). Now Deno has built-in workspace/monorepo support in deno.json.
Why is that? Seems like an agent framework limitation, not a reasonable requirement in general. (I do not have this limitation, but I also have a custom agent stack)
On my own machine I have a dev/ folder full of checkouts of other repos, and I'll often run Claude Code or Codex CLI in that top level folder and tell it to make changes to multiple projects at once. That works just fine.
In a poly repo setup, agents are less effective having to infer changes across repo boundaries using specs rather than code as context. Changes that impact multiple repos are also much messier to wrangle.
Who cares? Why does the world need so many fringe tools/runtimes? So much fragmentation. Why does every project have to be a long-term success? Put some stuff out if its misery. Don't waste the time of the already few open-source contributors who pour hours into something for no good reason.
The world doesn't need a dozen JS engines.
The world doesn't need many dozens of Linux distros.
The world doesn't need a handful of BSD distros.
The world doesn't need many dozens of package managers.
The world doesn't need hundreds of JS frameworks.
The world doesn't need dozens of programming languages or chat protocols or CI/CD systems.
The world doesn't need dozens of init systems, service managers, display servers, audio stacks, universal app formats, build tools/bundlers.
Deno may have dragged the JS runtime space forward, fully agree. Maybe it served its purpose and it is time to say goodbye.