Trying to pull people away from reference tooling requires lots of investment and historical has always failed.
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.
I’m not familiar with the author but something about this post just seems mean-spirited and petty.
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.
I didn’t like the tone of this. Building a company is hard. Building an VC-backed open source product is really, really hard.
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.
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.
I'm not fully convinced that there's a tenable model for open source devtool companies. Usually there's some handwavy plan to do hosting or code quality that never comes to fruition. Hosting is a hard business and the 800 pound gorilla in the room of AWS is even harder to surmount. Otherwise, I'm not sure what business model you can look towards. Support maybe?
Yeah, I mean Deno’s success is predicated on enterprises moving production apps from NodeJS to Deno. Node is extremely established and entrenched, and migrating the goddamn runtime of a large production server is not usually an easy project. If I have a 5-10 year old Node project, it might work well on Deno, but almost no one has the time to champion a migration when it just doesn’t have that many benefits.
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.
Open core can work, but you really have to find very strong product market fit on the proprietary side--ideally with features that discriminate between users who are relatively happy to pay and users who are not. (There's a reason "SSO tax" is so common.)
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.
"Become integral enough to the toolchain at OpenAI or Anthropic that they buy you" seems like the new one. Normally I dislike startups built with the intention to be acquihired instead of being a sustainable business, but with open source devtools maybe that's not the worst thing. I'm pretty confident that neither bun nor uv will stop existing anytime soon, and the makers got paydays out of it.
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.
I'd argue that the mainstream, lowest-common-denominator tools are the ones which waste people's time. (Especially when they're backed by an incumbent. Deno, on the other hand, clicked immediately.)
Why this person is so mean to someone who gifted Deno and Node to the JS ecosystem? It's not fair. They are trying to build a company on top of open source.
I could get behind some of this hate directed to Vercel’s CEO or even Cursor’s, but Deno is sort of like a breath of fresh air around the myriad of parasitic tech out there. Still, why so much hate? Who hurt you? What’s going on
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.
> 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.
I won't speak for Ryan, but these last 7/8 months have been extra extra hard for me with Mikeal dying, and at least, Ryan was as close to Mikeal as I was, so I'd guess it's been a hard time for him too. Being ambitious and taking on a lot is always... a lot, and he's been at it with Oracle as well. It doesn't get any easier the older you get, to be honest. Cut him some slack eh?
Like other commenters the tone of this post threw me off but I was really impressed by the design of the website. Congrats for building it, it shows your hard work and taste!
I find the irreverent tone refreshing, personally.
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.”
Pivoting to node support and even more-so rewriting deploy really hurt momentum on top of all those projects. Coming out swinging with 2.0 and then decreasing regions and rewriting the product that makes you money soon after was certainly a choice.
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.
It's easy to be critical in hindsight but honestly when Deno first came out it was pretty incredible. Even the whole idea about URL based imports makes lots of sense but it was incompatible with any of the existing toolchains that were wildly popular. At the same time, companies like Vercel launched a new kind of framework and leveraged that into a hosting business with I would say great success. They captured developers where they were at _today_, including acknowledging the demographics, the tools, the culture, etc.
Compatibility aside, Url-based imports are a bad idea as soon as you go beyond writing your entire program in a single source file and want to keep imported versions of common dependencies in sync. It's nice for scripts, but a deno.json file is better.
71 comments
[ 3.9 ms ] story [ 50.3 ms ] threadBut 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[0] https://news.ycombinator.com/item?id=47426659
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.
[0] https://deno.com/deploy
> 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.
https://blog.raed.dev/posts/predictions_2023
Bun is in much better shape than it was in 2023 and its future is less uncertain today than it was back then.
- 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.
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
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.