Deno 2.8

Release status and features

• At the time of the HN thread, the official v2.8 blog post was missing, but the GitHub v2.8.0 release tag was live.
• Noted features from comments: deno pack for simple single-executable-style packaging; stronger Node compatibility (around 76% of Node test suite vs ~40% for Bun); ongoing performance improvements.

Deno vs Node vs Bun

• Node is seen as the “forever” baseline: mature, stable, with growing TypeScript support and upcoming single-binary builds.
• Bun is praised for speed, simple “all‑in‑one” DX, and near drop‑in Node compatibility; early benchmarks and marketing drove adoption, though some question whether Zig/memory tweaks fully explain the speed claims.
• Deno is liked for its permission model, Rust base, native TS, web-standards focus, and solid CLI/stdlib. Several users say it feels like a “grown‑up Node” and use it happily for small to mid-size services and some production workloads.

Ecosystem, compatibility, and DX

• Early Deno decisions (URL imports, no npm, deliberate Node incompatibility) are widely seen as having slowed adoption; people struggled with popular tools (e.g., Astro, Prisma, Vite) and testing npm packages against Deno.
• Deno’s later pivot toward npm and Node APIs is viewed positively by some as pragmatic, but others see it as abandoning its original clean-break vision and JSR ecosystem.
• Bun is frequently described as “it just works” for typical TS/React/Node workflows, including local package linking and clearer error messages.
• Some complain Deno’s newer defaults (e.g., including Node types by default) pollute pure web/Deno code and erode its distinct DX.

Security and trust

• Deno’s permission flags (--allow-read, --allow-write, etc.) are valued, but some call them “basic” and advocate for finer-grained capability systems.
• There’s debate over whether recent npm supply-chain attacks would be mitigated by Deno’s model; lifecycle scripts are not run by default, but other vectors remain.
• Corporate ownership of runtimes (Bun by Anthropic, uv by OpenAI) raises “platform risk” concerns; some see more funding as safety, others see acquisitions as a long‑term risk compared to foundation‑backed Node.

TypeScript and browsers

• A side discussion asks why browsers don’t natively support TypeScript.
• Replies emphasize TS as a compile-time layer over JS, backward-compatibility constraints, performance/semantics issues, and ongoing but slow standardization efforts around type annotations rather than full TS.