Deno in 2023

Original Article ↗ Hacker News Discussion ↗

Deno, a JavaScript/TypeScript runtime created by the original author of Node.js, is drawing interest for its built-in tooling, TypeScript-first design, web-standards alignment, and secure-by-default permissions model, with some developers already running it in production and using its managed hosting (Deno Deploy) and KV store. At the same time, commenters question its long-term viability and ecosystem lock-in, worry about issues like large compiled binary sizes, limited multithreading options, and reduced edge regions, and debate whether it can realistically displace or complement entrenched Node.js and emerging competitor Bun. The launch of a new package registry (JSR), the Fresh web framework, and features like WebGPU support are seen as attempts to push the JavaScript ecosystem forward, but they also raise concerns about fragmentation and whether Deno’s team can sustain both a runtime and a cloud platform.

Deno Deploy, Regions, and Business Viability

  • Deno Deploy reportedly shrank from 35 to 12 GCP regions.
  • Some see this as sensible cost-cutting for a startup; others worry it signals weak growth and may deter users needing specific regions.
  • Concern about vendor risk: if hosting fails, will the Deno runtime/ecosystem survive? Many assume yes due to open source and self‑hosting, but it’s not guaranteed.

JSR and Package Ecosystem

  • JSR is understood as a TypeScript‑first JavaScript package registry and de facto npm alternative.
  • Mixed reactions: earlier Deno messaging suggested URL imports would avoid needing a registry; now they appear to be changing course, possibly learning from experience.

Node/Bun Compatibility and Value Proposition

  • Deno has moved towards Node compatibility (e.g., package.json, npm integration), partly because non‑compatibility hampered adoption.
  • Bun is seen as a faster drop‑in Node replacement, while Deno aims to “reimagine Node” with web‑standard APIs and built‑in tooling (TS, testing, linting, formatting, bundling).
  • Some argue that if Node adopted similar built‑ins, Deno/Bun would lose much of their appeal.

Developer Experience: Pros and Cons

  • Pro‑Deno points:
    • Single binary install; easy updates.
    • TS support out of the box, including REPL.
    • Sensible defaults; one config file instead of many.
    • Built‑in stdlib and tools reduce dependency sprawl and supply‑chain risk.
    • Good for one‑off scripts and CLIs; can compile to a single binary.
  • Critiques:
    • URL imports can be awkward (especially private repos).
    • Permissions model can feel fussy; some end up using broad --allow-all.
    • Running multiple CPU processes / clustering is weaker than Node’s cluster+pm2 story for bare‑metal deployments.

Compile Size and Deployment

  • Compiled binaries have grown from ~50MB to ~90MB+, which some see as too large for Go‑style deployment, serverless limits, or many small tools.
  • Others argue 90–100MB is acceptable for many server/CLI cases, especially given self‑containment; critics counter that size matters for FaaS, CI/CD, and many instances.
  • Deno team members report ongoing work that has already cut baseline binary size by ~40% in testing, with more improvements expected.

Frameworks, Hosting, and Next.js/Fresh

  • Deno’s Fresh framework is viewed as a Next.js competitor; some worry its existence reduces incentive to make Next.js run well on Deno.
  • Others argue Next.js/Vercel are themselves tightly coupled, so it’s reasonable for Deno to promote its own stack while still improving Next.js support.
  • Fresh is considered promising but “not quite ready” for large projects; CSS tooling (beyond Tailwind/plain CSS) is seen as immature by some.
  • Deno Deploy is praised for simplicity but criticized for cold starts and, now, fewer regions.

Deno KV and Data

  • Deno KV is likened to App Engine’s datastore: key‑value with manual indexing and transactions.
  • Works well for small records; tight size limits make it unsuitable for large blobs.
  • Local dev tooling for KV is described as pleasant; production experience in thread is limited but cautiously positive.

Security and Sandboxing

  • Deno’s permission model (no FS/network/env access by default) is seen as a core differentiator and useful for limiting third‑party modules (e.g., network only to specific hosts).
  • Critics note similar isolation can be achieved via containers or OS sandboxing; others point out that built‑in permissions work cross‑platform without container overhead and add value even when not containerized.

Multithreading and Concurrency

  • Question raised why Node alternatives (including Deno) don’t have “true” multithreading beyond workers.
  • Some argue JS workloads are naturally async and can leverage workers/C++ addons; others say real multithreading would be broadly useful but is hard to retrofit into the existing async ecosystem without data‑race issues.

New Use Cases and Integrations

  • Jupyter + Deno is welcomed for people fluent in JS/TS who only occasionally work with data, avoiding Python dependency friction.
  • Deno’s WebGPU and windowing hooks spark interest for building desktop GUIs in JS/TS without bundling a full browser (Electron); however, window creation and input/a11y still rely on extra native libraries, so the story is incomplete.

Overall Sentiment

  • Many express strong enthusiasm for Deno’s design, tooling, and branding, and report smooth production experiences for small–medium apps.
  • Skeptics question long‑term viability, binary sizes, certain missing features (clustering, rich GUI/ecosystem, CSS tooling), and the need for yet another JS runtime/registry.