どうしてReactを選ぶのか
私はフロントエンドの開発をしろと言われたらReactを選びます。
これを最初に書くとこの記事を読む必要がなくなってしまいますが、理由を先に書くと、HTML、CSS、JavaScriptが分離しているからです。
これ以降ではReactのほかのメリットやデメリットも書いていきたいと思います。
先に断っておきますが、今回の記事は主観を中心としています。客観的な話も出てきますが、あまり触れません。そのような情報が知りたい方はブラウザの戻るボタンを押したほうがいいと思います。
また、この記事でその他のフロントエンドフレームワークといった場合はVue、Svelteを想定しています。
Reactのいいところ
- HTML、CSS、JavaScriptが分離している
- チュートリアルが優秀
- JSX記法
- 利用者が多いため記事が多い
- TypeScriptと相性が良い
4、5については他の記事を見てもらうことにして、1、2、3について軽く意見を書きたいと思います。
その１ HTML、CSS、JavaScriptが分離している
最初にも書きましたが、これこそがReactを使っている一番の理由です。
ほかのフロントエンドのフレームワーク（VueやSvelte）でよく使われるものって、HTMLにJavaScriptを書けるようにしました！という印象のものが多いです。（正確にはHTMLテンプレート内にJavaScriptを書くらしいです。）
それらのフレームワークが「JavaScriptの記述量を減らす」という目的で作られているためだと思われます。
これはこれでいいとは思いますが、その結果、HTMLの中にJavaScriptを書いているように見えてしまいます。
HTMLは骨格、JavaScriptは変形、と役割が明確に違うものを同じ場所に書くのはそのコードをもう一度変更しようとしたときに原因の切り分けが難しくなると考えています。
「小規模プロジェクト」「個人開発」「短期間」であればそれでもいいのですが、企業で作るシステムではこの部分を意識しないと後で後悔することになります。
一方のReactではJavaScriptしか触らない場合が多いです。（この後にも書きますが、JSXはHTMLではなく、JavaScriptです。）
Reactの目的はUIを簡単に書けるようにするというものです。（正確には「UIを宣言的に記述できるようにする」が近いです。）
これによって、JavaScriptの記述量が増えるという、ほかのフロントエンドフレームワークと真逆の道を辿っています。
その代わりにHTMLをほとんど書く必要がなくなり、コンポーネント（再利用しやすい部品）に分けやすくなり、この機能を修正したかったらここを探ればよい、という原因の切り分けがやりやすくなります。
その２ チュートリアルが優秀
React自体に癖はありますが、優秀なチュートリアルのおかげで学習コストが低くなっています。
チュートリアルが優れている２つのポイントがあります。
- 日本語がかなり自然に近い
- 環境を用意しないでもブラウザ上で試せる
とりあえず、試してみてください。
※昔よりブラウザ上のお試し環境が少し使いにくくなったかもしれません。
※Vue.js、Svelte、Angularもチュートリアルがブラウザ上で試せました。
その３ JSX記法
ここは賛否があるところですね。ただ、これのおかげでHTMLとJavaScriptがしっかりと分離しています。
ただのJavaScriptだとinnerHTMLなどを使うのかもしれませんが、安全性という面ではいまいちですし、巨大なDOMを追加しようとすると文字列が長くなって見にくいです。
JSXを使うことによってHTML操作をわかりやすく書けるようになります。（ただし、HTMLやDOMを直接操作しているわけではないことには注意が必要です。）
たまにJSXが慣れないという声を聞きますが、「JSXはJavaScript」であるということを押さえれば自然と受け入れられるようになるのではないでしょうか？
Reactのよくないところ
もちろん、Reactにはよくないところもあります。
この辺りを克服したフロントエンドフレームワークが現れれば、そちらに移動するだろうと思っているほど、困っているところでもあります。
- 仮想DOMの範囲外であるcanvas、contenteditable属性などが使いにくい
- 癖が強い
useEffect - アップデートが早い
1番だけ言及します。
１. 仮想DOMの範囲外であるcanvas、contenteditable属性などが使いにくい
これ、実は結構深刻です。
Reactは基本的に仮想DOMと連動してDOMが変化します。
この連動の範囲外の動きがかなりきついという印象です。
useRefでできるとは言っても、仮想DOMの管理下にいないとただのJavaScriptと同じですからね。強みは発揮できないということです。
これに関連して、CSSとReactのどちらを使って動きを実装したほうがいいかという問題や、BootstrapなどのJavaScriptを含んでいるフレームワークと相性が悪いため一部分だけReactを利用することが難しいなどの課題もあります。
まとめ
以上を踏まえると、
- 長期的、複数人でフロントエンドの開発をするんだったらReactを選ばざるを得ないよね
- HTML、CSS、JavaScriptが分離していて仮想DOMではないフレームワークが出てきたら移行を検討
というのが私の感想です。
ただし、これらはあくまで筆者個人の感想であるため、鵜呑みにはせず、ほかの方の記事も調べて実際に触ってみて選んでください。
また、Vue.jsを触っていたのが数年前、AngularとSvelteは触ったことがない（チュートリアルだけ眺めただけです）ので、今は改善されているよ！などあれば、教えていただけると嬉しいです。
Discussion
useEffect癖強いはとても同意しました😀
他を使ったことがないので比較できないですが“コンポーネントに分けやすい”は、私も使ってて扱いやすいなと思う理由の一つでした（おかげで認知負荷減らせる）🙌
私は以前Vue3を書いていて今はReact開発しています。
Vueなどのテンプレートでは、HTMLの中にJavaScriptを書いているように見えるかもしれないですが、Reactの場合では逆にJavaScript(JSX)の中にHTMLを書いているので、関心の分離という観点では、個人的にはどちらも対して辛さは変わらないのではないかという印象を持っています。
Vue3でcomposition APIが導入されて、書き味的な所ではReactと大差がなくなったと思いますし、いまなぜReactを選ぶのか？という点に関しては(私は)明確な意見を出せないかもしれない...と感じた次第でした！
なるほど。やはり、Vue3でかなり変わったんですね。
Vue3を触ってみようと思います。情報ありがとうございました。
Vue2以前などのHTMLベースではscriptタグのようなものを用いてコード内にHTML部分と切り離してJavaScriptを記述していますが、
Reactではコンポーネント単位でHTML要素とそれに作用するJavaScriptを記述しています。
そのため、Reactの方がHTMLとJSがより密接しており他UIライブラリ(フレームワーク)で起きがちな「JSがどの部分に作用しているかがわかりにくい」という問題を解決できているように感じます。
これはよくわからなかったです。Vue も Svelte も、コンポーネントの骨格となる HTML とその動きを定義する JS/TS は、「分離性」という観点では React と大差ない書き方では？
そういう意味では React も「同じ場所 (コンポーネント内) に書く」スタイルですよね。基本的にロジックと view を分けて書く点でも React と同じですし
は少なくとも Vue と Svelte に関してはオーバーな表現で、そう言うのであれば React は逆に「JS/TS の中に HTML を書いているように」書くスタイルであることになります (このニュアンスは、
とのことなので両方きちんとキャッチアップしていただければわかると思います)
その上で、とりあえず
の「HTML、CSS、JavaScriptが分離していて」を「React と似たような書き方で」と読むことにすると、Solid ではダメなのでしょうか？
コメントありがとうございます。
とりあえず、Vue、Angular、Svelteあたりは最新の環境で触ってみようと思います。
Solidは知りませんでした。かなり良さそうなので、こちらも触ってみたいと思います。
情報提供ありがとうございました。