博士

ロボ子、今日はUIライブラリの話じゃ。なかなか興味深い記事を見つけたぞ。

ロボ子

UIライブラリですか、博士。どのような内容でしょう？

博士

この記事の筆者は、SSHターミナルで動くゲームを作っていて、RatatuiっていうRustのcrateを使ってUIを作ったらしいんじゃ。でも、Ratatuiのdiff処理が遅かったり、レイアウトが面倒だったりで、自分でkruciっていうUIライブラリを作ってみようとしたみたい。

ロボ子

なるほど。既存のライブラリに不満があったから、自分で作ったんですね。

博士

そうなんじゃ。kruciはウィジェットツリーを使って、必要な部分だけ更新するようにしたらしい。Ratatuiみたいに「すべてを描画する」方式じゃなくて、必要なところだけ書き換える方が効率が良いと考えたみたいじゃな。

ロボ子

ウィジェットツリーですか。コンポーネント指向な設計で、変更があった部分だけ再描画するようなイメージでしょうか。

博士

その通り！　SwiftUIのコンビネータみたいに、Text、HStack、VStackなんかを実装して、レイアウトを組むのも簡単にしたかったみたいじゃ。paint()とmount()っていうメソッドで、ノードのサイズを効率的に決めるようにしたらしいぞ。

ロボ子

SwiftUIのような宣言的なUIをターミナル上で実現しようとしたんですね。でも、記事には「課題」と書かれていますね。何が難しかったんでしょう？

博士

イベント処理、状態管理、z-スタック…色々あったみたいじゃな。イベント処理は、コールバックとかチャネルとか色々試したみたいだけど、複雑なUIだと組み合わせが難しかったらしいぞ。

ロボ子

イベント処理はUI開発の永遠の課題ですね。状態管理も難しそうです。

博士

状態管理は、親から子への状態の受け渡しとか、更新が大変だったみたいじゃ。Arc<RwLock<...>>を使うことも考えたみたいだけど、ロックのオーバーヘッドが気になったらしい。

ロボ子

ロックのオーバーヘッドはパフォーマンスに影響しますからね。z-スタックはどうでしょう？

博士

z-スタックは、モーダルウィンドウみたいに重ねて表示するときに、下のレイヤーの更新をどうするか考えないといけないのが面倒だったみたいじゃ。それに、ツリー構造の管理とか、セレクタとか、サーフェスとかのオーバーヘッドもあって、diff処理を避けるメリットが薄れてきたらしい。

ロボ子

なるほど。色々な課題があって、最終的にkruciの開発は断念したんですね。

博士

そうなんじゃ。Ratatuiでもゲームはちゃんと動くし、パフォーマンスに問題ないから、UIライブラリを最適化するよりも、ゲーム自体を良くする方が大事だって判断したみたいじゃな。

ロボ子

それは賢明な判断ですね。UIライブラリを作るのは大変そうです。

博士

本当にそうじゃ。でも、この実験を通して、UIライブラリの設計における色々な課題を学べたのは良かったと思うぞ。ロボ子も、いつかUIライブラリを作ってみるか？

ロボ子

私にはまだ早いと思います。まずは博士の助手として、色々なことを学んでいきたいです。

博士

良い心がけじゃ！　そういえば、この筆者、ゲームの名前を「kartoffels」って言ってたけど、これってドイツ語でジャガイモって意味らしいぞ。もしかして、ジャガイモをモチーフにしたゲームなのかもしれないのじゃ。

ロボ子

ジャガイモですか。なんだか可愛らしいですね。もしかしたら、主人公がジャガイモだったりして。

博士

それ面白い！　もしそうなら、敵は全部ミートソースとかかな？　そして、最終ボスはマッシュポテト製造機…って、それただの料理じゃん！