デスクトップGUIにローカルWebサーバー+HTML/CSS/JSフレームワークを使うのはアリ？ なぜ流行らないのか、デメリットと代替案を徹底議論！

間違いなく可能だし、実際にやってるアプリもあるよ。フロントエンドを複数のバックエンドから切り離すためにね（SQLエディタとかを想像してみて）。

ただ、一般的には効率が悪いのが主な理由。今の時代、ローカルで動くように設計されたソフトウェアのほとんどが、レイテンシとか帯域幅の問題でそうなってる。ローカルにデプロイするために色々頑張るなら、ローカルマシン上で（今は無料だとしても）同じようなボトルネックを抱える意味ある？

それって本当に主な理由？実際にはそうは思わないな。

ここではlocalhostのレイテンシの話をしてるんだよね。それはめちゃくちゃ小さい。もちろん、最適化されたQTアプリケーションの方がパフォーマンスが良いっていうのは理解できる。でも、ほとんどのデスクトップアプリケーションで、GUI自体がパフォーマンスのボトルネックになることってある？それに、1ms以下のレイテンシが問題になることなんてある？高リフレッシュレートのモニターだってそんなに速くない。派手な演出があったとしても、ウェブサイトはもう何年も前からそれをやってるじゃん。

JavaScript（特に多くのJSフレームワーク）のパフォーマンスがあまり良くないのは確かだけど、それが実際に（この文脈で）問題になることって多いの？最近のウェブデザインでは、Svelte、Wasm、新しいフレームワークによって多くの問題が改善されて、以前より問題になりにくくなってると思うけど。Reactは複雑な処理をするとかなり遅くなるけど、デスクトップGUIの95%はそうじゃないし、もしそうだったとしても、もっとパフォーマンスの良い選択肢があるよね？

ウェブ技術の多くがパフォーマンスが良いとは言えないのは確かだけど、ウェブサイトやGUIの95%において、それがユーザーが気づくほど問題になることってある？システム負荷が増加するって言うかもしれないけど、それはGUIが何らかの形で更新されるときにしか起こらないから、ここでは重要じゃないと思う。

だから答えとしては「やってる人もいる」と「最近のアプリでは、ローカルで動くソフトウェアを書く理由と、それをやりたくない理由が同じ」って感じかな。

複数のユースケースに（少なくとも今の考えでは妥当と思われる）適用できる単一のスキルセットを学ぶことには価値があると思う。デスクトップGUIからウェブページを取り除くと、クロスプラットフォームのデスクトッププログラムはQTかGTKくらいに限定されるよね？他にも選択肢はあると思うけど、おそらくそれがメイン。QTを学んでもあまり応用が効かないし、特定の生態系に縛られる。

ローカルアプリケーションを持ちたいけど、そういう縛りを受けたくないっていうことには価値があると思うな。

Electronみたいなのを使えば、全部ローカルで動かして、ウェブ開発のフロントエンドの機能を利用できるよ。Discordとかがそう。Androidアプリ、iOSアプリ、ウェブアプリ、デスクトップアプリとかに、一つのコードベースからリパッケージすることもできる。

ElectronかPWAアプリを調べてみて。

両方知ってるけど、Electron は Rust を使ってないから、俺のバックエンドには合わないんだよね。PWA は確かに役立つ場合もあるけど、いつでもそうとは限らないし（今やってる2つのアプリでは特に）。

ここで言いたいのは、Electron より（ほとんどの場合で）良いと思うアプローチについて質問してるってこと。

セキュリティへの影響を別の視点から考えてみる。攻撃者が何らかの攻撃で localhost 接続を確立する方法があるかもしれない。つまり、認証なしで localhost で SSH サーバーを実行することはないだろう。

なぜ？ ホストコンピュータ上の何かがネットワークアクティビティにアクセスできるなら、すでにターミナルアクセス権を持ってる。

もちろん、認証を追加して、XSS 攻撃に注意すれば簡単に解決できるけど、シングルユーザーのローカル実行アプリにユーザーアカウントを要求するのは、最高のユーザーエクスペリエンスとは言えないかもしれない。

XSS は、ローカルホストのアクティビティであっても、ウェブサーバーなら必ず対処しなければならない問題だ。

一方、ローカル以外のネットワークアクセスを許可することで、アプリケーションをリモートで使用できるという良い副作用もある。

これは、プラットフォーム間の移植性という追加のメリットがある。VSCode は素晴らしい例で、多くのプラットフォームで完全にウェブページアプリとしてよく使われる。

ちなみに、TauriはElectronに対するRustの代替手段だよ。

Tauriは少し違って、独自のWebビューをバンドルせず、システムのWebビューを使用する。バンドルサイズには良いけど、互換性と開発者の労力には悪い。

Electronのことは知ってるけど、nodejsのバックエンドが必要になる。Rustの方がはるかに適している（そして私の精神衛生上も良い）ので、それは私のニーズに合わない。Electronはいくつかの理由で私が説明しているものとは異なるけど、主な理由はnodejsへの依存にある。

TauriはRustのバックエンドを使ってElectronを改良しようとしているけど、独自の生態系を作り、WebViewに依存するという設計上の選択が、実際のローカルWebサーバー+フロントエンドよりも多くの欠点をもたらすと思う。

完全に実行可能だよ。ただ、通常は追加のツールやインフラが必要になるし、それが多くの人にとって参入障壁になるんだ。ウィンドウライブラリの依存関係を追加するだけよりね。多くのアプリケーションは、一人で作られてて、全部できないか、同じ考えを持った人が数人いて、ウェブ開発の経験がなくて、好みの問題か、もっと重要な問題があるから、既存のエコシステムにできるだけ留まりたいんだ。

じゃあ、そういうツールを提供するプロジェクトが存在しないのはなぜ？ OP で言ったように、必要なのは、いい感じに単一の実行ファイルか appimage にまとめてくれることだけなのに。

Electron/Tauri を選ぶ理由だけど、主にアプリケーションを完全に制御できることと、OS との連携が優れてることかな。ウェブアプリじゃできないことがネイティブアプリにはあるんだ。コアロジックをウェブベースにするべきじゃないってわけじゃないんだよ。VSCode とか Discord のコアみたいにね（特に VSCode はエディターコードを自分のウェブサイトで使える）。でも、OS と密接に連携できた方がうまくいくんだ。例えば、Discord は現在実行中のプロセスを見て、プレイ中のゲームを表示/ストリーミングできるし、VSCode はウィンドウマネージャーから直接ファイルを開ける。WSL との連携も、ネイティブアプリじゃなかったらどうなるかわからない。

でも、Electron や Tauri には、axum/actix などを使ったシンプルな webserver 設計よりも、より効果的になったり、可能になったりする要素はないよね。Rust （または他の言語）コードがバックエンドとして実行されていて、フロントエンドと通信できるんだから、本質的に全く同じ OS アクセス権を持ってるはず。Electron や Tauri が、ローカルプログラムなら 常に 存在する OS アクセス権に加えて、何を提供してくれるのか理解できない。

1つ目のポイントだけど、何が言いたいのかよくわからない。想像できるあらゆるアプリケーションに対して、ウェブアプリがあらかじめ作られていないのはなぜか、そして、なぜ各アプリケーションが独自の UI を作る必要があるのか聞いてるの？ それは自明のことだと思うけど。

2つ目のポイントだけど、技術的には可能だけど、非常に人間工学的ではなく、直感的ではない。人々は、ブラウザでファイルを開いたり、ウィンドウとして存在しない状態でアプリケーションが存在したりすることに慣れてない。確かに、エッジケースは存在するけど（俺も、localhost ウェブページとしてのみ公開されるローカルソフトウェアを使ってる）、ソフトウェアがどう動作するべきかという人々の期待、特にできるだけ多くの人にソフトウェアを使ってもらいたい企業にとっては、摩擦をできるだけ減らしたいんだ。だから、ウェブサーバーとして存在したり、通知センターのアイコンがあったりするよりも、適切な実行ファイルとして存在し、適切なウィンドウを表示する方が簡単なんだ。技術的な制限というよりも、人々が直感的にそう思うんだ。

1つ目の点についてだけど、何を言ってるのかよくわからないな。なぜ誰かが想像できるすべてのアプリケーションに対してWebアプリを事前に作成してないのか、そしてなぜ各アプリケーションが独自のUIを作成する必要があるのか​​を尋ねてるの？ それは自明のことだと思うけど。

違うよ。君は、Tauriのようにそれをやってくれるツールと比較して、追加のセットアップ作業が必要だと言ったんだ。「余分なツール/インフラ」が必要だって。WebViewに依存せずに、そのツールの一部をすぐに使えるツールがないのはなぜかと聞いているんだ。基本的なWebサーバーをセットアップしてくれて、起動するためのビルドツールのプリセットを提供して、出荷準備ができたらバンドルするのを手伝ってくれるようなもの。基本的には、Tauriだけど、適切なWebサーバー（axum/actixベースから選択可能）を使ってて、制限がなく、WebViewに限定されないもの。

2つ目の点についてだけど、技術的には可能だけど、非常に人間工学的ではなく、直感的じゃない。人々はブラウザでファイルを開いたり、実行中だけどウィンドウとして存在しないという奇妙な宙ぶらりんの状態にアプリケーションが存在したりすることに慣れてない。確かに、エッジケースは存在するけど（ローカルホストのWebページとしてのみ公開するローカルソフトウェアをいくつか使ってる）、それは人々がソフトウェアに期待する方法だし、特にできるだけ多くの人にソフトウェアを使ってもらいたい企業にとっては、摩擦をできるだけ減らしたいんだ。だから、たとえば、Webサーバーとして存在して、通知センターのアイコンを表示する代わりに、適切なウィンドウを表示する適切な実行可能ファイルである方が簡単なんだ。これは技術的な制限ではなく、人々が直感的に期待することなんだ。

これについてはすでに触れたけど、特にこれは、WebViewのようなアプローチで簡単に解決できる。ブラウザがほとんど「ヘッドレス」で実行されるんだ。メニュー/ブラウザ固有のUI要素なしでね。プログラムの見た目は他のデスクトップアプリと変わらないし、独自のアプリケーションとして実行される（単なるブラウザタブとしてではない）。もちろん、ブラウザタブもオプションだけど、それが絶対に必要だとは思わない。

ありがとう、それが僕が考えてたこととほぼ同じだね。おまけのリボンが付いてるって感じかな。このスレッドの一部の人が、これが可能じゃないと思ってる理由がわからないんだ。

僕の主張の核心は、WebViewとサンドボックスを強制しないTauriとか、nodejsとカスタム環境を強制しないElectronみたいなツールセットとして、おまけのリボンがすでに存在しててもおかしくないと思ってたんだ。

Dioxus はコンセプト的には素晴らしいけど、まだ未熟すぎて、本格的に dive into する気になれない。つい最近になって、使いやすい方法で一般的な要素が 0.7 でリリースされたばかりだ（実際には、4ヶ月くらい前に予定されてたのに、まだリリースされてない）。

今後数年間で、コンセプト的に似たようなフレームワークがたくさん出てくると思うけど、個人的には現状では面倒すぎる。

そう、Tauri は wry がベースになってる。これは良いアプローチだと思うけど、Linux ではブラウザとして WebKitGTK に依存するという欠点があると思う。これなら Tauri の問題の一部は回避できるけど、Linux の互換性が制限されるのは変わらない。でも、もっと調べてみるよ。ありがとう！ いつか WebView が Linux をもっとサポートしてくれるといいな。

一番の問題は、アプリの起動と停止が面倒なことだと思う。コマンドラインから起動する必要があるだろうし（ほとんどのユーザーには無理）、自動的に停止できないから、別途停止する必要がある。

なんでそう思うのか理解できない。なぜコマンドラインから起動する必要があるんだ？ フロントエンドがバックエンドへの接続が切れたり、閉じたりするのを検出して、自動的に閉じることができないのはなぜ？ なぜそんな決めつけをするのか理解できない。

できるかもしれないけど、Tauri/Electron みたいな解決策を使うか、普通のホスト型ウェブアプリを使うよりも、ずっと面倒だ。

これも理解できない。バックエンドがプログラムロジックのためにローカルアクセスできること以外は、フルblown のサーバーホスト型ウェブページとほとんど変わらない。前に議論したように、Tauri と Electron の "機能" は、標準的なウェブデータ転送方法を提供せず、制限が多いため、自由度を奪うものだと感じてる。

その理由を詳しく説明してもらえませんか？ ありがとう。

正直言って、君が言ってるのはある意味Electronアプリのことだよね。普通はローカルのaxumバックエンドサーバーなんて立てないし、それはどっちかっていうと面倒だからって理由が大きいと思うけど（それに、そうするとWebで完全に同じ構成を再現できないしね）。でも、理論的にはできない理由はないと思うよ。ただ、めんどくさいし、やりすぎだって話。

Electronの話じゃないんだよね。バックエンドにnodejsなんて使いたくないし。Electronのことは知ってるし、元々の投稿でもちゃんと触れたけど、Electronは僕の考えてるものとは違うんだ。あれはもっと肥大化してるし、さらに悪いことに、バックエンドのロジックにnodejsが必要になる。それは個人的には受け入れられないトレードオフなんだ。

コンセプトとしては似てるけど、僕が言ってるのはElectronよりTauriに近いかな。最初から専用のユーザー環境をパッケージ化するんじゃなくて、ユーザーがすでに持ってるブラウザを使いたいから。

Electronを学ぼうとしたことがあるんだけど、かなり複雑な3層構造なんだよね。まずレンダラー層。ここではWebコードを書いてて同期的な処理になるから、できるだけ軽くする必要がある。次にメインプロセス。これはバックエンド/オーケストレーターみたいなもの。そしてプリロードスクリプト。これは非同期レイヤーで、レンダラーにアタッチされてて、メインプロセスとレンダラーの間で情報をやり取りするために使われる。

デスクトップアプリだけど実はWebアプリっていうアーキテクチャは、結局すごく複雑でパフォーマンスも低い。流行った理由はおそらく、Webデベロッパーが多いからだと思う。

ああ、確かに、それはひどいアプリケーションの作り方だ。Electronが存在するのと同じ理由でnode.jsが存在する。それは、フロントエンドのWeb開発者が新しいことを何も学ぼうとしないからだ。

だから、私はOPに強く反論する。単一ユーザーのローカルアプリケーションにWebフロントエンドとHTTPサーバーを使うのは、ただのアホだ。

ああ、確かに、それはアプリケーションを作成するひどい方法だ。Electronが存在するのと同じ理由でnode.jsが存在するんだ。新しいことを学ぶことを嫌がるフロントエンドのWeb開発者の集まりさ。

だからこそ、OPに強く反論してるんだ。単一ユーザーのローカルアプリケーションのためのWebフロントエンドとHTTPサーバーは、ただのバカげたものだ。

だからこそ、Electronに明確に反対してるんだ。デスクトップアプリケーションでHTML/CSSが望ましく、役立つ理由をたくさん挙げたけど、それらの理由はElectronとはまったく関係ないし、nodejsとは絶対に関係ない。

＞デスクトップアプリケーションにとってHTML/CSSが望ましく、有用である理由をたくさん挙げたけど、

いや、全然してないじゃん。HTML/CSSがデスクトップアプリケーションにとって望ましいはずの、同じような曖昧な2つの理由をただ列挙して繰り返しただけで、それに対する関心が足りないとか、現在のアプローチが不十分だとか文句を言い続けてるだけじゃん。でも、自分が間違っている可能性を受け入れる代わりに、つまり、それらの解決策がイマイチなのは、それが良いアイデアではないからだという可能性を受け入れる代わりに、なぜそうなのかを具体的に説明せずに、それが根本的に良いアプローチだと主張し続けてる。

お前が言ってるのはこういうことだよね：

• ウェブアプリケーションを開発するスキルは、より多くの分野で一般的に役立つ
• HTML/CSSはアプローチに柔軟性があり、プラットフォームのUIパターンに限定されない

最初の点は、ウェブアプリケーションがタスクに適しているかどうかとは関係ない。それは完全に自己中心的な理由だ。エンドユーザーは、開発者であるあなたが多くの分野で働くことができ、特定のプラットフォーム向けのアプリケーションの作成に限定されないことなんて気にしない。

2番目の点も非常に自己中心的だ。人々は、良いUIとは何かについてのあなたの個人的な考えなんて気にしない。彼らはあなたのユニークなセンスを求めていない。彼らは見慣れた感じで、仕事をしてくれるものを求めている。

アプリケーションの品質を気にしていないように見える。あなたはただ、特定のデスクトップ環境に特化したものを学ぶ必要がないようにしたいだけだ。

＞Electronが存在する理由は、node.jsが存在する理由と同じだ：フロントエンドのウェブ開発者が新しいことを何も学びたがらないから。

いやいや、ちょっと待って。Electronが存在するのは、それが便利だからだよ（例：ネットワーク、マイク/カメラ/WebRTC、スタイリング、オーディオ/ビデオ/画像の組み込みサポート、Bluetooth、i18n、アクセシビリティ、UIのライブプレビュー + 支払いゲートウェイ/OpenIDログイン/アニメーションのような一般的なものに対する事前構築されたコンポーネント、npm経由の巨大なライブラリのエコシステム、どこでも動作する、開発者を見つけやすい、など）。他にそんなもの見つけるのは無理ゲーだよ。

Flutterが一番近いけど、Dart言語と（npmに比べて）限られたエコシステムのせいでまだイマイチなんだよね。

DartはTypeScriptよりもはるかに優れた言語だよ。生JSなんて話にならない。TSの「絶対にint型だって誓うよ - 実行時に文字列だったから爆発する」みたいなのじゃなくて、実際の静的型付けがあるのはマジででかい。

＞DartはTypeScriptよりもはるかに優れた言語だよ、

俺が言ってたのは、Dartに比べてTypeScript/JSの[経験豊富な]開発者を見つけるのがどれだけ簡単かってこと。

「巨大な」npmエコシステムの大部分は、単にコアのJavaScriptライブラリが非常に不足しているから存在するだけだ。一番簡単なことをするために100個のモジュールが必要になる。

他にデスクトップアプリケーション開発に必要なものをすべて備えているもの知ってる？　ネイティブのプラットフォームアプリケーションフレームワークだよ。Electronが存在するのは、ウェブ開発者がデスクトップアプリケーションを作るように言われたときに、他のことを学ぶのが面倒だからだ。それだけ。アプリケーションごとにウェブブラウザを同梱するのはバカげてる。ユーザーはそれを本当に望んでいない。俺は望んでない。

理性的な意見をありがとう。最近はみんな洗脳されてるみたいに、何でもWebテクノロジーを使おうとするんだよね。

その動機となる説得力のある理由をいくつか挙げたと思うよ。決して「Webしか知らないから、どこでも使いたいんだ」というわけじゃないと断言するよ。CSS/HTMLがWebを支配してきたのには多くの理由があって、そのほとんどはその有効性に関わるものなんだ。

最新のWebアプローチは、数十年にわたるツールと知識を基盤としながら、Webデザインの歴史的な問題を多く解決してる。特にSvelteとwasmが思い浮かぶね。Svelteは既存のWebデザインと比較して非常にパフォーマンスが高く、開発者/エンジニアとして非常に使いやすい。それに加えて、変更をほとんど加えずに他のプラットフォームに出荷できるという利点がある。VSCodeが100％ブラウザで動作したり、モバイル用のPWAを見てみて。

一方、QTはややマイナーで、QTを使用できる場合にのみ役立つ。HTML/CSSとWebフレームワークが唯一の選択肢であるべきだとか、使用されるべきだとはっきり言ってるわけじゃない。でも、そのコンセプトを気に入る論理的で説得力のある理由があると言ってるんだ。デスクトップアプリの95％は、ほとんどのWebフロントエンドのGUIパフォーマンスによって制限されない。ほとんどの場合、問題にならないんだ。

パフォーマンスというより、ソフトウェアのデザインの問題だと思う。ハイパーテキストドキュメントを書き換えるのが、例えば、ウィジェットが自己レンダリングして、明確なレイアウト管理をするModelview-ControllerアーキテクチャよりもGUIを作る上で優れてるってことを証明する必要があるよね。僕的には、ドキュメントを書き換えて、ブラウザがどう処理するか判断させるのは、完全に逆行した戦略だと思う。何十年も前から適切な解決策があったのに、ナンセンスとしか言いようがない。QTの経験は少しあるけど、HTMLはほとんどない。「divを中央に配置する方法」みたいなミームを見ると、マジで白目むくわ。

洗脳じゃなくて、実用性の問題だよ。現実として、ネイティブUIフレームワークで、ウェブほど人間工学的で、使い慣れてて、ドキュメントが充実してるものはないんだよね。HTMLなら5分でできることを、ネイティブ実装でやろうとしたら1日（あるいは1週間）かかるかもしれない。それに、Webベースのスタックなら、数えきれないほどのプラットフォームで一貫した使い心地が無料で手に入るんだよ（開発リソース的に）。

Electronも好きじゃないけど、多くの重要な問題を解決してくれるから人気があるんだよ。「洗脳」されてるから使ってるだけだって決めつけるのはフェアじゃないよ。

GUIアプリケーションを開発する時、MVP（Minimum Viable Product：実用最小限の製品）をどれだけ早く作れるかっていうのが、プラットフォームを選ぶ基準になるべきじゃないと思うんだよね。何年もメンテナンスする予定ならさ。それに、Electronを選ぶと、不要なフロントエンド・バックエンドの分離が発生して、あれこれやり取りする必要が出てきて、新たな問題が山積みにならない？

理論的には正しいけど、すべてのアプリが、何年もサポートできる大企業がついてて、何千時間も開発に費やせることを前提にしてるよね。でも、そんなケースは稀だよ。まあ、SpotifyとかDiscordには言い訳できないかもしれないけど、それはごく一部だよね。

ほとんどの場合、UI担当の開発者は0.5人くらいしかいなくて、2035年にアプリがどうなってるか心配するよりも、次のリリースをどうするかで手一杯なんだよ。

つまり、実際のエンジニアリングじゃなくて、ハッスル文化（とにかく頑張る文化）ってこと？それってストレス溜まりそう。

そんなことないよ。小さな趣味プロジェクトとか、人間工学よりも機能性を重視する小規模チームのプロジェクトなら、なおさらそうだよ。

リソース管理の問題なんだよ。テクノロジー大手みたいに無限のリソースがないなら、UIのレンダリング方法よりも、別のことにリソースを使った方がいいかもしれない。

一つには、すべてのものをHTTP接続を通してフィルタリングしたり、Webブラウザのサンドボックスの性質に対処したりすることなく、ローカルオペレーティングシステムのサービスに直接アクセスできること。確かにElectronはそれを簡単にするけど、それでもエンドユーザーとして、ほとんどのElectronアプリが嫌いだ。アプリと一緒にフルWebブラウザを同梱するのはバカげてる。

私もほとんどのElectronアプリが嫌いだけど、それはnodejsと特定の実装によるものが大きい。Webデザインをコンセプトとして使っているという単純な事実よりもね。nodejsが必要だとしても、パフォーマンスの良いElectronアプリはたくさんある。VScodeは素晴らしい一般的な例として挙げられるけど、他にもたくさんある。

私がここで言いたいのは、Electronの使用について尋ねているのではなく、Electronに概念的に類似していながら、（ほとんどの状況において）Electronよりも優れた代替手段だと私が認識しているものについて尋ねているということだ。

俺にとっては、Tauri はまさにあなたが言ってる "ローカル webserver + HTML/CSS/JS フレームワーク" だよ。必要に応じて便利な機能もたくさん追加できるし、いつでも "静的な" ウェブサイトを作って Tauri 経由で提供できる。

OP でも言ってるように、Tauri は axum/actix みたいな真の webserver と比べると、いろいろ制限があるし、個人的には助けになるどころか、かなり面倒だった。実際の webserver みたいにルートを処理しないし、データ転送の手段もすごく限られてる。データの扱い方がローカル webserver と完全に同じじゃないのが、大きな違いなんだよね。

ブラウザを開いて特別な URL にアクセスする必要がないし、同時に web サーバーを起動する必要もないという利点もある。

URL を開くって話だけど、ユーザーに手動でパスを開かせるくらいなら、システムの呼び出しでユーザーが選んだブラウザで URL を開けばいいじゃん？ webserver は他の Rust コードと同じように起動するし。何が言いたいのか全然わからない。

アプリにブラウザ全体をパッケージする必要がないから、Electron よりあなたが説明してることに近い。

なんでみんな俺が Electron を擁護してるみたいに言うんだ？ OP で明確に否定してるのに。俺からしたら、これは Electron や Tauri よりさらにミニマルなんだよ。Electron は過剰に嫌われてる気もするけど、擁護するつもりは全くない。肥大化してるのが嫌だし、バックエンドに nodejs を使うのはありえない。

簡単だよ。ちょっとしたおもちゃの3DプリンタースライサーUIを数日で作り上げられたし、パフォーマンスも最高だった。同じことをElectronでやろうとしたら、フレームワークとの戦いで、至る所でパフォーマンスのボトルネックにぶち当たった。

Eguiはいいね！ 知ってはいたけど、DOMやJSバインディングなしで、ブラウザでwasmとして実行されるように設計されてるとは知らなかった。

デスクトップアプリケーション以外にも役立つっていうのは魅力的だし、詳しく調べてみるよ。でも、採用されたばかりのアプリケーションが抱えるのと同じ問題、つまりドキュメントが少なかったり、サポートが少なかったりするんじゃないかと心配してる。

HTML/CSSは、広く受け入れられてる宣言的なアプローチとして、依然として多くの力と価値を持ってると思うけど、間違いなくこれをもっと調べてみるよ！ ありがとう。

CSS は本当に強力だし、最新のウェブ技術はメモリ使用量とパフォーマンスを大幅に向上させることができる。Svelte を良い例として見てみて。wasm も（まだ完全な代替にはなってないけど）。

Electron アプリの多くが poorly made だからといって、ウェブ GUI デザインのコンセプトが悪いわけじゃない。ウェブツールが今の形である理由はたくさんあるし、その多くは効果性に関係してる。

いや、全然違うよ。ネイティブアプリの方が同じ労力でずっと速い。最近のアプリはほとんどがめちゃくちゃ遅い。

僕はそんな経験をしたことがないし、証拠が君の主張を裏付けるとは思えないな。繰り返すけど、これは特にSvelteや同様のツールを使用する場合は当てはまらない。

最後にWebブラウザでパフォーマンスの問題（純粋にネットワークの遅延ではなかったもの）を経験したのはいつだったか思い出せないな。最適化が不十分なReactのWebサイトもたくさん含めてね。Webアプリがうまく作られてなくて、パフォーマンスの問題が存在する可能性がないとは言ってないよ。でも、それは一般的な問題じゃないし、特に一般的な問題である必要はないって言ってるんだ。もし仮に、Reactが常にパフォーマンスの悪いアプリにつながるなら、SvelteやVueなど、もっと合理的なものを使えばいい。Svelteでまともなアプリを作って、実際に目に見えるパフォーマンスの問題を抱えるのは本当に難しいよ。

言いたいことはわかるけど、逆に、本当にキビキビ動くレスポンスの良いアプリってのが今じゃレアすぎて、ほとんどの人が何が欠けてるのかわかってないんじゃないかな。

パフォーマンスが良くないと思うアプリの例をいくつか教えてもらえませんか？デスクトップアプリ、Electronスタイルのデスクトップアプリ、フルWebページ、どれでもいいので。繰り返しますが、存在しないと言ってるわけじゃなくて、普段使ってるもので何が当てはまるのか知りたいだけなんです。

ローカルデバイスではほとんどFOSSアプリしか使ってないし、FirefoxもGPUアクセラレーションでWebページはすごく快適だから、恵まれてるのかもしれません。でも正直、VSCodiumもサクサク動くんだよね。不思議なことに、VSCodiumはTauriを使うと重くなるんだけど、それはバックエンドの問題でGUIの問題じゃないんだよね（Tauriの肥大化した（個人的な意見）Rustのコンパイラチェック、VSCodiumのnodejsバックエンドとか。フロントエンドは全然関係ない）。

メモリサイズは別の問題で、ほとんどのElectronスタイルのアプリには当てはまると思うけど、これもカスタムブラウザとかnodejsバックエンドとかのElectron特有の問題だよね。Tauri + Svelte/wasmとか、ローカルWebサーバー + Svelte/Wasmとかだったら問題にならないはず。場合によっては、QTやeguiよりも小さくできる可能性もあるし、大きくても大差ないと思う。

ほとんどのデスクトップソフトウェアが遅いと感じるな。昔からある一般的なデスクトップソフトウェアって、20年前と比べて速くなってないよね。わかりやすい例はMS Wordかな。

コンピューターのハードウェアは20年前よりずっと速くなってるのに、ソフトウェアのレイテンシは悪化してる。

本当に比較したいなら、FLTKとElectronの両方で何か実装して比べてみな。違いは明らかだよ。

ポートの競合があるよね。

設定ファイルで開始ポートまたはポート範囲を指定できる。アプリケーションは起動時に自動的に空きポートを検索する。クライアントのレスポンスが何十年もそうしてきたようにね。

セキュリティ

これについてはすでに触れたけど、OS環境がすでに侵害されていると仮定した場合にのみ問題になる。個人的にはそれは妥当だとは思わないけど、他のアプローチよりも攻撃対象領域が広いことは認識してる。

あのクソみたいなものを起動したり止めたりするのが面倒

何がそんなに複雑なんだ？ 他のアプリケーションと何が違うんだ？

ネットワークプロトコルを介してローカルコンピューターと不必要に通信するのは馬鹿げてる。

君のコンピューターはすでにさまざまな方法でそれを行ってるよ。仮にそうでなくても、何が問題なの？

それは僕には可能な限り効率の悪い方法に聞こえるよ。Electronを使うよりも面倒じゃないし、それはかなりひどいことだよ。

それは絶対にElectronよりも効率的だし、飛び越えるべきハードルが少ないから、間違いなく簡単に動作させられるはずだよ。

君の考えがまったく理解できないんだ。もっと詳しく説明してくれる？ 君がどこから来てるのか、まったくわからないんだ。

Electron の利点を無視してるけど、かなり大きいと思うよ。典型的な仕事用コンピュータにとって、一番の生産性地雷はブラウザだ。俺の JIRA タブは、ハッカーニュースとか WhatsApp とか eBay とか、ランダムな emacs パッケージリポジトリとかライブラリドキュメント（たまたま HTML）とか、3つくらいのアンビエント YouTube タブ（2つは見つけられなくて一時停止してる）と混ざってるんだ。

アプリをウェブアプリとして作る問題は、他の天才も同じ考えを持ってて、あなたの UI が俺の小さなブラウザに詰め込まれて、まるでピエロの車みたいになってることだよ。

OP で明確に述べたように、Chromium* と Firefox ブラウザに WebView があってもおかしくないんだ。需要が高まれば、おそらく数週間でこの問題を解決できる。そうすれば、（ブラウザの UI 要素/メニュー/ダイアログなどがない）ネイティブデスクトップのようなインターフェースになるし、実際に選んだブラウザを使うことになる。Edge は WebView を提供していて、Chromium ベースだ。Firefox ブラウザはこれに関して制限が多いけど、結局のところ、現状では Linux の問題にすぎないと思う。

あなたの主張には同意する。JavaScript が勝ち、CAD パッケージ以外のネイティブ UI を書くのは時代錯誤だ。でも、少なくとも2つのクライアントができるまでは、サーバーを作らないでくれ。

JS にはたくさんの問題があるけど、それでもウェブで使われる理由はたくさんあるし、その主な理由のいくつかは、効果的だからだ。Svelte は、俺たちが慣れ親しんでるものと比べて、かなりパフォーマンスが良い。

ちょっと確認させて（俺はただのC++開発者だから、この辺のことはちょっと疎いんだ）。

ElectronはHTML/CSS/JSエンジンを含んでるけど、フル機能のブラウザが提供する多くのものが欠けてる。それはHTTP処理、Cookie、WebSocket、その他もろもろかもしれない。あるいは、グラフィカルな非互換性かもしれない。

だから、Electronのようなものを作りたいんだけど、上記をただ埋め込む代わりに、実行中のブラウザインスタンスの上にウィンドウアプリをホストしたいんだね。だからElectronとは違って、アプリとJIRAのタブすべてに対して単一のJSエンジンが稼働しているんだと思う。これは、Electronが通常欠いているブラウザ機能の不足という問題を解決する一方で、アプリがブラウザが実行するように求められるすべての信頼できないコードと一緒にされるという問題を引き起こす。

後者の点は、クライアント/サーバーアーキテクチャに移行せざるを得ない理由なんだ。ブラウザでホストされるコードは、ほとんど何も役に立たないから、ファイルを開くための必死の叫びを聞くためにlocalhostでリッスンしているサーバーが必要になる。

ただし、（暗黙のうちに主張していると思うけど）クライアントでホストされるコードもそれほど役に立たない。生産性は、リモートリソースからの読み書きをますます意味するようになっている（上司にメールで送るdocxを操作するのではなく、データベース操作を行う）。だから、ファイルシステムへのアクセスなんてどうでもいい。このアプリが成功すれば、結局サーバーを増やす必要があるんだから。

Tauriアプリでaxumサーバーを起動して、WebViewをそこに接続すれば、Tauriのやり方をほとんど無視できるし、それでもTauriのDXの恩恵を受けられるってことに注意してね。セキュリティ対策を無視するのは良くないけど、メンテされてないWebViewのバインディングを使ってカスタムソリューションを自作するよりはマシだと思うよ。

それも考えたんだけど、現時点では価値があるとは思えないんだよね。確かにTauriはサンドボックスみたいなものを提供するけど、そのほとんど/すべてを無視するのは、目的を無効にして、さらに面倒を増やすだけに見えるんだ。WebViewを使いたいなら、wry（Tauriの内部で使われてるもの）を直接使えばいいんだけど、それだとLinuxでの制限が大きすぎる。

LinuxでのWebViewのパフォーマンスの悪さは、X11環境でのTauri v2にのみ影響するはずだよ。特にNvidia GPUだとひどい。Tauri v1はX11で問題なく動作するし、Tauri v2はWaylandで問題なく動作するはず。

それは違うと思うな。問題は、LinuxではWebKitGTKしかWebViewの選択肢がないってことだと思うんだよね。それは「本物」のブラウザと比べて機能に大きな違いがあるし、基本的なデータ転送でもパフォーマンスがすごく悪いんだ。グラフィカルな変更どころじゃないんだよ。Waylandがどう影響するかもわからないけど、たぶん関係ないと思う。

Tauriの開発者たちは、WebKitGTKとSafariの問題や矛盾を修正するために、独自のWebView実装を研究してるって言ってたよ。それが彼らにできる最善のことだと思うから、成功することを願うよ。

いくつかの実験的なプロジェクトでは、TauriでServo.orgをWebViewとして使ってるけど、Servo自体は非常に簡素だよ。

TauriがCEFまたはカスタムChromiumをバンドルできれば、Electronのように、Tauriのいくつかの問題点が解消されるし、アプリのビルドをより長期的に維持できるようになる。システムのWebViewから切り離されるからね（これがLinuxでのパフォーマンス問題の原因だった）。

ああ、それは進行中だけど、少なくとも1年は先（もっと可能性が高い）だと思う。繰り返すけど、僕は専門家じゃないけど、調べて分かったのはそういうこと。

カスタムWebViewを配布すると、Chromiumの余計なディスク使用量とダウンロードサイズを削減するという、Tauriの最初のキラー機能が失われることになるけど、正直言って、まともなストレージとインターネット接続が普及してなかった10年前のような問題じゃないよね。ユーザーがインストールしたすべてのTauriアプリでWebViewランタイムを共有することもできる。

個人的にはそのアプローチは好きじゃないな。ネイティブブラウザを使ってほしい。そんなに単純な話じゃないのは分かってるけど、ブラウザにメニューやブラウザのUI要素なしでインスタンスを実行できるオプションがあれば（WebViewみたいだけど、実際にはWebViewじゃない）、今日の問題のほとんどは解決すると思うんだ。君が言ったように、アプリケーションのデータサイズの問題は昔ほどではないし、ブラウザの互換性の問題もそうだ。完全に解決されたわけじゃないけど、Electronが最初に勢いを増した頃よりははるかに良くなってる。

React Nativeは、ネイティブコードブリッジとの知識移転を実現するのに最適なフレームワークかもしれないけど、利用できる範囲は限られてる。MicrosoftはWindowsとmacOSのブリッジを作成したけど、QtまたはGTKをターゲットとするLinuxデスクトップ用のまともなサポート付きブリッジは知らないな。

個人的にはそれは受け入れられないな。React（特にReact Native）は、パフォーマンスに問題があるからね。それに縛られたくないし、パフォーマンスのためにSvelteみたいなものを選びたい。自由に選べることこそが、そもそも魅力の90％を占めてると思うんだ。

Webテクノロジーがリードしてるけど、万能なGUIアプローチなんてないし、結局は自分やチームの既存のスキルを活用するのが一番だよ。

確かに。適材適所ってことだね。でもね、Rust + Svelteは、デスクトップの仕事の90％くらいに合うツールになりえると思うんだよね。その上に、一般的なWebにも使えるっていうメリットもあるし。TauriやElectronの制限なしにそれを行うことが、個人的には魅力なんだ。