React

なぜ生まれた？

データが変わるたびに DOM のどこを直すかを手で書き、画面が育つほどコードが込み入った。

何を解決した？

画面を毎回まるごと描くように書かせ、前回との差分だけを React が DOM に当てた。

何を残した？

描き直しの計算は残り、それを省く指定や仕組みが、のちの版の課題になった。

登場

2013年5月29日

作者

Jordan Walke

状態

現役

React が生まれる前

広告部門の BoltJS

React の公式ブログが2016年に振り返った経緯は、Facebook の広告部門から始まります。そこでは社内の MVC フレームワーク BoltJS で、込み入ったクライアント側の Web アプリを作っていました。 記事に載った Bolt のコードは、車輪の数を変える setWheels の中で、表示中の部品を探して中身を書き換えています。データを変えたら、画面のどこを直すかも自分で書く形です。

“But as our applications grew more and more sophisticated, our Bolt codebases got pretty complicated.” （アプリが高度になるにつれ、Bolt のコードベースはかなり込み入っていった）

2013年に React を紹介した公式ブログも、ふつうの JavaScript のアプリでは “you need to look at what data changed and imperatively make changes to the DOM”（どのデータが変わったかを見て、DOM に命令的に変更を加える必要がある）と書いています。 この記事は jQuery の名前を挙げていませんが、jQuery が手軽にした「要素を選んで書き換える」やり方も、この側に入ります。

サーバー側の XHP

一方、Facebook のサーバー側では、2010年ごろから PHP を拡張した XHP が使われていました。PHP のコードの中に XML をそのまま書いて画面を組めるもので、2016年の記事はこう説明しています。

“It was first introduced to help prevent XSS holes but ended up being an excellent way to structure applications with custom components.” （はじめは XSS の穴を防ぐために入れたが、結果として、自作のコンポーネントでアプリケーションを組み立てるすぐれた方法になった）

PHP のプログラムはリクエストのたびにページを頭から組み立てるので、前に返したページのどこを直すかを考えずに済みます。ブラウザの中で長く動く画面では、そうはいきませんでした。

誕生

FaxJS から FBolt、そして React へ

Bolt の弱点を感じた Jordan Walke は、FaxJS という個人の試作を始めました（GitHub のリポジトリは2011年9月19日の作成）。 狙いは Bolt と同じ問題を「まったく違うやり方」で解くことで、props、state、木を評価し直して UI の差分をとること、コンポーネントといった React の基礎の多くがここで生まれた、と2016年の記事は書いています。

2012年3月、Walke はこれを Facebook のコードベースに取り込んで FBolt と名付け、Bolt と共存させて部品を1つずつ置き換えていきました。 やがて Walke と Tom Occhino は名前を React に決めます。その改名のとき、Walke はこう書いています。

“This API reacts to any state or property changes, and works with data of any form” （この API は state や props のどんな変化にも反応し、どんな形のデータでも動く）

なぜテンプレート言語でなく、JavaScript の中に HTML のような書き方（JSX）を混ぜたのか

FBolt が取り込まれる前に、Adam Hupp が XHP に似た書き方を JavaScript で試していましたが、HTML のような記述がすぐに DOM の要素を作るので、議論は innerHTML と createElement のどちらが速いかに集中しました。 React が入ってから、Walke はこの書き方を “simply map xml expressions to function call expressions”（XML の式を、関数を呼ぶ式に置き換えるだけ）にしようと提案します。 できた JSX は、XHP の作者 Marcel Laverdet の js-xml-literal を元にしています。XHP の書き心地を、DOM を直接作らない関数呼び出しとして JavaScript に持ち込んだものです。

2013年の公式ブログは、テンプレートを使わない理由に、JavaScript なら抽象化を組み立てられること、見た目とその処理を同じ場所に置けること、文字列をつなげないので XSS の危険が減ることを挙げ、JSX は使わなくてもよい構文の拡張だとしています。

Facebook の社内の道具を、なぜ公開したのか

2012年、Facebook は Instagram を買収します。Pete Hunt は Instagram の新しい Web チームに移り、サイトをすべて React で作ろうとしました。 Instagram は Facebook の基盤を使っていなかったので React を切り離す必要があり、2016年の記事はこれが公開に要る作業の “forcing function”（推し進める力）になったと書いています。サーバーで描くための renderToString も、このとき Hunt が実装しました。 公開を決めた理由そのものを作者たちが語った文は、見つけられませんでした。 確かめられるのは、Instagram のための作業が公開を可能にした、という経緯です。

2013年5月29日、公開リポジトリに「Initial public release」というコミットが入り、v0.3.0 のタグが付きました。この記事はこの日を登場としています。

なぜ変わった部分だけを直すのでなく、毎回画面全体を描き直すように書かせたのか

2013年のドキュメントは、データが変わると React は「概念上は “refresh” ボタンを押し」、変わった部分だけを更新すると説明し、Reconciliation のページはこれを設計の要に置いています。

“React key design decision is to make the API seem like it re-renders the whole app on every update.” （React の設計の要は、更新のたびにアプリ全体を描き直しているように見える API にしたことだ）

同じページは、これで “This makes writing applications a lot easier”（アプリケーションがずっと書きやすくなる）が、実用になる速さで動かすのはとても難しい課題でもある、と続けています。

render が返すのは文字列でも DOM でもない軽い記述で、React は前回の記述と比べ、最小の変更だけを DOM に当てます。2013年の公式ブログは、この描き直しが TodoMVC で約1ミリ秒と速いので、データバインディングを個別に指定しなくてよい、と書きました。

コードで見る違い

入力欄に書いた項目を一覧に足し、見出しの件数と「まだありません」の表示も合わせて変える処理で比べます。どちらもこの記事のための作例です。jQuery の側は、見出し・一覧・案内の要素を HTML に用意してある前提です。

todo.js（jQuery、2013年ごろ、作例）

$(document).ready(function () {
  var count = 0;
  $('#todo form').submit(function () {
    var text = $('#todo input').val();
    count++;
    $('#todo ul').append($('<li></li>').text(text)); // 一覧に1行足す
    $('#todo .count').text(count);                    // 見出しの件数を直す
    $('#todo .empty').hide();                         // 「まだありません」を隠す
    return false;                                     // フォームを送らない
  });
});

todo.js（React 0.3、作例）

/** @jsx React.DOM */
var TodoList = React.createClass({
  getInitialState: function () { return {items: []}; },
  handleSubmit: React.autoBind(function () {
    var text = this.refs.text.getDOMNode().value;
    this.setState({items: this.state.items.concat([text])});
    return false; // フォームを送らない
  }),
  render: function () {
    var items = this.state.items.map(function (text) { return <li>{text}</li>; });
    return (
      <form onSubmit={this.handleSubmit}>
        <h2>やること（{items.length}件）</h2>
        {items.length ? <ul>{items}</ul> : <p>まだありません</p>}
        <input type="text" ref="text" />
      </form>
    );
  }
});
React.renderComponent(<TodoList />, document.getElementById('todo'));

React の側は、2013年6月のチュートリアル（react-0.3.2）の書き方に合わせ、<script type="text/jsx"> に書いてブラウザの中の JSXTransformer で変換する前提です。 jQuery の側で「削除」を足すと、件数を減らし、0件なら案内を出し直す処理も書き足す必要があります。 React の側では render が「データがこうなら画面はこう」を1か所で書いているので、足すのは state を変える処理だけです。 なお、同じチュートリアルはサーバーとの通信に jQuery 1.5 の $.ajax を使っています。

なぜ広まったのか

最初の評判は芳しくありませんでした。公開1年の公式ブログ（2014年5月29日）は、公開直後の反応を “mostly disapproving first-impressions”（ほとんどが否定的な第一印象）だったとし、こう書いています。

“JSX, in particular, filtered out a huge chunk of potential early adopters.” （とくに JSX が、初期に使ってくれたかもしれない人の大きな部分をふるい落とした）

2013年9月の JSConf EU で、Hunt は「Rethinking Best Practices」と題し、論争を呼んだ3つの判断、「テンプレートでなくコンポーネント」「更新のたびにアプリ全体を描き直す」「仮想 DOM」を扱いました。

実例は早くからありました。2013年の公式ブログは、Instagram の Web が React と Backbone.Router で作った “single page” の Web アプリだと書いています（画面の大部分をブラウザで組む作り方の経緯は SPA の記事で扱います）。 2014年5月には約2,300のコミット、7,000近い GitHub のスターに達し、Khan Academy、New York Times、Airbnb が本番で使っていました。

ライセンスも変わりました。2017年9月22日、Facebook の Adam Wolff は、コミュニティの “several weeks of disappointment and uncertainty”（数週間の失望と不安）を受けて、特許の条項を付けた BSD ライセンスだった React などを MIT ライセンスに改めると発表し、9月26日の React 16 は MIT ライセンスで公開されました。

残した課題と、次に来たもの

本当に「仮想 DOM だから速い」のか

公開1年の記事は、社内で最初に提案されたとき、すべてを描き直して差分をとるやり方で性能が出ると考えた人はほとんどいなかった、と振り返っています。 Walke は「仮想 DOM」の考え方（この名前は当時まだ無かった）を持ち込んで、innerHTML と createElement の性能の議論を脇に置きました。2つの木の最小の差分は O(n³) の問題ですが、2013年の Reconciliation のページは、同じ型の部品は似た木を作る、リストの要素に安定した key を付けられる、という前提で O(n) にしたと説明しています。

Svelte の作者 Rich Harris は2018年12月27日、「仮想 DOM は速い」を神話と呼びました。Harris が引く Hunt の言葉も “React is not magic.”（React は魔法ではない）で、DOM を直接操作すれば React より速くもできると認めています。

	作者側の説明（2013年）	Rich Harris の評価（2018年）
速さ	TodoMVC の描き直しは約1ミリ秒	仮想 DOM の処理は、実際の DOM の操作への上乗せ
全体の描き直し	そう見える API にしたのが設計の要	実際には描き直しを省く shouldComponentUpdate が要る
得たもの	データバインディングを書かなくてよい	状態の移り変わりを考えずに書け、性能はおおむね十分

「毎回全体を描く書き方を楽にし、差分で DOM の操作を減らす」設計で、速さそのものが約束されたわけではありません。

描き直しの仕事を、区切るか省くか

2017年の React 16 は「Fiber」という新しい中核で作り直され、その公開の記事は、描画の合間にブラウザへ処理を返す非同期の描画に取り組んでいると書きました。Harris は、これで仕事は区切れても総量は減らない、と評しています。2022年3月29日の React 18 は、多くの機能を新しい concurrent renderer の上に載せました。 部品の書き方も変わり、2019年2月6日の 16.8 で、クラスを書かずに state を使える Hooks が安定版になります。 2025年10月7日の React Compiler v1.0 は、再計算を省く「メモ化」をビルドの時点で自動で入れる道具です。人が書いていた「描き直しを省く指定」を、道具が受け持つ方向に進んでいます。

最初の HTML をどこで作るか

2013年の公式ブログは、すでに SEO や性能のためにサーバーで React を動かせると書いていました。 最初の HTML をブラウザとサーバーのどちらで作るか（CSR・SSR）、サーバーの HTML に JavaScript をつなぎ直すハイドレーション、それらを受け持つ Next.js のようなフレームワークは、別の記事で扱います。

2026年10月時点の立ち位置

2026年10月時点で最新の版は、10月14日に公開された 19.3.1 です（npm の latest。10月29日に確かめた）。19 系の最初の版は2024年12月5日の公開でした。

持ち主も変わりました。2025年10月7日に Linux Foundation が React Foundation を作る意向を発表し、2026年2月24日に財団が発足しています。公式ブログは、React、React Native、JSX が “no longer owned by Meta”（もう Meta の所有ではない）と書きました。

指標	数字	出典
この1年に React で本格的な開発をした回答者（全回答者）	44.7%	Stack Overflow Developer Survey 2025
同じく（プロの開発者）	46.9%	同上
JavaScript のライブラリがわかるサイトのうち React を使う割合	8.0%	W3Techs（2026年10月29日）
すべての Web サイトのうち React を使う割合	6.0%	W3Techs（2026年10月29日）

Stack Overflow の全回答者の表では、Node.js（48.7%）に次ぐ2番目でした。 開発者の調査では上位にある一方、動いているサイトの数では、同じ W3Techs で 64.3% の jQuery と大きな差があります。

まとめ

• Facebook の広告部門では、BoltJS の画面が育つにつれ、DOM のどこを直すかを書くコードが込み入りました。サーバー側では PHP の XHP で部品を組めていました。
• Walke の FaxJS が FBolt を経て React になり、XHP の書き方を関数呼び出しにした JSX が加わりました。Instagram のための切り離しを経て、2013年5月29日に公開されました。
• 「毎回全体を描くように書き、差分だけを DOM に当てる」設計は、JSX とともに最初は疑われましたが、1年で本番の実例が増えました。
• 描き直しの計算は残り、shouldComponentUpdate・Fiber・React Compiler と扱い方の工夫が続いています。最初の HTML をどこで作るかは CSR・SSR・ハイドレーションの議論に引き継がれました。
• 2026年10月時点で最新は 19.3.1 で、React は React Foundation に移りました。Stack Overflow の2025年の調査では回答者の 44.7% が開発に使っています。

年表

1. 2011年9月19日

   Jordan Walke の FaxJS のリポジトリが GitHub に作られる github.com

2. 2012年3月

   Walke が FaxJS を Facebook のコードベースに取り込み、FBolt と名付ける（のちに React と改名） legacy.reactjs.org

3. 2013年5月29日

   公開リポジトリに最初のコミット「Initial public release」が入り、v0.3.0 のタグが付く api.github.com

4. 2013年6月5日

   Pete Hunt が公式ブログに「Why did we build React?」を書く legacy.reactjs.org

5. 2017年9月26日

   新しい中核「Fiber」で作り直した React 16 が、MIT ライセンスで公開される legacy.reactjs.org

6. 2019年2月6日

   React 16.8 で、クラスを書かずに state を使える Hooks が安定版になる legacy.reactjs.org

7. 2022年3月29日

   新しい concurrent renderer の上に機能を載せた React 18 が公開される react.dev

8. 2025年10月7日

   React Compiler v1.0 が公開され、Linux Foundation が React Foundation を作る意向を発表する react.dev

9. 2026年2月24日

   React Foundation が発足し、React・React Native・JSX が Meta の所有を離れる react.dev

系譜

前

• 課題jQuery2006年1月
• 課題SPA2003年5月16日
• 影響元PHP1995年6月8日

後

• 発展ハイドレーション2013年1月30日
• 発展Next.js2016年10月25日

この技術が出てくる物語

• サーバーとブラウザの振り子

同時代の出来事

• 2013年1月30日ハイドレーション

出典

1. 一次Why did we build React?（Pete Hunt, React Blog, 2013-06-05） legacy.reactjs.org
2. 一次Our First 50,000 Stars（Vjeux, React Blog, 2016-09-28） legacy.reactjs.org
3. 一次One Year of Open-Source React（Cheng Lou, React Blog, 2014-05-29） legacy.reactjs.org
4. 一次Community Round-up legacy.reactjs.org
5. 一次Why React?（React のドキュメント、2013年7月時点） facebook.github.io 保存版
6. 一次Tutorial（React のドキュメント、react-0.3.2、2013年6月時点） facebook.github.io 保存版
7. 一次Reconciliation（React のドキュメント、2013年12月時点） facebook.github.io 保存版
8. 一次facebook/react の v0.3.0（GitHub API） api.github.com
9. 一次jordwalke/FaxJs（GitHub） github.com
10. 一次Relicensing React, Jest, Flow, and Immutable.js（Adam Wolff, Engineering at Meta, 2017-09-22） engineering.fb.com
11. 一次React v16.0（Andrew Clark, React Blog, 2017-09-26） legacy.reactjs.org
12. 一次React v16.8: The One With Hooks（Dan Abramov, React Blog, 2019-02-06） legacy.reactjs.org
13. 一次React v18.0（React Blog, 2022-03-29） react.dev
14. 一次React v19（React Blog, 2024-12-05） react.dev
15. 一次React Compiler v1.0（React Blog, 2025-10-07） react.dev
16. 一次Linux Foundation Announces Intent to Launch the React Foundation（Linux Foundation, 2025-10-07） linuxfoundation.org
17. 一次The React Foundation: A New Home for React Hosted by the Linux Foundation（Matt Carroll, React Blog, 2026-02-24） react.dev
18. 一次npm registry（react） registry.npmjs.org
19. 二次Virtual DOM is pure overhead（Rich Harris, 2018-12-27） svelte.dev
20. 二次Stack Overflow Developer Survey 2025（Technology） survey.stackoverflow.co
21. 二次Usage statistics and market share of React for websites（W3Techs, 2026-10-29） w3techs.com