Reactの概要と特徴
こんにちは、OSSのレキシラジオです。
この番組は、現役エンジニアであり、
なんとここ2ヶ月のダイエットで7キロの減量に成功した私、hentekoが、
毎週1つのOSSプロジェクトを取り上げ、
そのプロジェクトにまつわる歴史やドラマを紹介していく番組になります。
7キロ痩せるとですね、目に見えて変わるもので、
ギリのお母さんから痩せ種なんて褒められたり、
前から家庭内で問題だったいびきの騒音問題も少し改善したようで良かったです。
やっぱり健康っていうのは大事かなと思いました。
さて、そんな話はさておき、今週のテーマは、
フロントエンド間への巨人、Reactの歴史についてです。
今や当たり前のように使われているReactがですね、
どのように生まれ、どのような困難を乗り越えて標準の座を勝ち取ったのか。
それでは見ていきましょう。
まずはReactの概要からおさらいしましょう。
ReactはWebアプリケーションのフロントエンド、
つまり画面の見た目や動きを作るためのライブラリーです。
現在では事実上の標準として扱われていて、
ディファクトスタンダードといっても過言ではないような存在かなと思います。
Reactの最大の特徴としてはコンポーネントというような考え方です。
ボタンやフォームといったUIの部品を機能ごとのコンポーネントという単位でまとめて、
パズルのように組み合わせることで画面というのを作れることができます。
これによってですね、構造の再利用性が高まり、
開発効率が積極的に向上するというような結果になりました。
React誕生の背景
このReactの開発元は現在のメーター社、当時のFacebookですね。
もともと彼らは社内ライブラリーだったんですけど、
2013年にオープンサースとして公開がされました。
それまではですね、フロントエンド開発というのはシステムが巨大化すればするほど、
どこを直せばどこが壊れるかわからないというようなカオス状態というのが続いていました。
というところにReactというライブラリーが現れて、
コンポーネントという概念で地図をもたらしたというような、
まさに旧選手のような存在かなと思っています。
ではここからは、なぜReactが生まれたのかというところのお話をしていけたらなと思います。
時は遡って2010年頃ですね。
当時のFacebook社というのは深刻な課題を抱えていました。
ユーザーが急増して機能がどんどん増えていく中でですね、
フロントエンドの行動の複雑さというのが爆発していきました。
この当時、2010年代の初頭のフロントエンド開発主流というのは、
JQueryというようなライブラリーでした。
このJQueryを使ってDOMを直接操作し、ページに動きというのをつけていたというような形です。
でもですね、Facebookのような常に新しい投稿が流れてくる、
かつ大規模かつ動的なアプリというのはですね、
このやり方というのはかなり限界に来ていました。
一番の問題点というのは予測不可能性です。
データの変更がですね、画面のどこに影響するのかというのが、
エンジニアですら把握しきれないというような問題がありました。
通知を消したはずなのに消えないだったりとか、
メッセージが古いままみたいな、そんなバグが頻発するような状況というのが当時でした。
そんな中ですね、解決の糸口というのは意外にもサーバーサイトから見つかりました。
Facebookにはですね、XHPというBHPの拡張機能を使っているようなところがあったんですけど、
このXHPというのが、BHPのコードの中にHTMLタグを直接書けるようにしたもので、
こういった形でBHPを使って、安全かつ再利用可能なUIコンポーネントというのを作るための仕組みとして、
XHPというものを使っていました。
あるときふとですね、これもしかしたらクライアントサイド、
つまりJavaScriptでも同じことができるんじゃないかというような考えがエンジニアたちの中でありまして、
2011年にはですね、FAXJSというプロトタイプというのを開発しました。
これが直接のリアクトの祖先になります。
ここではですね、彼らはとんでもなく大胆なアイディアというのを実装したんですけど、
それというのが、状態が変わったなら細かいことを言わずに、
もうUI全体を作り直せばいいじゃないかというような大胆な発想でした。
これというのが、実はサーバーサイドのレンダリングと全く同じような考え方ですね。
それというのをブラウザの中でやろうとしたというところが革新的なところでした。
そうすればですね、複雑な状態管理というのは不要になります。シンプルになります。
なので、バグというのが極力少なくなるんじゃないかというような考え方でした。
Reactの進化と受け入れ
でもですね、毎回画面全体を作り直していたら動作というのが重すぎて、
ブラウザで動作できなくなってしまう、使い物にならなくなってしまうというような懸念点ももちろんありました。
そこで登場したのが、仮想ドーム、バーチャルドームと呼ばれるものですね。
これがどういうものかというと、メモリ上に軽量なコピーを持って
変更前と変更後のUIの差分だけを計算し、必要な箇所だけをアップデートするというような
差分検出というような技術です。
これによってですね、パフォーマンスと開発のしやすさというのを両立させることに成功しました。
このFAX.jsというものがFacebookのニュースフィードなどに実験的に導入されるんですけど、
そちらの成功をもってこのFAX.js、こういった考え方というのの実証がされて、
ついにですね、2013年にはREACTという名前で全世界にオープンソースとして公開がされました。
さて、そういった形でREACTというのは誕生したんですけど、公開当初ですね、
どういった反応だったのかというとですね、正直言って最悪でした。
なぜならですね、当時のベストプラクティス、フロントエンド開発のベストプラクティスとしては
関心の分離というものがありました。
HTMLとCSS、JavaScriptというのはそれぞれ別のファイルに分けて書くというのが定義だと信じられていたというところがあります。
ところがですね、このREACTというのはJSXという新しい公文を使って
JavaScriptの中にHTMLタグを混ぜるということを推奨しました。
先ほどのXHPと同じような形ですね。
当時のエンジニアたちはですね、このJSXというのを見て、なんだこれは気持ち悪いというような形で反発したわけです。
これに対してですね、FacebookのREACT開発チームというのはこう反応しました。
ファイルを分けているのはただの技術の分離。
ファイルタイプによって分けているだけであって、それというのは本当の意味での関心の分離ではない。
UIの見た目とロジックというのは密接に関わっているわけなんだから、
コンポーネントという単位で一つにまとめるというのが真の関心の分離だというような形で反応をしました。
これは結構かっこいいですよね。
最初はこの考え方というのは実は受け入れられなかったんですけど、
実際に使ってみるとですね、報酬性が高いことが分かったりして、
時間をかけて現代のスタンダードとして定着するというような形になりました。
さてそこからのREACTの進化というのを止まることは知りませんでした。
Facebookの記録にしても通知アイコンが消えないというようなバグがあるんですが、
こちらを解決するために提唱されたのがフラックスアーキテクチャというものです。
このフラックスアーキテクチャはどんなものかというと、
考え方はシンプルでして、データは常に一方通行で流れるというような考え方です。
どういうことかというと、ユーザーのアクションが起きて、
それに伴ってディスパッチャーを通って、ストアが更新され、ビューが変わるというような一方通行の流れです。
この一方通行のルールによってデータの流れが完全に予測可能になることになります。
こういった形でデータの流れが基本的な一方通行になっているとですね、
どこで何が更新されてどう変わったのかというところがかなり追いやすくなったというようなものです。
この考え方、実はフラックスという名前のアーキテクチャなんですが、
フラックスという同名のライブラリーも存在していました。
現在ではアーカイブされているんですが、存在していました。
リアクトの進化と新技術
というのは、Facebookチームの方で開発された参考実装みたいな形なんですが、
基本的にフラックスのライブラリーを使うというよりも、
他のライブラリーを使ったり、もしくは自作するみたいなのが当時の流れでした。
そういったフラックスというものが現れるんですが、
後に考え方として、さらに洗練されたリラックスというライブラリーとして実装されて変わっていきます。
このリラックスの登場によって、リアクトとリラックスを使う、
組み合わせた使い方というのがかなり一般的になりました。
さらに2015年にはリアクトネイティブというものが登場します。
かつてFacebookではネイティブのモバイルアプリ、iOS、Androidのアプリというものは持っていなくて、
正確には持っていたんですけど、その中身というのがWebViewで開発されたWeb技術、
HTML5などで作成されたWebアプリとして構築されたものでした。
そういったものが、なかなかネイティブと比べてしまうとパフォーマンス面で劣っていたりというような形で、
Facebook自体の利用というのがどんどん低下していくような流れになってしまいました。
これについてですね、FacebookのCEOであるマーク・ザッカーバーグはですね、
モバイルアプリというのをHTML5で作ったというのが最大の会社としての失敗だったというような形で語っています。
ただですね、ここからモバイルアプリというのをFacebookが諦めるという話ではありません。
社内のハッカソンで、JavaScriptでネイティブのUIというのを操作できないかというような実験というのが行われました。
これによってですね、わずか2日間でプロトタイプというのが開発されました。
これによってWebアプリですね、リアクトネイティブとして名前を変えて登場するんですけど、
リアクトのコンポーネントを使ったまま、Webエンジニアがそのままの知識でですね、
リアクトの知識を使ったままサクサク動くようなネイティブアプリというのが作れるというような形になりました。
さて、そんな形でどんどん進化していったリアクトなんですけど、
10分満杯に見えるようなリアクトなんですが、2017年にはですね、危機も訪れました。
それがライセンス問題です。
もともとFacebookではですね、特許訴訟の対策として入れていた独自の情報というものがリアクトのライセンスにはあるんですけど、
それの中身というのが、リアクトを使うとですね、将来Facebookと訴訟などで争ったときに、
リアクトの使用ライセンスというのは白雑されるリスクがあるというような情報が盛り込まれていました。
これはですね、大企業とかあとはアパッチ財団から問題視されるというような形になっていました。
さらにですね、ワードプレスなどがリアクトの使用をやめるというような発表をするなどをして、
ビュージェイスなどの他のライブラリへの乗り換えのムードというのが一気に高まってくるというような形になっていました。
しかしですね、ここでFacebookというのは迅速に動きます。
2017年の9月に特許条項のない標準的なMITライセンスへの変更というのを発表することになりました。
この英談によってですね、法的な懸念は一掃されて、リアクトというのは現在の不動の地を確立することになります。
リアクトサーバーコンポーネントの脆弱性
さて時は戻り、2020年代中盤、現代ですね。
最近のリアクトのトピックといえばリアクトサーバーコンポーネントです。
これはですね、どういったものかというと、今までリアクトというのはクライアント側でやっていたレンダリングをしていたんですけど、
これをサーバー側でやってしまうというような技術です。
これは何が嬉しいかというとですね、クライアントサイドでレンダリング、リアクトのコンポーネントでレンダリングした際に、
一緒にバックエンド側のAPIを叩いてデータをフェッチしてきて、そのデータを持ってコンポーネントのレンダリングをする、
みたいなことをしていたんですが、そちらのバックエンド側のAPIというのをコンポーネントないから、
バックエンド側でレンダリングすることによって、APIを叩く手間というのが省けて、非常にいいよね、みたいなような機能なんですが、
こちらについてですね、リアクトサーバーコンポーネントに関しては、つい最近深刻な脆弱性が発見されてしまいました。
通称リアクトトゥセルというような名前で呼ばれているんですが、CVE番号としてはCVE-2025-55182です。
この脆弱性に関してなんですけど、危険度は間違いなくMAXの脆弱性です。
これはどんな脆弱性かというとですね、攻撃者がクライアントから採掘したようなデータを送ってしまうと、
サーバー上で任意のコードが実行できてしまうというような、本当に極めて危険なものです。
こちらの脆弱性に関して発見されたのは、つい先日の2025年の11月の29日です。
原因というのは、データのシリアライズ・デシリアライズ時の検証の不備というものがあったんですが、
ただですね、ここでもリアクターの開発チームというのの対応はかなり迅速でした。
発見されたのが2025年の11月29日だったんですが、11月30日翌日ですね、翌日には修正の方を開発を開始し、
12月3日にはですね、修正バージョンの公開というところまで行きました。
もしですね、リアクターサーバーコンポーネンツを利用しているようなシステムというのを運用している方がいればですね、
今すぐ、本当に今すぐ関連ライブラリのアップデートや確認というのをしてください。よろしくお願いします。
さていかがだったでしょうか。社外ツールのプロトタイプから始まって、常識への挑戦や炎上、ライセンスの問題、
そして最新の脆弱性の対応まで、リアクターの歴史というのはいろいろな歴史があるなというような形だったんですけど、
まさにですね、課題解決と進化というのの連続でした。
だからこそ、これだけ長く愛されて共通でやり続けているのかもしれないなと思っております。
さて今回のお話は以上なんですが、もし今回のお話が面白かった、役に立ったと思ったら、お聞きのプラットフォームでの高評価とフォローの方をお願いします。
また、Xなどでハッシュタグ、シャープOSSの歴史ラジオをつけて感想をつぶやいてもらえると励みになります。
次回はですね、終わりのない宗教戦争、エディタ戦争でおなじみのビムの歴史について見ていけたらなと思います。
ビム派の方も、EMAX派の方もお楽しみにしてください。
それではまた次回会いましょう。バイバイ。
