- WebアプリとTypeScriptコードで作られたDenoプロジェクトを、プラットフォームごとに再配布可能なデスクトップアプリのバイナリにまとめられる
- 出力物にはアプリケーションコード、Denoランタイム、Webレンダリングエンジンが含まれ、Deno v2.9.0に入ったが、まだ安定リリースではない
- デフォルトのWebViewバックエンドはOS内蔵のwebviewを使って小さなバイナリを目指し、レンダリングの一貫性が必要なら**Chromium(CEF)**バックエンドを選べる
- Next.js、Astro、Fresh、Remix、Nuxt、SvelteKit、SolidStart、TanStack Start、Vite SSRプロジェクトを検出し、リリースモードと
--hmr開発モードに合わせてサーバーを実行する
- Denoコードとwebview間の通信にはソケットベースのIPCではなくインプロセスチャネルを使い、クロスコンパイルとbsdiffベースの自動更新まで範囲に含まれる
deno desktopの役割と現状
deno desktopはDenoプロジェクトを自己完結型デスクトップアプリケーションに変換する
- 入力は単一のTypeScriptファイルからNext.jsアプリまで可能
- 出力はプラットフォーム別に再配布可能なバイナリ
- バイナリにはアプリケーションコード、Denoランタイム、Webレンダリングエンジンが含まれる
- この機能はDeno v2.9.0に含まれているが、まだ安定リリースではない
- 今試すには
deno upgrade canaryでcanaryビルドをインストールする必要がある
- コマンド、設定キー、TypeScript APIは安定化前まで変更される可能性がある
バックエンドの選択とWebプロジェクトの実行
- Web技術をデスクトップUIツールキットとして使いながら、既存のWebスタックベースのデスクトップアプリツールのトレードオフを減らす方向を取っている
- Electron、Tauri、Electrobunのようなツールには、大きなバイナリ、プラットフォーム対応の不足、JavaScriptエコシステムの欠如、組み込みアップデーターの不在、フレームワーク統合の不在といったトレードオフがあり得る
- デフォルトのWebViewバックエンドはOSのwebviewを使い、小さなバイナリを目指す
- DenoのNode互換レイヤーを通じてnpmエコシステムを利用できる
- macOS・Windows・Linuxで同じレンダリングが必要なら、バンドルされたChromiumであるCEFバックエンドを選べる
- フレームワーク自動検出は、既存のWebプロジェクトをコード変更なしでデスクトップ上で実行する方式
- 対象はNext.js、Astro、Fresh、Remix、Nuxt、SvelteKit、SolidStart、TanStack Start、Vite SSRなど
- リリースモードでは本番サーバーを実行する
--hmrではホットリロード付きの開発サーバーを実行する
ランタイム通信、ビルド、更新
- バックエンドとUIの通信にはインプロセスチャネルを使う
- 値は呼び出し境界を越える際にエンコードされる
- Denoコードとwebviewの間にクロスプロセスの往復がない
- 1台のマシンからmacOS、Windows、Linux向けにクロスコンパイルできる
- バックエンドはローカルでビルドせず、必要なときにダウンロードされる
- 自動更新は
latest.jsonマニフェストとbsdiffパッチを使う、組み込みのバイナリ差分更新方式
- ランタイムがポーリング、適用、失敗した実行に対するロールバックを処理する
簡単な例とドキュメント構成
- 1ファイルのデスクトップアプリは、
Deno.serve()でHTMLレスポンスを返すmain.tsを作り、deno desktop main.tsを実行して作成できる
Deno.serve(() =>
new Response("Hello, desktop
", {
headers: { "content-type": "text/html" },
})
);
deno desktop main.ts
- コンパイル済みバイナリは、
Deno.serve()ハンドラーにバインドされたローカルHTTPサーバーを指すウィンドウを開く
- macOS/Linuxでは
./mainで実行する
- Windowsでは
.\\main.exeで実行する
Deno.serve()はwebviewが移動するアドレスに自動でバインドされるため、ポートやホスト名を渡す必要はない- 関連ドキュメントは、設定、バックエンド、HTTP配信、フレームワーク、ウィンドウ管理、バインディング、メニュー、トレイとdock、ダイアログ、通知、HMR、DevTools、自動更新、エラー報告、デプロイ、比較、CLIリファレンスに分かれている
1件のコメント
Hacker Newsのコメント
Deno Desktopは、その折衷案をかなり強めに決めているように見える。「デフォルトは小さく、Node互換性は完全に」
記事の5行のHello Worldで
deno desktop index.tsを試したところ、Windows 10では結果が 442MB だったElectronビルドより小さいだろうと思っていたのに、はるかに大きくて驚いた。
libcef.dllが247MB、Hello Worldが入ったdeno-test.dllが78MBだった何か間違えたのか気になる
なので、OSのWebViewのようなものを再利用して 20MB以下 の解決策が出てくることを期待していたが、400MBを超えるのは少し誤魔化しっぽく感じる
設定を間違えたのかもしれないので、
deno desktop test.ts以外に何かすべきことがあるのか気になる「アプリごとにCEFをそれぞれバンドルする代わりに、共有CEFランタイムを管理すれば、アプリごとのバイナリサイズを数MBまで減らせて、ロードマップにも入っている」という部分は興味深い
CEFに詳しくないので、バージョン管理がどうなるのか気になる
アプリごとに必要なCEFのバージョンが違うなら、結局Electronのように各アプリが自分のブラウザを抱えて持ち歩くモデルに戻るのか、それともそういう場合でも共有ランタイムの利点が残るのか知りたい
https://docs.deno.com/runtime/desktop/comparison/
https://github.com/chromiumembedded/cef
結果はあまり良くなかったが、それがCEF技術自体の問題だったのか、ほかの構成要素やプロセスのせいだったのかは分からない
https://www.riotgames.com/en/news/architecture-league-client...
デスクトップのElectronアプリは、実際にはほとんどが互いに異なる Chromiumバージョン を使っていて、アップグレード時に壊れるリスクのせいで古いバージョンを維持することも多い
WindowsならWebView2のような方式だ
Denoは相変わらず印象的だ
新しいプロジェクトをDeno抜きで始めなくなってからかなり経つし、Node.jsより Denoエコシステム を完全に支持するようになった
この機能をどれだけ頻繁に使うかは分からないが、選択肢が増えたのは本当に良い
印象的な仕事だ
バイブコーディングでデスクトップアプリ を作るとき、かなり面白そうだ
Lovable、Bolt、v0のようなツールはWebアプリを作るときに基本的にTypeScriptを使うので、ここにうまく合いそう
小さなデスクトップアプリにはChromiumとNodeをバンドルする代わりにGo/Wailsを使ってきたし、Electronも役目は十分果たしていたが、あの大きなバンドルには自分としてはかなり抵抗があった
Denoの最大の強みのひとつである 権限システム とどう統合されるのか気になった
とくにエージェントを自分のデバイス上で自由に動き回らせるときには重要だ
CLIリファレンスには「コンパイル時に付与した権限は、コンパイル済みバイナリに焼き込まれる」と書かれている
ユーザーがどんな権限を与えるのか把握して判断できるよう、表に出してくれるとよいと思う
https://docs.deno.com/runtime/reference/cli/desktop/#runtime...
そこでDenoの権限プロンプトを見せると、その権限の 完全性保証 がないため、かえって誤解を招く可能性があると思う
ファイルシステムやネットワークアクセスのたびに権限プロンプトを出す、Denoの権限システムをデスクトップのサンドボックス化に適用する方式だ
リリースするには賢い機能だ
どのプラットフォームを使うか決めるとき、十分に検討対象になると思う
小さなインストールサイズ とクロスプラットフォームであれば、ElectronやTauriの有力な代替に見える
「Web技術は世界で最も広く知られたUIツールキット」という表現は、あまり適切ではないと思う
Electronアプリがよく批判される理由は、UIツールキットとはむしろ正反対に近いからだ
ホストOSのUIパターンにきちんと従えていないことが多い
Web技術は単なるWeb技術であって、ボタンをレンダリングすることはできても、スタイルを当てていないボタンですらOSネイティブのように見える保証はなく、ブラウザごとに異なる
目標が単に「UIツールキット」や「ホストOSのUIパターンに従うこと」だったことはない
Chromiumには膨大な機能が入っており、Electronはそのユーティリティをそのまま持ってこれるし、それは利点だ
たとえば動画処理をしたことがあるなら、デスクトップアプリの中で現代のブラウザの全能力を使えることがゲームチェンジャーだと分かるはずだ
動画再生はもちろん、現代のWebとWebCodecsで可能なトランスコードまで自前で実装するのは非常に大きな作業であり、しかもWindows/macOS/Linuxで動くデスクトップアプリならなおさらだ
Electronで数十時間で作ったアプリがあるが、別のやり方なら数十日かかったと思うし、AIを使っても動画の専門家でなければ難しかったはずだ
「ネイティブ」UIだと主張したことはない
LinuxのネイティブUIは昔からかなり見た目が悪いと感じていて、むしろきちんと作り込んだ HTML+CSSレイアウト を使うほうがずっと良いと思ってきた
私の経験では、Electronは主に肥大化して遅いという理由で叩かれていて、ネイティブではないことは人々が付け足しで言う程度だ
昔からHTML+CSSでレイアウトは使いつつ、JavaScriptランタイムは不要な直接的なブラウザ統合を作りたいと思っていた
Servoがどれほど軽量なのかは分からないが、いつかそういうアイデアが実現するといいと思う
ユーザーとしてはとても満足しているし、アクセシビリティのような基本機能はまだ不足しているが、近いうちに実装されると思う
開発者の立場では、Rust以外に何が参入障壁なのかよく分からないし、同時にRustが差別化要因でもある
25年くらい前の話で、Microsoftですら気にしなくなってからは、もう誰もあまり気にしていない
OSごとに自分のアプリの見た目が変わってほしくない
すべてのデバイスでテストするリソースはないし、あるシステムでテストした画面が別のシステムでもまったく同じに見えるのは非常に大きな利点だ
この領域に競合が出てきたのはうれしい
特にDenoは、現在のNode実装のように型を取り除くだけではなく、本物のTypeScriptを直接実行できる点がよい
ただ、これはTauriの市場をかなり奪いそうだ
これでなぜTauriを使う必要がある？
たいていのインターネット接続では、バンドルサイズが150MB増えてもダウンロード時間の差は1〜10秒にすぎず、その代わり信頼できるレンダリングエンジンを得られる
型チェックをするには
deno run --checkで実行するか、別途deno checkサブコマンドを使う必要がある開発中は通常IDEが型チェックとリンティングを自動でやってくれるので、大きな問題ではない
実際、JavaScriptを使う必要すらない
それに、Astro、Nuxt、UV、Bun、Viteのような開発者向けフレームワーク系スタートアップがいくつも買収されるのを見てきた
何年にもわたって維持・サポートされるべきソフトウェアなら、そういう流れは信頼感につながらない
Deno DesktopとTauriはどちらも システムWebView を使うのではないか？
なぜこれは使って、Electronは使うべきではないのか？
Denoが出した資料の中では、比較セクション がいちばん良かった
最後の行でiOS/Android対応がElectronは「no」、Denoは「not yet」になっているが、これを本当に実現できればずっと大きなものになるだろう
Webゲームを Steamアプリ やオンライン購入向けアプリとして配布するのに本当に良さそうだ
一度使ってみるつもりだ