<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1555066931-4365d14bab8c?w=1200">Ryan Dahl created Node.js, regretted a bunch of decisions he made in it, gave a famous talk about those regrets at JSConf 2018, and then built Deno. Seven years later, Deno 2.0 is production-ready with full npm compatibility, a built-in standard library, and a more coherent security model than Node has ever had. The question is whether that’s enough to break the gravity of the Node ecosystem.<hr><h2 id="what-deno-20-actually-fixes">What Deno 2.0 Actually Fixes</h2>Let’s be concrete about what Dahl’s regrets were and whether Deno 2.0 addresses them.<h3 id="the-node_modules-problem">The <code>node_modules</code> Problem</h3>Node’s <code>node_modules</code> is notoriously bad: enormous directories, symlink issues, version conflicts, and the inability to know what’s actually running without tracing the resolution algorithm. Deno’s original answer was “just use URLs, no package manager needed.”That turned out to be too radical. Deno 2.0 takes a pragmatic approach:<div><pre><code>// deno.json
{
 "imports": {
 "express": "npm:express@4",
 "lodash": "npm:lodash@4",
 "@std/path": "jsr:@std/path@1"
 }
}
</code></pre></div><div><pre><code>// This just works now
import express from "express";
import { join } from "@std/path";
import { pick } from "lodash";

const app = express();
app.get("/", (req, res) =&gt; res.send("Hello from Deno!"));
app.listen(3000);
</code></pre></div>npm packages run without modification in most cases. The resolver downloads to a global cache (<code>~/.deno/npm</code>) instead of project-local <code>node_modules</code>. It’s not perfect — packages that rely on native Node addons or deep <code>__dirname</code> hacks can break — but 95%+ of the ecosystem works.<img src="https://images.unsplash.com/photo-1627398242454-45a1465c2479?w=900" alt="JavaScript and TypeScript development"> Photo by Gabriel Heinzer on Unsplash<h3 id="security-by-default">Security by Default</h3>Node runs with whatever permissions the OS grants. Deno requires explicit permission grants:<div><pre><code># Explicit permissions
deno run --allow-net=api.example.com --allow-read=/tmp --allow-env=DATABASE_URL server.ts

# Or in deno.json for development
</code></pre></div><div><pre><code>{
 "tasks": {
 "dev": "deno run --allow-net --allow-read --allow-env --watch main.ts",
 "prod": "deno run --allow-net=:443 --allow-read=/app/data --allow-env=DATABASE_URL,PORT main.ts"
 }
}
</code></pre></div>This is more friction in development, but it’s genuinely useful in production. You can look at the permissions a Deno process requests and know exactly what it can touch — something Node has never offered.<h3 id="typescript-without-toolchain-hell">TypeScript Without Toolchain Hell</h3>This is perhaps Deno’s biggest win for developer experience:<div><pre><code>// This runs directly. No tsconfig. No tsc. No ts-node. No esbuild config.
// deno run types.ts

interface User {
 id: number;
 name: string;
 email: string;
}

async function fetchUser(id: number): Promise&lt;User&gt; {
 const response = await fetch(`https://api.example.com/users/${id}`);
 if (!response.ok) throw new Error(`HTTP ${response.status}`);
 return response.json() as Promise&lt;User&gt;;
}

const user = await fetchUser(1);
console.log(user.name);
</code></pre></div>No configuration needed. TypeScript is a first-class citizen, not a compile step you glue on.<hr><h2 id="jsr-the-npm-alternative">JSR: The npm Alternative</h2>Deno 2.0 ships with first-class support for JSR (JavaScript Registry), the npm alternative designed for the modern JavaScript ecosystem:<div><pre><code># Publish to JSR
deno publish

# Install from JSR
import { parseArgs } from "jsr:@std/cli@1";
import { encodeBase64 } from "jsr:@std/encoding@1/base64";
</code></pre></div>JSR packages are TypeScript-native (no DefinitelyTyped gymnastics), versioned with SemVer, and compatible with both Deno and Node (JSR generates compatible <code>node_modules</code> on install). It’s early, but the Deno standard library, a growing set of popular packages, and frameworks like Fresh have moved to JSR.<hr><h2 id="fresh-20-denos-answer-to-nextjs">Fresh 2.0: Deno’s Answer to Next.js</h2>Fresh is Deno’s full-stack web framework, and version 2.0 is meaningfully better than 1.x.<div><pre><code>// routes/blog/[slug].tsx — Fresh 2.0 route with server components
import { define } from "$fresh/server.ts";
import { getPost } from "../../lib/blog.ts";

export const handler = define.handlers({
 async GET(ctx) {
 const post = await getPost(ctx.params.slug);
 if (!post) return ctx.renderNotFound();
 return ctx.render({ post });
 }
});

export default define.page&lt;typeof handler&gt;(function BlogPost({ data }) {
 const { post } = data;
 return (
 &lt;article&gt;
 &lt;h1&gt;{post.title}&lt;/h1&gt;
 &lt;time&gt;{post.date}&lt;/time&gt;
 &lt;div dangerouslySetInnerHTML= /&gt;
 &lt;/article&gt;
 );
});
</code></pre></div>Fresh’s island architecture (only ship JS for interactive components) is elegant:<div><pre><code>// islands/Counter.tsx — only this component ships JavaScript to the browser
import { useSignal } from "@preact/signals";

export default function Counter() {
 const count = useSignal(0);
 return (
 &lt;div&gt;
 &lt;p&gt;Count: {count}&lt;/p&gt;
 &lt;button onClick={() =&gt; count.value++}&gt;+&lt;/button&gt;
 &lt;button onClick={() =&gt; count.value--}&gt;-&lt;/button&gt;
 &lt;/div&gt;
 );
}
</code></pre></div>Everything outside <code>islands/</code> is server-rendered with zero client JS. This makes Fresh apps fast by default — you have to opt into client JavaScript, not opt out.<hr><h2 id="deno-deploy-edge-first-runtime">Deno Deploy: Edge-First Runtime</h2>Deno’s cloud offering, Deno Deploy, runs your code on V8 isolates at the edge (currently 35+ regions). It’s comparable to Cloudflare Workers but with a better local development story:<div><pre><code>// Same code runs locally and on Deno Deploy
Deno.serve({ port: 8000 }, async (req) =&gt; {
 const url = new URL(req.url);
 
 if (url.pathname === "/api/time") {
 return Response.json({
 time: new Date().toISOString(),
 region: Deno.env.get("DENO_REGION") ?? "local"
 });
 }
 
 return new Response("Not found", { status: 404 });
});
</code></pre></div><div><pre><code># Local dev
deno run --allow-net server.ts

# Deploy
deployctl deploy server.ts
</code></pre></div>No adapter code, no platform-specific APIs. The Web Standard APIs (<code>Request</code>, <code>Response</code>, <code>fetch</code>, <code>Blob</code>) work identically locally and in production.<hr><h2 id="the-honest-comparison-with-node-in-2026">The Honest Comparison with Node in 2026</h2><table><thead><tr><th>Dimension</th><th>Node.js</th><th>Deno 2.0</th></tr></thead><tbody><tr><td>Ecosystem size</td><td>Massive (npm)</td><td>Growing (npm compat + JSR)</td></tr><tr><td>TypeScript DX</td><td>Good (with tooling)</td><td>Excellent (native)</td></tr><tr><td>Security model</td><td>None by default</td><td>Permission-based</td></tr><tr><td>Startup time</td><td>Fast</td><td>Fast</td></tr><tr><td>Tooling</td><td>Fragmented</td><td>Integrated (fmt, lint, test, bench)</td></tr><tr><td>Production track record</td><td>Decades</td><td>3-4 years serious use</td></tr><tr><td>Hiring pool</td><td>Huge</td><td>Node devs adapt quickly</td></tr></tbody></table>Node isn’t going away. The npm ecosystem is too large, and Bun (another Node-compatible runtime) is fighting for the same mindshare. But Deno 2.0 is a genuinely compelling choice for new projects — especially teams that want TypeScript-first development without the toolchain complexity.<hr><h2 id="getting-started">Getting Started</h2><div><pre><code># Install Deno
curl -fsSL https://deno.land/install.sh | sh

# Create a new project
deno init my-project
cd my-project

# Run with all the batteries
deno task dev
</code></pre></div>The tooling is integrated: <code>deno fmt</code> formats your code, <code>deno lint</code> lints it, <code>deno test</code> runs tests with code coverage, <code>deno bench</code> benchmarks. No Prettier config, no ESLint config, no Vitest setup.For new projects where you have the choice, Deno 2.0 is worth a serious look.<hr>References: <a href="https://deno.com/blog/v2">Deno 2.0 Announcement</a>, <a href="https://jsr.io/docs">JSR Documentation</a>, <a href="https://fresh.deno.dev/docs">Fresh 2.0 Guide</a> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

Ryan Dahl created Node.js, regretted a bunch of decisions he made in it, gave a famous talk about those regrets at JSConf 2018, and then built Deno. Seven years later, Deno 2.0 is production-ready with full npm compatibility, a built-in standard library, and a more coherent security model than Node has ever had. The question is whether that’s enough to break the gravity of the Node ecosystem.
What Deno 2.0 Actually Fixes
Let’s be concrete about what Dahl’s regrets were and whether Deno 2.0 addresses them.
The node_modules Problem
Node’s node_modules is notoriously bad: enormous directories, symlink issues, version conflicts, and the inability to know what’s actually running without tracing the resolution algorithm. Deno’s original answer was “just use URLs, no package manager needed.”
That turned out to be too radical. Deno 2.0 takes a pragmatic approach:
// deno.json
{
 "imports": {
 "express": "npm:express@4",
 "lodash": "npm:lodash@4",
 "@std/path": "jsr:@std/path@1"
 }
}
// This just works now
import express from "express";
import { join } from "@std/path";
import { pick } from "lodash";
const app = express();
app.get("/", (req, res) => res.send("Hello from Deno!"));
app.listen(3000);
npm packages run without modification in most cases. The resolver downloads to a global cache (~/.deno/npm) instead of project-local node_modules. It’s not perfect — packages that rely on native Node addons or deep __dirname hacks can break — but 95%+ of the ecosystem works.
Photo by Gabriel Heinzer on Unsplash
Security by Default
Node runs with whatever permissions the OS grants. Deno requires explicit permission grants:
# Explicit permissions
deno run --allow-net=api.example.com --allow-read=/tmp --allow-env=DATABASE_URL server.ts
# Or in deno.json for development
{
 "tasks": {
 "dev": "deno run --allow-net --allow-read --allow-env --watch main.ts",
 "prod": "deno run --allow-net=:443 --allow-read=/app/data --allow-env=DATABASE_URL,PORT main.ts"
 }
}
This is more friction in development, but it’s genuinely useful in production. You can look at the permissions a Deno process requests and know exactly what it can touch — something Node has never offered.
TypeScript Without Toolchain Hell
This is perhaps Deno’s biggest win for developer experience:
// This runs directly. No tsconfig. No tsc. No ts-node. No esbuild config.
// deno run types.ts
interface User {
 id: number;
 name: string;
 email: string;
}
async function fetchUser(id: number): Promise<User> {
 const response = await fetch(`https://api.example.com/users/${id}`);
 if (!response.ok) throw new Error(`HTTP ${response.status}`);
 return response.json() as Promise<User>;
}
const user = await fetchUser(1);
console.log(user.name);
No configuration needed. TypeScript is a first-class citizen, not a compile step you glue on.
JSR: The npm Alternative
Deno 2.0 ships with first-class support for JSR (JavaScript Registry), the npm alternative designed for the modern JavaScript ecosystem:
# Publish to JSR
deno publish
# Install from JSR
import { parseArgs } from "jsr:@std/cli@1";
import { encodeBase64 } from "jsr:@std/encoding@1/base64";
JSR packages are TypeScript-native (no DefinitelyTyped gymnastics), versioned with SemVer, and compatible with both Deno and Node (JSR generates compatible node_modules on install). It’s early, but the Deno standard library, a growing set of popular packages, and frameworks like Fresh have moved to JSR.
Fresh 2.0: Deno’s Answer to Next.js
Fresh is Deno’s full-stack web framework, and version 2.0 is meaningfully better than 1.x.
// routes/blog/[slug].tsx — Fresh 2.0 route with server components
import { define } from "$fresh/server.ts";
import { getPost } from "../../lib/blog.ts";
export const handler = define.handlers({
 async GET(ctx) {
 const post = await getPost(ctx.params.slug);
 if (!post) return ctx.renderNotFound();
 return ctx.render({ post });
 }
});
export default define.page<typeof handler>(function BlogPost({ data }) {
 const { post } = data;
 return (
 <article>
 <h1>{post.title}</h1>
 <time>{post.date}</time>
 <div dangerouslySetInnerHTML= />
 </article>
 );
});
Fresh’s island architecture (only ship JS for interactive components) is elegant:
// islands/Counter.tsx — only this component ships JavaScript to the browser
import { useSignal } from "@preact/signals";
export default function Counter() {
 const count = useSignal(0);
 return (
 <div>
 Count: {count}
 <button onClick={() => count.value++}>+</button>
 <button onClick={() => count.value--}>-</button>
 </div>
 );
}
Everything outside islands/ is server-rendered with zero client JS. This makes Fresh apps fast by default — you have to opt into client JavaScript, not opt out.
Deno Deploy: Edge-First Runtime
Deno’s cloud offering, Deno Deploy, runs your code on V8 isolates at the edge (currently 35+ regions). It’s comparable to Cloudflare Workers but with a better local development story:
// Same code runs locally and on Deno Deploy
Deno.serve({ port: 8000 }, async (req) => {
 const url = new URL(req.url);
 
 if (url.pathname === "/api/time") {
 return Response.json({
 time: new Date().toISOString(),
 region: Deno.env.get("DENO_REGION") ?? "local"
 });
 }
 
 return new Response("Not found", { status: 404 });
});
# Local dev
deno run --allow-net server.ts
# Deploy
deployctl deploy server.ts
No adapter code, no platform-specific APIs. The Web Standard APIs (Request, Response, fetch, Blob) work identically locally and in production.
The Honest Comparison with Node in 2026
Dimension
 Node.js
 Deno 2.0
 
Ecosystem size
 Massive (npm)
 Growing (npm compat + JSR)
 
TypeScript DX
 Good (with tooling)
 Excellent (native)
 
Security model
 None by default
 Permission-based
 
Startup time
 Fast
 Fast
 
Tooling
 Fragmented
 Integrated (fmt, lint, test, bench)
 
Production track record
 Decades
 3-4 years serious use
 
Hiring pool
 Huge
 Node devs adapt quickly
 
Node isn’t going away. The npm ecosystem is too large, and Bun (another Node-compatible runtime) is fighting for the same mindshare. But Deno 2.0 is a genuinely compelling choice for new projects — especially teams that want TypeScript-first development without the toolchain complexity.
Getting Started
# Install Deno
curl -fsSL https://deno.land/install.sh | sh
# Create a new project
deno init my-project
cd my-project
# Run with all the batteries
deno task dev
The tooling is integrated: deno fmt formats your code, deno lint lints it, deno test runs tests with code coverage, deno bench benchmarks. No Prettier config, no ESLint config, no Vitest setup.
For new projects where you have the choice, Deno 2.0 is worth a serious look.
References: Deno 2.0 Announcement, JSR Documentation, Fresh 2.0 Guide

Deno 2.0 and the End of the Node Monoculture

댓글