ハクソク

世界を動かす技術を、日本語で。

FlutterとRustからRustとEguiに切り替えました

2025年6月24日原文(jdiaz97.github.io)

概要

  • Flutter + Rust から Rust + egui への移行体験談
  • 複雑性の最小化 と 個人の強みに合わせた選択 が主な理由
  • eguiの即時モードUI による開発効率の向上
  • 生成コードやFFI管理の煩雑さ からの解放
  • パフォーマンス向上 と シンプルなUI構築 の実感

Flutter + RustからRust + eguiへの移行理由

  • これは 個人的な経験談 であり、絶対的な真実ではない
  • Flutter + Rust 構成では、 flutter_rust_bridge によるバインディング生成を利用
    • 多くのケースでflutter_rust_bridge_codegen generateだけで動作
    • ただし、FFIやAPI設計時に 生成が動作しない場合のトラブル が発生
  • egui を選択したきっかけは rerunプロジェクト の印象的な成果
  • 週末でUIコードを書き直し、 Flutterを捨てる決断

複雑性の最小化

  • 2言語併用 はプロジェクトの複雑性を増加
  • BoquilaHUB は小規模プロジェクトであり、不要な複雑性は排除したい
  • 自動生成コード は数千行に及び、理解不能で最適化困難
  • 自分で書いたコードより生成コードが多い 状態も発生
  • プロジェクト全体の理解度 と 管理しやすさ を重視

個人の強みに合わせる

  • 開発者は自分一人 であり、FlutterのGUI力を活かしきれない
  • egui は最小テンプレートの修正だけで十分な見た目を実現
  • FlutterのWidget構造 による状態管理の煩雑さ（例：setState問題）に悩まされる
  • egui なら即時モードで毎フレームUIがリフレッシュ
    • コールバックや状態管理フレームワーク 不要
    • 例えばボタン追加もシンプルなRustコードで完結

即時モードUIのメリット

  • egui では状態管理・再描画の悩みがゼロ
  • 複雑なコールバックやフレームワーク （getx, bloc, provider等）不要
  • UI変更が即座に反映 され、直感的な開発体験

パフォーマンスの体感

  • Rustが速い、Dartが遅い という単純比較ではない
  • FFI経由の処理やデータコピーの影響 で、Flutter + Rust構成は体感的に遅く感じた
  • ONNX Runtime の呼び出しも、Rustのみの構成で より高速・スナッピー な動作
  • アプリ全体のレスポンス向上 を実感

まとめ

  • Flutter + Rust から Rust + egui へ移行したことで
    • 複雑性の削減
    • 自分に合った開発体験
    • パフォーマンス向上 を実現
  • BoquilaHUB への支援を希望

この体験談が、同様の選択に悩む方の参考になれば幸いです。

Hackerたちの意見

インスタントモードのGUIはクールだけど、アクセシビリティのサポートがちょっと不足してる気がする。ネイティブフレームワークではそれが無料で手に入ることが多いし、WebではARIAに従えば無料でできるけど、インスタントモードのGUIだといつも後回しにされてる感じがする。例えば、eguiはAccessKitをサポートしてるみたいだけど、Webで使うときはそうじゃないみたい。Dear ImGuiはもっとひどくて、そっち方面の努力はあるけど、アクセシビリティに関するチケットが開いてる状態（これはざっと見た感じだから、間違ってるかも）。インスタントモードはスピードとゲームみたいなアプリに焦点を当ててるから、そうなるのも分かるけど、両方の良いとこ取りができたらいいのにね。

└

インスタントモードのGUIでアクセシビリティサポートが不足しているのは、技術的な制限があるからなの？それとも単に手間がかかるだけ？Flutterはコントロールのレンダリングを自分でやるから、たくさんのアクセシビリティ機能を自分で実装しなきゃいけないんだよね。

└

ウェブのアクセシビリティの欠如は、即時モードの問題というより、ウェブのネイティブUIスタックを避けて、自分で全部レンダリングすることに起因してると思う。カスタムレンダリングの内容をブラウザに伝える方法はあるけど、それにはかなりの手間がかかるし、AccessKitがネイティブでやるよりも統合が必要なんだよね。

やっぱり昔ながらのWYSIWYGデザイナー付きのGUIフレームワークが好きだな。

└

最近、Slintがかなり近づいてきてると思う：https://slint.dev/ まだ簡単なドラッグ＆ドロップはないけど、IDEのライブプレビュー機能があって、かなり近い感じ。Visual StudioのGUIデザインの日々が懐かしいけど、オープンソースのRust界隈も昔ほどシンプルじゃなくなってきたね。

└

WYSIWYGデザイナーは便利そうだけど、あんまり人気がないのには理由があるよね。コードでUIを書く方が柔軟だし、メンテもしやすいし、プロジェクトが大きくなるにつれてうまく機能するんだ。

└

FlutterFlowを試してみたけど、結局はすべてコードで書く方が好きだったな。それに、LLMはFlutterのレイアウトを書くのにすごく便利だよ。

└

HTMLにあまりにも焦点を当てすぎて、ウェブデザインが後退したってことをずっと言い続けるつもり。Dreamweaverのサイトは確かに素晴らしいものではなかったけど、今の大多数の作品よりもクリエイティビティとデザインがあったと思う。

eguiは、アプリケーションの実行時間が短いプロジェクトや、長寿命のプロジェクトのオーバーレイには最適だね。スクリプトのビジュアル版みたいなもので、ユーザーにとって役立つためには少しの即時の視覚フィードバックとパラメータの調整が必要だってことが分かる。Flutterはもっと堅牢なUIについての質問に答えてくれる。正しいツールを選んだのは良いことだし、もっと多くの人が選択肢があることを知るべきだと思う。でも根本的には、eguiのように低摩擦で、アクセシビリティ、パフォーマンス、スタイル可能な保持モードのGUIの視覚的柔軟性を持つ堅牢なUIフレームワークの可能性に最もモチベーションを感じてる。Raph Levienとxilemプロジェクトがそれに近づけてくれるかも。

└

UIが十分に速ければ、複雑なUIでも問題ないんじゃない？UI処理のコードをできるだけ速く保つための良いモチベーションになると思うよ。

└

両方のアプローチには欠点があって、私の見解では、保持モードとインスタントモードはUIの複雑さが増すにつれて収束する傾向があると思う。今のところ、少し複雑なアプリケーション（デスクトップのワードプロセッサ）でeguiを使っても、実装したいUIに問題はなかったよ。インスタントモードはReactからの新鮮な風だね。[編集：ただし、私のアプリケーションには標準的なアクセシビリティの批判が当てはまるけど、これはインスタントモード全般の問題というより、私の実装の問題だと思う。]

└

Flutterとeguiについての意見、ありがたい！完璧ではないけど、堅牢なUIと単一のコードベースを提供しているのはFlutterくらいしか知らない。Flutterよりも複雑でない方法で、同じように単一のコードベースからマルチプラットフォームソリューションを実現できるものにはとてもオープンだよ。

Hacker Newsで議論の続きを見る