Deno 2 vững về mặt kỹ thuật. Nó chạy được npm packages, thực thi TypeScript natively, và ship dưới dạng một binary đơn tích hợp sẵn formatter, linter, test runner, và compiler. Không ai tranh cãi điều đó. Điều người ta tranh cãi là liệu tất cả những thứ đó có đang thắng hay không.

State of JS 2025 khảo sát 11.141 developer. Deno có 1.244 người dùng — 11.2%, xếp thứ sáu, giảm một bậc so với 2024. Bun có 2.321 — 21%, xếp thứ ba, tăng bốn điểm phần trăm so với năm trước. Tháng 3/2026, Deno Land Inc. cắt giảm nhân sự đáng kể. Cái rebrand từ “không có npm” sang “tương thích Node.js hoàn toàn” đáng lẽ phải thu hút những người đang do dự. Dữ liệu nói là không.

Bài này dành cho ai

Bạn đang đánh giá Deno 2 cho một dự án TypeScript mới và muốn đọc nhận xét thực tế, không phải một bảng so sánh tính năng. Bạn đã biết JavaScript. Bạn muốn biết Deno vấp ngã ở đâu, không chỉ nơi nó tỏa sáng.

Nếu dự án của bạn phụ thuộc nhiều vào CJS packages hoặc gRPC services, hãy nhảy thẳng đến phần compatibility trước — phần đó có thể kết thúc quá trình đánh giá ngay từ đầu.

Những gì chúng tôi thử nghiệm

Deno v2.8.1 (phát hành ngày 27/5/2026), so sánh với Node.js v24.x và Bun v1.x. Số liệu về mức độ sử dụng lấy từ khảo sát State of JS 2025 (2025.stateofjs.com, n=11.141, không có trọng số). Chúng tôi không chạy performance benchmarks — xem phần Lưu ý để hiểu lý do.

Kết quả

Mức dùng đang dậm chân trong khi Bun tăng tốc

Deno không chết. GitHub cho thấy ~107k stars, v2.x vẫn tiếp tục ra releases đến tháng 5/2026, và dự án vẫn đang hoạt động. Nhưng “không chết” và “đang lớn” là hai chuyện khác nhau.

Bun tăng bốn điểm phần trăm trong State of JS 2025. Deno không tăng gì đáng kể. Con số về mức độ adoption quan trọng vì giá trị của một runtime cộng hưởng với hệ sinh thái của nó — libraries, câu trả lời trên StackOverflow, kỹ sư mới tuyển đã biết dùng nó. Hệ sinh thái của Deno không thu hẹp, nhưng nó cũng không tăng nhanh hơn Node.js hay Bun. Nếu State of JS 2026 trông tương tự, khoảng cách này sẽ trở thành vấn đề cơ cấu, không phải theo chu kỳ.

Tại sao Bun đang bứt phá là một phần do phỏng đoán. Khả năng tương thích npm của Bun cao hơn ngay từ đầu. Bun ra mắt trên Windows sớm hơn. Marketing về hiệu năng của Bun — dù các con số chưa được kiểm chứng — ồn ào và dễ thấy hơn. Pitch của Deno (tính đúng đắn, bảo mật, TypeScript-first) nhắm đến một nhóm đối tượng coi trọng những thứ đó, và rõ ràng đó không phải là nhóm lớn hoặc đang tăng so với cộng đồng JavaScript nói chung.

Còn một chiều kích tổ chức nữa. Bun vẫn đang trong giai đoạn tăng trưởng ban đầu, với một đội nhỏ và tập trung. Deno Land Inc. đã lớn hơn trước và vừa cắt giảm đáng kể. Tổ chức nhỏ hơn có thể di chuyển nhanh hơn; nhưng họ cũng có thể không ship được gì nếu tinh thần sụp đổ. Release v2.8.1 vào cuối tháng 5 cho thấy team vẫn đang làm việc, nhưng chúng tôi đang theo dõi sát hơn so với một platform đã ổn định. Để xem so sánh trực tiếp, tham khảo Bun vs Deno 2026.

Tương thích npm: tốt — cho đến khi không còn tốt nữa

Lời hứa chính của Deno 2 là tương thích Node.js thực sự. Với trường hợp phổ biến, nó thực hiện được. node_modules sống chung với deno.json. Hầu hết packages bạn cần từ ngày đầu đều import sạch sẽ.

Các trường hợp ngoại lệ là cạnh sắc thực sự.

fp-ts và CJS directory imports. Nếu bạn dùng fp-ts hoặc bất kỳ package nào resolve qua CJS directory style — require('fp-ts/Option') — Deno sẽ throw Is a directory (os error 21). GitHub issue #27894 ghi lại điều này. Nó đã bị đóng với nhãn not-planned. Cách workaround là import trực tiếp file (fp-ts/Option/index.js), chỉ hoạt động khi bạn kiểm soát import site. Nếu một transitive dependency thực hiện CJS directory import, bạn không thể sửa từ bên ngoài.

@google-cloud/tasks gRPC. OAuth flow trong @google-cloud/tasks thất bại với Premature close bắt đầu từ Deno 2.2.6, được ghi lại trong issue #28813. Bug này còn mở tại thời điểm viết bài (tháng 5/2026) và đã được đóng — hãy xác minh xem bản sửa có trong phiên bản Deno bạn nhắm đến chưa trước khi commit.

Cả hai trường hợp đều không phải là hiếm gặp. Cả hai đều ảnh hưởng đến các library thực tế. Khả năng tương thích của Deno tốt hơn Deno 1.x, nhưng nó không phải là Node.js.

JSR: độ tin cậy đang cải thiện, nhưng độ phủ vẫn còn hạn chế

JSR là lựa chọn thay thế npm của Deno: TypeScript-native, chỉ dùng ESM, không cần compile để publish. Quản trị của nó trông như một nước cờ để xây dựng uy tín: Ryan Dahl, Isaac Schlueter (người tạo ra npm), Evan You (Vue), James Snell (Node core), Luca Casonato. Ban quản trị là thực và những cái tên đó có trọng lượng.

Sức kéo cũng có thực. SDK JavaScript chính thức của OpenAI được publish trên JSR. pnpm v10.9+ thêm hỗ trợ native cho jsr: protocol, nghĩa là các dự án Node.js có thể kéo JSR packages mà không cần chạy Deno. Khả năng tiếp cận đa runtime đó không có được một năm trước.

Publish lên JSR đơn giản hơn đáng kể so với npm. Bạn định nghĩa deno.json với name và version, chạy deno publish, và JSR tự động tạo API documentation từ TypeScript types của bạn — không cần JSDoc, không cần upload build output. Với tác giả library, đó là giảm thiểu friction thực sự. Với người dùng, documentation luôn đồng bộ với types vì chúng là cùng một artifact.

Giới hạn là nguồn cung. npm chứa khoảng 3 triệu packages. JSR chứa một phần nhỏ trong đó — tổng số không được hiển thị nổi bật trên jsr.io, điều đó tự nó đã là một tín hiệu. Nếu bạn đang build thứ gì đó hoàn toàn mới với TypeScript, JSR đủ để làm việc. Nếu bạn đang tích hợp với hệ sinh thái JavaScript hiện có, npm vẫn là chuỗi cung ứng chính. JSR là nơi bạn publish library mới, không phải nơi bạn tìm những thứ đã có trong production.

DX: lý do thực sự để chọn Deno

Lập luận về developer experience cho Deno mạnh hơn vị thế thị trường của nó.

TypeScript không cần build step. Deno chạy trực tiếp file .ts. Không cần gọi tsc, không cần tsconfig.json, không cần watch process để compile. Bạn viết TypeScript và chạy nó. Node.js 24 đã thêm native type stripping — bạn có thể chạy file .ts mà không cần tsc — nhưng có những khác biệt thực sự. Type stripping của Node loại bỏ enums, decorators, parameter properties, và namespace declarations có runtime code. Nó bỏ qua hoàn toàn việc type checking: runtime strip types và chạy, không validate chúng. Bạn vẫn cần cấu hình package.json và tùy chọn tsconfig.json để có hành vi mong muốn. Hỗ trợ TypeScript của Deno đầy đủ hơn.

Một binary, không cần lắp ghép toolchain. deno fmt. deno lint. deno test. deno bench. deno compile. Tất cả ship cùng với runtime. Các dự án Node.js thường phải lắp ghép từ bốn đến tám npm packages riêng lẻ với config và version constraints của riêng chúng. Mô hình all-in-one của Deno loại bỏ toàn bộ bề mặt đó.

Quyền hạn mặc định bị từ chối. Một Deno script không thể đọc filesystem trừ khi bạn truyền --allow-read. Nó không thể kết nối mạng mà không có --allow-net. Không thể truy cập biến môi trường mà không có --allow-env. Trong thực tế, điều này có nghĩa là bạn chạy deno run --allow-net --allow-env src/server.ts và runtime thực thi hợp đồng đó — một dependency cố exfiltrate files âm thầm sẽ gặp phải từ chối quyền hạn ngay tại runtime. Đây không phải là bảo vệ hoàn hảo cho supply chain; một package độc hại vẫn có thể gây hại trong phạm vi được phép. Nhưng nó nâng cao mức sàn theo cách Node.js không thể làm mà không cần thêm công cụ sandboxing. Với các script xử lý dữ liệu nhạy cảm, câu chuyện kiểm soát rõ ràng hơn đáng kể.

Tích hợp IDE. Language server và VS Code extension của Deno hoạt động tốt với Cursor — TypeScript autocomplete, import resolution qua deno.json, và workspace config đều hoạt động mà không cần những thủ thuật path trong tsconfig.json mà các dự án Node TypeScript thường yêu cầu.

Deno Deploy: edge functions với những lưu ý

Deno có sản phẩm deployment được host — Deno Deploy — được thiết kế để chạy Deno scripts tại edge, gần Cloudflare Workers hơn là VPS truyền thống. API nhạy cảm với độ trễ và phân phối toàn cầu là use case nhắm đến. Xem so sánh đầy đủ tại Deno Deploy vs Cloudflare Workers.

Sản phẩm tồn tại và hoạt động. Câu hỏi sau khi Deno Land Inc. cắt giảm nhân sự vào tháng 3/2026 là liệu mảng thương mại có còn là ưu tiên hay không. Chúng tôi không xác nhận được rằng free tier và giá Pro vẫn không thay đổi sau khi giảm nhân sự — trang pricing vẫn hiển thị các gói, nhưng team duy trì nó nhỏ hơn. Với các workload production trên Deno Deploy, hãy xác minh trực tiếp điều khoản giá và SLA với Deno trước khi commit. Điều này không phải là mối lo với Deno tự host; nó chỉ áp dụng cho managed service.

Hiệu năng: đừng tin vào benchmarks

Chúng tôi không chạy performance benchmarks. Chúng tôi cũng sẽ không trích dẫn một blog post năm 2024 đếm số HTTP responses hello world mỗi giây.

Điều chúng tôi có thể nói: Deno và Node.js đều chạy trên V8. Bun chạy trên JavaScriptCore. Sự khác biệt về thời gian khởi động giữa các runtime là thực và đo được — subprocess startup của Bun thực sự nhanh, điều này quan trọng với script chạy ngắn. Sự khác biệt về throughput với các server-side workload thông thường — HTTP APIs, xử lý dữ liệu — phụ thuộc vào workload và thường đủ nhỏ để không phải là trục đánh giá đúng khi chọn runtime.

Blog benchmark cho thấy Deno hoặc Bun ở mức gấp 2× hay 3× throughput của Node hầu như luôn đang đo http.listen + JSON serialization trong isolation. Đó không phải là một web server. Nếu throughput runtime là ràng buộc cứng trong quá trình đánh giá của bạn, hãy viết một benchmark thực thi hot path thực tế của bạn — database queries, middleware stack, serialization format — và đo trên hardware bạn sẽ deploy. Đừng đưa ra quyết định công nghệ production dựa trên một con số không tương ứng với workload của bạn.

Kết luận về Deno 2

Chọn Deno 2 nếu bạn đang build dự án TypeScript-first mới với dependency tree nông hoặc được kiểm soát — CLI tools, internal services, scripts, automation. DX là có thực. Sự đơn giản trong toolchain là có thực. Mô hình bảo mật là một lợi thế thực sự.

Giữ Node.js nếu dự án của bạn kéo từ hệ sinh thái npm ở bất kỳ độ sâu nào: legacy packages, CJS-heavy libraries, hoặc dependencies bạn không kiểm soát. Khả năng tương thích của Deno vững chắc với trường hợp phổ biến và giòn ở các trường hợp ngoại lệ. Xem thêm Deno vs Node.js 2026 để biết chi tiết.

Xem xét Bun nếu tiêu chí chính của bạn là tương thích npm và tốc độ khởi động, và bạn không cần đặc biệt mô hình quyền hạn của Deno. Bề mặt tương thích của Bun rộng hơn, momentum cao hơn, và nó là lựa chọn thay thế hợp lệ cho các dự án mà thiết kế security-first của Deno không phải là ưu tiên.

Lưu ý

Việc cắt giảm nhân sự là tín hiệu rủi ro thực sự. Deno Land Inc. cắt giảm nhân sự đáng kể vào tháng 3/2026. Dự án ship v2.8.1 hai tháng sau đó, vì vậy team vẫn làm việc. Nhưng team nhỏ hơn đồng nghĩa với phản hồi bug chậm hơn, phạm vi compatibility work hẹp hơn, và sự không chắc chắn thực sự về mảng thương mại — đặc biệt là Deno Deploy. Deno là open-source và có thể tiếp tục độc lập, nhưng điều đó không được đảm bảo. Hãy tính đến điều này khi đặt cược production.

gRPC sau 2.3.x chưa được xác minh. Issue #28813 còn mở tại thời điểm viết bài (tháng 5/2026) và đã được đóng — hãy xác minh xem bản sửa đã có chưa trước khi triển khai.

Giá Deno Deploy chưa được xác minh lại. Chúng tôi không xác nhận liệu free tier hoặc giá Pro sau khi cắt giảm nhân sự có thay đổi không. Kiểm tra trực tiếp trang Deno Deploy trước khi lập ngân sách.

Cloudflare Workers. Nếu bạn đang đánh giá Deno cho edge deployment, Workers là so sánh tự nhiên. Chúng tôi không có affiliate agreement với Cloudflare và không link đến đó, nhưng giá cả và độ phủ region đáng so sánh trực tiếp.

Link Cursor ở trên là affiliate link. Xem phần công bố ở đầu trang.

Deno 2 năm 2026 — cái rebrand có đang hoạt động không?