限界を感じた瞬間
ビデオ会議の最中でした。参加者の1人が画面を共有しながらSlackを開いていました。マウスカーソルがカクカク動くのが見えました。通話自体は問題なし。原因は、16 GBのRAMを搭載した現代のワークステーションで、バックグラウンドのSlackがCPU約4%、RAM 1 GB以上を消費していたことです。
リソースが足りないマシンではありません。チャットアプリに、目に見えてパフォーマンスが低下している最新のコンピューターです。その場にいた全員がそれを当たり前のように受け入れていました。
同じ不満を持つ人は私たちだけではなかった
この不満は珍しくありません。「Slack 重い」「Slack メモリ」で検索すれば、何年分ものフォーラム投稿、Redditのスレッド、コメント欄が出てきます。Slack側からの一貫した回答は「パフォーマンス改善に取り組んでいます」でしたが、アーキテクチャは変わっていません。
Slackは依然としてElectronで作られており、つまりChromiumブラウザエンジンを丸ごと同梱しています。フレームワークだけで最低150〜200 MBの基本的なオーバーヘッドが生じます。
なぜWebアプリのラッパーを作らなかったのか
手っ取り早い解決策は、Slackのウェブインターフェース（app.slack.com）をデスクトップウィンドウで包み込んで「ネイティブクライアント」と呼ぶことです。いくつかのツールがこれを実装しています。
しかしそれでは作りたくありませんでした。ウィンドウ管理の問題は解決されますが、メモリやCPU使用量については何も変わりません。依然としてChromiumを動かしているからです。根本原因に対処しない解決策は、本当の解決策ではありません。
ネイティブ開発を選んだ理由
Telegram DesktopにもUIフレームワークとして採用されているQt6を選択しました。Qtは真のネイティブコードにコンパイルされます。ブラウザを内蔵せず、起動時にJavaScriptランタイムも仮想マシンも使いません。OSからは他のネイティブアプリと同様に扱われます。
トレードオフもあります。ネイティブ開発はWeb技術よりも開発サイクルが遅い。機能の構築に時間がかかります。しかしその成果が1秒未満で起動し、アイドル時のCPU使用率がほぼ0%のアプリです。それが解決したかったことであり、解決できました。
諦めたこと、それでも正しい選択だと思う理由
msgaは今日時点でSlackの完全な機能セットを持っていません。音声・ビデオ通話、ハドル、キャンバス、アプリ連携はロードマップにありますが、まだ準備できていません。これらの機能が日常業務に不可欠な方には、今のところ公式アプリが正解です。
しかし、Slackを主にテキストのやり取りに使う多くの人々にとって — メッセージ送受信、チャンネル閲覧、スレッドへの返信、検索 — msgaはオーバーヘッドなしでその役割を果たします。
今後の展開
macOSとWindowsのサポートを開発中です。目標は3つのプラットフォーム全てで同じ体験：素早い起動、静かなアイドル、小さいメモリフットプリント。
msgaはGPL-3.0ライセンスの無料・オープンソースソフトウェアで、GitHubで公開開発されています。Slackの重さにうんざりしているなら、試してみてください。