Deno 2 is technically solid. It runs Node.js packages, executes TypeScript natively, and ships as a single binary with formatting, linting, testing, and compilation built in. None of that is disputed. What is disputed is whether any of it is winning.

State of JS 2025 surveyed 11,141 developers. Deno had 1,244 users — 11.2%, sixth place, down one rank from 2024. Bun had 2,321 — 21%, third place, up four percentage points year over year. In March 2026, Deno Land Inc. conducted significant layoffs. The rebrand from “no npm” to “full Node.js compatibility” was supposed to convert fence-sitters. The data says it hasn’t.

Who this is for

You are evaluating Deno 2 for a new TypeScript project and want a real read, not a feature matrix. You already know JavaScript. You want to know where Deno breaks, not just where it shines.

If your project depends heavily on CJS packages or gRPC services, jump to the compatibility section first — it may end the evaluation early.

What we tested

Deno v2.8.1 (released May 27, 2026), compared against Node.js v24.x and Bun v1.x. Adoption figures come from the State of JS 2025 survey (2025.stateofjs.com, n=11,141, unweighted). We did not run performance benchmarks — see the Caveats section for why.

Findings

Adoption is plateauing while Bun accelerates

Deno is not dying. GitHub shows ~107k stars, v2.x releases shipped continuously through May 2026, and the project is active. But “not dying” and “growing” are different things.

Bun added four percentage points in State of JS 2025. Deno added none worth measuring. The adoption curve matters because a runtime’s value compounds with its ecosystem — libraries, StackOverflow answers, hired engineers who already know it. Deno’s ecosystem is not shrinking, but it is not growing faster than Node.js or Bun. If State of JS 2026 looks similar, the gap becomes structural, not cyclical.

Why Bun is pulling ahead is partly guesswork. Bun’s npm compatibility is higher out of the box. Bun arrived on Windows earlier. Bun’s performance marketing — even when the numbers are unverified — is louder and more visible. Deno’s pitch (correctness, security, TypeScript-first) speaks to an audience that values those things and is not, apparently, a large or growing one relative to the JavaScript population.

There’s also an organizational dimension. Bun is still in its early growth phase, with a small and focused team. Deno Land Inc. had grown larger and just cut it back down significantly. Smaller organizations can move faster; they can also ship nothing if morale collapses. The v2.8.1 release in late May suggests the team is still shipping, but we are watching this closer than we would be watching a stable platform. If you are evaluating Bun and Deno side by side, see Bun vs Deno in 2026.

npm compatibility: good until it breaks

The headline promise of Deno 2 was real Node.js compatibility. For the common case, it delivers. node_modules coexists with deno.json. Most packages you’d reach for on day one import cleanly.

The edge cases are hard edges.

fp-ts and CJS directory imports. If you use fp-ts or any package that resolves via CJS directory style — require('fp-ts/Option') — Deno throws Is a directory (os error 21). GitHub issue #27894 documents this. It was closed as not-planned. The workaround is to import the file directly (fp-ts/Option/index.js), which only works when you control the import site. If a transitive dependency does the CJS directory import, you cannot fix it from the outside.

@google-cloud/tasks gRPC. The OAuth flow in @google-cloud/tasks fails with Premature close starting in Deno 2.2.6, documented in issue #28813. The bug was open at time of writing (May 2026) and has since been closed — verify whether the fix is in your target Deno version before committing.

Neither of these is exotic. Both affect real libraries. Deno’s compatibility is better than it was in Deno 1.x, and it is not the same as Node.js.

JSR: credibility improving, reach still limited

JSR is Deno’s alternative to npm: TypeScript-native, ESM-only, no compilation required to publish. Governance reads like a credibility play: Ryan Dahl, Isaac Schlueter (who created npm), Evan You (Vue), James Snell (Node core), Luca Casonato. The board is real and the names carry weight.

Traction is real too. OpenAI’s official JavaScript SDK is published on JSR. pnpm v10.9+ added native jsr: protocol support, which means Node.js projects can pull JSR packages without running Deno at all. That cross-runtime reach was not available a year ago.

Publishing to JSR is meaningfully simpler than publishing to npm. You define a deno.json with name and version, run deno publish, and JSR generates API documentation from your TypeScript types automatically — no JSDoc required, no build output to upload. For library authors, that’s a real reduction in friction. For consumers, the documentation is always in sync with the types because they are the same artifact.

The limit is supply. npm holds roughly 3 million packages. JSR holds a fraction of that — the total count is not published prominently on jsr.io, which is itself a signal. If you are building something greenfield with TypeScript, JSR has enough to work with. If you are integrating with the existing JavaScript ecosystem, npm is still the supply chain. JSR is where you’d publish new libraries, not where you find the ones already in production.

DX: the honest case for Deno

The development experience argument for Deno is stronger than its market position suggests.

TypeScript without a build step. Deno runs .ts files directly. No tsc invocation, no tsconfig.json, no watch process for compilation. You write TypeScript, you run it. Node.js 24 added native type stripping — you can now run .ts files without tsc — but there are real differences. Node’s type stripping drops enums, decorators, parameter properties, and namespace declarations with runtime code. It skips type checking entirely: the runtime strips types and runs, it does not validate them. You still configure package.json and optionally tsconfig.json to get the behavior you want. Deno’s TypeScript support is more complete.

One binary, no toolchain assembly. deno fmt. deno lint. deno test. deno bench. deno compile. All ship with the runtime. Node.js projects typically assemble these from four to eight separate npm packages with their own configs and their own version constraints. Deno’s all-in-one model eliminates that surface area.

Deny-by-default permissions. A Deno script cannot read the filesystem unless you pass --allow-read. It cannot hit the network without --allow-net. It cannot access environment variables without --allow-env. In practice, this means you run deno run --allow-net --allow-env src/server.ts and the runtime enforces the contract — a dependency that tries to exfiltrate files silently hits a permission denial at runtime. This is not a perfect supply-chain defense; a malicious package could still do damage within its allowed scope. But it raises the floor in a way that Node.js cannot match without additional sandboxing tooling. For scripts that process sensitive data, the audit story is meaningfully cleaner.

IDE integration. Deno’s language server and VS Code extension work well with Cursor — TypeScript autocomplete, import resolution via deno.json, and workspace config all function without the tsconfig.json path hacks that Node TypeScript projects often require.

Deno Deploy: edge functions with caveats

Deno has a hosted deployment product — Deno Deploy — designed for running Deno scripts at the edge, closer to Cloudflare Workers than to a traditional VPS. Latency-sensitive APIs and global distribution are the target use case. See Deno Deploy vs Cloudflare Workers for a full pricing and feature breakdown.

The product exists and functions. The question after the March 2026 layoffs is whether the commercial side remains a priority. We could not confirm that the free tier and Pro pricing are unchanged after the staff reduction — the pricing page itself still shows plans, but the team maintaining it is smaller. For production workloads on Deno Deploy, verify pricing and SLA terms directly with Deno before committing. This is not a concern for self-hosted Deno; it’s specific to the managed service.

Performance: don’t trust the benchmarks

We did not run performance benchmarks. We are not going to cite a 2024 blog post counting hello world HTTP responses per second.

What we can say: Deno and Node.js both run on V8. Bun runs on JavaScriptCore. Startup time differences between runtimes are real and measurable — Bun’s subprocess startup is genuinely fast, which matters for short-lived scripts. Throughput differences for typical server-side workloads — HTTP APIs, data processing — are workload-dependent and usually small enough that they are not the right axis for a runtime selection decision.

The blog benchmark that shows Deno or Bun at 2× or 3× Node’s throughput is almost always measuring http.listen + JSON serialization in isolation. That is not a web server. If runtime throughput is a hard constraint in your evaluation, write a benchmark that exercises your actual hot path — database queries, middleware stack, serialization format — and measure it on the hardware you’ll deploy to. Do not make a production technology selection off a number that does not correspond to your workload.

Deno 2 Verdict

Pick Deno 2 if you are building a greenfield TypeScript-first project with a shallow or controlled dependency tree — CLI tools, internal services, scripts, automation. The DX is real. The toolchain simplicity is real. The security model is a genuine advantage.

Stick with Node.js if your project pulls from the npm ecosystem at any depth: legacy packages, CJS-heavy libraries, or dependencies you do not control. Deno’s compatibility is solid for the mainstream and brittle at the edges. See Deno vs Node.js in 2026 for a detailed breakdown of where the gap remains.

Consider Bun if your primary criteria are npm compatibility and startup speed and you don’t specifically need Deno’s permission model. Bun’s compatibility surface is wider, its momentum is higher, and it is a legitimate alternative for projects where Deno’s security-first design is not a priority.

Caveats

The layoffs are a real risk signal. Deno Land Inc. conducted significant layoffs in March 2026. The project shipped v2.8.1 two months later, so the team is still working. But a smaller team means slower bug response, narrower compatibility work, and genuine uncertainty about the commercial side — Deno Deploy specifically. Deno is open-source and could continue independently, but that is not guaranteed. Factor this into production bets.

gRPC post-2.3.x is unverified. Issue #28813 was open at time of writing (May 2026) and has since been closed — verify whether the fix landed before deploying.

Deno Deploy pricing was not re-verified. We did not confirm whether the post-layoffs free tier or Pro pricing changed. Check the Deno Deploy site directly before budgeting.

Cloudflare Workers. If you are evaluating Deno for edge deployment, Workers is the natural comparison. We don’t have a Cloudflare affiliate agreement and are not linking there, but the pricing and region coverage are worth comparing directly.

Cursor link above is an affiliate link. See the disclosure at the top of this page.

Deno 2 Review 2026: Is the Runtime Rebrand Working?