です。特に宣言的UIという考え方はReactが普及に一役買ったと感じています。
日高：たしかに宣言的UIはWebだけでなくモバイルアプリの文脈でもよく登場してきています。
うひょ：簡単に宣言的UIを説明すると画面の変更を直接書く、いわゆる命令的なスタイルではなく、あるべき状態を記述してUIを構築するという考え方です。これはReact登場以前ではパフォーマンス良くやることが難しかったのですが、仮想DOMとの組み合わせにより、うまく実現できるしくみが整いました。
日高：宣言的UIはReactiveプログラミングとの相性もよく広く受け入れられつつあると私も感じています。フロントエンドで宣言的UIが普及するきっかけとなったReactですが、開発者に受け入れられた理由は何かあるんでしょうか？
うひょ：よく言われるのがReactは非常にシンプルなライブラリだという表現ですね。いわゆるイージーの対極としてのシンプルです。芯の通ったコアとなる概念があって、その上に組み立てられている設計の良さと言えばいいんでしょうか。そういうところにReactの魅力があると感じています。
実はReactってバーンと新しい設計を持ち込んでユーザーを困惑させるみたいなことを、これまで何回かやっていると思うんですよ。たとえば最近では広く使われているReact Hooksです。これはかなり大きな転換点でした。ソースコードの書き方も変わってしまい、登場した当時はif文の中にフックを書いてはいけないなどの独自のルールがあり、少なからず奇異に感じたユーザーもいたと思います。
日高：一見、アグレッシブな変化が設計に効果的だったと？
うひょ：はい。しばらく経ってみるとReact Hooksの良さがコミュニティやエコシステムに伝わっていって、もうフックのない書き方はほとんどやらないよねという状況にまでなっています。
驚きがありましたが理に適っていたわけで、シンプルな設計を打ち出してエコシステムを引っ張るという姿勢がReactの魅力というか、ここまで大きなライブラリに成長した秘訣なのではと感じます。
日高：ちなみにうひょさんがReactに出会ったときにそのような設計の魅力を感じて触ってみたんでしょうか。まだ普及していないタイミングだったんですか？
うひょ：えっと2013年か2014年ぐらいだったと思うんですけども、正直あまり憶えていないです。どうもReactっていうライブラリがあるらしいと耳に入ってきまして、それなら使ってみるかと思ってちょっと使ってみたんです。そのときは理想が高いとか設計が良いとかは考えていなくて、単に新しいものを試してみようくらいの感覚でしたね。使ってみたらかなり良くて、いつのまにか手放せなくなってしまいました。
論理的なシンプルさ
日高：お話を聞いているとより良い開発を達成しようというライブラリ設計者の気持ちが伝わってきます。実際に仕事でも生産性などでメリットは感じますか？
うひょ：宣言的UI、より具体的にはReactの用意しているAPIに関していうと我々、使う側に対してすごく設計を意識させてくれるところがあります。やっぱり良い設計をしてこそReactを使いこなせる側面があって、設計がおぼつかないと汚いReactのコードになってしまう。きれいなReactらしいコードを書こうと頑張っていると、いつの間にか良い設計が強制される、そういう意識を感じます。
日高：逸脱しようとしても書き味が良くない。結果、書いていて気持ち良くないみたいなところを開発者に気付かせるんですかね。
うひょ：そうですね、無駄な処理がたくさん連なっていて良くないなと気付けるということがあります。
自分は、すごく論理的にいろんなことを突き詰めながら考えてプログラムを書くタイプでして、そういうやり方にはReactがマッチしているなと思います。React自体が意志が強いライブラリというか「我々が考えたこの設計に乗っかればうまくいくよ」みたいな色が出ている気がするんです。ですのでライブラリ設計者が用意した条件にのっとって自分のやりたいことを考えると、物事が整理しやすくなります。
Reactの良さを最大限活かすには、どういう設計にすればいいかなと考えさせてくれるんです。うまく乗っかれたときはメンテナンス性やパフォーマンスという結果もついてきます。そういうところはやっていて楽しい、いいな、今どきだなと感じます。
日高：そのロジカルな設計の良さがあったからこそReactは普及していったということでしょうか。
うひょ：そうですね、理想としては「良いものだから普及したんだ」って言いたいところではありますが、コミュニティが頑張った側面もあります。比較的最近にはコミュニティに向けてドキュメンテーションを充実することにコアチームが取り組んでいます。
顕著に出ているのはReact 18というメジャーバージョンのアルファ版アナウンスのときです。ディスカッション用のリポジトリでQ&Aを準備して網羅的に疑問を解消してくれていたり、あるいはコミュニティからの質問を受け付けたりとか。普及のための活動をかなり頑張っているようでした。
ここ1～2年でReactのドキュメントの多言語化や翻訳も進んでいます。Reactのコアチームとしてもコミュニティに情報を発信していく気持ちが強くなってきているなと思っています。
Reactを取り巻く環境
日高：エコシステムが育ってきているんですね。実はもう一つ会話で気になっていたところがあります。設計が良くても、やはりパフォーマンスが伴わないと使われないんじゃないかと思うんですが……。
うひょ：もちろんReact本体もパフォーマンスにすごい力を入れているっていうのは感じるところですけど、我々がパフォーマンスに力を入れるための道具をちゃんとそろえてくれているなーって印象も強いですね。
日高：それは計測ツールとかですか？
うひょ：そういうツールへのケアが厚いんです。何か作るとき、開発者が何も考えなくても設計に沿えばある程度いい感じにできてしまう側面があるんですが、本当に突き詰めようと思ったら自分たちもパフォーマンスチューニングに取り組まないといけないんですね。
そのときには道具をちゃんとそろえてくれているなというのが、Reactのパフォーマンスへの姿勢に対する自分の印象です。Facebookが用意しているDevToolsだったり、React.memoといった再レンダリングを最適化するためのAPIだったりと最適化をしたいときの手段も手厚い。
聞き手 日高正博
日高：最適化のアプローチがAPIレベルで用意されていると。
うひょ：React.memoだけではなくuse Callback、useMemoといったフックを使うんですが、我々開発者はちゃんと使いこなさないといけない難しさがあって、コミュニティでもいろんな人がいるので議論が巻き起こります。しかしReactは限界まで突き詰めるための道具をちゃんと我々に与えてくれている印象です。
日高：道具があってそれでパフォーマンスを突き詰める、とても楽しそうに聞こえます。実際に試してみて自分なりのベストプラクティスを見つけているんですか？
理論を検証するおもしろさ
うひょ：そうですね。ただ何回ベストプラクティス作ってもReactが天から新しい設計を降らせてくるので（笑）。今だとReact 18のアルファ版の情報が出ているので先にキャッチアップして、こうしたらベストかな？と考えることがあります。
日高：やはり試行錯誤はあるんですね。
うひょ：おもしろい点は、Reactの場合だと情報を見るだけでも考察材料になるんですよ。そこがまたすごいところだと思うんですけども。だから情報を見て頭の中だけで考えてみて論理的に結論付けてから小さいアプリケーションに落としてみるってのが最近は多いですね。
日高：へー。なんとなくうひょさんの持つ論理的なプログラムが好きな性質とうまく噛み合っている気がしてきます。結局、Reactのシンプルな設計って論理的に整合していないと成り立たないんじゃないかなと思いました。
うひょ：はい。将来の話になりますが次のバージョンではConcurrent Renderingを実現したいって2年前ぐらいから言っていて、私はもう今か今かと待ち続けています。コミュニティに理解してもらうには情報だけでも先出しが必要なので、必然的にこちらとしてもベストプラクティスの考察がやりやすくはなるのかなと思っています。
日高：コアチームが中長期の計画も含めて情報を出してチャレンジして、結果を取り込む、その背景が理論的に組み立てられていて説明できるってすごい良いところですね。将来性も高そうです。
宣言的UIの将来性
うひょ：私はReactの将来性はめちゃくちゃ高いと思っています。最近はフロントエンドの宣言的UIのライブラリの分野もまた群雄割拠になってきました。いわゆる3大フレームワークのReact、Vue、Angularに加えてSvelteのような手軽なものも出てきています。後発のライブラリならではの良さもあるんですが、そのうえでReactは独自の良さを出し続けていけるというのが自分の想像ですね。
日高：それは何に起因するのかな……すごい気になったんで続きをお願いします。
うひょ：これまでも宣言的UIやReact Hooksといったブレークスルーを作ってきた実績を知っているので期待しているんですが、Reactのコアが仮想DOMの実装に特化しているなと感じています。周辺のライブラリはサードパーティのものが主流で、ステート管理やルーティングライブラリ、ルーティングってのはURLと画面を対応付けることですね。あとはAPIを呼び出す非同期処理周りのライブラリも、基本的にFacebookのReactコアチームは管理していないんですね。
日高：周辺の部分に関与せずコアだけに注力していると？
うひょ：はい。コアな機能に集中するという点はVueなどとはちょっと違う特徴かなと思っています。もちろんエコシステムを無視するというわけではなく、APIクライアントライブラリのために最適化するためのキャッシュレイヤをReactコアに取り入れたり、ステート管理ライブラリもConcurrent Renderingが入るとReact Reduxがちょっと壊れちゃうのでuseMutableSourceというAPIを新設したりと最低限の変更は入っています。エコシステムと協調するイメージです。これも設計を重視するReactならではだなぁと。
日高：私はモバイルアプリの開発者ですが、宣言的UIを取り入れたパラダイムがどんどん普及してきていると感じます。
うひょ：モバイルアプリは詳しくありませんが、きっとReactのAPIがそのまま移植されているわけではなくて設計の考え方やエッセンスが他分野のエコシステムに影響を与えている気がします。もしそうであれば望ましいブレークスルーですね。概念で新しいものを生み出せていればより広い範囲で影響を与えてくれておもしろいなと。
日高：フロントエンドではすでに起こりつつありますね。モバイル分野でも楽しみです。
うひょ：変化の例ですが、Concurrent Renderingを構成する具体的な要素にsuspenseがあります。これはVueのバージョン3でも実験的に入っています。もちろん具体的なAPIは違っていますが、概念レベルでは同じゴールを向いている。このような影響力が出せているのはReactのすばらしいところです。宣言的UIだけでなく、今後もブレークスルーが続いてほしいという思いがあります。
写真1 うひょさん（左）にはリモートで対応いただきました。
理想を実現する道具
日高：理解が進んだところで、はじめの話題に巻き戻りますが、Reactの宣言的UIという考え方と実現するための仮想DOMの組み合わせはシンプルな設計の最適解なんでしょうか？
うひょ：宣言的UIが何を解決したいかという部分によりますが、スケーラビリティなども対象だと思います。Webアプリケーションの複雑性をReactライブラリなどの中に閉じ込めてしまう。仮想DOMやフックはそのための道具という印象です。
日高：複雑な課題をシンプルになるよう設計に落とし込んでいるんですね。
うひょ：そうですね。設計っていうとアプリケーション開発者が頑張るものだと考えがちなんですが、Reactは良い設計のためのギプスとして機能していると思います。個人的にもReactの設計の良さは発信していきたいですね。
日高：得てして設計の良し悪しは好みで語ってしまうことがあるんですが、言語化されたパフォーマンスであったり生産性であったり、論理的な評価や会話ができるとめちゃくちゃいいですね。
うひょ：今はReactはかなり普及していて、いろんなレベルの人にも使ってもらえているライブラリだと感じます。だからこそ高い理想をバーンと出して俺について来いではなくて、理想を追い求めることを手伝える、吸収してもらえるように私も伝えていきたいと思います。
日高：Reactを使っている当事者だからこそ出てきた言葉という気がします。ほかのフレームワークへも影響を与えているところを見ると、いかにWebやモバイルの体験を良くしていくかという大きなフェーズに変わってきているなと。
うひょ：理解しようとがんばれば応えてくれるライブラリかなと。ReactがWebの中でそのような役割を担っていくと将来、良い体験につながっていくと思います。Reactの設計や先進性が伝わったならうれしいです。
- 特集1
仕様ファーストでいこう！
実践API設計
堅牢で、保守性に優れたWebサービスの実現
- 特集2
はじめての画像回帰テスト
Storybook&Chromaticで品質も生産性も向上！
- 特集3
画像生成AIのしくみ
Stable Diffusionの内部を探る
