Deno 3.0 shipped Monday, and the headline is a deletion. The unstable node compatibility flag is gone, because compatibility is no longer a mode you opt into. The runtime now resolves npm workspaces, respects package.json exports and imports maps, reads .npmrc for private registries, and runs the node: builtin modules without ceremony. Ryan Dahl's team has spent three years walking back the original premise that Deno would replace the Node ecosystem rather than absorb it, and this release completes that retreat. The result is a runtime that runs most existing Node projects unmodified while keeping the permission model, the built-in TypeScript support, and the standard library that made Deno interesting in the first place.
What compatibility means in practice
The team ran the top 1,000 npm packages by download volume against their own test suites under Deno 3.0 and reports 94.2 percent passing, up from 81 percent under Deno 2.4. The failures cluster in three areas: packages using native addons through node-gyp, packages that monkey-patch internal Node modules, and a handful that depend on precise garbage collection timing. Native addon support exists but requires the addon to be built against Deno's headers, which in practice means popular ones work and obscure ones do not.
Frameworks matter more than raw package counts, and here the news is good. Next.js 16, Nuxt 4, SvelteKit 3, Astro 6, and Remix all build and run without configuration changes. Express, Fastify, and Hono work. Prisma works after a 3.0-specific patch the Prisma team shipped in June. The notable holdout is anything depending on the Node cluster module's exact fork semantics, which Deno emulates with workers and which behaves differently under load.
The install speed claim
Deno's package cache is content-addressed and global, so a package downloaded for one project never downloads again. That is the same approach pnpm takes, and the benchmarks the Deno team published show a cold install of a 1,200 dependency project at 4.1 seconds against pnpm's 11.3 and npm's 47.8. Warm installs land under 400 milliseconds for all three. The cold number is the honest advantage, and it comes from a Rust resolver doing concurrent metadata fetches rather than any architectural magic.
Reproducing those numbers on a real project gave slightly less dramatic results. A monorepo with 2,400 direct and transitive dependencies installed in 7.9 seconds under Deno and 14.2 under pnpm on the same machine with a cleared cache. Still a meaningful gap in CI, where cold installs are the normal case and where a seven second saving multiplied across a few hundred daily pipeline runs adds up to real compute cost. The lockfile format is Deno's own, which means a mixed-tooling team maintains two.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
The permission model is the actual differentiator
Everything above makes Deno an adequate Node replacement. The permission model is why someone would switch. A Deno process cannot read the filesystem, open a network connection, or spawn a subprocess without an explicit grant, and 3.0 extends granularity so a network permission can name specific hosts and a filesystem permission can name specific paths. For running third-party build tooling, which is the most common software supply chain attack vector in the JavaScript ecosystem, that containment is worth more than any performance number.
Deno 3.0 adds a per-dependency permission scope in an unstable form, which would let a project declare that a specific npm package may reach only one API host. That is the feature the security community has wanted since the event-stream incident in 2018. The implementation intercepts at the module boundary and has known holes when a package passes a callback across scopes, which is why it remains behind a flag. If it stabilizes and holds up to scrutiny, it is a genuinely new capability rather than a faster version of an old one.
Where Deno stands against Bun and Node
Node itself has absorbed much of what made alternatives attractive. Node 24 runs TypeScript directly through type stripping, ships a test runner, includes a permission model, and has a built-in watch mode. The gap that remains is quality of implementation rather than presence of features. Bun competes on speed and has the fastest numbers in most benchmarks, with a compatibility story that is good and slightly behind Deno's, plus a company with venture funding and an aggressive shipping pace.
The three-way split has settled into rough segments. Node holds enterprise and anything requiring long-term support guarantees. Bun wins where startup time and raw throughput decide, which includes a lot of serverless. Deno's constituency is teams that care about the permission model, teams that like the standard library, and increasingly teams building agent tooling that runs untrusted generated code, where sandboxing is the entire requirement. That last category has grown fast enough that the Deno company reoriented part of its commercial roadmap around it.
The business behind the runtime
Deno Land the company sells Deno Deploy, an edge hosting product, and recently added a managed KV and queue service. Revenue figures are private. Dahl said in a June interview that the company is not profitable and has runway into 2028 on its 2022 Series A plus a smaller extension. That matters to anyone considering Deno for a long-lived system, because runtime maintenance is expensive and the open source project has few full-time contributors outside the company.
The mitigating factor is that Deno is genuinely open source under MIT with a broad contributor base for the standard library, and the JSR package registry the company launched has been donated toward independent governance. If the company failed tomorrow, the runtime would survive in some form. Teams making a five year bet should still weigh that risk honestly rather than assuming permanence.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Open Source
- TypeScript
