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.

▲

daveidol 6 hours ago | parent | next [-]

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

	▲	cscheid 2 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

▲

tempest_ 5 hours ago | parent | prev [-]

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