DiscordがElectronを捨て、Rust版でメモリ70%削減を実証
Every Windows 11 app should kill Electron, and Discord just showed why
Discordの共同創業者Stanislav Vishnevskiy氏が公開した映像で、Rust製の新クライアントが旧Electron版より先にフレンドリストを表示する様子が確認された。2アカウント同時ログインでもRAM使用量は290.2MBと、従来の約1GBから7割減。UIはZed発のGPUIで描画し、HTMLを使わずGPUで直接レンダリングする。モバイルもReact Nativeをやめ、Web版はWASMへ移行する方針だ。
新しいDiscordクライアントのメモリ削減は話の一部にすぎない。クリックすれば即座に反応する。もう元には戻れない。起動時間を見てほしい。
HNでの議論
107- cheschire
これはElectronの初期から知られていたことだと思う。VS Codeが最初にリリースされたときの主要な不満の一つでもあった。
Electronの価値提案は常に、一つのチームが最小限の追加作業で複数のプラットフォームでサポートされる一つのアプリを制作することにある。
この記事はそれには何も触れていない。
- ezst
それはUI全体をネイティブ/非Webフレームワークで書き直したのか？そうでなければ、これはまだブラウザ上で動作している、つまりElectronの肥大化要因の80%程度に留まっており、速くなった理由はおそらく（主に？）通常のクライアントほど多くの機能をまだ追加していないからだろう。
Discordはサーバーサイドプロトコルであり（クライアントはサーバーが規定した状態を表示する以外にほとんど何もしていない）、そこでは大きな違いを説明できるほどのロジック/計算はほとんど行われていない。
- LaurensBER
Electronは、小さなチームが既存のWebスキルセットを使ってまともなGUIアプリを構築できるという点でかなり素晴らしいが、そろそろ何かより良いものが必要な時期だとも感じる。
RAMの価格が狂っている今、基本的なタスク（Discordの場合、90%はメッセージの読み書き）をこなすためだけに数GBを消費するアプリを複数動かさなければならないのはかなりフラストレーションが溜まる。他の人がより高度な機能（ボイスチャットなど）を使うことは理解できるが、それらはオンデマンドで読み込めばいい。
512MBのRAMでLinuxスタック全体（+ Podman、監視、アラート、複数のサービス）を快適に動かせる（今確認したら40%空き！）のに、Windows PCはデスクトップを表示するだけで5.5GBも必要というのはちょっとおかしい。現実的には基本的なWebブラウジングに8GBから16GBのどこかが必要で、それでもDiscordのようないくつかのアプリをバックグラウンドで動かしていると遅く感じることがある。
- mococa
この愚かさが理解できない——Qtで全OS（BSDでさえ）向けの単一コードベースを持つのは超簡単だ（自分一人で何度もやった）。
人々はすごく怠惰になったと思う……「ああ、数百MBのRAMを食うだけだ、問題ない、出荷しよう。」
何十億、いや何兆ドルもする企業がElectronでくだらないものを出荷している。
- smusamashah
最近のアプリの起動の遅さにはすっかり慣れてしまったと思う。最近Task Slinger [1]を使い始めたが、起動するたびに、すでに動いていてウィンドウが表示されただけのような感覚になる。すべての現代のソフトウェアがこうであってほしい。
- bemtevi
Electronアプリはパフォーマンスの面でも、そしてより適切な言葉が見つからないが、肥大化した感じを助長するように思えるので、ほとんど好きになったことがない。VS Codeを試したが、AIを詰め込みすぎて複雑さが増したのでやめた。Sublimeの方がずっと良い。
よくわからないが……すべてのElectronアプリには何か不快なものがあるように思える。
- EddieRingle
Discordはここで模範とすべき例ではないと思う。彼らはネイティブAndroidアプリを廃止してReact Nativeに移行し、今度はReact Nativeをやめようとしている（モバイルはどういうわけか「ネイティブUI」を維持しているとCTOのツイートにある）。コードの再利用を最大化し機能開発を加速させたかったのなら、代わりにKotlin Multiplatformを検討すべきだった。そうすればReact Nativeという回り道をせずに、実際にプラットフォームにネイティブなアプリを構築できたはずだ。（RustとそのUIフレームワークの不協和音は、私の知る限りどこでも本当にプラットフォームネイティブではない。Pop OSくらいかもしれないが、それを特にターゲットにしている人を知らない。）
これは明らかに主観的だが、Rustは言語として、人々が適用しようとしている多くのユースケース、特にUI開発にとって十分に人間工学的ではない。これまで見てきたほとんどのRust UIライブラリは、より命令的なスタイルを使うか、Compose UIやSwiftUIのようなより宣言的なアプローチを模倣しようとしているが、読み書きを簡単にする素敵な言語の美しさを欠いている。そして、そこでの反論がLLMにこれを読ませ書きさせるというのであれば、それはまた別の厄介な問題だ：（1）補助金付き推論の時代は急速に終わりつつあり、（2）どうせLLMを使うなら、なぜ各プラットフォームにできるだけネイティブなアプリを維持しないのか？
- azuanrb
Electronは常に、より高いメモリ使用量と潜在的に悪いパフォーマンスを犠牲にして、クロスプラットフォームアプリを迅速に提供することにあった。LLMがあってもなくても、その核となる価値提案は変わらない。LLMは単にフレームワークの既存の強みを増幅させるだけだ。
もともとネイティブmacOSランチャーだったRaycastは、最近ハイブリッドアーキテクチャを使ったv2をリリースした。Electronではないが、Spotifyのデスクトップアプリと同様のアプローチで、ネイティブシェル内でWeb技術を使っている。
メモリ使用量は依然としてかなり大きい。アイドル時で約350〜450MB、ワークロードによっては1〜2GBに達することもある。利点は、macOSとWindows間でコードの大部分を共有でき、単なるアプリランチャーを超えて進化できることだ。
常にトレードオフであり、LLMはそれを根本的に変えるものではない。