Deno Keeps Shipping
Deno 2.3 just landed, and while the changelog is long, most of it doesn't affect your daily work. Here's what actually matters — the stuff that changes how you write code.
1. Native npm Compatibility Is Finally Solid
// This just works now — no import maps, no --compat flag
import express from "npm:express";
import pg from "npm:pg";
const app = express();
app.get("/", (req, res) => res.json({ status: "ok" }));
app.listen(3000);
The npm: specifier now handles 97%+ of npm packages correctly, including packages with native addons. This was the #1 blocker for adoption, and it's essentially solved.
Why it matters: You can now migrate Express/Fastify/Hono apps from Node to Deno with minimal changes. The runtime handles node_modules resolution transparently.
2. deno compile Produces Smaller Binaries
# Compile to a single executable
deno compile --output myapp server.ts
# Result: ~40MB (down from ~80MB in Deno 2.0)
ls -lh myapp
They cut binary size by ~50% through better tree-shaking. A simple HTTP server compiles to ~40MB instead of ~80MB. Still not tiny, but much more reasonable for containerized deployments.
3. Built-in SQLite (deno.sqlite)
// No npm package needed
const db = new Deno.openKv(); // Uses SQLite under the hood
// Or use the raw SQLite API
import { Database } from "jsr:@db/sqlite";
const db = new Database("app.db");
db.exec(`CREATE TABLE IF NOT EXISTS users (
id INTEGER PRIMARY KEY,
name TEXT,
email TEXT UNIQUE
)`);
const insert = db.prepare("INSERT INTO users (name, email) VALUES (?, ?)");
insert.run("Alice", "alice@example.com");
for (const row of db.prepare("SELECT * FROM users")) {
console.log(row);
}
SQLite is now a first-class citizen in Deno. No need for better-sqlite3 or sql.js. This is huge for CLI tools and local-first apps.
4. Workspace Support (Finally)
// deno.json
{
"workspace": ["./packages/api", "./packages/web", "./packages/shared"]
}
Monorepo support that actually works. Each workspace member gets its own deno.json for dependencies, but shares a lockfile. Similar to npm workspaces but with Deno's security model.
5. deno task Got Smarter
{
"tasks": {
"dev": "deno run --watch --allow-net server.ts",
"test": "deno test --parallel",
"build": "deno compile --output dist/app server.ts",
"deploy": "deno task build && deployctl deploy"
}
}
deno task now supports &&, ||, pipes, and environment variables natively — without needing a shell. Cross-platform task running that doesn't break on Windows.
What I'm Actually Using Deno For
After 6 months with Deno 2.x, here's where it genuinely beats Node:
-
CLI tools —
deno compile+ built-in SQLite = ship single binaries - API servers — TypeScript without tsconfig, built-in test runner
- Scripts — Replace bash scripts with type-safe TypeScript
- Edge functions — Deno Deploy is genuinely fast
Where Node still wins:
- Massive existing codebases (migration cost)
- Packages that rely on native addons not yet supported
- Teams that already have Node CI/CD pipelines
The Real Question
Deno vs Bun vs Node isn't about which runtime is "better." It's about which one fits your specific use case:
| Use Case | Best Runtime | Why |
|---|---|---|
| New API server | Deno | TypeScript native, security model |
| CLI tools | Deno |
deno compile to single binary |
| Existing Node app | Node | Migration cost not worth it |
| Raw performance | Bun | Fastest HTTP, fastest install |
| Edge/serverless | Deno | Deno Deploy, small cold starts |
| Frontend tooling | Bun | Bundler + runtime in one |
What's your runtime of choice in 2026? Still Node? Switched to Bun? Trying Deno? I'm curious what's winning in production.
I write about practical dev tools and APIs. Follow for weekly no-BS tutorials.
More from me: 10 Dev Tools I Use Daily | 77 Scrapers on a Schedule | 150+ Free APIs
Top comments (0)