Denoが「デスクトップアプリ用の土台」を本気で用意してきた、という話です。Webサイトを作る感覚のまま、Windows・macOS・Linuxで動くアプリをまとめて配れる。しかもDenoのランタイムまで一緒に抱え込んで、ひとつの実行ファイルにしてしまう。こういう発想はかなり気持ちいいです。面倒な配布や環境差を、なるべく見えなくする方向に振っているのが好印象でした。
Denoのdesktopは、ざっくり言うと「Webで作った画面を、普通のデスクトップアプリとして配るための仕組み」です。元記事では、単なるTypeScript 1ファイルからNext.jsアプリまで対応すると書かれています。ここがかなり重要で、最初から専用UIフレームワークを学ばなくても、すでにあるWeb資産をそのまま活かしやすい。
この手の領域は、Electronのような先行勢がずっと強かったわけですが、悩みもはっきりしていました。バイナリが重くなりがちだし、OSごとの扱いもややこしい。Denoはそこに対して、「小さく始められる」「でも必要ならChromiumを同梱できる」「npmエコシステムも使える」と、かなり実務寄りの答えを出してきた印象です。
Deno desktopのデフォルトはOS標準のWebViewを使う方式です。これは要するに、macOSならmacOSの、WindowsならWindowsの、LinuxならLinuxの“その場の表示機能”を借りるやり方です。全部を自前で抱え込まないので、実行ファイルを軽くしやすい。配布の気楽さを考えると、かなりありがたい設計です。
一方で、表示の再現性を優先したいなら、Chromiumを含むCEFバックエンドを選べます。ここは実務で効きます。Webアプリをデスクトップ化すると、OSごとの見え方の差が地味に面倒なんですよね。フォント、スクロール、細かなレンダリング差。そういうのを「できるだけ同じにしたい」と思った時に、Chromium同梱の選択肢があるのは安心感があります。
個人的には、この二段構えはかなり賢いと思います。軽さを取るか、一貫性を取るか。どちらか一方に押し付けないのがいい。
元記事で特に便利そうだと感じたのが、Framework auto-detectionです。Next.js、Astro、Fresh、Remix、Nuxt、SvelteKit、SolidStart、TanStack Start、Vite SSRなどを指すと、Deno desktopがそれを理解して動かしてくれる。しかも本番ならproduction server、開発中なら--hmrでdev serverとホットリロードを使える。
ホットリロードは、コードを直したら画面にすぐ反映される仕組みです。いちいちアプリを閉じて起動し直さなくていいので、開発のストレスがかなり減ります。Web開発の快適さを、デスクトップアプリの世界にそのまま持ち込みたい。そんな思想が見えます。
ここは地味だけど大事です。新しいデスクトップ基盤って、結局「専用の書き方を覚えてください」になりがちなんですが、Deno desktopはそこをできるだけ避けている。すでにあるフレームワークをそのまま使えるなら、導入の心理的ハードルはかなり下がるはずです。
もうひとつ面白いのが、バックエンドとUIのやり取りです。一般的なElectron系のアプリでは、メインプロセスとレンダラープロセスの間をIPCでつなぐことが多いです。IPCは「プロセスをまたいだ会話」みたいなものですが、Deno desktopはそれを、より近いところのチャネルでやる設計になっています。
記事によると、値は境界をまたぐときにエンコードされるものの、Denoコードとwebviewの間でクロスプロセスの往復はしない。ここは設計思想としてかなり強いです。通信の回り道が減るので、シンプルで、速くて、考えることも少なくなる。少なくとも理屈の上では、アプリの内部構造が少しすっきりするはずです。
もちろん、こういう仕組みには適材適所があります。何でもかんでも軽快になるとは限らない。でも「できるだけ近いところで完結させる」という方向は、個人的にはかなり好みです。
デスクトップアプリで本当に面倒なのは、作ることより配ることです。ここをDeno desktopはかなり意識しています。
1台のマシンからmacOS、Windows、Linux向けにビルドできて、バックエンドはローカルで全部コンパイルするのではなく、必要に応じてダウンロードして使う仕組みになっている。さらに、差分更新にも対応しています。latest.jsonマニフェストとbsdiffパッチを使い、アプリが自動で更新を確認し、失敗したらロールバックする。これはかなり実用的です。
差分更新というのは、アプリ全体を丸ごと入れ直すのではなく、変更部分だけを配るやり方です。ユーザーのダウンロード量を減らせるし、更新の負担も軽くなります。デスクトップアプリを運用したことがある人なら、このありがたみはかなり分かるはずです。更新でコケた時に戻せるのも、地味ですが本当に大事。
元記事には、Deno.serve()でHTMLを返すだけの小さな例が載っています。これをdeno desktop main.tsで実行すると、コンパイルされたバイナリがローカルHTTPサーバーに向いたウィンドウを開く、という流れです。
この手触りはかなり良いです。いきなり大げさなアプリにしなくても、まずは1ファイルで試せる。そこから必要に応じてフレームワークを載せたり、ネイティブのメニューや通知を足したりできる。こういう「小さく始めて、あとから育てる」設計は、技術を広める上でとても強いと思います。
しかもDeno.serve()が、webviewが向かうアドレスに自動でバインドしてくれるので、ポート番号やホスト名を細かく意識しなくていい。こういう気遣いは、使ってみると効いてきます。細部の面倒を隠してくれる道具は、だいたい長く使いやすいです。
記事の「What's in this section」を見ると、Deno desktopは単なる表示枠では終わっていません。ウィンドウ管理、bindings、メニュー、trayやdock、ダイアログ、通知、DevTools、エラー報告、配布、比較ページまで揃っています。
ここでうれしいのは、ちゃんと「デスクトップアプリらしさ」に必要なものが意識されていることです。Webページをただウィンドウに入れるだけでは、実用アプリにはなりません。メニューがほしいし、通知もほしいし、システムトレイに常駐させたいこともある。Deno desktopはそこを最初から射程に入れているので、単なるデモで終わらない気配があります。
これは、すでにWeb技術でアプリを作っている人にかなり向いていると思います。Next.jsやAstroなどの資産があるなら、その延長でデスクトップ版を出しやすい。Deno自体に親しみがある人なら、ランタイム、配布、更新までひと続きで扱えるのも魅力でしょう。
逆に、最初から完全ネイティブな見た目や操作感を徹底したい人には、別の選択肢が合う場面もあるはずです。ただ、現代の多くの業務アプリやツールは、そこまで“完全ネイティブ”である必要がないことも多い。そう考えると、Deno desktopの「Webを主役にして、足りない部分を埋める」やり方はかなり現実的です。
個人的には、Denoはここでかなり面白い位置に来たと思います。単に「WebViewで表示できます」ではなく、「開発、実行、配布、更新まで、ひとつの流れとして設計しています」というのが強い。道具としてちゃんとしている感じがあるんですよね。
参考: Desktop apps
