kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

Rails7のフロントエンドの方向性について理解したことをメモ

Rails

ざっくりまとめ

  • Rails7は、StimulusとTurboのHotwireを標準のjsとしているが、jsまわりのトレンドとは方向が異なる
  • Railsでリッチなフロントエンドをバリバリやるのは難しく、そのあたりの不満がフロントエンド側から表出している
  • Railsは(最初から)、小さいチームによるフルスタック開発のためのフレームワークと表明しており、リッチなフロントエンドをバリバリやることは目指していない

ソース

techfeed.io

👆 DHHによる、「Rails 7は、2021年以降のJavaScriptに対する3つの素晴らしい答えを出すだろう」 の翻訳記事

Railsは当初からフルスタックである。
Rails 7では、JavaScriptに3つの明確な選択肢が用意されている
Hotwireとimport mapsを使ったデフォルトの道。
人気のあるJavaScriptバンドラーの1つとの薄い統合を使った代替の道。
そして最後にフロントエンド用の別のリポジトリを使った厳格なAPIの道。
最後に、Railsを単にAPIとして使用するという選択肢もある。
それを利用するSPAは、まったく別のプロジェクトとリポジトリに置いておく。
Railsは長い間、--apiでこの道をサポートしてきて、これからもそうしていく。
小中規模のチームにはお勧めできない方法だが、フロントエンドとバックエンドの間に高い壁を設けてSPAを作ることに専念している大規模な組織の中にいる場合は、意味のある方法かもしれない。

　

　

kenzoblog.vercel.app

StimulusやHotwireなども少し学習で触りましたが、それなりに学習コストがかかるので、Rails7の上でDHHが推しているJavaScriptの書き方でやっていくと、「Railsの上ではJavaScriptが書ける」みたいな状態になりそうに思います。

DHHの推奨するRailsでのjsに特化しちゃうとキャリアが狭まりそうだよねというのはすごく分かる

　

　

blog.unasuke.com

View層においてJavaScriptのFrameworkもしくはコードの比重が増えていくとともに、バックエンドまで一気通貫で同じ言語を使用できればいいのにという思想からか、加えてRailsとモダンフロントエンドとの相性がよくないからか、Railsの出番は今後減っていくだろうという意見に対しての賛同が増えてきているのを感じている。

今のトレンドである(と思われる)リッチなUXを提供するには、Railsは無用なものになってしまうのでは? という危機感の記事

　

　

zenn.dev

Rails のフロントエンド周りは限界
Rails は文化的にパフォーマンスに対する指向を持たない
ActiveRecord の賞味期限は Rails と同じ
型による大規模化への伸びしろの有無が決定的な差になってきた

　

　

okuramasafumi.hatenablog.jp

👆 Railsはスケールしない個人開発レベルのプロジェクトで強みが活かせるというお話

スケーラビリティが不要なアプリケーションをスモールチームで開発するためのフレームワークがRails
そこ(個人開発の場)では「フロントエンドの最適化」よりも「いかに仮説を検証するか」が重要であり、Railsが提供する高速な開発が重要な意味を持ちます。Railsのエコシステムにより各種実装を省略できることもまた重要です。
Railsに欠けているものは詰まるところ「段階的なスケーラビリティ」に尽きるのではないかと私は考えています。

ぼんやりした感想

  • Railsは、SPAみたいなバリバリのjsではなく、ページの一部をちょっと動的に動かせれば(ほとんどのユースケースで)十分では? というスタンスっぽい
  • そういう意味では、一般ユーザをメインにする最近のwebサイトよりは、業務システムみたいなものの方がRails向きなのかもしれない
  • この辺の方針は理解できるし、個人や数人で全部やる系のシステムではそれで良さそう
  • ただし、StimulusとTurboのHotwireが、フロントエンドとしてのキャリアパスとしてひらけているの? といったら疑問が残るので、バリバリフロントやりたい! って人には向いてなさそう
  • フロントと、バックエンドでチームが明確に分かれてしまっている会社の場合、APIサーバとして使えば良いけど、Railsの良さは活かせないよ? というのがDHHのスタンス
  • そういう場合、Rails以外を選ぶのも良いのかもしれない
  • はてブで指摘があったけど、RailsとDockerとの相性の悪さはめっちゃ理解できる。 bundle install が手間ですよね...

フルスタックRailsを選んだ場合のチームビルドについて

  • 別にチームのキャリアパスとして、フロントエンドとバックエンドが別れてしまっている場合、フルスタックRailsを選択するのは、スピードが得られる代わりにフロントエンド側に多大な負担をかけるよなぁという気持ち
  • フルスタックRailsという選択肢が現状では、フロントエンドのキャリアを閉ざしてしまうので、福利厚生としてよろしくない
  • フルスタックRailsやるんなら、サーバサイドがキャリアの主軸で、フロントもちょこちょこいじれます! って人が良いんだろうなぁ...

自分はどうしましょう

  • なんやかんやで、Railsはまだ残り続けると思うので、それらをメンテナンスするスキルはしばらく腐らなそう。Railsやgemのバージョンアップとか。そのへんは磨き続ける
  • Rails以外のAPIを提供のトレンドを知っておきたい
  • 転職してからインフラに軸足が移りつつあるので、今の所焦燥感は無い
  • フロント側もうすこし勉強しないとな...