Thank You, Deno

63 pointsjcbhmr7 hours ago11 commentsView on HN

I'm really sad about the announcement and that the Deno runtime as it was is going away. I'll definitely be following and likely using an active fork if it presents one.

I've been using Deno a lot for straight shell scripting. Being able to link directly to dependencies and run without a separate install step or node_modules directory is huge. The fact that it's a single binary download and can self update is so nice too.

I'm not sure if these features are similar for Bun or not. I'm just sad about the whole thing.

ameliaquining4 hours ago

Bun supports this if your dependencies are npm packages: https://bun.sh/docs/runtime/auto-install

It is also a single self-contained binary and has a self-updater.

NetOpWibby1 hour ago

There's a fork-in-progress called "Dodo," the Discord server is quickly filling up. https://github.com/denoland/deno/issues/37030#issuecomment-6...

Dodo aims to be a drop-in replacement.

Then there's Ende, my fork, and I ripped out Node compatibility, Deploy, KV, Jupyter, &c. https://ende.sh

ChrisArchitect4 hours ago

Cloudflare acquires Deno

https://news.ycombinator.com/item?id=50019911

crabmusket2 hours ago

> Deno 1.0 shipped in 2020 on the original terms, & then spent the next four years walking them back one piece at a time. First the deps.ts convention, one file that re-exported every URL: a manifest in all but name. Then lock.json, an integrity hash per URL: a lockfile. Then import maps, so you could write bare specifiers again.

I object to two of these categorisations.

deps.ts was a convention, not a built-in runtime feature. If you want to follow the convention, that's fine. It's just a regular old typescript file!

Import maps were not Deno walking back, but implementing a web platform feature. Parity with browser JS was a standout feature of Deno from the beginning. This was walking forwards if anything.

However, broadly, the story is indeed one of Deno moving away from its opinionated roots towards pragmatism (drop-in replacement for Node).

BrunoBernardino11 minutes ago

Thanks for calling that out, it also stood out to me as "falsy".

egeozcan47 minutes ago

Thank you deno!

You are added to the list of projects I thought would really become essential to my work but slowly faded away. Another one, for example is rethinkdb.

At least Deno actually caused some movement in the node world, just like io.js.

rob7446 minutes ago

I guess between the original Node and the many alternatives that aren't Node (that I, a former PHP guy using Go for side projects, wish would gain more traction) there isn't enough of a niche for a "mostly like Node, but with fewer warts" project?

pimterry37 minutes ago

Partly yes, but I also I think more than expected Node has been able to fix a lot of the warts itself within the existing model, which really undermines the niche further.

Quothling12 minutes ago

I think it was more a question of what that niche was meant to be. Bun does alright in the "we don't want external dependencies" space of Node development. We switched a lot of our Go projects to it because it allows us to use nothing but Microsoft packages for Azure and Bun, similar to how we were using Go, but now we have a language less. Bun is largely a dropin for node though, and it would be rather easy to switch back.

RadiozRadioz9 minutes ago

I do think those of us who were long skeptical of Deno are owed a small "I told you so".

Fundamentally, there is a big sect of the JavaScript ecosystem / culture that is hype-driven and has extreme churn. Jumping to every new framework and runtime without thought for the long-term, or any regard for historical patterns.

This stuff keeps happening. Somehow I'd love to get through to the perpetuators of the JS hype treadmill that they're only hurting themselves and making themselves look foolish when the churn inevitably hurts them and the wider ecosystem.

But maybe they jumped to the next shiny thing after Deno before Demo's demise was announced, and they'll learn nothing.