Deno 2.8

• deno add và deno install mặc định xử lý tên gói không có tiền tố trong CLI như các gói npm:, giúp dễ thay thế npm install, yarn hoặc pnpm install trong các dự án Node hiện có
• deno audit fix tự động nâng cấp các gói npm phụ thuộc có lỗ hổng lên bản vá gần nhất thỏa mãn ràng buộc phiên bản, đồng thời hiển thị riêng các mục cần thay đổi major version
• Các lệnh con mới deno ci, deno pack, deno transpile, deno why, deno bump-version được bổ sung để hỗ trợ cài đặt có thể tái lập, tạo tarball để phát hành npm, chuyển đổi TS→JS, truy vết đường đi phụ thuộc và cập nhật phiên bản workspace
• Khả năng tương thích API Node.js tăng từ khoảng 42% ở Deno 2.7 lên 76.4% (3.405/4.457) ở Deno 2.8 theo bộ test của chính Node, và nhiều mô-đun node: được tải trì hoãn nên chương trình không dùng các mô-đun đó khởi động nhanh hơn
• Hiệu năng so với Deno 2.7.1 được cải thiện với cài đặt npm lạnh nhanh hơn 3,66 lần từ 3.319ms xuống 906ms, base64 của node:buffer nhanh hơn 3,07 lần, thông lượng node:http tăng 2,21 lần và scrypt của node:crypto tăng 2,12 lần
• Thay đổi về khả năng tương thích khiến setTimeout và setInterval toàn cục trả về đối tượng Timeout của Node thay vì số, nên mã từng lưu giá trị trả về dưới dạng number hoặc dùng cho kiểm tra kiểu hay phép toán cần được sửa thành NodeJS.Timeout hoặc tương đương
• TypeScript 6.0.3 được tích hợp sẵn và deno check, LSP mặc định bao gồm lib.node, nên có thể phân giải các kiểu Node như NodeJS.*, Buffer, process mà không cần cấu hình thêm
• Trong debugging, tab Network của Chrome DevTools có thể hiển thị lưu lượng fetch(), node:http/node:https và WebSocket của Deno, đồng thời có thể tạo profile V8, flamegraph SVG và báo cáo Markdown bằng --cpu-prof, --cpu-prof-flamegraph, --cpu-prof-md
• Với quản lý gói và workspace, giao thức catalog:, deno install --os --arch, --prod, nodeModulesLinker: "hoisted", min-release-age trong .npmrc và --package-json được thêm vào để hỗ trợ thống nhất phiên bản monorepo, cài đặt đa nền tảng, cài đặt production và chuyển từ dự án Node hiện có
• deno compile phát hiện các dự án Next.js, Astro, Fresh, Remix, SvelteKit, Nuxt, SolidStart, TanStack Start và Vite SSR để chạy deno task build rồi tạo entry point phù hợp, đồng thời cũng hiển thị tiến độ khi xử lý cây phụ thuộc npm lớn
• Trong kiểm thử và Web API, giá trị mặc định của sanitizeOps và sanitizeResources trong Deno.test() đổi thành false, thêm timeout theo từng test và coverage ở mức hàm, đồng thời bổ sung OffscreenCanvas, Headers, Request, Response và Streams có thể truyền, SHA3 digest và hỗ trợ Web Crypto P-521
• Về nâng cấp và nền tảng runtime, deno upgrade khi có thể sẽ dùng cập nhật delta để giảm dung lượng tải từ khoảng 48MB xuống còn 3–6MB, có thể cài bản build PR bằng deno upgrade pr <number>, và V8 được nâng từ 14.6 lên 14.9

[GN⁺]

Ý kiến trên Hacker News

• Deno hữu ích vì có mô hình phân quyền mặc định, được viết bằng Rust và hỗ trợ TypeScript nguyên bản
  Tôi không quá đào sâu vào hệ sinh thái web dev/Node/Bun, nhưng đã dùng Deno khá hài lòng cho các dịch vụ nhỏ trong vài năm qua. Tôi tò mò vì sao Bun có vẻ phát triển nhanh như vậy. Không rõ có phải nó chủ yếu được dùng như bundler và ít được dùng hơn như một JavaScript runtime hay không
  Chỉ riêng hệ thống phân quyền thôi cũng đã khiến Deno hấp dẫn, nên tôi không thật sự hiểu vì sao nhiều người chuyển từ Node sang Bun mà không chọn Deno

  • Deno và Bun có trọng tâm khá khác nhau khi mới ra mắt. Deno là nỗ lực của Ryan, người tạo ra Node, nhằm sửa nhiều thứ mà ông ấy cho là sai ở Node, còn Bun ngay từ đầu đã tập trung vào tương thích Node và chạy các framework phổ biến như Next.js
    Trong thời gian dài, rất nhiều dependency và framework không chạy đúng trên Deno, và ban đầu thậm chí còn chưa có tính năng cài dependency từ npm. Nhìn lại các cuộc tấn công chuỗi cung ứng npm, có thể Ryan đã đúng
    Vì vậy Bun trông giống một Node tốt hơn, nhiều tiện ích hơn và ít cần cấu hình mà vẫn chạy ngay. Có vẻ đội ngũ Deno cũng nhận ra muốn thành công thì cần tương thích Node, và đã tập trung vào đó trong vài năm qua. Hiện tại tôi cho rằng Deno còn tương thích Node tốt hơn Bun
  • Khi bắt đầu một side project TypeScript nhỏ, chỉ cần dùng Bun là đủ thay vì bị chìm trong biển npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime
    Nhân tiện, chỉ một phần trong số đó là chiêu thức Pokémon, còn lại đều là công cụ thật trong hệ sinh thái JS/TS
  • Tôi dùng cả hai và đều thích. Bun gần với một bản thay thế drop-in cho Node hơn
    Khi không muốn đụng vào cấu hình test, tsconfig hay ES module, nó thường cứ thế mà chạy. Deno có standard library tốt, hỗ trợ CLI rất tuyệt, và trước đây tôi cũng thích deno deploy, nhưng dạo này nó đã trở nên khá phiền phức
  • Tôi chủ yếu là backend developer, nhưng khi thỉnh thoảng đụng đến frontend cho dự án cá nhân thì Deno có vẻ là lựa chọn hợp lý nhất
    Nó thật sự rất dễ làm việc cùng, nên khá tiếc là nó chưa lan rộng hơn trong giới JS
  • Tôi đã dùng Deno khoảng 1 năm và thích nó vì những ưu điểm kể trên, nhưng gặp quá nhiều vấn đề tương thích với các package như Astro, Prisma, Vite
    Vì thế tôi chuyển sang Bun và mọi thứ mượt mà hơn nhiều

• Tôi tò mò không biết Deno hiện giờ đang ở trạng thái nào
  Node là lời giải ổn định và sẽ còn tồn tại lâu dài. Giờ nó cũng dùng được TypeScript, và có vẻ sắp có thể build ứng dụng thành một file thực thi duy nhất, kể cả kèm native dependency
  Bun thì hơi hỗn loạn nhưng nhanh, và cách tiếp cận đưa mọi thứ vào standard library khá thú vị. Ngoài ra nó còn được Anthropic mua lại
  Deno từng có câu chuyện hấp dẫn về sandbox và việc import dependency bên thứ ba dễ dàng, nhưng sandbox giờ có cảm giác đã trở nên khá phổ biến, còn cách import đó rốt cuộc cũng chưa chắc tốt hơn npm add là bao

  • Deno đã sa thải khoảng một nửa công ty vào khoảng 2 tháng trước: https://news.ycombinator.com/item?id=47467746
  • Có ai xem chuyện bị Anthropic mua lại là tích cực sao?
  • Để hệ sinh thái không bị trì trệ thì có nhiều lựa chọn vẫn là điều tốt
  • Việc phân phối dưới dạng single executable đã làm được rồi. CLI của sản phẩm tôi là ứng dụng Node single executable
  • Tôi không biết là rồi đây có thể build single executable kèm cả native dependency. Đó là một tính năng rất mạnh

• Deno rất tuyệt. Tôi đang viết các dịch vụ web nhỏ và cỡ vừa bằng Deno
  Nó chạy chuẩn như đồng hồ Thụy Sĩ, và triết lý dự án cũng rất hợp với tinh thần Unix
  Cá nhân tôi thấy những người làm ra Deno hơi khiêm tốn. Ngay cả khi người dùng biết ơn đề nghị quyên góp cho dự án, họ cũng lịch sự từ chối. Tôi hiểu lý do, nhưng về lâu dài điều đó có thể tạo ra áp lực tài chính không cần thiết cho dự án
  Một gói đăng ký hàng tháng kiểu “xin hãy nhận tiền đi” dành cho những người dùng phụ thuộc vào thành công lâu dài của dự án có thể khá phù hợp

  • Dùng nó thực sự rất thích. Gần như cảm giác pha trộn giữa JavaScript và Go
    Nhanh, linh hoạt, có package management hơi tỉnh táo hơn với tính năng mạnh hơn các lựa chọn JS/TS khác, mô hình bảo mật tốt hơn, standard library tốt hơn. Và nó còn rất nhanh

• Với những ai chưa quen tên Deno, thì Deno là một JavaScript và TypeScript runtime
  Có một bài review so sánh Deno 2.6 với đối thủ Bun 1.3 và Node.js 25: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

  • Thật ngạc nhiên khi Bun nhanh hơn nhiều như vậy trong xử lý web request. Bài viết cho rằng Zig là một yếu tố, nhưng tôi tự hỏi liệu chỉ riêng kiểm soát bộ nhớ chi tiết có thể mang lại lợi thế hơn 2 lần so với Node hay không
    Tương tự, dù không nói rõ, có vẻ Bun được chạy trong trạng thái package cache đã nóng. Tôi cũng muốn biết các runtime khác có cache hay không

• Chu kỳ phát hành đều đặn của Deno rất ấn tượng. Tôi mong chờ xem bản này có những cải thiện hiệu năng nào

• Lệnh deno pack mới là một bổ sung tốt cho việc đóng gói an toàn và đơn giản
  Nếu dùng Node.js, một lệnh tương tự có thể thực hiện bằng https://www.npmjs.com/package/ts-node-pack
  Giờ đây Node.js hỗ trợ import module .ts, nên sẽ có thêm nhiều repository có thể dùng cách này mà không cần bước build hoặc đưa build artifact vào checkout

  • Đọc bài blog này làm tôi lập tức phải cân nhắc. deno pack có thể thay thế luồng npm publish hiện tại của package mã nguồn mở của tôi, đồng thời phù hợp để tiếp tục chuyển công việc sang hướng ưu tiên Deno/lấy Deno làm trung tâm
    Ở chiều ngược lại, vì TypeScript support của Node đang mạnh lên, chuyển sang package npm chỉ dành cho TypeScript cũng có thể là một tín hiệu rất nhỏ gửi tới hệ sinh thái
    Dù vậy, tôi vẫn vui vì JSR tồn tại như một hệ sinh thái tương đối sạch sẽ hơn
  • Nghe khá giống DNT vốn đã có từ lâu (https://github.com/denoland/dnt)
    Nhưng khi được đưa vào Deno CLI thì mức độ hiện diện sẽ tăng lên đáng kể

• Nếu Deno giữ vững giá trị ban đầu thêm một chút nữa, áp lực về tương thích Node có lẽ đã được AI agent bù đắp phần nào
  Phần lớn áp lực đó đến từ vấn đề mức độ thành thạo. Nếu bạn chỉ biết cách cấu hình bằng express.js, thì bạn sẽ cảm thấy bất kỳ công cụ hay runtime nào về sau cũng phải cung cấp lớp trừu tượng tương tự để việc chuyển đổi được “mượt mà”. Điều này không liên quan đến việc giải pháp đầu tiên tệ đến mức nào
  Ngày nay có thể giới thiệu công nghệ mới cho developer bằng cách cung cấp kèm một gói công nghệ cần thiết cùng sản phẩm, và điều đó đôi khi thực sự thay thế được tài liệu, đồng thời khá hữu ích trong việc cho thấy những cách tiếp cận thay thế tốt hơn

  • Nếu SDK JS/TS tôi nhận từ một nhà cung cấp SaaS không chạy được trên Deno mà không cần chỉnh sửa, thì tôi sẽ không dành nổi 1 giây để sửa nó

• Từ trải nghiệm đã dùng Deno cho nhiều hobby project, tôi tin chắc rằng Deno là hướng mà hệ sinh thái JS nên đi tới
  Tuy vậy, để khuyến nghị nó trong công việc ngoài một số use case rất cụ thể và thường khá hẹp thì lại phức tạp. Đến lúc nào đó nếu dự án đổi hướng vì lý do kinh doanh, cuối cùng bạn vẫn sẽ cần Node

• Sau khi Edge.js [1] ra mắt, thật vui khi thấy Deno bắt đầu nghiêm túc hơn với tương thích Node.js
  Chỉ trong khoảng 2 tháng, mức này đã tăng từ hơn 40% lên khoảng 75%, dù là ngẫu nhiên hay không thì đây rõ ràng cũng là một bước đi đúng hướng
  Chúc mừng toàn bộ đội ngũ Deno
  [1] https://edgejs.org/

  • Tự quảng bá thế này không thấy chán à?

• Tôi bọc phần lớn các thành ngữ kiểu Node và dùng Deno làm runtime. Nó hoạt động tốt
  Nếu project là TypeScript thuần thì tôi cứ chạy bằng Deno. Các tùy chọn bổ sung cho bảo mật cũng tốt, và tôi thích việc script cài đặt bị tắt mặc định
  Nếu bạn vẫn đang dùng Node trực tiếp thì nên dừng lại. Tối thiểu thì theo tôi dùng Bun còn tốt hơn
  Với công việc dựa trên agent, gần như không có lý do gì để dùng thứ khác ngoài Rust và TypeScript. Có thể có người không đồng ý, nhưng type safety, memory safety và kho ngữ liệu công việc khổng lồ là rất quan trọng. Agent sẽ dễ khám phá hơn khi có những lỗi khó nhằn và các pattern tích hợp sẵn. Với UI thì TypeScript là hợp lý nhất vì có quá nhiều ví dụ thiết kế sẵn có ngoài kia