5 điều tôi thích ở Deno

Vấn đề

Deno phiên bản ổn định đã được giới thiệu cách đây 3-4 năm về trước. Thời điểm đó nó nhận được khá nhiều sự chú ý vì không ai khác - chính Ryan Dahl - cha đẻ của Node.js - cũng đồng thời là người đỡ đầu cho Deno. Hả! Bạn không nghe nhầm đâu. Tại sao anh ta lại tạo ra công cụ mới cạnh tranh với chính "đứa con" của mình chứ?

Ryan Dahl đã thừa nhận rằng Node.js tồn tại những điểm yếu chí mạng. Ban đầu, Node.js được thiết kế để tập trung đến sự đơn giản, phóng thoáng. Nhưng qua năm tháng mọi thứ đã vượt quá tầm kiểm soát. Node.js đã phát triển rất mạnh mẽ, càng nhận được sự quan tâm, mọi người càng cố nhồi nhét mọi thứ vào ngôi sao mới nổi này và điều đó làm nó phức tạp hơn mức cần thiết.

Deno ra đời để khắc phục những điểm yếu của Node. Nhưng thực tế ở thời điểm ra mắt, nó chưa thể hiện được điểm mạnh của mình. Hiệu năng thậm chí còn thua xa Node.js, chưa kể việc không hỗ trợ npm - vốn là điểm ăn tiền nhất của Node cũng không có. Điều đó khiến cho khó khăn chồng chất lại chồng chất.

Vốn là một đứa tò mò, tôi đã nhanh chóng thử nghiệm một số đoạn mã cùng Deno và nhận ra sự bất tiện về hệ thống thư viện. "Chà, chắc phải rất lâu nữa thì thư viện yêu thích của mình mới xuất hiện trên này, chứ nhìn vào thì cái gì cũng vừa mới mà vừa lạ mắt" - Tôi nghĩ!

Mọi thứ thay đổi kể từ khi tôi bắt tay vào "Đập đi xây lại" trang Blog. Sau nhiều lần đắn do, suy nghĩ lựa chọn công nghệ mới thì cái tên Fresh xuất hiện. Thế nhưng Fresh cần Deno làm môi trường chạy. Vốn chưa có kinh nghiệm triển khai trước đó nhưng với suy nghĩ "nó cũng chỉ là môi trường chạy JavaScript thôi mà!" thì càng khiến mình tự tin hơn. Câu chuyện tiếp theo chính là bài viết này.

Ngày hôm nay, tôi sẽ tổng hợp lại 5 điểm mà tôi cảm thấy "thích" khi làm việc với Deno.

Hỗ trợ TypeScript

Deno mặc định hỗ trợ TypeScript. Điều đó có nghĩa bạn có thể chạy trực tiếp một tệp .ts mà không cần qua một bước chuyển đổi mã về .js như các thư viện khác thường làm. Nhiều người thắc mắc điều này có khác gì với sử dụng công cụ hỗ trợ chạy mã TypeScript như ts-node không? Chắc chắn là có rồi vì ts-node cần có các tệp cấu hình của TypeScript để hoạt động trong các trường hợp phức tạp, còn Deno thì không. Việc hỗ trợ TypeScript là mặc định giúp đơn giản hoá quá trình chạy trực tiếp mã .ts.

Tôi thường xuyên tạo ra các tệp script để xử lý một vài công việc lặt vặt cho mình. Mỗi lần tạo mới một script, luôn phải phân vân giữa việc lựa chọn .js hay là .ts. Và khi Deno xuất hiện thì .ts như là một lựa chọn mặc định. Kể cả trong dự án Node, khi cần viết một script để thực hiện nhanh một tác vụ nào đó, tôi vẫn ưu tiên lựa chọn .ts và dùng Deno để thực thi đoạn mã đó.

Không cần nhiều file cấu hình nữa

Khi càng tiếp xúc nhiều với các dự án JavaScript/TypeScript nói chung hay Node.js nói riêng, có một điều mà tôi luôn thắc mắc hoặc thậm chí là cảm thấy khó chịu vì... có quá nhiều các tệp cấu hình. Mà mỗi dự án khác nhau thì lại có các tệp với tên khác nhau. Từ package.json, package-lock.js, thêm cả tsconfig.js nếu dự án sử dụng Typescript... Chưa kể nếu cấu hình một vài thứ nữa như webpack, vite, tailwind, posscss... thì ôi thôi! Thời gian đầu do chưa quen, phải đi đọc xem ý nghĩa và cách sử dụng của từng cái cấu hình xuất hiện trong dự án là gì, vừa đọc vừa chửi thầm vì "Thế quái nào mà các ông có thể tạo ra hàng trăm tệp cấu hình như này được chứ!?"

Khi sang Deno, thật ngạc nhiên khi không còn bất kỳ một tệp cấu hình nào cả. Tức là hoàn toàn có thể chạy dự án mà không cần "config" - nghe có vẻ ảo nhỉ! Mà nếu có thì cũng chỉ là một tệp deno.json duy nhất. Deno đã khéo léo loại bỏ đi nhiều cấu hình phức tạp hoặc đặt nó vào trong một tệp json duy nhất. Thật hạnh phúc biết bao khi mỗi lần mở dự án lên không phải lo sợ về sự xuất hiện của một cái tên lạ nữa.

Hỗ trợ Web APIs và Node APIs

Deno đã và đang cố gắng hỗ trợ Web APIs nhất có thể. Web APIs là tập hợp các API được tiêu chuẩn hoá có trong trình duyệt. Việc hỗ trợ tốt Web APIs có thể giúp chương trình chạy trong Deno có thể chạy trong trình duyệt, theo kiểu viết một lần - chạy mọi nơi. Mở thêm đường cho thư viện dạng "Universal".

Nếu đã từng làm việc trên Serverless, đặc biệt là Cloudflare Workers. Bạn sẽ biết rằng Workers không hoàn toàn tương thích với Node.js, nên nếu sử dụng các thư viện dành riêng cho Node nhiều khả năng sẽ không hoạt động. Ngược lại, nếu thư viện sử dụng hoặc tương thích với Web APIs thì lại hoạt động mượt mà. Điều này cũng áp dụng cho Deno.

Hỗ trợ Node APIs giúp Deno có thể chạy hầu hết các "gói" trên npm. Thế là từ nay có thể thoải mái sử dụng package trên npm mà không phải lo về khả năng tương thích nữa.

Cơ chế bảo mật mới

Kể cũng lạ, có một sự thật hiển nhiên là khi khởi động (start) một dự án Node, thì mặc định nó sẽ có tất tần tật quyền của người dùng. Có nghĩa là chương trình thoải mái truy cập vào tệp tin hay thực thi một câu lệnh nào đó trong hệ thống thay cho người dùng. Quả là nguy hiểm đúng không. Thử nghĩ đến trường hợp lỡ "run" dự án ai đó gửi sang mà quên chưa kiểm tra trước, rồi nó quét hết toàn bộ dữ liệu trên máy, gửi về một máy chủ nào đó, hoặc mã hoá hết tệp tin để tống tiền thì kiếp này coi như bỏ, sai lầm không thể sửa chữa!

Deno khắc phục được nhược điểm này bằng cách bổ sung thêm các cờ (flags) để xin quyền khi chạy chương trình. Các quyền có thể kể đến như truy cập file, truy cập internet... nếu chương trình muốn truy cập vào hệ thống tệp tin, hoặc kết nối Internet thì ít nhất cần phải xin quyền. Ví dụ:

$ deno run --allow-read --allow-write --allow-net index.ts

Có rất nhiều quyền cần phải "xin", để biết thêm chi tiết bạn đọc tham khảo tại Security and permissions | Deno Docs. Còn cách nhanh nhất là cho phép toàn bộ quyền bằng cách sử dụng cờ -A hoặc --allow-all.

Hiệu năng càng ngày càng được cải thiện

Nhớ những ngày đầu khi vừa được giới thiệu, Deno đã tỏ ra lép vế trước Node.js về hiệu suất chương trình. Cụ thể các bài benchmark đã chỉ ra sự khác biệt giữa Deno và Node khi chạy cùng một chương trình giống nhau, Deno luôn thua thiệt. Đỉnh điểm, bun.sh bỗng xuất hiện. bun nổi lên như một hiện tượng vì nó đánh bật cả Node.js về hiệu suất. Điều đó càng làm cho Deno trở nên nhạt nhoà.

Thực tế, khi sử dụng bun để chạy một số ứng dụng Node, tôi gặp khá nhiều vấn đề và kể cả lỗi. Có vẻ như bun chưa sẵn sàng cho "sản xuất". Vậy nên thời điểm đó, tôi kết luận Node vẫn là chân ái cho ai yêu thích sự ổn định.

Gần đây, với sự ra mắt của Deno 2.0 cho thấy những nỗ lực đáng kể để cải thiện hiệu suất và nâng cao trải nghiệm lập trình của chú "khủng long đen" này. Theo tài liệu mới nhất mà họ công bố, Deno tỏ ra nổi bật về mọi mặt so với 2 cái tên Node và bun đình đám.

Tổng kết

Trên đây là những điểm mà tôi thấy thích khi làm việc với Deno. Còn một vài tính năng nữa như cung cấp Deno Deploy miễn phí để triển khai ứng dụng. Thế nhưng thi thoảng vẫn bắt gặp các bài viết "chỉ trích" về hiệu năng và hệ thống modules cũng như khả năng tương thích với Node rất thấp. Những hạn chế này đã được khắc phục trong phiên bản 2.0 mới nhất. Góc nhìn của tôi về Deno đã thay đổi so với thời điểm mà nó mới ra mắt, hy vọng Deno sẽ nhận được nhiều sự quan tâm từ cộng đồng và có nhiều bứt phá hơn nữa trong tương lai.

Còn bạn thì sao? Bạn đã dùng Deno chưa? Có khen chê gì về môi trường chạy mã JavaScript này không? Hãy để lại ý kiến xuống phía dưới phần bình luận nhé!