undefined

points

[-]

I lead a project built on Deno; it was not my call, just to be clear. Deno turned out unfortunately to be a miss and we had seen the writing on the wall. FWIW, we're moving to a much bigger Rust core program with node for JS user extensibility. (In other words, I'm not willing to risk using the deno_core crates.)

The one silver lining here is that Deno had already increased their node/npm compatibility. Migrating off of the jsr ecosystem and back to npm is going to be less painful than one might imagine. I expect present LLMs to be sufficiently good at the task, for example.

by daveidol9 hours ago|

parent|

[-]

Can you elaborate on why it was a “miss”?

by cscheid5 hours ago|

parent|

[-]

A few things off the top of my head (we've been on deno since 2022)

- They originally bet on being a TypeScript dialect that didn't quite match the expectations of node in a few small places that ended up mattering hugely.

- One of the original value propositions was "deno compile" and "deno bundle", and those never actually worked well enough to be robust for our real-world use cases (early on they didn't support TLA, then dynamic imports didn't work, then they had issues with ARM compilation)

- Then they simultaneously tried to support node syntax out of the box with npm import specifiers _and_ create a new javascript registry (jsr.io)

- At the point where we expected them to actually make their base-level ecosystem robust, they pivoted to edge compute, and then the writing was on the wall

by tempest_8 hours ago|

parent|

prev|

[-]

LLMs writing rust that no one reads will spell doom for all the server side JS stuff in time.

by gritzko10 hours ago|

prev|

[-]

Do these runtimes have some value today? Sort of. But the cost of reimplementing them goes down, down, down. I made two bespoke JS runtimes within a year. Next year it will be even easier.

Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.