ディスカッション (11件)
Denoを活用してデスクトップアプリケーションを構築するためのプロジェクトです。詳細は現在公開待ちの状態ですが、Denoのランタイム環境を活かしたクロスプラットフォーム開発の新しい選択肢として期待されています。
これは賢い実装だね。自分にとっても、どのプラットフォームを使うか決める際の判断材料になりそう。
Web技術は世界で最も広く知られているUIツールキットである。
個人的には、あまり良い言い方とは思えないな。
Electronアプリが批判される理由は、それが「UIツールキット」以外の何物でもないからだ。ホストOSのUIパターンを導入することにおいて、常に的を外しているんだよ。
Web技術は単なるWeb技術だ。確かにボタンを描画することはできるけれど、スタイルを当てていない状態のボタンはOSネイティブに見えるとは限らないし、ブラウザによっても見た目が変わってしまう。
Denoの権限システムとこれがどう統合されるのか気になっていた。これは特に、エージェントがデバイス上でやりたい放題になるのを防ぐための最大の強みだからね。
CLIのリファレンスページ0にはこうある。
コンパイル時に付与した権限は、コンパイル済みのバイナリに組み込まれる
ユーザーがどの権限を与えるかを確認・決定できるように、何らかの形でユーザーに通知される仕組みがあるといいな。
この分野での競争は歓迎だ。特にDenoはTypeScriptをそのまま実行できるし、現在のNode.jsの実装みたいに型を削除するだけじゃないからね。
とはいえ、これはTauriの市場をかなり食い荒らすことになるだろう。今さらTauriを使う理由があるか?追加のバンドルサイズ150MBなんて、今のネット環境ならダウンロード時間に1〜10秒追加される程度だし、信頼性の高いレンダリングエンジンが手に入るんだから。
アプリ間でCEFランタイムを共有。現状、各アプリはCEFを個別にバンドルしている。管理された共有ランタイムがあれば、アプリあたりのバイナリサイズを数MBまで削減できる。ロードマップ入り。
これ0は興味深いね。CEFに詳しくないから、バージョニングがどうなるのか疑問だ。異なるアプリが異なるバージョンのCEFを要求した場合、結局はすべてのアプリが独自のブラウザをバンドルするElectronモデル(少しマシなだけ)になってしまうんじゃないか?それとも「共有ランタイム」にはまだ利点があるんだろうか?
Denoには感心させられっぱなしだよ。正直、新プロジェクトを始める時にこれを使わないなんてことがしばらくなかった。Node.jsから完全に乗り換えたし、エコシステムもかなり成熟してきたね。この機能をどれくらい使うかは分からないけど、選択肢があるのは本当に素晴らしい!
最後にDenoでデスクトップアプリを試した時は、フルスクリーンのWebViewアプリができなかった記憶がある。キオスク端末用アプリとしては致命的だったんだよね。今なら解決しているか確認しなきゃ。Denoが着実に進歩しているのを見るのは嬉しいよ。
これは嬉しいニュース。CEF、WebView、Raw * のバックエンドが用意されているのは分かったけど、ブラウザ起動オプション(WebUIみたいに)があるといいな。webkitgtkという面倒なものを避けつつ、Chromiumエンジンの更新管理に追われたくない自分にとっては、それが一番バランスが良いんだ。
バインディングはIPCではない。Denoランタイムとレンダリングバックエンドは、同じアドレス空間(CEF)または協調プロセスグループ(WebView)内でスレッドやプロセスとして実行される。呼び出しはプロセス内チャネルを経由し、バックエンドがその実行ループからディスパッチする。 -- https://docs.deno.com/runtime/desktop/bindings/
協調プロセスグループがどう動いているのか理解できない。マルチプロセスモードなら、それは必然的にIPCってことにならないか?もしかして「共有メモリ空間」という主張は、OSレベルの話というより、アーキテクチャ上の記述なのかな?
全体として非常に堅実な機能だと思うけど、CEFを使わない場合でも平均パッケージサイズが40MB以下にならないのは驚き。開発時にそこはあまり重視されていなかったのかな?TauriやDioxusなら簡単に5MB以下に抑えられるしね。
機能比較のマトリックス表は非常によくできているし、その下のメリット・デメリットを説明するセクションは、最近読んだドキュメントの中でも最高レベルの内容だった。