Friendship ended with Deno, now Node is my best friend
A blog post arguing there is “no reason to use Deno today” reignites debate over the relative merits of Node.js, Deno, and Bun as JavaScript/TypeScript runtimes. Commenters contrast Node’s stability, longevity, and growing built‑in tooling (like `node:test` and TS type-stripping) with Deno’s integrated toolchain, stricter security/permissions model, and JSR ecosystem, and with Bun’s performance claims and ergonomics—tempered by concerns over bugs, compatibility, and recent corporate drama. Several point out that AI coding assistants now strongly influence runtime adoption by defaulting to popular stacks, which may be accelerating consolidation around “boring” choices like Node even when alternatives offer better developer experience or security.
Runtimes: Node, Deno, Bun
- Many see Node as the “boring, safe bet”: long‑lived, stable, likely to outlast newer runtimes.
- Deno is viewed as philosophically nicer and more modern, but seen by some as drifting into obscurity.
- Bun gets praise for ergonomics and speed, but also concern over past bugs, the Rust rewrite, acquisition drama, and alleged politics around its creators.
Why some prefer Bun
- Praised as “lighter” than Node/Deno: fewer dependencies, integrated bundler/test tooling, easy TS builds, and single‑binary deployment.
- Some report good DX and reduced need for shell scripting.
- Others counter that in simple benchmarks Node used less memory and similar CPU, questioning Bun’s performance narrative.
Why some stick with Node
- Considered mature, stable, and widely compatible; “good enough” performance.
- Some say everything else eventually gets reabsorbed by Node’s ecosystem.
- Built‑in
node:testand coverage are noted improvements, though linting/type checking still need extra tools.
Why some still choose Deno
- Strong points: built‑in test/lint/check, simple TS story, security permissions, JSR/standard library, and ability to compile to a single binary.
- Desktop/WebGPU support and sandboxing are highlighted as unique advantages, especially for agent/AI use.
- Several like its “one CLI, batteries included” feel versus Node’s config/tooling sprawl.
HTTP and compatibility debates
- Heated debate over HTTP GET with a request body:
- One side insists it’s non‑standard and unsafe; implementations can ignore it.
- Others note widely used tools (e.g., Elasticsearch, some GraphQL clients, infrastructure tooling) rely on it and expect Node‑style behavior; Bun’s stricter behavior is seen as a compatibility break.
TypeScript and ecosystem
- Disagreement over the article’s claim that Node’s TS limits are “philosophical” anti‑Microsoft; commenters cite concrete technical reasons (tsconfig differences, performance).
- Some argue declaration files solve most library‑typing needs; others just want simple type‑stripping for TS source.
- Broader split: some view TypeScript/strong typing as essential for non‑trivial systems, others see TS as overhead with limited benefit.
LLMs and tool choice
- Several note that LLMs often default to Node/Bun/Next.js/Supabase, nudging adoption.
- Others argue competent users should explicitly tell LLMs which runtime/stack to use; “LLMs don’t reach for it” mainly affects product popularity, not capability.