- Gần đây đã xuất hiện những lời chỉ trích và lo ngại về động lực phát triển của Deno Deploy, KV, Fresh cũng như toàn bộ công ty và các dự án
- Một phần các chỉ trích là xác đáng, và việc không công khai đầy đủ tiến độ cũng góp phần làm tăng sự nhầm lẫn, nhưng phần lớn các tin đồn và chỉ trích này là suy đoán vô căn cứ hoặc thông tin sai sự thật
- Kể từ khi ra mắt Deno 2 (sau tháng 10 năm 2023), tỷ lệ chấp nhận theo chỉ số người dùng hoạt động hằng tháng đã tăng hơn gấp đôi
- Khả năng tương thích Node mạnh mẽ của Deno 2 đã loại bỏ một rào cản lớn trong triển khai thực tế, và nền tảng đã trở nên nhanh hơn, mạnh hơn và đơn giản hơn
Những thay đổi và sự tiến hóa của Deno Deploy
- Một trong những câu hỏi được hỏi nhiều nhất gần đây là lý do đằng sau việc giảm số lượng region khả dụng của Deno Deploy
- Đằng sau việc cắt giảm không chỉ là chi phí mà còn là sự thay đổi trong mô hình sử dụng và nhu cầu thực tế
- Với phần lớn ứng dụng, điều quan trọng không phải là mọi region, mà là tốc độ, debug và tuân thủ ở khu vực gần với dữ liệu
- Kể từ khi ra mắt Deploy, số region đã thay đổi từ 25 lên 35, và hiện còn 6 region
- Nhiều region thực tế gần như không được sử dụng, và việc phân tán quá mức còn gây suy giảm hiệu năng (độ trễ, vấn đề dung lượng)
- Nhóm đang tái xây dựng một tầm nhìn “edge” thực tế hơn, phù hợp với nhu cầu của người dùng
- Một phiên bản Deploy mới đang được phát triển, và nền tảng đang tiến hóa theo hướng hosting toàn bộ ứng dụng
- Dự kiến sẽ hỗ trợ subprocess, tác vụ nền, OpenTelemetry, build pipeline, region tự lưu trữ, v.v.
- Sắp tới sẽ cung cấp khả năng ghim ứng dụng vào region hoặc chạy trên đám mây riêng của người dùng
Định hướng của KV (kho key-value)
- Deno KV là một kho với API đơn giản, cung cấp không cần cấu hình, đảm bảo tính nhất quán toàn cục và tính năng thời gian thực
- Nó phù hợp cho dữ liệu phiên, feature flag, trạng thái cộng tác, nhưng không dành cho cơ sở dữ liệu mục đích tổng quát
- Với các nhu cầu quản lý dữ liệu rộng hơn, nhóm đang theo đuổi hai hướng
- Tăng cường tích hợp cơ sở dữ liệu quan hệ hiện có vào Deno Deploy
- Thúc đẩy một dự án mới giúp đơn giản hóa liên kết giữa compute và state (lấy cảm hứng từ Cloudflare Durable Objects)
- Theo định hướng trên, KV sẽ tiếp tục ở trạng thái beta, chỉ duy trì xử lý các lỗi nghiêm trọng và vấn đề bảo mật
- Vai trò trung tâm trong giải pháp quản lý state tổng thể hoặc vai trò tiến hóa hơn trong tương lai nhiều khả năng sẽ do một dự án khác đảm nhiệm
Tình hình của framework Fresh
- Fresh vẫn là nền tảng của toàn bộ ứng dụng/web nội bộ, đồng thời đang được duy trì và cải tiến tích cực
- Nhóm nhận thức rõ kỳ vọng lớn và thời gian chờ đợi kéo dài đối với Fresh 2
- Thay vì phát hành vội vàng, họ ưu tiên mài giũa chất lượng nền tảng và cấu trúc cốt lõi
- Hãy tham khảo bài blog về các cải tiến chi tiết vừa được công bố gần đây
- Dự kiến sẽ triển khai Fresh 2 ổn định trong năm nay
Deno, một nền tảng vượt ra ngoài runtime
- Deno không chỉ là một runtime mà còn là một nền tảng hệ thống JavaScript hoàn chỉnh
- Với một hệ công cụ duy nhất, có thể tích hợp viết, chạy, kiểm thử, triển khai, giám sát và nhiều tác vụ khác
- Tính tích hợp, cấu hình mặc định, cờ lệnh và kết nối giữa các công cụ đang tiếp tục được tăng cường
- Mục tiêu không chỉ là tương đương về tính năng mà là xây dựng một hệ sinh thái tích hợp
- Deno hướng đến nâng cao chất lượng cốt lõi của phát triển JavaScript, và đang thử thách việc mở rộng phạm vi để đạt mục tiêu đó
Mục tiêu và lý do của nền tảng này
- Ngôn ngữ kịch bản đóng vai trò không thể thiếu trong phát triển thực tế tốc độ cao
- JavaScript có tương lai còn sáng hơn về mặt tiêu chuẩn hóa, hệ sinh thái quy mô lớn và khả năng mở rộng đa dụng
- Cần một nền tảng “đi kèm đầy đủ pin”, và Deno theo đuổi điều đó (quản lý quyền, web server, quan sát, lint, kiểm tra kiểu, v.v. được cung cấp sẵn)
- Nền tảng này mang lại trải nghiệm thống nhất thay cho các công cụ rời rạc
Kế hoạch tương lai và tăng cường giao tiếp
- Deno không bước vào giai đoạn thu hẹp mà đang bước vào giai đoạn mở rộng
- Nền tảng đang tiếp tục cải thiện tốc độ, khả năng tương thích và độ hoàn thiện, đồng thời JSR cũng đang phát triển cơ chế quản trị độc lập
- Song song đó là hợp tác cộng đồng như TC39/ WinterTC và nhiều hoạt động khác vì hệ sinh thái JavaScript
- Dựa trên kinh nghiệm từ Deploy và KV, nhóm đang phát triển các sản phẩm mới bền vững và phân tán, và sẽ sớm công bố thêm thông tin
- Để giảm tranh cãi và sự mất lòng tin, họ sẽ tăng cường giao tiếp và coi trọng niềm tin với nhà phát triển
3 bình luận
Hay là Bun tốt hơn Deno?
Tin đồn về sự suy yếu của Deno: số region trên toàn cầu giảm còn 6
Có vẻ đây là phản hồi cho bài viết đó.
Họ cũng đã đăng riêng một bài nói về lý do bản cập nhật Fresh bị chậm: Bản cập nhật Fresh 2 của framework web Fresh của Deno
Ý kiến trên Hacker News
Có cảm giác ngay từ đầu đã khá rõ rằng phần lớn lập trình viên không chỉ triển khai các hàm stateless đơn giản, mà việc xây dựng ứng dụng thực tế giao tiếp với cơ sở dữ liệu như app full-stack mới là chuyện phổ biến. Việc giờ mới nhận ra điều này thấy cũng hơi hiển nhiên
Chia sẻ nhận định rằng gần đây đã có làn sóng chỉ trích nhắm vào Deno, Deploy, KV, Fresh và cả đà tăng trưởng nói chung. Riêng về chỉ trích liên quan đến tăng trưởng thì chưa thấy có đề cập hay phản hồi cụ thể nào, nên tự hỏi có phải họ cố tình tránh né không. Vì phía công ty có nói một phần chỉ trích là hợp lý, nên nếu họ công khai rõ những chỉ trích nào là đúng và định giải quyết ra sao thì sẽ tạo được niềm tin hơn. Cá nhân cho rằng việc công ty thẳng thắn thừa nhận cả điểm yếu lại là yếu tố tích cực khi lựa chọn. Từng có trải nghiệm thích cách Migadu minh bạch nêu ưu/nhược điểm như trên trang pro/con của họ
Lý do từng kỳ vọng vào Deno lúc đầu là vì nó không bị ám ảnh bởi tính tương thích với cái cũ và có thể khởi đầu mới một cách gọn gàng với ít độ phức tạp hơn. Dù có vài điểm bất tiện mới so với Node nhưng vẫn thấy ở mức chấp nhận được. Nhưng rồi thay vì theo đuổi giải pháp riêng, họ lại ngày càng bám vào khả năng tương thích với Node, và giờ thành ra một cấu trúc kép thậm chí còn thấy phức tạp hơn cả Node. Gói Node dĩ nhiên nên chạy được trên Deno, nhưng có quá nhiều edge case không hoạt động do API chưa được triển khai hoặc lỗi. Framework test yêu thích nhất là AVA cũng vẫn chưa được hỗ trợ. Trước đây còn có thể phớt lờ lớp tương thích npm và chỉ dùng riêng Deno, nhưng giờ ngày càng thấy phiền. Chỉ nhìn vào các tùy chọn dòng lệnh thôi cũng thấy vài năm qua đã phức tạp lên kinh khủng, mà phần lớn là để tích hợp npm nên với tôi chỉ là thông tin không cần thiết. Điều tôi muốn nhất từ khả năng tương thích Node là Deno linter hỗ trợ cấu hình ESLint, nhưng có vẻ họ không quan tâm. Dù vậy vẫn mong Deno thành công vì nó thúc đẩy Node cải thiện. Chỉ là hướng đi hiện tại của Deno không còn tạo cảm giác nhất quán với mục tiêu ban đầu
Cảm thấy Deno đã mất phương hướng. Ban đầu nó được định vị rất đơn giản là một JS/TS runtime an toàn và nhanh viết bằng Rust, nhưng giờ trong menu thả xuống ‘Products’ trên website lại thêm quá nhiều sản phẩm một cách rối rắm. Có vẻ họ đã cố đi theo hướng Vercel làm nền tảng deploy sau NextJS
Từ lúc Deno thêm khả năng tương thích với Node và từ bỏ lời hứa ban đầu thì kỳ vọng cũng biến mất. Với tôi, sức hút cốt lõi của Deno là loại bỏ độ phức tạp không mong muốn và di sản cũ từ Node, nhưng giờ ngoài TypeScript tích hợp sẵn và permission ra thì hầu như chẳng còn gì khác Node. bun.sh cũng cung cấp khả năng tương thích Node tương tự. Tò mò không biết có ai biết một engine script TypeScript phía server nào không theo đuổi tương thích Node hay không
Tương thích npm là bổ sung thêm tính năng, nên không thấy đó là đánh mất điều gì. Không nhất thiết phải dùng Node API, chỉ cần dùng các thư viện mong muốn từ jsr.io cũng đã đủ. Trên thực tế vẫn có thể tận hưởng trải nghiệm phát triển khác biệt với Node trong Deno. Chỉ là không có nhiều người thực sự đòi hỏi sự “thuần khiết” hoàn toàn, nên việc chọn tính đại chúng và thực dụng có lẽ là điều đáng mừng hơn
Bày tỏ nghi vấn về lý do phải tìm một TypeScript runtime không theo đuổi tương thích Node. Node đúng là có nhiều vấn đề, nhưng dù vậy vẫn đủ hữu dụng để được dùng rộng rãi. Để tạo ra một lựa chọn thay thế thực tế thì либо phải có (1) ưu điểm đủ mạnh để chấp nhận một cuộc migration quy mô lớn, hoặc (2) ít nhất phải có chi phí migration thấp cùng các cải tiến rõ ràng về hiệu năng, độ tin cậy hoặc khả năng sử dụng. Nhưng Deno lại lưng chừng ở cả hai điểm này. Không chạy được code Node hiện có, trong khi các ưu thế mang tính đột phá lại không đủ mạnh, nên đây là kiểu tiếp cận dễ chỉ thu hút “người theo chủ nghĩa lý tưởng” hoặc “lập trình viên làm vì sở thích”
TypeScript runtime không theo đuổi tương thích Node khiến người ta nghĩ đến workerd của Cloudflare Workers, nhưng về bản chất nó không phải backend runtime đa dụng, và bị hạn chế ở chỗ gần như không có package mặc định hay tính năng tích hợp sẵn nào đáng kể
Bản thân thích dùng JSDoc hơn. Nó không liên quan tới Node mà vẫn mang lại những lợi ích tương tự, lại không có độ phức tạp của chuỗi biên dịch
Nếu ở backend không bắt buộc phải bám vào JS thì việc cân nhắc lựa chọn tốt hơn thay vì TypeScript là điều hợp lý. Nếu có thể kiểm soát toàn bộ stack thì không có lý do gì phải ở lại với ngôn ngữ compile-to-JS
Nghĩ rằng bài viết gần đây có lẽ là phản hồi cho bài trước đó https://news.ycombinator.com/item?id=43863937
Dù đây là bài do CEO viết, nhưng nội dung tập trung nhiều hơn vào việc biện minh cho các quyết định nội bộ thay vì phản hồi những chỉ trích cụ thể nhắm vào Deno. Dẫu vậy, vẫn có cảm giác bộ sản phẩm của Deno hoạt động khá tốt trong môi trường Deno
Hiện vẫn chưa có được cảm giác tin tưởng hay chắc chắn. Có lẽ sắp tới sẽ biết Deploy sẽ ra sao, nhưng với KV thì nếu không có ý định tiếp tục phát triển thêm sau giai đoạn beta, tôi nghĩ hoàn toàn không có lý do gì để dùng cho dự án mới. Fresh được nói là sẽ được refactor sang alpha vào khoảng cuối Q3, nhưng thật ra từ đầu nó vốn chỉ là framework cung cấp phần cơ bản, mà ngay cả cấu trúc không cần build/compile từng là điểm đáng chú ý cũng đang biến mất. Runtime thì vẫn đang tiếp tục phát triển, nhưng khá thú vị là release note lại tập trung vào tương thích Node/NPM đến mức làm câu tuyên bố “không theo đuổi sự tương đương tính năng với các runtime khác” trở nên trớ trêu
Cho rằng quyết định dừng phát triển liên tục cho KV thực sự là một lựa chọn rất tệ. Các doanh nghiệp không dùng KV không phải vì tính năng kém mà vì cái nhãn beta. Bản thân đã dùng Cloudflare Workers KV khá nhiều và không mấy quan tâm tới Durable Objects, nên từng rất kỳ vọng vào Deno KV, nhưng giờ có lẽ phải loại nó khỏi danh sách cân nhắc. Việc công bố sản phẩm mới rồi gần như lập tức bỏ mặc tạo ấn tượng chiến lược cực kỳ xấu
Chia sẻ rất thật rằng từng cân nhắc dùng KV nhưng vì không thấy triển vọng nên đã phải nghĩ tới phương án thay thế
Tò mò liệu việc phần lớn lập trình viên triển khai không phải các hàm stateless đơn giản mà là app full-stack gắn chặt với cơ sở dữ liệu có phải là câu chuyện đúng với toàn bộ phe serverless nói chung hay không. Nếu đúng thì không rõ điều đó có phù hợp với ý định ban đầu của phong trào serverless hay chỉ đơn giản là người ta chọn nó để tránh hạ tầng phức tạp như Docker/Kubernetes
Giải thích rằng Deno Deploy thường xuyên nhận được câu hỏi về việc giảm số lượng region. Phía Deno nói rằng phần lớn ứng dụng không cần chạy ở mọi nơi trên toàn thế giới; chỉ cần nhanh ở gần dữ liệu, dễ debug và phù hợp quy định địa phương là đủ, nên họ tối ưu theo hướng đó. Tuy nhiên, cá nhân tôi đã không dùng Deno Deploy vì vị trí region của họ thực tế không đủ gần để yên tâm về hiệu năng. Trong khi đó đã có nhiều lựa chọn khác gần dữ liệu và người dùng hơn, còn việc tuân thủ quy định thì ở đa số trường hợp chỉ cần theo cấp quốc gia là đủ, nên hướng tối ưu này thấy không thuyết phục