Deno 2.3 dropped this week with workspace support for monorepos and further improvements to Node.js compatibility. Meanwhile, Bun continues to iterate rapidly, and Node.js itself keeps absorbing good ideas from its competitors. After years of runtime fragmentation anxiety, I’m starting to think the JavaScript server-side ecosystem is reaching a productive equilibrium. Let me explain why.
What’s New in Deno 2.3#
The headline feature in Deno 2.3 is native workspace support. If you’re managing a monorepo with multiple packages — and who isn’t these days — Deno now handles cross-package dependencies, shared configurations, and coordinated builds without external tooling. This closes one of the biggest gaps that kept teams from adopting Deno for larger projects.
The workspace implementation is thoughtful. Each workspace member gets its own deno.json configuration, but they inherit from a root configuration. Dependencies can be shared across the workspace or scoped to individual packages. The lockfile is unified, preventing version conflicts between packages. If you’ve dealt with the complexity of npm workspaces, yarn workspaces, or pnpm workspaces, you’ll appreciate how clean this feels.
Node.js compatibility continues to improve. Deno 2.3 now supports over 95% of npm packages without any compatibility flags or shims. The remaining 5% are packages that rely on Node.js-specific internals or native addons with Node-specific build systems. For most practical applications, you can now drop Deno into an existing Node.js project and it just works.
The built-in toolchain also got updates: deno fmt now supports CSS and HTML formatting, deno lint has new rules for accessibility in JSX, and deno test gained snapshot testing. These built-in tools continue to be one of Deno’s strongest selling points — no need to configure Prettier, ESLint, and Jest separately.
The State of the Three-Runtime Landscape#
Let me step back and look at the bigger picture. We now have three serious JavaScript/TypeScript runtimes: Node.js, Deno, and Bun. Two years ago, this felt like chaos. Today, it feels like healthy competition that’s driving all three to improve.
Node.js remains the default for most teams, and for good reason. The ecosystem is massive, the tooling is mature, and the long-term support model gives enterprises confidence. Node 22, currently in LTS, brought native TypeScript support via type stripping, a stable permission model inspired by Deno, and significant performance improvements. Node.js is no longer the “boring, old” option — it’s actively incorporating the best ideas from its competitors.
Bun carved out a niche as the performance-focused runtime. Its bundler, test runner, and package manager are all blazing fast, and for projects where build time and startup time matter — think serverless functions, CLI tools, edge computing — Bun offers real advantages. The 1.x series has been stable enough for production use, and I know several teams running Bun in production without issues.
Deno is positioning itself as the “correct by default” runtime. Security permissions, TypeScript support, web-standard APIs, built-in tooling — it’s the runtime that makes the right thing easy and the wrong thing hard. The 2.x series removed the friction that kept teams from adopting it, particularly around npm compatibility.
Why This Competition Is Healthy#
I’ve seen people lament JavaScript runtime fragmentation, but I think the competition has been enormously beneficial. Consider what Node.js has adopted from its competitors in the past two years: built-in TypeScript support (from Deno’s influence), a permission model (directly from Deno), improved test runner (Bun showed how good built-in testing could be), and faster startup times (competitive pressure from Bun).
Without Deno and Bun pushing the boundaries, Node.js would still require a separate TypeScript compiler, a pile of configuration files, and five different tools for tasks that should be built in. Competition created convergence toward better defaults.
The ecosystem is also more portable than people fear. Well-written JavaScript and TypeScript code runs on all three runtimes with minimal changes. The web-standard API convergence — using fetch, Request, Response, Web Streams — means that most code doesn’t rely on runtime-specific APIs. The WinterCG (Web-interoperable Runtimes Community Group) has been instrumental in driving this standardization.
Choosing a Runtime in 2026#
So which runtime should you use? My pragmatic advice:
Choose Node.js if you’re building enterprise applications with large teams, need maximum ecosystem compatibility, or require long-term support guarantees. It’s the Toyota Camry of runtimes — reliable, well-supported, and nobody ever got fired for choosing it.
Choose Deno if you’re starting a new project, value security defaults, want a batteries-included development experience, or are building with TypeScript from the start. The developer experience is genuinely superior for greenfield projects.
Choose Bun if performance is your primary concern — serverless functions, CLI tools, build-heavy workflows — or if you’re in an environment where startup time directly impacts user experience.
For most of my consulting work, I recommend Node.js for existing projects and Deno for new ones. But honestly, the choice matters less than it did two years ago. The runtimes are converging, and the code you write is increasingly portable between them.
My Take#
The JavaScript runtime landscape in 2026 is healthier than it’s ever been. Competition has driven innovation, standards have reduced fragmentation, and developers have genuine choices without catastrophic lock-in. Deno 2.3’s workspace support removes one of the last practical barriers to adoption for team-based projects.
What I’m most excited about is the meta-trend: all three runtimes are moving toward batteries-included, secure-by-default, TypeScript-native experiences. The days of spending a day configuring your development toolchain before writing any application code are ending. And having lived through the Grunt-to-Gulp-to-Webpack-to-Vite evolution, I can’t tell you how welcome that is.
This is part of my ongoing Developer Landscape series, tracking the tools, frameworks, and practices shaping modern software development.