「とりあえずReact」から離れてみた話

少し前まで、フロントエンドの仕事が来ると「とりあえず React」だった。

React を選ぶことに疑問を持ったことがなかった。エコシステムが豊富、採用も多い、コミュニティが大きい。選ぶ理由はいくらでもある。むしろ React 以外を選ぶ理由を探す方が難しかった。

でも去年、個人開発のプロジェクトで意図的に「React を使わない」という縛りを設けてみた。それが思いのほか、多くのことを教えてくれた。

Vanilla JS でやってみた

まず試したのは、素の JavaScript だ。

個人開発のダッシュボードツールを、React なしで作ってみた。DOM 操作を手書きし、イベントリスナーを自分で管理し、状態の更新ロジックを自前で書く。

最初は「こんなの面倒くさい」と感じた。React なら useState 一発で済むところを、何行もかけてやっている。

でも、しばらくしてあることに気づいた。「自分が React に何を任せていたか」がはっきりわかるのだ。

仮想 DOM の差分更新、イベントのデリゲーション、コンポーネントのライフサイクル管理。React はこれらを抽象化して隠してくれていた。それが便利である反面、「なぜうまく動いているのか」を理解しないまま使っていたということでもある。

React の「魔法」に頼りすぎていた

React を使っていると、useEffect の依存配列が原因のバグにハマることがある。useMemo を入れるとなぜか遅くなる現象が起きる。コンポーネントが意図せず再レンダリングされる。

これらを「React の問題」として処理していたが、Vanilla JS で基礎を掘り返してみて気づいた。「自分が JavaScript そのものをちゃんと理解していなかった」という点も大きかった。

クロージャ、プロトタイプチェーン、イベントループ。React の抽象の下にあるこれらを、ちゃんとわかっていなかった。

軽量なライブラリの面白さ

Vanilla JS の後、いくつかの軽量ライブラリも試してみた。

Alpine.js はその一つで、HTML に属性を追加するだけで双方向バインディングが動く。React ほどの複雑さはないが、小さなインタラクションには十分すぎるほどだ。このブログに使っているテーマにもインタラクションを足したとき、React を入れるより Alpine.js の方が明らかに適していた。

htmx も面白かった。HTML の属性だけでサーバーとの非同期通信が書ける。SPA をごりごり作る場合には向かないが、既存のサーバーサイドアプリにちょっとしたインタラクションを足す用途なら、JavaScript をほとんど書かずに済む。

React が優れているのは確か

誤解のないように言っておくと、React が優れているのは疑いない。

大規模な SPA、複雑な状態管理、チーム開発での標準化。これらが求められる場面では React の選択は理にかなっている。エコシステムの充実度も、他に比べて圧倒的だ。

私の本業でも React を使っているし、これからも使い続けるだろう。

「問いを立てる」習慣

この実験から得た一番の収穫は、技術を「当たり前」として使わなくなったことだ。

「この案件に React は本当に必要か？」「静的なサイトに SPA の複雑さは適切か？」「ビルドツールのオーバーヘッドを払う価値があるか？」

こういった問いを立てるようになった。答えが「やっぱり React が最適」になることも多いが、問いを立てるプロセス自体が技術選定の精度を上げてくれる。

講師として生徒に教えるとき、「なぜ React を使うのか」を説明できる生徒は少ない。「周りが使っているから」「求人に多いから」という理由は正直なものだが、それだけでは React の設計思想を活かした使い方にはつながらない。

道具は、なぜそれが存在するかを知っていると、はじめて使いこなせる。

「とりあえず React」をやめてみた実験は、私にそのことを改めて教えてくれた。