デスクトップ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とは絶対に関係ない。

I've listed a plethora of valid and compelling reasons why HTML/CSS are desirable and useful for desktop applications,

You absolutely did not. You just listed and repeated the same two vague reasons why HTML/CSS SHOULD be desirable for desktop applications and then went on to complain about how there's not enough interest in it and how the current approaches to it are lacking. But rather than accept the possibility that you are mistaken, that the reason those solutions suck is because it's just not a good idea, you double down on it and reassert that it is a fundamentally good approach without really saying why.

Here's what you have:

• The skills to develop web applications are more generally useful across domains
• HTML/CSS offers flexibility in approach, not limited to platform UI patterns

The first point has nothing to do with how good a web application is for the task. That's a purely selfish reason. End users don't care that you the developer can work in many domains and aren't limited to making applications for a specific platform.

The second point is also extremely selfish. People don't care about your personal ideas about what makes a good UI. They don't want your unique flair. They want something that looks and feels familiar and does the job.

You don't seem to care about the quality of the application. You just don't want to have to learn anything that might be specialized for a particular desktop environment.

. The same reason Electron exists is the same reason node.js exists: A bunch of front end web devs unwilling to learn anything new.

oh, come on. Electron exists because it's convenient (eg: networking, microphone/camera/webrtc, styling, built-in support for audio/video/images, bluetooth, i18n, accessibility, live previews of ui + pre-built components for common stuff like payment gateways/open-id-login/animations, massive library ecosystem via npm, works everywhere, easy to find devs etc.). Good luck finding anything like that anywhere else.

Flutter comes the closest, but still sucks due to dart lang and the limited ecosystem (compared to npm).

Dart is a much better language than typescript will ever be, not to even mention raw JS. Having an actual static typing instead of - "I swear to god it's int - explodes in runtime because it was a string" of a TS is a game changer

Dart is a much better language than typescript will ever be,

I was talking about how easy it is to find [experienced] devs of typescript/js compared to dart.

A good chunk of the "massive" npm ecosystem exists simply because the core Javascript libraries are so lacking. You need 100 modules to do the the simplest things.

You know what else has everything you listed for desktop application development? Any native platform application framework. Electron exists because web developers can't be arsed to learn anything else when tasked with making a desktop application. That's it. SHipping a web browser with every application is stupid. Users don't really want it. I don't want it.

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

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

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

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

It's not about performance as much as it is about software design. You have to prove that mutating a hypertext document is a better way to do GUI than, say, Modelview-Controller architecture with widgets rendering themselves and a clear layout management. In my book, mutating a document and having the browser figure out what to do accordingly is a totally backwards strategy. I would go as far as saying it is absurd considering that we have had suitable solutions for the problem for decades. I have a bit of experience working with QT and little with HTML but seeing those "how to center a div" memes makes me roll my eyes.

It's not brainwashing, it's a practicality concern. The reality is, no native UI framework is as ergonomic, familiar and well-documented as the web. I could spend 5 minutes with HTML and make something that will take you a whole day (or even week) to replicate with a native implementation. Now factor in that a web-based stack gives you a consistent feel across countless platforms for absolutely free (in terms of dev resources).

I don't like electron either, but it's popular because it's a solution to many nontrivial problems. Pretending it's just a thing people use because they're 'brainwashed' isn't a fair characterization.

I feel like the time to whip up a MVP shouldn't be the criteria for choosing a platform when developing a GUI application that you're planning on maintaining for years. And when picking electron don't you manufacture a whole set of new problems due to the fact that you now have a totally uncalled-for frontend-backend separation forcing you to marshal things back and forth?

Theoretically true if you assume every app has a large company capable of supporting it for years and able to dump thousands of man-hours into developing it, but that's rarely the case. Yeah, maybe Spotify and Discord don't have much of an excuse, but they're also the vast minority.

More likely, you have like 0.5 developers doing UI, and they're just trying to make the next release instead of worrying about what the app will look like in 2035.

So it's all hustle culture instead of actual engineering? That sounds stressful.

Not at all, this goes triply for small hobby projects or projects made by small teams who are more concerned with functionality than ergonomics.

It's more about resource management. If you don't have the nearly infinite resources of a tech giant, you're probably better of spending them on something other than how your UI is rendered.

一つには、すべてのものを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でまともなアプリを作って、実際に目に見えるパフォーマンスの問題を抱えるのは本当に難しいよ。

I get what you're saying, but conversely, I think that truly snappy, responsive apps have become so rare that most people don't know what they're missing.

Would you mind sharing some examples of what you think aren't performant apps, either desktop, desktop electron style, or full on web pages? Again I'm definitely not saying they don't exist - I'm just wondering what in common use you would be referring to.

Maybe I'm spoiled because I almost exclusively use FOSS apps for most everything on local devices, and Firefox with GPU acceleration is very performant for web pages. But honestly even VSCodium runs like a charm for me. Weirdly enough, VSCodium will bog down when using Tauri of all things, but that is a backend issue and not a GUI issue (compiler checks for rust with Tauri's (imo) bloat, nodejs backend of VSCodium, etc - nothing which is actually frontend related at all).

Memory size is a different issue and I'll grant you that one with most Electron style apps - but again, this is an Electron specific problem due to the custom browser, nodejs backend, etc. It simply wouldn't be an issue with Tauri + Svelte/wasm or a local webserver + Svelte/Wasm, etc. Arguably, it could be smaller than QT or egui in the right contexts - but it would almost never be larger by an actually significant amount.

I find most desktop software to be slow. Take most common desktop software that's been around a long time and it doesn't run any faster today than it did 20 years ago. An obvious example would be MS Word.

Computer hardware is so much faster than it was 20 years ago yet software latency has gotten worse.

If you really want to make a comparison, implement something in both FLTK and Electron and compare. The difference will be stark.

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

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

セキュリティ

これについてはすでに触れたけど、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 は、俺たちが慣れ親しんでるものと比べて、かなりパフォーマンスが良い。

So let me see if I understand (I’m just a C++ dev so I’m somewhat foggy on all this).

Electron contains a HTML/CSS/JS engine, but lacks a bunch of stuff provided by a full-fledged browser. Maybe that’s http handling, cookies, web sockets, whatever. Maybe it’s graphical incompatibilities.

So you want to make something that is like Electron, but instead of just embedding the above, you want to essentially host a windowed app on top of a running browser instance. So unlike Electron I guess in that there is presumably a single JS engine humming away for your app and all my JIRA tabs. This solves the problem of your app lacking … whatever browser capabilities Electron typically lacks, while introducing the problem that your app gets lumped in with all the untrusted code the browser is expected to execute.

The latter point is what kind of forces you into a client/server architecture, because browser-hosted code is largely incapable of doing anything useful, so you have to have a server listening on localhost for its desperate cries to open a file.

However, (I think you argue implicitly) client-hosted code isn’t that useful anyway. Productivity increasingly implies reading and writing from some remote resource anyway (database operations instead of operating on some docx that you will email to your boss) so fuck it, why even care all that much about file system access, if this app succeeds it will have to grow a server anyway.

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の制限なしにそれを行うことが、個人的には魅力なんだ。