Hotwire, Reactにまつわる誤った認識
フロントエンド技術を批判的に、正確に分析する。
- Reactを採用するか、それともERB/Hotwireを採用するかは二者択一ではありません。HotwireのページにReactを埋め込むことは簡単にできます。ERBの開発スピードの速さ、メンテナンス性の高さを生かしながら、Reactをどうしても使いたいところでは使うやり方が合理的です。
- ERB/Hotwireの中にReactを埋め込むことは時代遅れであり、UI/UX的に最適ではないという考え方があります。しかしこれは間違いです。状況次第ですが、むしろERB/HotwireにReactを埋め込んだ方が優れたUI/UXになる可能性があります。UI/UXに大変なこだわりを持つApple社も、Apple Storeの製品選択ページではサーバレンダリングされたHTMLにReactを埋め込んでいます。特に最近のSpeculation Rules APIや
<script>タグのblocking属性を使うと、MPAであってもSPAのsoft navigationを超えるUI/UXが実現できます。
- デザインシステムを活用するにはReactやVue等のモダンフロントエンドで作る必要があるという考えがあります。これは間違いです。デザインシステムは特定フロントエンド技術に閉じ込められるべきものではありません。
- 実際にデジタル庁のデザインシステムはReactとnative HTMLの双方の技術で例を用意しています（アコーディオンの例）。
- 近年ではWeb componentを使ったフロントエンドフレームワーク非依存のデザインシステムが増えています。Web componentはReact, Vue等が不要で、HTMLとvanilla JSだけで作りますので、Hotwireはもちろんのこと、Wordpressなどの従来技術で構築されたウェブサイトでも使用できます。特にLit、Stencil等のライブラリを使って、コーポレートサイト、マーケティングページ、SaaSプロダクト横断的に使えるコンポーネントライブラリが注目されています。
- Reactの方がエコシステムが充実していると言われていますが、Hotwireが不利になることはありません。
- Reactのライブラリの多くは、vanilla JSをラップしているに過ぎません。Reactでなければ実現できないライブラリはほぼ存在せず、Hotwireから使えるvanilla JSのものがベースになっていることが一般的です。
- HotwireのStimulusはvanilla JSのライブラリをラップするのにとても適しています。
- ReactはUIライブラリが充実していますが、AIを使用することで効率的にHotwire化できます。
この点についてはRailsTokyo#4で発表させていただきました。11:30の時点からAIとUIライブラリについて解説しています。
- jQueryなどのレガシーフロントエンド技術をやめて、React等のモダンフロントエンドを採用すれば開発生産性が向上するという意見があります。しかし実際の現場で見る限り、モダンフロントエンドへのリプレイスをした後に生産性が向上すること(例えば機能開発速度が向上するなど)は客観的には確認できません。
- しばしば見落とされるのは、Reactのコンポーネントにデータを渡す前のバックエンド処理、OpenAPI契約、データfetchとエラーハンドリング、認証・認可、ステート管理の負担の大きさです。開発者工数の多くはJSON基礎工事とも言える工程です。ReactはUI/UXに届く前段の負担が大きく、生産性を落としてしまいます。これについてはReactアプリで不要だと感じるもので紹介しています。
- Reactでなければ作れない高度なUI/UXはほぼありません。ReactはあくまでもHTML/CSS/JSを抽象化した薄いレイヤーでしかなく、JavaScriptに独自の機能を追加するものではありません。Reactで作れて、vanilla JSで作れないものは原理的に存在し得ません。
- React/Vueを使わないと実現できないと考えられていたUIが、Hotwire数行で実現できることもあります。React神話、モダンフロントエンド神話を捨てて、Reactが実現するものは何か、JavaScriptで何ができるかをしっかり見つめる必要があります。
これについてはTypeScript vs. ERBの型安全性で解説しています。
TypeScriptだけをいくら使用しても型安全にはなりません。逆にRuby ERBを使用すればほとんど何もしなくても高い型安全性が得られます。
- 理想的なスキーマ駆動開発ができれば、JSON APIが開発初期から固定され、フロントエンドとバックエンドが独立して開発することが可能になりそうです。しかし現実には理想的なスキーマ駆動開発はなかなか実現できません。
- フロントエンドとバックエンドの双方がスキーマを則っていることを担保するために、しばしばスキーマ定義からFE/BEのインタフェースを自動生成したり、自動テストでAPIレスポンスを確認したりします。しかし実際にこのようなレポジトリで開発すると分かりますが、FE/BEの独立性が失われます。遅くともCIの時点でFE/BEがお互いにスキーマに則っていないといけないためです。スキーマに影響がある変更をする場合は、独立した開発は結局できなくなります。