Deno Desktop: Đóng gói dự án Deno thành ứng dụng desktop

 (docs.deno.com)
1 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Có thể đóng gói dự án Deno được tạo bằng ứng dụng web và mã TypeScript thành các tệp nhị phân ứng dụng desktop có thể phân phối lại theo từng nền tảng
  • Đầu ra bao gồm mã ứng dụng, runtime Deno và công cụ kết xuất web trong cùng một gói; tính năng này đã được đưa vào Deno v2.9.0 nhưng vẫn chưa phải bản phát hành ổn định
  • Backend WebView mặc định sử dụng webview tích hợp của hệ điều hành để hướng tới tệp nhị phân nhỏ, và nếu cần tính nhất quán khi kết xuất thì có thể chọn backend Chromium (CEF)
  • Tự động phát hiện các dự án Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, Vite SSR và chạy máy chủ phù hợp với chế độ phát hành hoặc chế độ phát triển --hmr
  • Giao tiếp giữa mã Deno và webview dùng kênh trong cùng tiến trình thay vì IPC dựa trên socket, đồng thời còn bao gồm cả biên dịch chéo và tự động cập nhật dựa trên bsdiff

Vai trò và trạng thái hiện tại của deno desktop

  • deno desktop chuyển đổi dự án Deno thành ứng dụng desktop tự chứa
    • Đầu vào có thể là từ một tệp TypeScript đơn lẻ cho tới ứng dụng Next.js
    • Đầu ra là tệp nhị phân có thể phân phối lại theo từng nền tảng
    • Tệp nhị phân bao gồm mã ứng dụng, runtime Deno và công cụ kết xuất web
  • Tính năng này đã được đưa vào Deno v2.9.0 nhưng vẫn chưa phải bản phát hành ổn định
    • Nếu muốn thử ngay lúc này, cần cài bản dựng canary bằng deno upgrade canary
    • Câu lệnh, khóa cấu hình và API TypeScript có thể thay đổi trước khi được ổn định hóa

Lựa chọn backend và chạy dự án web

  • Hướng tiếp cận là dùng công nghệ web như bộ công cụ UI desktop, đồng thời giảm bớt các đánh đổi thường gặp ở những công cụ làm ứng dụng desktop dựa trên web stack hiện có
    • Các công cụ như Electron, Tauri, Electrobun có thể đi kèm những đánh đổi như tệp nhị phân lớn, thiếu hỗ trợ một số nền tảng, thiếu hệ sinh thái JavaScript, không có cập nhật tích hợp sẵn, hoặc thiếu tích hợp framework
  • Backend WebView mặc định sử dụng webview của hệ điều hành để hướng tới tệp nhị phân nhỏ
    • Có thể dùng hệ sinh thái npm thông qua lớp tương thích Node của Deno
    • Nếu cần kết xuất giống nhau trên macOS·Windows·Linux, có thể chọn backend CEF là Chromium được đóng gói sẵn
  • Tự động phát hiện framework là cách chạy các dự án web hiện có dưới dạng desktop mà không cần sửa mã
    • Đối tượng gồm Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, Vite SSR, v.v.
    • Ở chế độ phát hành, nó chạy máy chủ production
    • Với --hmr, nó chạy máy chủ phát triển có hot reload

Giao tiếp runtime, build và cập nhật

  • Giao tiếp giữa backend và UI sử dụng kênh trong cùng tiến trình
    • Giá trị được mã hóa khi đi qua ranh giới gọi
    • Không có vòng qua lại liên tiến trình giữa mã Deno và webview
  • Có thể biên dịch chéo cho macOS, Windows và Linux từ một máy duy nhất
    • Backend không được build cục bộ mà sẽ được tải xuống khi cần
  • Tự động cập nhật là cơ chế cập nhật vi sai tệp nhị phân tích hợp sẵn, dùng manifest latest.json và bản vá bsdiff
    • Runtime xử lý việc polling, áp dụng và rollback với các lần chạy thất bại

Ví dụ đơn giản và cấu trúc tài liệu

  • Có thể tạo ứng dụng desktop một tệp bằng cách tạo main.ts trả về phản hồi HTML với Deno.serve() rồi chạy deno desktop main.ts
Deno.serve(() =>
  new Response("Hello, desktop

", {
    headers: { "content-type": "text/html" },
  })
);

deno desktop main.ts
  • Tệp nhị phân đã biên dịch sẽ mở một cửa sổ trỏ tới máy chủ HTTP cục bộ được gắn với trình xử lý Deno.serve()
    • Trên macOS/Linux, chạy bằng ./main
    • Trên Windows, chạy bằng .\\main.exe
  • Deno.serve() được tự động gắn với địa chỉ mà webview điều hướng tới, nên không cần truyền cổng hay tên máy chủ
  • Tài liệu liên quan được chia thành cấu hình, backend, HTTP serving, framework, quản lý cửa sổ, binding, menu, tray và dock, hộp thoại, thông báo, HMR, DevTools, tự động cập nhật, báo cáo lỗi, triển khai, so sánh và tham chiếu CLI
    • Deno.BrowserWindow liên quan đến vòng đời cửa sổ, nhiều cửa sổ và sự kiện
    • Deno.autoUpdate() liên quan đến manifest, bsdiff và rollback
    • bindings.() là cách binding để gọi mã Deno từ webview

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Ý kiến trên Hacker News

  • Có vẻ Deno Desktop đã chọn một điểm thỏa hiệp khá mạnh tính định hướng: “mặc định nhỏ gọn, tương thích Node đầy đủ”
    Tôi đã thử deno desktop index.ts với ví dụ Hello World 5 dòng trong bài, và trên Windows 10 kết quả là 442MB
    Tôi tưởng nó sẽ nhỏ hơn bản build Electron, nhưng lại lớn hơn nhiều nên khá bất ngờ; libcef.dll là 247MB, còn deno-test.dll chứa Hello World là 78MB
    Không rõ có phải tôi đã làm sai gì không

    • Tôi nhớ là Hello World của Electron cũng chỉ vào khoảng 100~150MB, đã bao gồm cả runtime trình duyệt/Chromium
      Nên tôi đã hy vọng có thể có một giải pháp dưới 20MB bằng cách tái sử dụng webview của hệ điều hành, nhưng hơn 400MB thì hơi có cảm giác gây hiểu nhầm
      Có thể là do tôi cấu hình sai, nên không biết ngoài deno desktop test.ts ra còn phải làm gì nữa không

  • Phần nói rằng “thay vì mỗi app tự bundle CEF, có thể quản lý runtime CEF dùng chung để giảm kích thước nhị phân mỗi app xuống còn vài MB, và việc này nằm trong lộ trình” khá thú vị
    Tôi không rành CEF nên tò mò việc quản lý phiên bản sẽ ra sao
    Nếu mỗi app yêu cầu phiên bản CEF khác nhau thì rốt cuộc có quay về mô hình như Electron, tức mỗi app mang theo trình duyệt riêng của nó, hay trong trường hợp đó vẫn còn lợi ích từ runtime dùng chung? https://docs.deno.com/runtime/desktop/comparison/

    • CEF là Chromium Embedded Framework
      https://github.com/chromiumembedded/cef
    • Tham khảo thêm thì CEF cũng từng được dùng trong Riot và client League of Legends
      Kết quả không được tốt lắm, nhưng tôi không rõ đó là vấn đề của chính công nghệ CEF hay do các thành phần hay quy trình khác
      https://www.riotgames.com/en/news/architecture-league-client...
    • Tôi nghi ngờ lợi ích sẽ lớn đến mức nào
      Các ứng dụng Electron trên desktop thực tế gần như đều dùng phiên bản Chromium khác nhau, và nhiều app còn giữ phiên bản cũ vì sợ bị vỡ khi nâng cấp
    • Các lập trình viên web vốn đã quen với việc môi trường đích liên tục được cập nhật lên mới nhất, nên có lẽ sẽ có chỗ cho lựa chọn tham gia hoặc không tham gia vào kiểu mô hình “cứ dùng bản mới nhất mà bạn đang có”
    • Tôi thích dùng system webview hơn là tự tải xuống và quản lý trình duyệt nhúng
      Trên Windows thì kiểu như WebView2

  • Deno vẫn tiếp tục gây ấn tượng
    Đã khá lâu rồi tôi chưa bắt đầu dự án mới nào mà không dùng Deno, và tôi đã hoàn toàn nghiêng về hệ sinh thái Deno thay vì Node.js
    Tôi không biết mình sẽ dùng tính năng này thường xuyên đến mức nào, nhưng có thêm lựa chọn thì thực sự rất tốt

  • Đây là một công việc ấn tượng
    Có vẻ sẽ khá thú vị khi làm ứng dụng desktop bằng vibe coding
    Các công cụ như Lovable, Bolt, v0 mặc định dùng TypeScript khi tạo web app, nên trông khá hợp với hướng này
    Với các ứng dụng desktop nhỏ, tôi vẫn dùng Go/Wails thay vì bundle Chromium và Node, còn Electron thì cũng làm tốt phần việc của nó nhưng những bundle khổng lồ đó rõ ràng luôn khiến tôi ngại

  • Tôi từng thắc mắc nó sẽ tích hợp thế nào với hệ thống quyền hạn vốn là một trong những điểm mạnh lớn nhất của Deno
    Điều này đặc biệt quan trọng khi để các agent tự do chạy trên máy của tôi
    Tài liệu tham khảo CLI có nói rằng “các quyền được cấp lúc biên dịch sẽ được ghi cứng vào binary đã biên dịch”
    Sẽ tốt hơn nếu điều đó được hiển thị rõ để người dùng biết và có thể quyết định cấp những quyền nào
    https://docs.deno.com/runtime/reference/cli/desktop/#runtime...

    • Đây là tình huống chạy một binary nhận từ nhà phát triển
      Nếu ở đó hiện prompt quyền của Deno, tôi nghĩ điều đó lại có thể gây hiểu nhầm vì không có bảo đảm toàn vẹn cho các quyền đó
    • Một trong những thứ Deno Desktop vẫn chưa có là quyền runtime cho ứng dụng desktop
      Tức là áp dụng hệ thống quyền của Deno vào sandbox desktop, hiển thị prompt quyền cho từng lần truy cập filesystem hay mạng

  • Đây là một tính năng được tung ra rất thông minh
    Có vẻ đủ sức trở thành một phương án đáng cân nhắc khi quyết định dùng nền tảng nào

    • Đồng ý
      Nếu có kích thước cài đặt nhỏ và đa nền tảng thì trông như một lựa chọn thay thế khá ổn cho Electron hoặc Tauri

  • Tôi không nghĩ cách diễn đạt “công nghệ web là bộ công cụ UI được biết đến rộng rãi nhất trên thế giới” là phù hợp lắm
    Lý do ứng dụng Electron bị chỉ trích nhiều là vì nó gần như trái ngược với một bộ công cụ UI
    Trong nhiều trường hợp, nó không tuân theo đúng các mẫu UI của hệ điều hành chủ
    Công nghệ web chỉ đơn giản là công nghệ web; nó có thể render nút bấm, nhưng ngay cả một nút chưa được style cũng không có gì đảm bảo sẽ trông như native của OS, và còn khác nhau giữa các trình duyệt

    • Đó không phải lý do người ta dùng Electron
      Mục tiêu chưa bao giờ đơn thuần là “bộ công cụ UI” hay “tuân theo các mẫu UI của hệ điều hành chủ”
      Chromium có cực kỳ nhiều tính năng, và Electron mang nguyên bộ tiện ích đó vào, đó là ưu điểm
      Ví dụ, nếu từng làm việc với video, bạn sẽ biết việc dùng toàn bộ khả năng của trình duyệt hiện đại bên trong ứng dụng desktop có thể thay đổi cuộc chơi thế nào
      Không chỉ phát video mà cả transcoding có thể làm được với web hiện đại và WebCodecs; nếu phải tự triển khai trực tiếp thì đó là khối lượng công việc rất lớn, nhất là với ứng dụng desktop phải chạy trên Windows/macOS/Linux
      Tôi có một ứng dụng làm bằng Electron chỉ trong vài chục giờ; nếu làm theo cách khác chắc phải mất vài chục ngày, và kể cả dùng AI thì nếu không phải chuyên gia video cũng sẽ rất khó
    • Tôi không hiểu vì sao lại nói cách diễn đạt đó tệ
      Chưa từng có ai khẳng định đó là UI “native”
      UI native của Linux từ trước đến nay lúc nào cũng trông rất xấu, và tôi luôn thấy dùng bố cục HTML+CSS được chăm chút còn tốt hơn nhiều
      Theo trải nghiệm của tôi, Electron chủ yếu bị chê vì cồng kềnh và chậm; chuyện nó không phải native chỉ là điều người ta nói thêm vào
      Từ lâu tôi đã muốn có kiểu tích hợp trực tiếp với trình duyệt để dùng HTML+CSS cho layout nhưng không cần runtime JavaScript
      Tôi không biết Servo nhẹ đến mức nào, nhưng hy vọng một ngày nào đó ý tưởng như vậy sẽ thành hiện thực
    • Mỗi lần dùng Zed trên Linux, macOS và Windows, tôi lại ngạc nhiên vì framework GPUI ổn định và nhanh đến thế nào
      Với tư cách người dùng, tôi rất hài lòng; đúng là các tính năng cơ bản như accessibility vẫn còn thiếu, nhưng tôi nghĩ sẽ sớm được triển khai
      Từ góc độ lập trình viên, ngoài Rust ra thì tôi không rõ rào cản gia nhập là gì, đồng thời Rust cũng chính là điểm khác biệt
    • Việc UI trông có giống native hay không từ lâu đã không còn nhiều sức nặng như một lập luận phản đối nữa
      Đó là câu chuyện của khoảng 25 năm trước; từ khi ngay cả Microsoft cũng bắt đầu không còn bận tâm, thì chẳng còn ai quá để ý nữa
    • Có vẻ bạn xem việc không tuân theo các mẫu UI của hệ điều hành chủ là nhược điểm, nhưng với tôi đó lại là một trong những ưu điểm cốt lõi của Electron
      Tôi không muốn ứng dụng của mình trông khác nhau trên các OS khác nhau
      Tôi không có đủ nguồn lực để test trên mọi thiết bị, nên việc màn hình đã test trên một hệ thống sẽ hiển thị y hệt trên hệ thống khác là một lợi thế rất lớn

  • Mừng vì lĩnh vực này có thêm đối thủ cạnh tranh
    Đặc biệt, tôi thích việc Deno hiện tại có thể thực thi TypeScript thật sự trực tiếp, thay vì chỉ loại bỏ kiểu như cách triển khai Node hiện nay
    Tuy vậy, có vẻ điều này sẽ lấy đi khá nhiều thị phần của Tauri
    Giờ thì tại sao còn phải dùng Tauri?
    Với đa số kết nối Internet, việc tăng kích thước bundle thêm 150MB chỉ tương đương chênh lệch thời gian tải xuống khoảng 1–10 giây, đổi lại bạn có được một engine render đáng tin cậy

    • Deno khi chạy mã TypeScript theo mặc định cũng chỉ loại bỏ các chú thích kiểu
      Muốn kiểm tra kiểu thì phải chạy bằng deno run --check hoặc dùng lệnh con deno check riêng
      Trong lúc phát triển, IDE thường tự động làm việc kiểm tra kiểu và linting nên đây không phải vấn đề lớn
    • Tauri không khóa bạn vào một hệ sinh thái JavaScript cụ thể
      Thực ra bạn thậm chí không cần dùng JavaScript
      Và chúng ta cũng đã thấy nhiều startup framework cho lập trình viên như Astro, Nuxt, UV, Bun, Vite bị mua lại
      Với phần mềm cần được duy trì và hỗ trợ trong nhiều năm, xu hướng đó không tạo ra nhiều niềm tin
    • Tôi dùng Tauri khi “backend” không phải là JavaScript
    • Tôi không thật sự hiểu ý “có được một engine render đáng tin cậy”
      Chẳng phải cả Deno Desktop lẫn Tauri đều dùng system webview sao?
    • Theo logic đó thì cũng chẳng khác gì đang nói nên dùng Electron
      Vậy tại sao nên dùng cái này mà lại không nên dùng Electron?

  • Trong số các tài liệu Deno công bố, tôi thích nhất là phần so sánh
    Ở dòng cuối, hỗ trợ iOS/Android được ghi là Electron “no”, còn Deno là “not yet”; nếu họ thực sự làm được điều đó thì sẽ còn lớn hơn nhiều

  • Có vẻ sẽ rất phù hợp để phát hành game web dưới dạng ứng dụng Steam hoặc ứng dụng phục vụ mua hàng online
    Tôi định sẽ thử dùng một lần