Deno's Decline

Original Article ↗ Hacker News Discussion ↗

Webdev Churn & JS Tooling Fragmentation

  • Several comments frame frontend as perpetual churn: new frameworks and runtimes every few years, often “reinventing” older ideas like server‑side rendering.
  • Some argue this is because the “right” solution hasn’t been found; others blame JavaScript’s weak “batteries included” story, which forces ecosystem tools to be constantly re‑invented.
  • Comparisons are made to Python’s fragmented tooling; many see JS as even worse.

Node, Bun, Go, Rust & TypeScript

  • Strong sentiment of “no more JS rugpulls”: many prefer to stay on Node for its stability, ecosystem, and tooling.
  • Others say Node’s very rough edges (ESM vs CommonJS, TS setup, package managers) are why Bun/Deno get any attention.
  • Bun is praised for “just works” compatibility, speed, and first‑class TypeScript, though concerns about crashes and lack of a business model are raised.
  • Some suggest if you truly want performance and simplicity, Go or Rust are better than any JS runtime, with TypeScript’s own move to a Go compiler cited as evidence.

Perceptions of Deno’s Traction & Direction

  • Mixed views on whether Deno ever had real adoption; some cite extension download numbers, others say community channels feel small.
  • Several people like Deno’s APIs, security model, URL imports, and “batteries‑included” feel, using it heavily for scripting and glue code.
  • Others bounced off due to incompatibilities, immature or confusing framework options (e.g., Fresh), and difficulty integrating into existing JS tooling.
  • Node compatibility and JSR are seen by some as backtracking on the original “clean new runtime” vision, turning Deno into a Node/NPM clone plus its own registry.

Deno Deploy, Regions & Business Model

  • The article’s “decline” evidence (Deploy regions cut from 35→12→6) is a central topic.
  • One camp views this as a serious warning sign and a “rug pull” on the broader Deno philosophy; another says it’s just rational cost‑cutting around a weakly used product.
  • Multiple comments stress the distinction between Deno (runtime) and Deno Deploy (hosting); criticism is mostly aimed at Deploy and VC‑driven SaaS pivots.
  • Some see a possible “dip” before recovery; others doubt tools like runtimes can sustain VC‑style businesses at all.

Security, Dependencies & Compliance

  • Deno’s permission flags and sandbox are widely admired, but several note that real risk lies in transitive dependencies; Deno doesn’t yet solve per‑package permissions.
  • Lack of mature SBOM/SCA tooling for deno.lock and distributed HTTP imports is a blocker for organizations with compliance requirements.
  • Some argue the security advantages are undermined in practice because most real apps must grant broad env/network/filesystem permissions anyway.

Ecosystem Fatigue & Historical Parallels

  • There’s broad skepticism that alternative JS runtimes can dethrone Node, drawing parallels to historic “second implementations” (alternative Python/Ruby VMs, database forks).
  • Others counter that forks sometimes do win, but note it’s extremely hard to unseat an entrenched platform.
  • Several participants express general exhaustion with JS ecosystem churn and a growing preference for “boring,” well‑tooled languages and runtimes.