Deno Desktop: Mengemas proyek Deno menjadi aplikasi desktop

 (docs.deno.com)
1 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Dapat membundel proyek Deno yang dibuat dengan aplikasi web dan kode TypeScript menjadi biner aplikasi desktop yang dapat didistribusikan ulang untuk tiap platform
  • Hasil output mencakup kode aplikasi, runtime Deno, dan mesin rendering web, serta sudah masuk ke Deno v2.9.0 tetapi belum merupakan rilis stabil
  • Backend WebView default menggunakan webview bawaan sistem operasi untuk menargetkan biner kecil, dan jika membutuhkan konsistensi rendering dapat memilih backend Chromium (CEF)
  • Mendeteksi proyek Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, dan Vite SSR lalu menjalankan server sesuai mode rilis maupun mode pengembangan --hmr
  • Komunikasi antara kode Deno dan webview menggunakan kanal in-process, bukan IPC berbasis socket, dan cakupannya juga mencakup cross-compilation serta pembaruan otomatis berbasis bsdiff

Peran dan status saat ini dari deno desktop

  • deno desktop mengubah proyek Deno menjadi aplikasi desktop mandiri yang self-contained
    • Input dapat berupa satu file TypeScript hingga aplikasi Next.js
    • Output berupa biner yang dapat didistribusikan ulang untuk tiap platform
    • Biner mencakup kode aplikasi, runtime Deno, dan mesin rendering web
  • Fitur ini sudah disertakan di Deno v2.9.0, tetapi belum merupakan rilis stabil
    • Untuk mencobanya sekarang, perlu memasang build canary dengan deno upgrade canary
    • Perintah, kunci konfigurasi, dan API TypeScript dapat berubah sebelum stabil

Pemilihan backend dan menjalankan proyek web

  • Mengambil arah menggunakan teknologi web sebagai toolkit UI desktop sambil mengurangi trade-off yang ada pada alat aplikasi desktop berbasis stack web yang sudah ada
    • Alat seperti Electron, Tauri, dan Electrobun bisa memiliki trade-off seperti biner besar, dukungan platform yang tidak lengkap, ketiadaan ekosistem JavaScript, ketiadaan pembaruan bawaan, atau ketiadaan integrasi framework
  • Backend WebView default menggunakan webview sistem operasi untuk menargetkan biner kecil
    • Ekosistem npm dapat digunakan melalui lapisan kompatibilitas Node milik Deno
    • Jika memerlukan rendering yang sama di macOS, Windows, dan Linux, dapat memilih backend CEF yang membundel Chromium
  • Deteksi framework otomatis menjalankan proyek web yang sudah ada sebagai desktop tanpa perubahan kode
    • Targetnya mencakup Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, Vite SSR, dan lainnya
    • Pada mode rilis, menjalankan server produksi
    • Pada --hmr, menjalankan server pengembangan dengan hot reload

Komunikasi runtime, build, dan pembaruan

  • Menggunakan kanal in-process untuk komunikasi antara backend dan UI
    • Nilai akan di-encode saat melewati batas pemanggilan
    • Tidak ada round-trip lintas proses antara kode Deno dan webview
  • Dapat melakukan cross-compilation untuk macOS, Windows, dan Linux dari satu mesin
    • Backend tidak dibangun secara lokal, melainkan diunduh saat dibutuhkan
  • Pembaruan otomatis adalah mekanisme pembaruan diferensial biner bawaan yang menggunakan manifes latest.json dan patch bsdiff
    • Runtime menangani polling, penerapan, dan rollback untuk eksekusi yang gagal

Contoh sederhana dan susunan dokumentasi

  • Aplikasi desktop satu file dapat dibuat dengan menulis main.ts yang mengembalikan respons HTML melalui Deno.serve() lalu menjalankan deno desktop main.ts
Deno.serve(() =>
  new Response("Hello, desktop

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

deno desktop main.ts
  • Biner yang telah dikompilasi membuka jendela yang mengarah ke server HTTP lokal yang terikat pada handler Deno.serve()
    • Di macOS/Linux dijalankan dengan ./main
    • Di Windows dijalankan dengan .\\main.exe
  • Deno.serve() otomatis terikat ke alamat yang dinavigasi oleh webview sehingga tidak perlu memberikan port atau nama host
  • Dokumentasi terkait dibagi ke dalam konfigurasi, backend, HTTP serving, framework, manajemen jendela, binding, menu, tray dan dock, dialog, notifikasi, HMR, DevTools, pembaruan otomatis, pelaporan error, deployment, perbandingan, dan referensi CLI
    • Deno.BrowserWindow berkaitan dengan siklus hidup jendela, banyak jendela, dan event
    • Deno.autoUpdate() berkaitan dengan manifes, bsdiff, dan rollback
    • bindings.() adalah mekanisme binding untuk memanggil kode Deno dari webview

Bacaan terkait

1 komentar

 
GN⁺ 5 jam lalu
Komentar Hacker News

  • Deno Desktop tampaknya mengambil kompromi itu dengan cukup tegas: “default dibuat kecil, kompatibilitas Node tetap lengkap”
    Saya mencoba deno desktop index.ts dengan Hello World 5 baris dari artikelnya, dan hasilnya di Windows 10 adalah 442MB
    Saya kira akan lebih kecil daripada build Electron, tetapi ternyata jauh lebih besar, dan libcef.dll berukuran 247MB, sementara deno-test.dll yang berisi Hello World berukuran 78MB
    Jadi saya penasaran apakah saya melakukan sesuatu yang salah

    • Seingat saya, Electron Hello World juga hanya sekitar 100~150MB termasuk runtime browser/Chromium
      Jadi saya berharap bisa ada solusi di bawah 20MB dengan memanfaatkan kembali webview OS atau semacamnya, tetapi lebih dari 400MB terasa agak menyesatkan
      Mungkin saya salah konfigurasi, jadi saya penasaran apakah ada hal lain yang perlu dilakukan selain deno desktop test.ts

  • Bagian yang mengatakan “alih-alih setiap aplikasi membundel CEF sendiri, kami bisa mengelola runtime CEF bersama sehingga ukuran biner per aplikasi turun menjadi beberapa MB, dan ini ada di roadmap” cukup menarik
    Saya tidak begitu paham CEF, jadi saya penasaran bagaimana pengelolaan versinya
    Kalau setiap aplikasi membutuhkan versi CEF yang berbeda, apakah pada akhirnya akan kembali ke model seperti Electron, di mana setiap aplikasi membawa browser-nya sendiri, atau apakah bahkan dalam kasus seperti itu tetap ada keuntungan dari runtime bersama
    https://docs.deno.com/runtime/desktop/comparison/

    • CEF adalah Chromium Embedded Framework
      https://github.com/chromiumembedded/cef
    • Sebagai referensi, CEF juga pernah digunakan di Riot dan klien League of Legends
      Hasilnya tidak terlalu bagus, tetapi saya tidak tahu apakah itu memang masalah pada teknologi CEF itu sendiri atau pada komponen/proses lain
      https://www.riotgames.com/en/news/architecture-league-client...
    • Saya ragu keuntungannya akan sebesar itu
      Hampir semua aplikasi Electron di desktop pada praktiknya memakai versi Chromium yang berbeda-beda, dan ada juga yang mempertahankan versi lama karena risiko rusak saat upgrade
    • Pengembang web sudah terbiasa dengan lingkungan target yang terus diperbarui ke versi terbaru, jadi rasanya mungkin saja ada pilihan untuk ikut atau tidak ikut dalam model seperti “pakai saja versi terbaru yang sudah kamu punya”
    • Daripada mengunduh dan mengelola browser bawaan sendiri, akan lebih baik memakai system webview
      Di Windows, contohnya seperti WebView2

  • Deno terus terasa mengesankan
    Sudah cukup lama saya tidak memulai proyek baru tanpa Deno, dan saya sudah sepenuhnya berpihak pada ekosistem Deno dibanding Node.js
    Saya tidak tahu seberapa sering akan memakai fitur ini, tetapi sangat bagus bahwa sekarang ada opsi tersebut

  • Pekerjaan yang mengesankan
    Ini tampaknya akan sangat menarik untuk membuat aplikasi desktop dengan vibe coding
    Alat seperti Lovable, Bolt, dan v0 pada dasarnya memakai TypeScript saat membuat aplikasi web, jadi ini terlihat sangat cocok untuk itu
    Untuk aplikasi desktop kecil, saya selama ini memakai Go/Wails alih-alih membundel Chromium dan Node, dan meskipun Electron juga menjalankan perannya dengan baik, bundel besarnya jelas selalu membuat saya enggan

  • Saya penasaran bagaimana ini terintegrasi dengan sistem perizinan Deno, yang merupakan salah satu kekuatan terbesar Deno
    Ini terutama penting ketika agen dibiarkan berkeliaran sesuka hati di perangkat saya
    Dokumentasi referensi CLI mengatakan bahwa “izin yang diberikan saat kompilasi akan dipanggang ke dalam biner hasil kompilasi”
    Akan bagus jika ini diekspos agar pengguna bisa mengetahui dan memutuskan izin apa yang akan diberikan
    https://docs.deno.com/runtime/reference/cli/desktop/#runtime...

    • Ini adalah situasi ketika menjalankan biner yang diterima dari pengembang
      Jika prompt izin Deno ditampilkan di situ, menurut saya itu justru bisa menyesatkan karena tidak ada jaminan integritas atas izin tersebut
    • Salah satu hal yang belum ada di Deno Desktop adalah izin runtime untuk aplikasi desktop
      Yaitu pendekatan yang menerapkan sistem izin Deno ke sandboxing desktop, dengan menampilkan prompt izin untuk setiap akses ke filesystem atau jaringan

  • Ini fitur yang cerdas untuk dirilis
    Saat memutuskan platform apa yang akan dipakai, ini sepertinya cukup layak dipertimbangkan

    • Setuju
      Dengan ukuran instalasi yang kecil dan lintas platform, ini tampak seperti alternatif yang cukup baik untuk Electron atau Tauri

  • Menurut saya, ungkapan “teknologi web adalah toolkit UI yang paling dikenal luas di dunia” kurang tepat.
    Alasan aplikasi Electron sering dikritik justru hampir berlawanan dengan konsep toolkit UI.
    Aplikasi seperti itu sering gagal mengikuti pola UI OS host dengan baik.
    Teknologi web ya tetap teknologi web; memang bisa merender tombol, tetapi bahkan tombol tanpa styling pun tidak ada jaminan akan terlihat seperti native OS, dan tampilannya juga berbeda di tiap browser.

    • Tapi bukan itu alasan orang memakai Electron.
      Tujuannya tidak pernah sekadar menjadi “toolkit UI” atau “mengikuti pola UI OS host”.
      Chromium punya sangat banyak fitur, dan Electron membawa utilitas itu apa adanya, dan itu adalah kelebihannya.
      Misalnya, kalau pernah mengerjakan video, Anda tahu bahwa bisa memanfaatkan seluruh kemampuan browser modern di dalam aplikasi desktop itu sangat mengubah keadaan.
      Bukan cuma pemutaran video, bahkan transcoding yang dimungkinkan oleh web modern dan WebCodecs akan menjadi pekerjaan sangat besar jika harus diimplementasikan sendiri, terlebih lagi untuk aplikasi desktop yang harus berjalan di Windows/macOS/Linux.
      Saya pernah membuat aplikasi dengan Electron dalam hitungan puluhan jam; dengan pendekatan lain mungkin akan butuh puluhan hari, dan bahkan dengan AI pun akan sulit kalau bukan ahli video.
    • Saya kurang paham kenapa ungkapan itu dianggap buruk.
      Tidak pernah ada klaim bahwa UI-nya “native”.
      UI native Linux menurut saya selalu terlihat sangat jelek, dan saya justru merasa layout HTML+CSS yang dirancang baik jauh lebih bagus.
      Dari pengalaman saya, Electron biasanya dicela karena bloat dan lambat; soal tidak native itu hanya tambahan yang orang-orang sebutkan.
      Sejak lama saya ingin membuat integrasi browser langsung yang tetap memakai HTML+CSS untuk layout tetapi tidak memerlukan runtime JavaScript.
      Saya tidak tahu seringan apa Servo, tetapi akan bagus kalau suatu hari ide seperti itu bisa jadi kenyataan.
    • Setiap kali memakai Zed di Linux, macOS, dan Windows, saya selalu kagum betapa stabil dan cepatnya framework GPUI.
      Sebagai pengguna saya sangat puas, dan meski fitur dasar seperti aksesibilitas masih kurang, saya rasa itu akan segera diimplementasikan.
      Dari sisi pengembang, selain Rust saya kurang tahu apa hambatan masuknya, dan pada saat yang sama Rust juga menjadi pembeda utamanya.
    • Apakah UI terlihat native sudah lama kehilangan daya sebagai argumen tandingan.
      Itu pembicaraan sekitar 25 tahun lalu; sejak Microsoft sendiri berhenti terlalu peduli, praktis tidak ada lagi yang benar-benar mempermasalahkannya.
    • Anda tampaknya menganggap tidak mengikuti pola UI OS host sebagai kekurangan, tetapi bagi saya itu justru salah satu keunggulan utama Electron.
      Saya tidak ingin aplikasi saya terlihat berbeda di OS yang berbeda.
      Saya tidak punya sumber daya untuk menguji di semua perangkat, dan fakta bahwa tampilan yang diuji di satu sistem akan terlihat sama persis di sistem lain adalah keuntungan yang sangat besar.

  • Senang melihat ada pesaing baru di area ini.
    Khususnya, saya suka bahwa Deno saat ini bisa menjalankan TypeScript sungguhan secara langsung, bukan seperti implementasi Node saat ini yang hanya menghapus tipe.
    Tapi ini tampaknya akan mengambil cukup banyak pasar Tauri.
    Sekarang kenapa saya harus memakai Tauri?
    Pada kebanyakan koneksi internet, kenaikan ukuran bundel 150MB biasanya cuma berarti selisih waktu unduh 1–10 detik, dan sebagai gantinya Anda mendapat mesin rendering yang bisa diandalkan.

    • Deno juga secara default hanya menghapus anotasi tipe saat menjalankan kode TypeScript.
      Untuk pemeriksaan tipe, Anda harus menjalankannya dengan deno run --check atau memakai subperintah deno check secara terpisah.
      Saat pengembangan, biasanya IDE sudah menangani pemeriksaan tipe dan linting secara otomatis, jadi ini bukan masalah besar.
    • Tauri tidak mengunci Anda ke ekosistem JavaScript tertentu.
      Sebenarnya Anda bahkan tidak harus memakai JavaScript.
      Dan kita sudah melihat sejumlah startup framework pengembang seperti Astro, Nuxt, UV, Bun, dan Vite diakuisisi.
      Untuk software yang harus dipelihara dan didukung selama bertahun-tahun, tren seperti itu tidak terlalu menumbuhkan kepercayaan.
    • Saya memakai Tauri ketika “backend”-nya bukan JavaScript.
    • Saya kurang paham maksud pernyataan bahwa Anda mendapat “mesin rendering yang bisa diandalkan”.
      Bukankah Deno Desktop dan Tauri sama-sama memakai system webview?
    • Kalau mengikuti logika itu, sama saja dengan mengatakan sebaiknya pakai Electron.
      Kenapa harus memakai ini tetapi tidak Electron?

  • Dari materi yang dirilis Deno, bagian perbandingan adalah yang paling saya sukai.
    Di baris terakhir tertulis dukungan iOS/Android untuk Electron adalah “no”, sedangkan untuk Deno “not yet”; kalau mereka benar-benar berhasil mewujudkannya, dampaknya akan jauh lebih besar.

  • Ini tampaknya akan sangat bagus untuk mendistribusikan game web sebagai aplikasi Steam atau aplikasi untuk pembelian online.
    Saya berniat mencobanya.