世界を動かす技術を、日本語で。

Deno デスクトップ

2026年6月22日原文(docs.deno.com)

概要

  • deno desktop はDenoプロジェクトを自己完結型デスクトップアプリ化
  • コード、Denoランタイム、Webレンダリングエンジンをバイナリに同梱
  • Deno v2.9.0 から導入、安定版は未リリース
  • Web技術活用、OSごとのWebViewまたはChromium(CEF)選択可能
  • Node互換・クロスコンパイル・自動アップデート など多機能

deno desktopとは

  • deno desktop はDenoプロジェクト(TypeScript単一ファイルからNext.jsアプリまで)をデスクトップアプリに変換
  • 出力は 再配布可能なバイナリ、コード・Denoランタイム・Webレンダリングエンジンを一体化
  • 各プラットフォームごとに 1つのバンドル を生成

利用方法と現状

  • Deno v2.9.0 で導入、現在は安定版ではない
  • すぐに試すにはdeno upgrade canaryでカナリアビルドをインストール
  • コマンドやAPIは安定版リリース前に変更の可能性あり

deno desktopの特徴

  • Web技術 を最大限活用、既存のElectronやTauri、Electrobunの課題を解消
  • バイナリサイズは 小型、Node互換性も確保
  • デフォルトは各OSのWebViewを使用し、必要に応じて Chromium(CEF)バンドル にも対応
  • npmエコシステム がDenoのNode互換レイヤー経由で利用可能

フレームワーク自動検出

  • Next.js、Astro、Fresh、Remix、Nuxt、SvelteKit、SolidStart、TanStack Start、Vite SSR を自動検出
  • 既存Webプロジェクトを コード変更なし でデスクトップ化可能
  • リリースモードでは本番サーバー、--hmrではホットリロード付き開発サーバーを自動起動

バックエンド・通信方式

  • プロセス内バインディング でバックエンドとUIが通信
  • ソケットベースのIPCではなく、 高速なインプロセス通信 を実現
  • DenoコードとWebView間のラウンドトリップを排除

クロスコンパイルとアップデート

  • 1台のマシンでmacOS、Windows、Linux用バイナリを生成 可能
  • バックエンドは必要時にダウンロード、ローカルビルド不要
  • バイナリ差分自動アップデート (manifestとbsdiffパッチ対応)
  • 起動失敗時は自動ロールバック

シンプルなサンプル

  • 1ファイルアプリ例:
    • main.ts
      • Deno.serve(() => new Response("<h1>Hello, desktop</h1>", { headers: { "content-type": "text/html" }, }))
    • コマンド:deno desktop main.ts
    • 実行バイナリを直接起動(./mainまたはmain.exe

主な機能一覧

  • 設定 :deno.jsonのdesktopブロック
  • バックエンド選択 :CEF、webview、raw
  • HTTPサーバ連携 :Deno.serve()統合
  • フレームワーク対応 :Next.js等主要Webフレームワーク
  • ウィンドウ管理 :Deno.BrowserWindowライフサイクル、複数ウィンドウ、イベント
  • バインディング :webviewからDenoコード呼び出し
  • メニュー :アプリ・コンテキストメニュー
  • トレイ・ドック :システムアイコン、macOS Dock
  • ダイアログ :prompt(), alert(), confirm()をネイティブポップアップ化
  • 通知 :Web Notification APIによるネイティブ通知
  • ホットリロード--hmrでフレームワーク/非フレームワーク両対応
  • DevTools :Denoランタイムとwebview両方に統合DevTools
  • 自動アップデート :Deno.autoUpdate(), manifest, bsdiff, ロールバック
  • エラー報告 :未捕捉例外・パニックのキャプチャ
  • 配布 :クロスコンパイル、出力形式、インストーラ
  • 他ツール比較 :Electron、Tauri、Electrobun、Dioxusとの違い
  • CLIリファレンス :コマンド、フラグ、deno.json desktopスキーマ

Hackerたちの意見

これは発送するのに賢い選択だね。プラットフォームを選ぶときには、私にとってかなり重要なポイントになると思う。

同意!小さいフットプリントでクロスプラットフォームって、ElectronやTauriのいい代替になりそうだね。

ウェブ技術は、世界で最も広く知られているUIツールキットです。個人的には言葉の選び方が悪いと思う。Electronアプリが批判される理由は、UIツールキットとは真逆の存在だからだよ。ホストOSからのUIパターンを取り入れるのがいつも上手くいってない。ウェブ技術は単なるウェブ技術。ボタンを描画することはできるけど、スタイルがなくても、そのボタンがOSにネイティブに見えるとは限らないし、ブラウザによっても違うからね。

それがUIツールキットかどうかは変わらないよ、確かにそうだし。

OSにネイティブに見える それが問題なの? 読みやすいラベルのついたボタンはボタンだよ。ホストOSは、実行するアプリケーションと全く同じ見た目である必要はないんだ。

どうして言葉の選び方が悪いの?「ネイティブ」なUIではないかもしれないけど、彼らはそう主張してないよ。LinuxのネイティブUIはいつもすごく醜いと思っていて、むしろスタイリッシュなHTML+CSSレイアウトを使いたい。私の経験では、Electronは主に膨れすぎて遅いことで批判されていて、ネイティブでないことは時々追加される二次的なポイントだと思う。HTML+CSSを使ったレイアウトの直接ブラウザ統合を作りたいと思ってるけど、JSランタイムが必要ないものがいいな。Servoがどれくらい軽量かはわからないけど、いつか私のアイデアが実現することを願ってる。

Linux、macOS、WindowsでZedを使うたびに、そのGPUIフレームワークがどれだけ安定していてパフォーマンスが良いかに驚かされるよ。ユーザーとしてはすごく満足してる。ただ、アクセシビリティみたいな基本的な機能が欠けてるのは残念だけど、きっとすぐに実装されると思う。開発者としては、Rust以外に何が障壁になってるのかは分からないけど、それがユニークなポイントでもあるよね。

そうだね、ほとんどが怠慢とコスト削減のせいで、ユーザーが犠牲になってる。今はもう言い訳も通用しないよ。ネイティブフレームワークでサクッとコード書いちゃえばいいのに。

ネイティブに見えることは、UIについての異論としてはもう25年前に終わってるよ。Microsoftが気にしなくなってから、誰も気にしなくなった。

それが人々がElectronを使う理由じゃないよ。目標は「UIツールキット」や「ホストOSからのUIパターンを採用する」ことじゃなかった。Chromiumにはめちゃくちゃ多くの機能が詰まってるから、すごいことだよ。それらのユーティリティがElectronに付いてくるのは良いことだし。例えば、動画に関わったことがあるなら、デスクトップアプリに現代のブラウザのフルパワーがあるのはゲームチェンジャーだってわかるよね。動画再生(トランスコーディングも含めて、現代のウェブやウェブコーデックで可能だけど)は複雑な作業で、それを自分で実装するのは大変だし、win/mac/linで動くデスクトップアプリでやるのはさらに大変。Electronを使えば、数十時間で作れるアプリが、そうじゃなければ数十日以上かかることもあるよ(AIを使ってるから、動画の専門家じゃないけどね)。

ウェブ技術はただのウェブ技術だよ。ボタンを表示することはできるけど、スタイルがなくても、そのボタンがOSにネイティブに見えるわけじゃないし、ブラウザによっても違うからね。ほんと、イライラするし、余計なお節介だよね。

ネイティブに見えるかどうかなんて気にしないよ。ネイティブのUIも常に変わるし、必ずしも良い方向に行くわけじゃないし。

Hacker Newsで議論の続きを見る