Deno vs Node.js — cuộc tranh luận đã có hồi kết?

Cuộc tranh luận về Deno trước đây xoay quanh tương thích npm. Vấn đề đó đã được giải quyết: Deno 2.x import bất kỳ package npm nào mà không cần npm install. Câu hỏi năm 2026 là liệu những lợi thế về DX — TypeScript zero-config, permission default-deny, toolchain tích hợp sẵn — có đáng để chuyển đổi cho một dự án Node.js production không. Với dự án TypeScript-first mới: có. Với monolith Node.js đang chạy: chưa.

Bài này dành cho ai

Backend JS/TS developer đang cân nhắc bắt đầu dự án mới trên Deno, hoặc đang cân nhắc việc migrate từ service Node.js hiện tại. Nếu stack của bạn có native C++ addon, dừng lại ở đây — Deno không xử lý được trường hợp đó, và chi phí migration không bù đắp được.

Tổng quan nhanh

Tiêu chí	Deno 2.7	Node.js 24
Package npm	✅ qua specifier `npm:`	✅ native
TypeScript	✅ tích hợp sẵn, zero-config, kiểm tra type	⚠️ chỉ strip-types; không JSX, không kiểm tra type
Mô hình bảo mật	✅ default-deny; cờ allow/deny tường minh	✅ cờ `--permission` ổn định (từ Node 22.13.0); default-allow
Throughput HTTP (production, Deno 2.x vs Node 22)	~47.000 req/s	~42.000 req/s
Cold start (TypeScript)	~80ms	~400ms (với tsx/ts-node)
Thư viện chuẩn	✅ `@std` trên JSR	❌ không có stdlib chính thức; dùng npm
Formatter / linter / test runner	✅ tích hợp sẵn (`deno fmt`, `deno lint`, `deno test`)	❌ cần ESLint + Prettier + Jest/Vitest
Hỗ trợ native addon	⚠️ cần `--allow-ffi`; chưa đầy đủ	✅ hỗ trợ đầy đủ
Hệ sinh thái package	npm (3,2M qua `npm:`) + JSR (~40k)	npm (3,2M)
LTS	✅ kênh backport 6 tháng	✅ chu kỳ LTS 30 tháng

TypeScript

Đây là lập luận mạnh nhất của Deno. Một binary duy nhất. Không tsconfig, không ts-node, không bước build.

deno run server.ts

Type checking chạy song song với thực thi. JSX hoạt động luôn. Toolchain — formatter, linter, test runner — đã tích hợp sẵn. Với dự án mới, điều đó loại bỏ ba đến bốn file config và một bước build mà bạn không bao giờ phải viết.

Node 24 có --strip-types, cho phép chạy file .ts trực tiếp. Cái tên đã nói lên tất cả: nó strip annotation rồi bỏ đi. Không kiểm tra type. JSX không hoạt động. Enum và decorator cần transformation vẫn phải dùng tsx hoặc ts-node. Để có hỗ trợ TypeScript đầy đủ trong Node, bạn vẫn phải quản lý tsconfig và transpiler.

Deno 2.6 thêm tsgo dạng thử nghiệm — một type checker TypeScript được viết lại bằng Go, chạy nhanh hơn khoảng 2× so với TypeScript compiler tiêu chuẩn. Nó chưa ổn định. Nhưng hướng đi đã rõ: Deno đang đầu tư vào hiệu năng TypeScript; Node đang thêm khả năng chạy TypeScript nhưng bỏ qua type safety.

Mô hình bảo mật

Mô hình của Deno là default-deny. Đọc file, yêu cầu mạng, spawn subprocess — tất cả đều bị chặn cho đến khi được cấp phép rõ ràng.

deno run --allow-net=api.stripe.com --allow-env="STRIPE_KEY" server.ts

Nếu một dependency npm transitively cố ghi vào disk, Deno chặn lại. Các team migrate từ Node báo cáo phát hiện ra truy cập filesystem ngoài ý muốn từ dependency trước khi lên production — loại hoạt động không bao giờ lộ ra trên runtime default-allow.

Cờ --permission đã được ổn định trong Node 22.13.0 và Node 23.5.0, bao gồm đọc, ghi, tiến trình con, worker, và mạng. Các quyền kiểm soát tương đương Deno. Sự khác biệt nằm ở mặc định: Deno chặn mọi thứ và bạn mở cụ thể những gì cần; Node cho phép mọi thứ trừ khi bạn nhớ truyền --permission khi khởi động.

Một lỗ hổng đã được xác nhận (Endor Labs — CVE-2025-55130) cho phép absolute symlink vượt qua giới hạn file-system khi --permission đang hoạt động trong Node. Deno không có lỗ hổng tương đương nào được biết đến.

Với dự án greenfield mà bảo mật là ưu tiên, mô hình của Deno vượt trội rõ ràng. Với internal API trên mạng tin cậy, khoảng cách thực tế nhỏ hơn.

Hiệu năng

Một ca migrate production kéo dài sáu tháng của nhóm ba người đã benchmark cùng một service tương đương Fastify trên cả hai runtime:

Chỉ số	Deno 2	Node.js 22 + Fastify
Throughput	~47.000 req/s	~42.000 req/s
Tăng hiệu năng production	+5–8%	—
Độ trễ p99	~10ms	~12ms
Bộ nhớ	thấp hơn ~10%	—

Benchmark tổng hợp từ cộng đồng cho Deno ~75k req/s và Node ~65k req/s — Bun dẫn đầu cả hai ở ~180k req/s trong các bài test đó. Số liệu tổng hợp biến động quá nhiều tùy setup để dùng ra quyết định; báo cáo production là baseline tốt hơn cho một HTTP API thông thường.

Cold start là nơi Deno có lợi thế cấu trúc rõ ràng: ~80ms cho TypeScript so với ~400ms của Node với tsx/ts-node. Với worker ngắn hạn và compute kiểu Lambda, con số này có ý nghĩa. Với API server chạy lâu dài chỉ khởi động một lần, nó không quan trọng.

Hệ sinh thái — JSR và npm

Deno hỗ trợ package npm qua specifier npm:, được resolve và cache tự động.

import chalk from "npm:chalk@5";
import express from "npm:express@4";

Hệ sinh thái 3,2 triệu package npm sẵn dùng mà không cần bước install riêng. deno install còn được báo cáo nhanh hơn 15% cold-cache và 90% warm-cache so với npm — hữu ích cho CI pipeline.

JSR là registry native TypeScript mới hơn, khoảng 40k package vào đầu 2026. Nó không thay thế npm — mà là nơi phù hợp hơn cho các thư viện TypeScript-first cần reach cross-runtime (Deno, Node, Bun, trình duyệt). Hono, các module @std của Deno, OpenAI, và Supabase đều publish ở đó. Setup thực tế cho dự án Deno mới: npm cho dependency production đã ổn định, JSR cho package nào có publish ở đó, @std cho tiện ích chuẩn.

Điểm ma sát khi migrate

Những nơi các team thực tế gặp khó khăn, trích từ báo cáo migrate production và tài liệu tương thích của Deno:

Native C++ addon — giới hạn cứng. Package có native binding cần --allow-all và node_modules local. Team có addon phụ thuộc C++ hoặc Rust không nên migrate.

Thư viện WebSocket [email protected] — rò rỉ bộ nhớ trên Deno do dùng stream internals của Node thay vì WebSocket chuẩn Web. Nhóm production gặp vấn đề này sau sáu giờ có traffic. Cách giải quyết: viết lại dùng WebSocket API native của Deno.

Prisma trước 6.x — edge case với binary query engine. Prisma 6.x (2026) hoạt động trên Deno; các phiên bản trước thì không.

__dirname / __filename — không dùng được trong Deno. Thay bằng import.meta.dirname và import.meta.filename.

Package JS/TS thuần — ít ma sát. Express, Fastify, zod, axios, date-fns, và jose đều chạy không cần thay đổi theo báo cáo production.

Khối lượng migrate thực tế: codebase TypeScript thuần mất từ hai giờ đến hai ngày. Codebase dùng nhiều native addon có thể mất ba tuần — hoặc không khả thi.

Verdict

Chọn Deno nếu:

Bạn đang xây dựng service backend hoặc CLI tool TypeScript-first
Bạn muốn formatting, linting, testing, và kiểm tra type trong một binary duy nhất không cần config
Bảo mật là ưu tiên và permission default-deny là cơ chế hữu ích
Cold start quan trọng — worker ngắn hạn, CLI tool, compute kiểu Lambda

Ở lại Node.js nếu:

Dự án của bạn có native C++ addon
Bạn đang chạy monolith Express hoặc Next.js và không có lý do cụ thể để viết lại
ESLint config, Jest suite, và deployment pipeline của team đã ổn định và hoạt động tốt
Bạn phụ thuộc vào Prisma trước 6.x hoặc ORM chưa được test trên Deno
Infrastructure của bạn là AWS Lambda hoặc ECS và cần Node container-native

Tương thích không còn là lý do để ở lại Node. Những gì còn lại rất cụ thể: native addon, toolchain đã đầu tư nhiều, và ORM chỉ hỗ trợ Deno một phần. Nếu không cái nào áp dụng cho dự án mới của bạn, Deno là điểm xuất phát năng suất hơn.

Về deployment: Deno Deploy đã GA vào ngày 3 tháng 2 năm 2026 — V8 isolate trải rộng 35+ edge region, 1 triệu requests/tháng miễn phí, 1 GB KV storage, không cần thẻ tín dụng. Với service dùng Node, Vercel, Fly.io, và Railway vẫn là lựa chọn vững chắc.

Nếu bạn đang so sánh các JS runtime, xem Bun vs Node.js — chọn cái nào năm 2026? của chúng tôi. Với team xây dựng web app React full-stack trên Node, xem so sánh Next.js 16 vs React Router v7. Nếu cân nhắc ngôn ngữ backend non-JS vì hiệu năng, xem Go vs Rust 2026.