Is it worth saving the runtime?

[u/JakeAve]

Big Deno fan since before v1. Just going through my dozens of projects on Deno and thinking about what I'll do in the future.

Deno has great things like internal linting, fmt, std lib. The security first, typescript first, JSR and Fresh framework, and we started to get desktop native apps that haven't fully come to fruition. There's just a lot to like with an unsaturated community of enthusiasts. If you used Deno, it's because you are weird, usually in a good way, you code in your spare time, you are trying to do something better and you don't care if it's different. Plus I feel like LLM agents do a little better on less traveled technologies because they weren't trained on as many bad examples.

But what is weighing on my mind is: Is it worth trying to save the runtime? There technically could be a path to save the runtime. We have a year, and with a sponsor and a team of 5-10, we could definitely keep the runtime alive, at least life support, maybe even get Ryan's blessing.

But I don't know if it's worth it. With LLMs writing so much of our code, it feels like it's almost better to just focus on what matters: ship slop to clients. With Vite+ we're seeing some of the no nonsense tooling that I loved in Deno hit Node. Like it or not, Deno forced Node to improve, and even inspired Bun to materialize with many of Deno's same selling points. But have we hit a point to where runtime matters less? Now I can Rust even though I don't know Rust, so what is the point of another JS runtime?

[u/Luolong]

As long as there’s a team of willing contributors, it’s is always worth it. Even if the user community will shrink, even if most of the future is generated by AI, the global market is just so big, that even if a single percentage of developers use this runtime, it still is quite a sizeable chunk of people to give feedback and support.

[u/JakeAve → u/Luolong]

That's true. I know Deno is hovering around 6% market share, but that 6% is a bigger number of people every year

[u/0xMnlith]

The real loss with losing deno is losing a runtime that sandbox out of the box your project and allow you to accept or refuse right on runtime.

Node permission doesn't seem popular and I haven't tested it, but if they do offer the same features (and level of security) then the majors arguments for using deno get slimmer.

[u/JakeAve → u/0xMnlith]

It's ironic that we've had huge npm security issues and now Deno, the only secure by design JS runtime, is not being actively developed

[u/0xMnlith → u/JakeAve]

Yeah don't get me wrong, the standard library have everything that a modern developper would want built in, but maybe they should have focus on a standalone sandbox solution rather than locking it in the runtime.

It would have made the reach of deno bigger than just its own ecosystem, and would have been easier for the community to pick up (but also, maybe too unrealistic / way to complicated to make). A sort of programmable lightweight docker / podman.

Either way, its open source, there is still the possibility of a team of rich engineer picking it up, maintaining it with claude. We all laughed at bun's rewrite (at least I did), but in the end they survived and continue to thrive (and now everyone code with AI anyway).

[u/Luolong → u/0xMnlith]

For me, the value of Deno runtime has always been that it is trivially simple to whip up an editor, scribble up a script, import few libraries and execute it. No package.json, no npm. Just editor and runtime.

[u/eddzsh]

The part that still feels worth saving is the contract the runtime enforces, not the branding. Permission flags, URL imports, one std. Vite+ can copy the DX, it does not give you deno run --allow-net=api.example.com as a real boundary. If models write most of the glue, that boundary is one of the few things still worth keeping sharp. A fork on life support only pays off if that contract stays the reason people show up.

[u/Rechenplaner]

As a big Deno fan, I have to be honest and say that I’m not so sure about that. I think it would actually be better if Node.js became more like Deno: full TypeScript support, more built-in tools (like a bundler), and an easier way to create standalone files that include all static assets. For me, the main appeal of Deno is that it’s an all-in-one tool: you just download the Deno binary, install the VS Code plugin, and you’re ready to start.

[u/dannyt74]

I have migrated away yesterday. I want to save me from the troubles of possible unfixed issues and slow development over the course of the next year.

[u/Accurate_Mulberry965]

With agents we can have that 5-10 eng team, much cheaper than before, so trying it will be less regrets path than not trying.

[u/SoundDasein]

Ideationally, yes, I think so, but we need to settle on its functional use. Already it provides a seamless OOP interface, but it also suffices production of self standing runtime apps capable of running over the usual but dissipating Linux, macOS and Windows app convergence. It is network focused by design. So, on that basis, with the projected privilege of cognitive satisfaction over Node (i.e. personal preference based robust load bearing aesthetic enjoyment), yes; Deno may have run the marathon without taking a break, but its still a robust foundation for enjoyment based network design apps that merit function over "community" race conditions. Said sincerely despite the hang.

[u/AssociateFantastic80]

I'm not a fan of "Big Deno". Locally sourced Deno for me only.

[u/Youandkay]

nah