最近ずっと考えていることがあります。
それは、
「なぜFlutterのような描画基盤は特定の言語やフレームワークに閉じているのか？」
ということです。
Flutterは非常に優れた技術です。
しかしFlutterを使うためにはFlutterの世界に入る必要があります。
もし同じようなGPUネイティブな描画基盤を、
- Rust
- TypeScript
- Python
- Go
- C/C++
- Swift
- Kotlin
など、あらゆる言語から利用できたらどうなるでしょうか。
私はそのための構想として、
Hayate（疾風）
Hayabusa（隼）
という二つのプロジェクトを考えています。
プロジェクト:
Hayateとは
HayateはUIフレームワークではありません。
Reactでもありません。
Vueでもありません。
状態管理ライブラリでもありません。
Hayateは、
命令型・保持型・GPUネイティブなUI基盤
です。
アプリケーションはHayateに対して、
- 要素を作る
- スタイルを設定する
- 更新する
だけを行います。
Hayate自身が、
- レイアウト
- 描画
- テキスト処理
- プラットフォーム差異の吸収
を担当します。
私のイメージでは、
HayateはUI界のLinuxカーネル
です。
その上でどんなフレームワークが動いても構いません。
Rust専用でもありません。
JavaScript専用でもありません。
特定の言語がHayateを独占するべきではないと考えています。
Hayabusaとは
HayabusaはHayateの上で動くRust製フレームワークです。
Signalベースのリアクティブシステムを持ち、
コンポーネントやルーティングなどを提供する予定です。
ただし重要なのは、
HayabusaはHayateの唯一の利用方法ではない
ということです。
Hayabusaはあくまで、
RustからHayateを使うための一つの選択肢です。
将来的には、
- TypeScript向けフレームワーク
- Python向けフレームワーク
- Go向けフレームワーク
- 独自DSL
- ゲームUI
なども同じHayateの上で動くことを想定しています。
関係としては、
Application
↓
Hayabusa
↓
Hayate
↓
GPU
ですが、
これは数ある構成の一例に過ぎません。
本質はHayateであり、
Hayabusaはその上に構築される一つの実装です。
技術スタック
現時点では以下を想定しています。
- Rust
- WIT (WebAssembly Interface Types)
- wgpu
- Vello
- Taffy
- Parley
- AccessKit
描画はGPUネイティブ。
インターフェースはWITによって言語非依存化します。
Webだけではありません。
将来的にはWindows、macOS、Linux、iOS、Androidも視野に入れています。
なぜ作るのか
現代のWebは文書表示のための技術として発展しました。
しかし今私たちが作っているのは、
- IDE
- AIアプリ
- Infinite Canvas
- Realtime Collaboration
- データ可視化
のようなアプリケーションです。
私は、
これらを支える新しい描画基盤が必要になると考えています。
DOMでもない。
特定言語専用のランタイムでもない。
すべての言語から利用できる共通の描画基盤です。
これはまだ構想段階です。
しかし、
「すべての言語にFlutterを」
という方向性には大きな可能性があると思っています。
今後の記事では、
- なぜDOM互換を目指さないのか
- なぜWITを選んだのか
- Hayateの内部構造
- HayabusaのSignal設計
- WebGPU時代のUIアーキテクチャ
などを少しずつ書いていく予定です。
すべての言語にFlutterを。
Hayateは描画を担当する。
HayabusaはRustからそれを使う一つの方法に過ぎない。
主役は特定の言語ではなく、共通の描画基盤そのものである。