ReactはJavaScriptのフレームワークのひとつで、もともとはFacebookで利用するためにFacebookが開発したものです。

Google製のAngularや、そこから分岐した(というと語弊があるけど)Vue.jsと並び、比較的新しい部類の三大フレームワークに数えられ、数あるJavaScriptのフレームワークの中でもよく使われる部類になると思います。

どのフレームワークにも向き不向きがあり適した用途など考察することもできますが、それぞれについて細かくはここでは触れません。

トレンドの移り変わりが激しいといわれるフロントエンドフレームワーク界隈ですが、2016年以降はわりとこの3つに落ち着いている感じもありますね。

私はReactが一番気に入ってるので、Reactを使っています。

JavaScriptのフレームワークといえば、jQueryが主流の時代がありました。

というか、jQueryは今でも根強い人気があり、未だに新規案件で採用されるなど注目を集めています。

しかし、問題点や課題が多く、いまどきをうたうプロジェクトなどはReactなど新しいフレームワークの採用事例も増えています。

例えば、Qiitaなど。

置き換えられるのだから似てるのかな、と思いきやかなり別物です。

特にふんわり触っているうちは全く別のものに見えると思います。

jQueryはピュアなJavaScriptを拡張するフレームワークというイメージで、アニメーションが得意分野でした。これがReactに置き換えようという流れは、JavaScriptの歴史の変遷と関連があります。

かつてWebサイトといえばサーバからデータをダウンロードしてきて、そのまま表示するだけでした。

時代が変わり、必ずしも静的なWebサイトだけではなくなりました。各ユーザや状態に合わせて動的にWebサイトを書き換える必要が出てきます。

Cookieなどを駆使してサーバサイドでPHPなどを利用する手段もありますが、XMLHttpRequest(Ajax)の登場によってJavaScriptを介してWebサイトがサーバとやりとりすることができるようになりました。これにより、最初のアクセスではWebサイトの中身を受信せず、後からデータを取得する方法も普及していきました。

これを簡単に実装できたのもjQueryが普及した要因の一端だと思います。

しかし、Webサイト(Webアプリケーション)をjQueryで実装するには複雑になるほど読みにくくなるという難点があります。

サーバから取得したデータを対象のDOMに反映するのがjQueryの役目ですが、1つのデータについて、書き換える対象のDOM(HTML)とjQueryのスクリプトと、2か所に記述が必要になります。

1件の修正に対して2か所の変更が必要になり、複雑なアプリケーションになるともうわけがわからなくなります。

ReactはjQueryとはまったく異なるアプローチで、UIをばらばらの独立したパーツ(コンポーネント)として扱います。

細かくコンポーネントを分けることで再利用したり、多層化したりすることができます。

なによりReactによりコンポーネントのスクリプトを1か所にまとめることができ、可読性が格段に上がります。

仮想DOMにより、データの変更したい部分のみ再レンダリングを行うことで、高速化も実現しました。

素晴らしい面が多いReactですが、jQueryに対して面倒な部分もあります。

jQueryは基本的にフレームワークのコードを読み込むことで利用可能で、テキストエディタとブラウザさえあれば開発可能です。

Reactはnpmを導入したりWebpackやトランスパイラなど周辺環境を揃えるのがまず手間です。

しかもプロジェクトの構成には正解がなく、作っているうちにこれは正しいのかなど疑心暗鬼になります笑

複数のファイルをHTMLで読み込むのではなく、webpackやBabelを使ってひとつのファイルにまとめる方法が主流です。

何がいいたいのかわからん記事になってしまいました。

とりとめのない記事なので後でまた書き直せるといいな。