r/typescript • u/basixuser • 18d 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."
218
u/CmdrSausageSucker 18d ago
Was it ever really "alive"? The learnings by Ryan Dahl when creating
77
u/SawToothKernel 18d ago
It wasn't even that. Deno was just too developer-unfriendly for too long. The import incompatibility was just too much.
5
1
u/Rechenplaner 1d ago
For entirely new projects, it was the opposite. I don’t know of any other tool that was this handy.
14
u/simple_explorer1 18d ago
Bun survived despite starting AFTER Deno let alone node.
5
u/CmdrSausageSucker 17d 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...
9
u/umtala 17d 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.
1
u/Rechenplaner 1d ago
I think it would have been better if Ryan Dahl had tried to improve the Node ecosystem directly; for instance, by focusing on full TypeScript support, an improved package system, simplified tooling, and so on.
However, as a competitor, Deno has certainly had a positive influence on Node.js. I noticed this when I switched to Node.js: it wasn't nearly as bad as I had expected, and I’m quite satisfied, even though Node.js only supports TS's typing (which is actually sufficient).
-21
41
u/hyrumwhite 18d ago
Wonder if they’ll still support deno deploy, I’m one of the three people that use it
20
7
u/donnikitos 18d 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 😬
5
u/Outrageous-Catch4731 18d ago
It will be around for six months before you'll have to migrate to Cloudflare.
3
71
u/xroalx 18d 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.
56
u/TimMensch 18d ago
I think it's the reverse. Deno was DOA because they ignored
, and because they tried really hard to not have a package.json equivalent. Node compatibility 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.
4
14
u/Arve 18d ago
Bun now being owned by Anthropic and being a purely vibecoded project is going to set it severely back.
6
11
u/TimMensch 18d ago edited 18d 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.
1
u/JaggedxEDGEx 18d 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 18d ago
Someone mentioned that Deno survived the npm attack that required filesystem permissions.
1
u/TimMensch 17d 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 17d 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 17d ago
Fair enough. I've been saying roughly the same from the first I heard about it. But no one believed me. 🤷♂️
2
u/xroalx 18d 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 18d 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.
1
u/plalloni 18d ago
What would be "the same mistake that Go made that they had to walk back"?
2
u/TimMensch 17d ago
A package file. Go used direct GitHub links for imports first, like Deno. Now they have package management.
2
u/ninth_reddit_account 18d 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
u/Active_Name5021 11d ago
I have one app running in prod based off deno. I really liked their support for browser compatible APIs and native typescript support. I feel stupid now...
I'm wondering, does anyone know a decent alternative?
1
1
1
u/SawToothKernel 18d ago
This is ironic, then, that they have been consumed by a platform that also aims for Node compatibility.
1
1
u/EqualityIsProsperity 18d 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.
2
u/410LongGone 17d ago
Yeah, Bun has lots of these little inconsistencies that're annoying as hell to run into, FS stuff comes to mind for me
1
u/simple_explorer1 18d 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 18d ago
this is why Bun was successful
10
u/xroalx 18d ago
Was it?
1
u/theguymatter 18d 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.
36
u/ColonelGrognard 18d ago
So Cloudflare bought Deno with the intention of shutting it down. A pure purchase of the Deno team.
8
u/mr_tolkien 18d ago
Well they are very good devs for working on Cloudflare workers and other similar tools.
Deno clearly was not picking up steam unfortunately.
19
5
u/AcridWings_11465 18d 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
6
u/NatoBoram 18d 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.
3
6
u/ragemonkey 18d ago
I remember someone at work proposing introduce Deno and the answer was “no”. Glad that we dodged that bullet.
2
u/alchemyzt-vii 18d 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
3
u/JJangle 18d 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
2
u/mj_flowerpower 18d 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
1
u/hedgehog125 17d 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 17d 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.
1
1
u/Revolutionary_Loan13 16d ago
Untyped languages with low performance are no longer considered "good enough" in the age of AI
3
u/Disastrous_Fee5953 18d ago
Bun killed Deno. There was never a real advantage in picking Deno over Bun.
1
u/trymeouteh 11d ago
I like how Bun is now entirely in Rust but the way it was done with AI is concerning long term. If Bun uses AI that's fine, but if Bun is vibe coded AI slop that is going to be a disaster.
I also did not like there being 3 major runtimes in the JS space (Node, Deno, Bun) and do prefer there being 2.
However a few years who I thought Deno would be the future since the guy behind Deno was the one who created Node, but Bun has good Node compatibility, good tooling, and is focused on speed/performance. Deno was focused more on security and I thought was was a cool approach having all of the permissions prompts before running JS code. I hope Bun adds this security feature in the future and other programming languages add this feature as well which is handy when working with 3rd party packages.
1
u/bestjaegerpilot 18d 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 18d ago
Did you even read it? After a year they will stop development of open source version...
1
-4
u/NullVoidXNilMission 18d 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.
-2
u/servermeta_net 18d 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
6
u/ninth_reddit_account 18d 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.
-9
u/Logical-Idea-1708 18d ago
I guess Bun won as the successor to node
9
18d ago
-5
u/Logical-Idea-1708 18d 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
-26
u/Keith 18d ago
All Hail Bun. Y'all see what they've been cooking with ahead-of-time TypeScript compilation?
1
u/Devatator_ 18d 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
0
135
u/TheWebDever 18d ago
I consideredDeno Bun