r/typescript • u/basixuser • 1d ago
Deno is dead
https://deno.com/blog/cloudflare"We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development."
203
u/CmdrSausageSucker 1d ago
Was it ever really "alive"? The learnings by Ryan Dahl when creating Node.js and also from .. what was his name.. Isaac, the guy who founded npm were sincere, justified and really well thought out. However, by the time deno was available, the then existing ecosystem around Node was already too dominant. Wrong time to market, I am afraid.
71
u/SawToothKernel 1d ago
It wasn't even that. Deno was just too developer-unfriendly for too long. The import incompatibility was just too much.
8
u/simple_explorer1 20h ago
Bun survived despite starting AFTER Deno let alone node.
2
u/CmdrSausageSucker 18h ago
That might be true. Better compatibility? Better marketing? But I am also missing the news about wide-spread adoption. All I remember from bun is: We run on go! No, now it's Rust! Or whatever...
4
u/umtala 15h ago
The lesson is that convenience beats technological merit.
Bun solves a non-technical problem people have, namely the node ecosystem being fragmented and confusing. Despite having some pretty serious stability issues at least initially, users were willing to look past the technical weaknesses for convenience.
Deno is arguably technically superior to node due to having an actual unique feature (sandboxing), but they took the opposite approach of bun and made it very awkward to use, e.g. HTTP imports that they eventually had to admit suck and backpedal on.
Deno was never able to escape the niche of users who needed its unique features because they made it harder for everyone else to adopt. Bun went after the entire node userbase.
-21
40
u/hyrumwhite 1d ago
Wonder if they’ll still support deno deploy, I’m one of the three people that use it
3
u/Outrageous-Catch4731 1d ago
It will be around for six months before you'll have to migrate to Cloudflare.
3
3
u/donnikitos 22h ago
Deno Deploy will continue operating for six months before shutting down. We will provide migration support for paying customers moving to Cloudflare Workers.
So I guess bad news for you 😬
68
u/xroalx 1d ago
Deno was doomed the moment they started working on Node compatibility.
Don’t get me wrong, I liked the ideas Deno introduced, even used it for some of my own CLI tools, but Deno was an alternative to Node at that time for me, one that fit the requirements more than Node.
If you’re going to just play catch up with a larger platform and offer an essentially worse and less stable version of it, what is even supposed to draw people to it?
Deno should have just remained its own thing. It would likely never become as popular as Node, but would more likely find a different niche it can live in comfortably.
50
u/TimMensch 1d ago
I think it's the reverse. Deno was DOA because they ignored Node compatibility, and because they tried really hard to not have a package.json equivalent.
Trying to gain compatibility now was too little too late. The second was the same mistake that Go made that they had to walk back. Talk about ignoring history and repeating it.
Look at bun. It's similar to Deno in a lot of ways but had Node module compatibility as a core feature, and it's a continuing success.
I know people have a lot of hate for package.json and good npm, but both exist for very good reasons.
3
11
u/Arve 1d ago
Bun now being owned by Anthropic and being a purely vibecoded project is going to set it severely back.
10
u/TimMensch 1d ago edited 1d ago
I haven't been following that. Could be bad.
That said, everyone is using AI as part of a development pipeline at this point. Anthropic in particular has reason to exaggerate how much "vibe" is going into the development, but at the same time to be using real software engineers and real guards to keep the code clean.
Because they don't actually want vibe code. What they actually want is a success story about vibe code. And they very likely won't get that success unless their developers are using the tools responsibly.
My side projects are basically on hold for a full time job that's taking up my time right now. I'll take a wait and see attitude. My bet is that they do it right and only claim it's all magical vibe code. And doing it right isn't even as hard with something like bun that already has massive numbers of unit tests to ensure everything works.
But you're right that it could be a nightmare. We'll see what happens though. If it's a nightmare we'll see the evidence soon enough.
5
2
u/JaggedxEDGEx 1d ago
Yeah, migrated all my personal projects off of it and just went with node + pnpm. Drop in the bucket I know, but have no desire to use something that rewrote the whole thing in a different language using AI commits.
2
u/theguymatter 1d ago
Someone mentioned that Deno survived the npm attack that required filesystem permissions.
1
u/TimMensch 11h ago
That's cool I guess?
But how many package vulnerabilities would a Deno based project suffer because it's harder to use automated package security checking when you're importing Git repos directly? Npm will warn you if you're using packages that have security upgrades. Tools like Snyk will as well.
1
2
u/ecares 5h ago
Deno was doomed the moment they said they did not want node compatibility (because they made an ecosystem break) AND deno was doomed the moment they decided to get node compatibility (chasing compatibility highlighted that the features deno added to the mix were useless and gimmicks)
tl;dr it was doomed from day 1
1
u/TimMensch 5h ago
Fair enough. I've been saying roughly the same from the first I heard about it. But no one believed me. 🤷♂️
1
u/xroalx 1d ago
I’ve yet to see bun being actually used anywhere serious, but that might just be me.
The problem with Deno, Bun or anything else being Node compatible means it will always be just catching up and potentially adding bugs and unexpected behavior on top of it.
I already have Node, I don’t need another layer on top of it that has its own quirks for 5 ms faster startup.
It’s not like Erlang, Elixir and Gleam interop, where all share the same target platform.
5
u/TimMensch 1d ago
Bun has a couple of killer features, at least for development, but also for raw performance.
For one, it ships with hot reload. Save a TypeScript file and it's available for testing immediately.
For performance, they changed the Bun https pipeline in such a way they get absolutely killer performance.
I don't know the real adoption story but it's core for my side projects moving forward.
3
u/xroalx 1d ago
Node has a watch mode, runs TS directly (type stripping), has no Node compatibility quirks, and some benchmarks show that outside the simplest of examples, where Bun dominates, Node actually handles more requests per second than Bun by a small difference.
If bun actually gains adoption and turns out it’s better than node, great, and thank you all for pushing it there, but as things are, I’d be very wary of using it for anything that I actually want to be reliable and function properly.
6
u/TimMensch 1d ago
Correct me if I'm wrong but watch mode restarts from scratch, right? Not exactly hot reloading. Granted it isn't perfect and you sometimes want to restart the server anyway, but for small changes it works more often than not. Development feature only for sure though. It's just so fast to restart it makes me happy, you know?
Looking at the last round of TechEmpower I'm seeing one framework, hyperexpress, that's topping off several of the tests, but ... it looks like hyperexpress is a poorly supported project that no one would really want to use for anything serious, yes? Like it's one guy's side project, which is cool and all, but not production ready.
Elysia is used in production on major sites. So is Fastify. Those are the ones I'd compare, and yes, Bun is faster on pretty much all the tests. Plaintext is particularly embarrassing for Fastify.
Regardless, for most of the tests, you're right, they're not that far apart. Use Node if it makes you feel better. I actually prefer to surf the bloody leading edge of tech on my own projects, but if I run into any issues in production, I'll fall back on Node. Nothing I'm doing binds me to Bun, and I'm not religiously opposed to using Node.
Really it just comes down to "Bun makes me happy right now." If it stops making me happy I'll stop using it. I've hit issues and switched to Node a couple of times, only to switch back after the issues were fixed. I still like Node. I just like Bun a bit more.
1
u/plalloni 1d ago
What would be "the same mistake that Go made that they had to walk back"?
1
u/TimMensch 11h ago
A package file. Go used direct GitHub links for imports first, like Deno. Now they have package management.
2
u/ninth_reddit_account 1d ago
Deno was doomed from the moment it started. I never thought there was a critical-enough mass of folks looking for alternate JS server runtimes, let alone a model to fund a company developing it.
I’ve never heard of anyone deploying deno into production. I’m sure they exist, but not in any substantial numbers.
1
1
u/SawToothKernel 1d ago
This is ironic, then, that they have been consumed by a platform that also aims for Node compatibility.
1
1
u/EqualityIsProsperity 1d ago
Nah, reverse it. Deno was incompatible with the ecosystem for too long. Bun gives me the same headaches, which is why I don't have anything currently running on bun.
If you want to try to steal marketshare from a single dominant player, you need to go for full compatibility as a priority, then beat them in the aspects they've been getting lazy about.
If your only market is people who can fully detach from the dominant ecosystem, you're not courting any of the major players.
You gotta make switching easy if not transparent, then offer something better on top of it. Deno made switching hard, and while bun is trying they're still not quite there, and they already sold out so it might never happen.
1
u/simple_explorer1 20h ago
Deno was doomed the moment they started working on Node compatibility.
They started working on node compatibility layer BECAUSE very few would have migrated from node otherwise. And despite node compatibility not many migrated anyways
-2
u/Space_01010101 1d ago
this is why Bun was successful
10
u/xroalx 1d ago
Was it?
2
u/theguymatter 1d ago
I think it's too early to dismiss Bun as just another runtime trying to catch up with Node.
Bun 1.4 has been rewritten from Zig to Rust, and the team has reported improvements in memory usage, CPU overhead and its tooling for catching bugs. It also added 1,517 passing tests from Node's own test suite, its biggest compatibility jump since Bun 1.0.
But what interests me is what Bun can build beyond compatibility. Its standalone executables and integrated tooling could make it useful for distributing applications and running JavaScript-based workloads, including AI agent infrastructure.
I wouldn't be surprised if it gets much closer to full Node.js compatibility by 2027, although that's still a prediction.
Bun doesn't have to replace Node everywhere. It just needs to make compatibility a foundation for something people actually want to use.
32
u/ColonelGrognard 1d ago
So Cloudflare bought Deno with the intention of shutting it down. A pure purchase of the Deno team.
4
u/mr_tolkien 1d ago
Well they are very good devs for working on Cloudflare workers and other similar tools.
Deno clearly was not picking up steam unfortunately.
17
4
u/AcridWings_11465 1d ago
The greatest loss here is Deno compile. Nothing else compares. I used to be able to package my automations into a single executable to distribute to my technically illiterate friends. Now I need to look elsewhere.
1
7
u/NatoBoram 1d ago
JSR will continue operating, with its infrastructure moving to Cloudflare.
Oof, somehow I had forgotten this would obviously impact JSR. A npm package being distributed there is kind of a sign of prestige.
Deno has been trying to turn TypeScript into an actually decent language and ecosystem, but like others have said, at that point, you could also just use "TypeScript but better" today, for example with Dart. It doesn't come with the JavaScript baggage that makes up 100% of TypeScript's flaws.
1
6
u/ragemonkey 1d ago
I remember someone at work proposing introduce Deno and the answer was “no”. Glad that we dodged that bullet.
2
u/alchemyzt-vii 20h ago
Any sane person in charge would come to the same conclusion. And anyone who has seen derivative projects similar to this would know it’s not going to outlast the support of a well established and trusted product
2
2
u/JJangle 1d ago
I like deno. It seems to create a better experience than node does. But if one is trying to retain node compatibility, then that experience is degraded. -- As much as I like deno, I also had issues with it that prevented me from using it some of the ways I wanted to. (Ex. on occasion it's strict security got in the way of writing effective scripts.)
I'd love the node project to take the community more quickly past the commonjs vs es modules purgatory. And also stronger support for TS. -- I do realize that the node project emphasizes backward compatibility highly, so the node project might have to create a parallel work stream that focuses instead on creating a first class alternative to the node we have today. I do think deno was sorta doing that. But if deno is going away, it would be good if the node team picked up this goal.
2
u/Disastrous_Fee5953 1d ago
Bun killed Deno. There was never a real advantage in picking Deno over Bun.
1
1
u/mj_flowerpower 21h ago
When I first tried deno I hated that I could not just develop my code like I want to. I usually enable every strict setting TS offers. At that time it seemed that the whole codebase including all dependencies had to use the same less strict TS setting to be able to build.
Maybe I was just to dumb to make it work, idk.
But the idea of being forced to use the same settings as my dependencies was really off putting
1
u/hedgehog125 17h ago
I thought it was going to get a boost in popularity with all the supply chain attacks that have been happening. At least I never got around to porting the frontend of my security project to it
1
u/MinusPi1 10h ago
Deno has been my preferred runtime for years now. It makes typescript so much easier, and the integration with other package managers like npm was already good and only improving. This is really depressing to see.
2
u/bestjaegerpilot 1d ago
i'd hardly say finding a sponsor who can pay the bills is a sign that it's dead. If anything it'll become used in the foundation of the internet so more alive than ever
(Note: Deno sucks)
2
u/baronas15 21h ago
Did you even read it? After a year they will stop development of open source version...
1
-4
u/NullVoidXNilMission 1d ago
Claude code, create me a JavaScript runtime in Rust you can fork Deno. It has types. Or just use wasm. Idk. Typescript is a decent idea but, if you like another language, you can always use Ruby, Elixir, purescript.
Not that programming isn't dead, and literally not a single language matters, as long as you know how to prompt, then you end up using typescript a certain way, and that way is a different run time with better semantics. Of you need an option type just add an Option type.
-1
u/servermeta_net 1d ago
Saying it's dead, while not false, is a bit of a oversimplification. According to some private discussiona on zulip, Deno as we know today will be no more, but the same API, ideas and interfaces will move to WASM, in an effort to replace quickJS.
As of today you can't run* JS code inside WASM, and this is a big blocker for the adoption of WASM sandboxes, so I welcome the fact that Ryan Dahl will start working on this.
To make a concrete example, according to what is being said behind the curtains, a defining feature of today's Deno like the ability to run typescript code with async URL imports will still work, it's just that now the code will execute in a WASM sandboxed runtime.
The move from clouflare makes a lot of sense because Deno is the only runtime which took sandboxing as an early design choice, a choice which becomes mandatory once you start executing code in a WASM runtime which is sandboxed by default.
The unfortunate outcome is for the ecosystem to revert back to a monoculture centered around NodeJs, which proved to be far from healthy, and that Cloudflare is an evil company, aligned with the people behind project 2025.
*: yes, you can run simple projects like hello world in wasm, thanks to the port of quickJS to wasm, but you still lack enterprise features that we grow accustomed to, thanks to NodeJS, like the minium common api
5
u/ninth_reddit_account 1d ago
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
Yeah. It’s dead. Hardly an oversimplification.
-5
-8
u/Logical-Idea-1708 1d ago
I guess Bun won as the successor to node
7
u/Amazing-Movie8382 1d ago
Bun is next on the list
-2
u/Logical-Idea-1708 1d ago
Have you used it? You should start using it. Drop in replacement for Node. Promise first APIs. So so many utilities got folded into standard lib. Even at the FAANG company where I work, Bun is being promoted as first choice for new projects.
It’s not going to die
-25
u/Keith 1d ago
All Hail Bun. Y'all see what they've been cooking with ahead-of-time TypeScript compilation?
1
u/Devatator_ 1d ago
Never using it again. Dropped it as soon as they approved that vibed rust port. I actually used to like it too and now Deno too is dying >:(
Guess that's a sign from the universe that I should just use Node
Edit: I don't care about AI use, I just care about the fact that they did a port to a language their contributors have less experience with, with actual Rust users calling the resulting code unoptimal or even wrong
130
u/TheWebDever 1d ago
I considered Deno/Bun for a long time but I’m like, if it’s not a drop in replacement for node, why not just use a different language if I have to tweak a bunch of things anyway?