Electron製MacアプリをRustで書き換え！
引用元：https://news.ycombinator.com/item?id=44118023
最近ね、逆のことしたんだよ（Tauriで始めてElectronに移行）。プラットフォームによって使ってるWebViewのレンダリングが違ってイライラしたからなんだよね．．．移行してからクロスプラットフォームでUIバグに遭遇した？
あんたのUIの要件はかなりシンプルで、計算が複雑みたいだから、QAの追加コストを考えても割に合うんだろうね．．．ただ、俺の経験が珍しかったのか、それともレンダリングの違いって俺が感じたほどよくあることなのか、気になってさ。
あと、Tauri 2．0を使ったの？それとも1．0？V1の途中で2．0の最初の安定版が出たんだけど、移行が悪夢でドキュメントがひどかったんだよ．．．ドキュメントは整備されたのかな？
Tauriでのレンダリングの違いへの対応って、普通のWebアプリ作る時より難しくないんじゃないの？
Electronはアプリにchromeをバンドルするから、一つのレンダリングエンジンだけ扱えばいいんだよ．Tauriはアプリをインストールしたシステム上のデフォルトブラウザを使うんだ
知ってるよ．俺が言いたいのは、Tauriは普通のWebアプリ開発よりも物事を難しくしてるわけじゃないってこと．クロスブラウザで動くWebアプリを作るのって別に新しくて怖いことじゃないでしょ
実はまだTauri版ではクロスプラットフォーム対応を展開してないんだよ．だからこれからどうなるか様子見だね．幸い、俺たちのUIの要件はシンプルなんだ．Tauriでどんなレンダリングの違いを見たの？一番良かった／悪かったプラットフォームはあった？次はWindowsもサポートしたいと思っててさ．
Electron版のアプリでは、Intelチップ搭載のMacでバンドルしたバイナリを実行するのに問題があったんだ．それで頭を悩ませたから、Tauriで再構築するにあたっては、他のプラットフォームをサポートする前にまず一つのプラットフォーム（Appleチップ搭載のMac）に集中しようって決めたんだ．
Tauri 1．4を使ったんだけど、今のところ問題ないよ．2．0への移行のドキュメントをチェックして、どんな感じか見てみる必要があるね．
新しくも怖くもないけど、”俺のマシンで動けばどこでも動く”に頼るよりは、時間やお金がずっとかかるんだ．
俺は大規模な消費者向けWebアプリで働いたことがあるけど、そこには専任のQAチーム（や外部の協力会社）がいて、複数のプラットフォームやブラウザバージョンで視覚的回帰テストを実行してたんだ．ソロ開発者としては、趣味プロジェクトでそんなチームになる気は全然ないね．だから俺にとってTauriとのトレードオフは、”明らかなUIバグを出荷するのを許容する”か、”肥大化したバイナリを出荷するのを許容する”かだったんだ．
フォーラムで読んだアネクドートによると、200MB余計にかかることに対して大騒ぎするのはHNの読者くらいらしいし、俺のアプリは彼らをターゲットにしてないんだよ．
いや、WebkitGTKは問題児で有名だよ．
＞ 最近ね、逆のことしたんだよ（Tauriで始めてElectronに移行）．プラットフォームによって使ってるWebViewのレンダリングが違ってイライラしたからなんだよね．．．
これが俺たちのTauriに関する一番の不満なんだ．OS提供のシステムWebViewは、開発の基盤として安定してて、再現性があって、一貫性があるプラットフォームじゃないんだよ．
Tauriは、アプリにブラウザランタイムをバンドルしないことをプラットフォームの主要なセールスポイントにした．代わりに、オペレーティングシステムのブラウザランタイムを使うことになった．各OSで違うランタイムだ．
紙の上では良さそうだけど、それが俺たちにとっては大きな頭痛の種になった．SafariやEdgeはすごく気難しくて非標準的な挙動をするし、それが最悪なんだ．ブラウザ機能が頻繁に壊れる．タイトなシステムサンドボックスとCORSの挙動（ブラウザごとに違う）の間で、とにかく奇妙な方法で動作してるのに、微妙な違いが積もり積もって死に至るんだ．そしてそれが止まらないように見える．これらはCSSのパディングみたいな小さな問題じゃなくて、本格的なアプリの挙動の破壊なんだ．”caniuse．com”でさえ、組み込みWebViewとの互換性マトリックスについては間違ってる．（※以下、テストの手間、Rustは良いけどシステムWebViewは悪い決定、Chromeをバンドルしたい、容量より時間が大事、開発者は読んでほしい、コミュニティ全体の意見だ、という内容が続くが200字以内のため要約）
俺たちはRustに惹かれてTauriを選んだけど、システムブラウザランタイムは本当にひどい決定だった．
Tauri開発者たちはこの不満を聞いてるけど、残念ながら彼らの解決策はServoのサポートをロードマップに入れることだ．それは1000％間違った修正だ．Servoはまだ製品レベルのプラットフォームじゃない．俺たちはただChromeが欲しいだけなんだ．
アプリに最新のchromeをバンドルさせてくれよ．小さいプログラムやインストーラーサイズで誰かの頭痛を救ってるわけじゃない．ゲームはすでに巨大だし、みんな許容してる．たくさんのソフトウェアが大きい．それは受け入れられてるし、大丈夫、普通なんだ．俺たちにはたくさんのスペースがあるけど、たくさんの時間はない．それが本当のトレードオフだ．
俺はRustを使いたい．Chromeを使いたいんだ．
Tauri開発者がこれを読んでくれることを願ってる．これは俺一人からの意見じゃない．コミュニティ全体のコンセンサスだ．
組み込みWebViewはTauriのセールスポイントじゃない．Rustなんだ．
俺はWeb開発者で、TauriやElectronはまだあまり使ったことがないんだ．
なぜプラットフォーム間でレンダリングの違いがそんなに問題になるのか疑問に思ってるんだよね？Webアプリを構築する時も同じ課題に直面するから、そんなに変わらないんじゃないかと思ってたんだ．
Tauriが使うWebkitGTKって、WebアプリのユーザーのWebブラウザが使うWebkitGTKより悪いものなの？
いや、でも誰も（一次近似で）Gnome webなんて使ってないっしょ。WebKitGTKのせいで大半のJavaScriptウェブアプリはあのブラウザで動かないと思うよ。人気のGnomeディストリビューションは全部Firefoxが最初から入ってるから、「とりあえずデフォルト使っとこ」って人もGnome webは使わないだろうね。
ぶっちゃけChromeOSプラットフォームだけ残ればWebはずっと良くなるんじゃない？ 標準とか複数ベンダーとか、誰が要るんだよって話。
開発者にとっては支配的なオープンソースブラウザエンジンがある方が断然楽だよ。オープンソースってこういう標準とか複数ベンダーの必要性を減らしてくれるんだよね。Linuxがどうやって大量のUNIXを置き換えたか見てみなよ。みんなで一つのプロジェクトに貢献できて、必要に応じてカスタマイズできるってのは成功したモデルだってことだよ。
「追加の200MBに騒ぐのはHN読者だけ」って意見あるけど、ユーザーはElectronアプリ多数でRAMが常にパンパンなことに気づく？ Electronの批判は単にバイナリが大きいだけでなく、みんなが過剰にRAM使うアプリ作ってることなんだよ。
Kreya.appでシステムWebViewを使ってるよ（Tauriじゃなくてカスタム実装だけどね）。プラットフォームの違いはめったに問題にならないな…。Polyfillsでほとんど解決するし、Linuxで自動のエンドツーエンドテストを走らせてるから大半の問題はこれで捕まる。個人的には一番難しいのは、特にLinuxとmacOSで、ユーザーのWebViewバージョンがどれくらい古いかを把握することだと思う。WindowsはWebView2の実装でうまくやってるね。
BSDの人たちがどう思ってるか聞いてみなよ。単一文化は最高さ、ただしそれが俺たちが賭けたやつならね。
Electronの売りは、開発に使ったChromeのバージョンがアプリと一緒に配布されること。自分のマシンで正しく見えれば、実行する誰のでも正しく見えるってわけだ。これはWeb開発みたいに、どのブラウザやバージョンをテスト・サポートするか決めるよりずっと楽だよね。
TauriはChromeをアプリにバンドルしないからバンドルサイズはすごく小さくなる。でもそのトレードオフとして、デフォルトのWebViewブラウザでレンダリングすることになる。MacだとSafari（macOSのバージョンによる）、Windowsだと最近のEdgeだね。Tauriにはこれを細かく説明したいいページがあるよ: https://v2.tauri.app/reference/webview-versions/
これはつまり、新しいOSが出るとアプリの見え方が変わる可能性があって、ユーザーはアプリをアップデートしなくてもUIバグが出るってことだね。
まあ、オープンソースだったおかげで、ニッチなOSでも互換レイヤーとかLinuxドライバー経由でLinuxソフトを動かせるようになって、むしろ良くなったってわけだね。
それは確かにそうだね。私のアプリ（そして多分元の記事のアプリも）は、それがユーザーの現在の焦点かつ優先事項であって、タスクが終わったら終了されるものだと想定して作られてる。こういう主要なアプリのために結構な量のRAMを要求することについては悪くないと思ってるけど、もしバックグラウンドツールとか小さなユーティリティを出荷するなら考え方は違うだろうね。
でもさ、Tauri使ってるならウェブアプリは自分でコントロールできるんでしょ。ってことはWebkitGTKでもテストする必要があるってこと？ それが追加の負担ってことなの？
Microsoftって結局正しかったんだね，訴訟とかマジ金の無駄じゃん，モノカルチャー最高！
ゲーム開発者がWindowsばっか気にしてるのも同じでしょ，Protonはオープンソースだし別にいいじゃん，気にする必要なくなくない？
Tauriも全部でうまくいくわけじゃないよ．LinuxのWebkitGTKはパフォーマンス問題あるししょぼい．Slackの開発者がWebviewからChromiumに移った話みたいに，多くのチームが通った道だしElectronがあるのにも理由があるんだよ．（Tauriが皆の言う”聖杯”みたいじゃないってことね）
特にmacOSはアプリを”終了”しない前提で作られてるんだよね．ウィンドウ閉じても裏で動いてる．cmd＋qとかで終了しないと．
使い終わったら終了しろって要求するのはUXとして良くない．アイドルでRAM食うElectronも，裏でCPU食うRust UIフレームワークも，多くが抱える問題だね．
WebkitGTKにデプロイしたことあんの？
WebRTCサポートしてないからビデオ会議アプリ”テスト”できるといいね！エラーページテストにはなるかもだけど．
これ以外にも機能不足，バグ，ヤバいパフォーマンスの例はたくさん．通知なし，：hasなし，TLAなし．（Epiphany開発者を責めてるわけじゃないけどね）
unpopular takeだと思うけど，自分でテストできないプラットフォーム向けのバイナリ出すの，マジ疑問．理解できない複雑さとか，デバッグ能力の限界とか考えると，ユーザーは不満だろうし有料アプリなら購入に繋がりにくいし解約されやすいでしょ．唯一のメリットはマーケティングページにアイコンが増えるくらい．
Tauri 2．0に移行すれば，もしかしたらパフォーマンス面でもっとメリットあるかもよ．特に大量のデータを動かすときに，JS－Rust bridgeがめっちゃ強化されたからね．
＞モノカルチャー最高
ブラウザこそがプロダクト．OSSエンジンは新規参入障壁下げる．
＞ゲーム開発者がWindowsばっか気にしてんのも一緒，Protonオープンソースだし別にいいじゃん
だからValveは開発者にWindowsターゲット＆Proton推奨．単一プラットフォームの価値はデカい．前はLinuxにひどいポート作ってたしね．
Electron／Tauriは主導実装がクローズドで高機能な点で状況が違うけどね．
単純な事実として，同じUIを複数のOSで出すのはいくつかのOS（もしかしたら全部？）にとっては明らかに間違ってるんだよ．
WebベースのクロスプラットフォームUIツールキットは，基本的なUI慣習さえ間違えるからね．
UI一貫性のためだけにWebアプリじゃなくてElectronアプリ出すこと，わざわざ選ぶ人っている？
俺が見たElectronアプリの大半は，公開されてるWebアプリとコード共有してるか（結局クロスブラウザテストは必要），Webじゃできない機能（ファイルシステム権限とか）のためなんだよ．
逆に，うちみたいに複雑なWebアプリだとマジで大きな問題なんだよ．
8年も前のMacのWebviewでユーザーバグ対応するの，マジしんどかったし．LinuxのWebkitGTKのパフォーマンスもヤバいしね．
もっとコメントを表示（1）
俺の代わりに決めつけないでくれよ。俺はアプリが少し違ってても1GBもない方が全然良いね。Tauri使ってる大半の人は君みたいな問題抱えてないと思うよ。そもそもなんでそんな問題になったのか分からんし。システムWebView使うってサイトにデカデカと書いてあるじゃん。フォークの飾りを見て使っといて、先が尖ってるからスプーンにしろって文句言ってるようなもんだよ。
俺も似たことやったよ。Electronで簡単なwebcam viewer作ったら500MBになっちゃって、App Store出すのにこれは無いなって。Tauri V2に移植したら15MBまで減ったぜ。
TauriとElectronって何が違うの？どっちも描画にブラウザ使うけど、Electronはブラウザ丸ごと入れてて、Tauriはシステムにあるやつ使うって理解で合ってる？
違いは君の言う通り。それに加えてTauriはバックエンドがRust、ElectronはNode.js。Electronは成熟しててコミュニティもでかいけどTauriも勢い増してるよ。メモリ安全性とかサイズ、パフォーマンス気にするならTauriが良い選択肢だね。Electronも悪くないけど、新しいのいっぱい出てくるのは理由があるんだ。
一番大きな違いは、ElectronはChromeをまるっと同梱してるからMacとかWindowsとかLinuxで見た目のズレがほとんどないこと。その代わり数百MB増えるけどね。TauriはOSのエンジン使うから、WindowsならEdge、MacならSafariのWebKitとかになって、表示とか機能で違いが出る可能性あるよ。
” If memory safety
TauriってWebKitのラッパーでしょ？WebKitってほぼC++で書かれてるんじゃなかったっけ？
そうだよ、でもWebKitは君のアプリコードよりずっとテストされて、fuzzテストもされて、研究もされて、実戦で鍛えられてるんだ。だから全体で見れば安定性とかセキュリティのリスクはそんな高くない。全部メモリ安全だったら最高だけど、それが君自身のコードをメモリ安全な言語で書かない理由にはならないよね。
自分のRustコードとすごく簡単に繋げられるから、本当に大事な部分（自分のコード）はメモリ安全になるよ。
TauriはネイティブのWebView（古いOSだと古い可能性あり）を使って、ネイティブコードにコンパイルされる。ElectronはChromium（HTML/CSS+V8）とNode.jsをまるっと入れてる。Node.js使わないで、コンパイル言語（Rustは低レベルすぎるかもだけど）使うElectronがあったら、もっと良かったのになぁ。
マジそれな。ElectronはアプリごとにChromium入れてるけど、TauriはOSのネイティブWebViewを使うんだ。Electronの方がずっと成熟してるけど、Tauriも良くなってるよ。
めっちゃいいね。ナイスな作業じゃん。アプリの名前なんていうの？今週App Storeに申請する作業やってんだよね。
アプリ名はMicroscopic Viewにしたよ。ウェブサイトも作ったんだ。https://microscopic-view.jgarrettcorbin.com
申請プロセスに手こずって他のプロジェクトに追われてまだストアには出てないんだけど、もしよかったらビルド送るよ。
これが低スペックなAndroid向けに最適化されたらいいな〜古いタブレットってタダ同然なのにネット見るのさえ厳しいし。
あと、安くて使える顕微鏡のおすすめ教えてくんない？AliExpressで色々試したけど全部詐欺かゴミだったんだ。
https://plugable.com/products/usb2-micro-250x/これが俺が使ってるやつ。値段の割にめっちゃ良い。普通のウェブカメラみたいに使えるんだ。主にマイクロはんだ付けに使ってるから用途が違うかもしれないけど、値段考えたら超良いよ。Amazonに公式ストアあったはず。
興味あるんだけど、どうやって動画データをfrontendにストリームしたの？
標準のWeb APIにあるMediaStreamを使ったよ。https://developer.mozilla.org/en-US/docs/Web/API/MediaStream
俺もチームもMacユーザーじゃないしRustへの書き換えも考えてないんだけど…でもこの記事、めっちゃ感謝してるよ。
これが”Show HN”に期待することなんだよね、現実の問題を解決するために必要な技術的なトレードオフを分かりやすくまとめたやつ。経験を共有してくれてありがとう！
経験を共有できて嬉しいよ。長い間議論してたことなんだ。すでにまあまあ動いてるものを再構築するのは大変だけど、この場合は結果に満足してるよ。
Tauri、Flutter、Electron、React Nativeとか、最新クロスプラットフォームフレームワークの比較ベンチマークが見たいな。バンドルサイズ、メモリ、起動時間とかの指標で。特にTauriはプラットフォームでWebViewの挙動違うから、その互換性マトリクスもあると開発者が選びやすくなると思うんだ。
2週間前に更新された良い比較ベンチマークあるよ！→ https://github.com/Elanis/web-to-desktop-framework-compariso…
ランタイムではElectronも結構戦えてるね。みんなディスクよりメモリ気にすべきだと思うんだ。メモリ使用量（シングルウィンドウ、リリースビルド）のデータも一部抜粋するね。
Win: Electron ≈93MB, Tauri ≈154MB
Mac: NodeGui ≈84MB, Tauri ≈86MB
Linux: Tauri ≈16MB, Electron ≈70MB
LinuxのTauriやばすぎ！
ベンチマークにはTauriがLinuxで起動に25秒、Windowsで空っぽアプリのビルドに4分以上かかると書いてあるね。この数字が本当に合ってるのかどうかは分かんないけど。
数ヶ月前、WindowsでWailsとTauriを試してみたんだ。確かにRustオプションでのビルドはありえないくらい時間かかったけど、Goだとずっと速かったよ。理由は分かんないけど、Wailsもだいたい同じことできたし、それが理由でTauriはやめちゃったんだ。
作ったWAILSアプリ、公開できたの？一番苦労した点は何だった？
あれは社内アプリで、CLIツール設定GUIだったんだ。VueでローカルSPAを作って、配布サイズが小さいのが助かったよ。Goコードとの連携も快適だったな。一番苦労したのはオンラインで情報が少ないこと。Electronがみんな使ってて情報が多いからね。
それ、WAILSアプリには最高の使い方みたいだね、よく作ったね！
これこれ。Casey Muratoriがネットの変な人が作ったベンチマークは信用するなって言ってたのを思い出したよ。Tauriアプリが起動に25秒かかるなんて絶対ありえないね。だってLinuxでTauri触ったことあるもん。これは全然桁が違う話だよ。
TauriがLinuxだとすごい良くて、Electronが最悪なのは、それぞれ最適化されてるか、されてないかってのが理由なのかなって思うね。
ブロックエディタ（NotionはElectron、AppflowyはFlutterとか）を、ブログ記事[1]で同じような条件で自分で作ったQt C++＆QMLのブロックエディタと比べたことがあるんだ。読んだら面白いかもよ。[1] https://rubymamistvalove.com/block-editor
前の会社ではデカくなったElectronアプリをメンテしてたんだ。Squirrelでの更新が大変で。
それでGUIはInferno製のSPAにして、C#とSwiftで書いたネイティブアプリからwebviewで表示するように構成を変えたんだ。そしたらサイズとメモリが90％くらい減ったよ。配布もストアにしたし、マジで良い決断だったな。
ネイティブストアでの配布と更新を褒めるなんて珍しいね
承認とか配信の遅れが普通なのに
Squirrelって知らないけど、ネイティブに変えて何が良くなったの？
もっとコメントを表示（2）
Apple対応は大変だけど、更新問題が全部解決したのはデカかった
自分たちにリソースが無かったからね
無料アプリだったからストア経由とかSquirrel使ったけど、メイン製品ならもっと良い方法にした
2018年当時はSquirrelにサーバーが必要で、macOSではマシだったけどWindowsはひどかった
exeが変なフォルダに入って、リンク消すと見つけられないとか
WebViewで作るのは超簡単だったよ
その後、OSに統合する新しい機能も追加したんだ
2018年のことだから記憶がちょっと曖昧なんだけど、全体で2〜3週間くらいの作業だったかな
SquirrelとかElectronに費やした時間よりは間違いなく短かったと思うよ…
LPのTryが購入ページなのは変、トライアル必要だよ
99ドルは高いかも
LPに性能情報がないのが気になる
詳細求む
Electronがボトルネックで処理時間激減したの衝撃
CLIP
ffmpeg連携だけでは
自分は似たElectronツールで性能問題なかった
なぜMac Only
Electron
Tauriはクロスプラットフォームなのに
最近Swift触ったけど良かったよ
アクティブユーザーすごい、マーケティングどうやったの
フィードバックありがとう
トライアルは今後やるかも
似たツール作ったっていいね、リリースしなかった理由は
需要あれば数ヶ月でWindows
Linux版出すよ
ユーザーはHN
reddit
linkedinでのローンチと口コミがほとんど
Electronと動画処理性能について、workerの使い方が悪かったかも
Rust移行でシーン検出やffmpegのGPU加速、バッチ処理もやって改善したけど、バッチ処理はクラッシュもした
Macアプリを目指してたなら、Rust
TauriじゃなくてSwift
SwiftUIにしなかったのはどうして
ちょっと気になっただけ
見てくれてありがとう
Desktop Docsはクロスプラットフォームにするのが目標なんだ
Windowsサポートのリクエストがたくさん来てるから、これから出すWindows版のためにRustを選んだんだよ
まだ実用的じゃないかもしれないけど、Arc browserのチームがどこでもSwiftを使いたいからWindows向けのランタイムを開発してたはずだよ
前にちょっと見てみたんだけど、結局MacではSwiftUIとかAppkit、WindowsではWinUIって感じで、２つのUIを違うフレームワークで書く必要があるんだよね
SwiftでWinUIのコードを書けるようになっただけなんだ
Appkitをwindows APIに移植するのって大変だろうから、まあわかるけど、クロスプラットフォーム開発って意味では大したメリットじゃないよね。ブラウザみたいなの作るならどうせ超低レベルなことやるし、そういうクロスプラットフォーム用の便利機能もあんま役に立たないだろうね。
Windows版のテストもう始めた？OSごとにTauriが使うブラウザの違いで何か問題見つかった？
Windows版のテストはまだ始めてないんだ。君はWindows使ってるの？そのバージョン出すときに教えてあげるよ。
アプリめっちゃ良さそう！Windows使ってるから見るのが待ちきれないよ！
サンキュー！そのバージョンに興味あったらメールちょうだいね: hello ［at］ desktopdocs dot com。準備できたらアップデート送るよ！
俺も同じ質問したかったんだ。Swiftってなかなか良い言語だし、Rustのメリットもたくさん提供してるみたいだね。別のコメントした人が聞いてたけど、俺もCLIPsの統合の詳細に興味あるな。あと、アプリを移植する必要があった理由についての話、すごくいいね。
サンキュー！別のコメントで言ったけどさ、RustのOrt crate使ってて、onnxruntimeをアプリにバンドルしてるんだ。Swiftも間違いなく検討したし、最後に使ってからかなり良くなったのは知ってるんだけど、SwiftじゃなくてRustにしたのはクロスプラットフォームのサポートがあったからなんだよね。移植に関して言えば、新しいバージョンの方がずっとメンテしやすくて満足してるよ。
俺も興味あるな。デスクトップアプリ作ろうと思ってて、Swiftは長いこと使ってないし、Rustもまだ初心者なんだ。Tauriはすごく期待できそう。Electronアプリは本当に嫌いなんだよね。爆速のマシンでも起動がめっちゃ遅いんだもん。何か知見があったら教えて！
Electronを経験してから、もっと早く得意分野（JS）から離れとけばよかったなって思うよ。Electronはとにかく最適化が必要で、すぐに必要ないものをロードしないようにimportsをマジでタイトにしなきゃいけないんだ。Tauriだとバンドルサイズ小さいし超高速だから、努力する価値は十分あるね。
正直気になったんだけどさ、もっとシンプルな組み込み型ソリューションのSQLiteじゃなくて、なんでRedisみたいなサービスを選んだの？個人的にはRedisって分散型ソリューションの方が向いてる気がするんだけど、デスクトップアプリ作ったことないから、たぶんよくわかってないだけかも。
チームの効率上げるためのツール、昔はWinForms、最近WinUI3試したらダメダメ。React+Azure Static Site+Tauriに変えた。Tauriはほとんどの事できてファイルサイズも小さいのが良い。Chrome含まずWebとデスクトップ同じコードでいけるの最高だね。
小さいツールならiced-rsの方がずっと良いんじゃない？Tauriより軽いし、どこでも動くでしょ。最初はコード見るの怖いし手取り足取り教えてくれないからイライラするかもだけど慣れると楽。前に使った時は以前より簡単になってた。複雑なUIならTauriが良いと思うけどね。
WPF使うべきだったね．Windows開発者でWinUIを真剣に考えてる人いないよ，Project Reunionが2020年に発表されてからどんだけメチャクチャかみんな知ってるし．BUILD 2024でWPFが地位を取り戻した理由があるんだよ．
そうそう，Electronアプリでやってたのと同じ機能がTauriでだいぶ小さいバイナリでサポートできるの最高だよね．
eguiとかじゃなくてどうやってTauriに決めたの？Electronの経験があるからかな？俺はPython+QtアプリをRustに移植するのちょっとためらってるんだ，RustのGUIライブラリがQtみたいにリッチじゃない気がして，どこかで詰まるだろうなって分かってるからさ．
俺たちにとってもリッチなUIライブラリは重要だったよ．WebのUIライブラリにアクセスしたかったからTauriを選んだんだ．
Pythonがパフォーマンス的にダメな場所が2つあったんだ．いくつか言語でテストしたら，RustとC++がダントツで一番だった．Rustのコンポーネント書いてPythonから使うこともできたし，C++でQtを使うこともできた．あるいは，Rustにどっぷり浸かることもできた．これは個人アプリで他のユーザーいないから，スキルを磨き続けるのに良い場所だってわけ．
