「Railsを主戦場としている自分が今後学ぶべき技術について」のメモ
View層においてJavaScriptのFrameworkもしくはコードの比重が増えていくとともに、バックエンドまで一気通貫で同じ言語を使用できればいいのにという思想からか、加えてRailsとモダンフロントエンドとの相性がよくないからか、Railsの出番は今後減っていくだろうという意見に対しての賛同が増えてきているのを感じている。
実際のところ、HTMLがサーバーから返ってきて、ちょっとしたインタラクションがある、なんていうシンプルなWebアプリケーションの世界ならば、JavaScriptの存在は「塩」であれたかもしれない2。だが、例えば自分が関わったOOPartsだったり、Webブラウザ上でネイティブアプリケーションのようなリッチな体験を提供したいとなると、RailsはよくてJSONを返すAPI serverとしての立場でしか居られず、フロントでの資産をバックエンドでも使用したいという判断になった場合にはそもそもRubyの居場所が無くなってしまう。
そんなJavaScript優勢となりつつある昨今においてのRailsの優位点のひとつに、世界最強のORMであるところのActiveRecordの存在が挙げられるが、それも前述の記事において触れられているPrismaの出来が良くなればひっくり返る。 言語に関係しないスキルとしては、設計がある。自分はClean Architectureを知らぬ。ActiveRecordに頼り、密結合したMVCばかり書いてきた。conventionに頼ってきたので、いざ自由に書くとなったときに指針が無く、途方に暮れることがままある。アプリケーション単体の設計についてもそうだし、大量のアクセス、大量のデータを捌くためのアーキテクチャというものについても知識が薄い。PofEAAを読み直す時期なのかもしれない。 流行っているからいい、悪いではないとも思いますが、OSS においてはコミュニティの趨勢というのがその言語の価値を決めるとも思っています。一時期、ActionScript の仕事をしたことがあるのですが、自分が触った期間で ActionScript の新しい OSS は一つも出てきませんでした。ベストプラクティスが定まっていない、トレンドの移り変わりが高い昨今の開発現場で、手持ちの弾で正しい設計を導けていないと感じながら、その言語で開発を続けるのは、とても苦しいものがありました。 とくに、開発者コミュニティが評価されている言語で、コミュニティから人がいなくなるのは致命的です。日本だとそこまで感じませんが、何か新しいことを調べる時に、海外コミュニティだと Ruby で書かれたコードはほとんど見かけなくなりました。観測範囲の問題もあるでしょうが…
そのコミュニティの趨勢を決定づけているものとして、自分は型アノテーションの有無があると思っています。 2000 年代に関数型言語周りの型推論の技術が発達し、2010 年代にそれが C#、TypeScript などに応用されていきました。タイプ数が多いから静的型はコード量が多くて不利、という言説は、今では覆りつつあります。それはほぼ古い Java に当てはまる特性です。 個人的には、もう型の静的解析がない言語を日常的に使いたいと思えません。自分が使う TypeScript の型は、ランタイムにおいて存在しない「偽物」かもしれませんが、ドキュメントとして機能して、開発を牽引するという役割は見事に果たしてくれています。
自分の経験上、Rails とフロントエンドがいる組織で、結果として起こるのが、「誰が View を握るのか」という開発者同士の主導権の奪い合いです。Rails エンジニアは生産性の為に ORM とマッピングしたページネーションや Form を生成し、場合によっては多少の jQuery を追加し、リアルタイムなバリデーションやインタラクションを求められるフロントエンドエンジニアは、自分が担当になった瞬間に、それを捨てます。
React のような宣言的 UI のフロントエンドは、テンプレートの生成過程そのものを握る必要があります。Rails で生成した文字列にはその情報が残らないので、それを利用する限り jQuery 的な手続き的な差分処理になり、差分処理による状態遷移の複雑さが閾値を超えた段階で、設計として破綻します。
ブラウザからみたとき、個別のリクエストは単なる HTTP/S なので、それぞれが最適化されていれば、何がバックエンドだとしても理論上同じパフォーマンスは出ます。
ですが、 ここに Rails Way というものが立ちふさがります。Rails Way はその文化として フロントエンドの最適化を内包していないので、フロントエンドの最適化は Rails Way からすると異常なやり方に見えることがあります。これが、 「Rails Way に従わないフロントエンドエンジニア」に見えることがあり、文化的な軋轢を生みます。その環境では、フロントエンドとしては、Rails Way に従わない合理的な理由を説明する必要に迫られます。
フロントエンドからすると、 Rails がフロントエンドの最適化に興味がないので、最適化のヒントが残っていません。なので自力でそれっぽい規約を導入するか、一切を諦めて個別のコンポーネントに徹するか、といった話なります。Rails の規約がある以上、そこに規約を足すとどうしても不自然になります。
Next.js が実践しているフロントエンドのベストプラクティスは、乱暴に要約すると「いかに静的に確定する部分を増やして、それを CDN に置くか」なんですが、Rails は全てのリソースが動的になりうる世界観なので、確定できるものが少ないです。 2000 年代では、Ruby の動的型によるダックタイピングという手法が、当時の Rails においては有効だったように思いますが、TypeScript の柔軟な表現力なら、 Rails を「食える」と思っています。
Next.js は View とルーティングに特化したフレームワークですが、この上に ORM のレイヤーを一つ重ねることで、Rails 相当になる期待感があります。
とはいえ、現状の Next.js のフルスタックフレームワークは全部実験段階です。この段階で Rails を倒せる、というのは、大言壮語であるという認識もあります。
「雑に作っても速度が担保されるアーキテクチャ」こそが目指すべきで、フレームワークというものは、アーキテクチャを表現した実装だと思っています。アーキテクチャの伸びしろを求めると、そこをサポートしない Rails には表現力の限界があると考えるざるを得ません。
そしてその限界が、近年の UX やパフォーマンス指向、Core WebVital による SEO への影響とかち合って来ています。フロントエンド的には、新規に Rails を採用する理由は、既存のエンジニアリソース以外、ほとんどないと言わざるを得ません。
パフォーマンスは贅沢品から、ビジネスを勝ち抜くための必須要件になりつつあります。これについて書くと長くなるので、また今度にしますが、もっというと、 Next.js ではパフォーマンスと生産性は両立します。Rails はそこでパフォーマンスを欠いています。
というわけで、Web に関するものは一旦 Node.js に集約して、その上で Web Assembly の時代がきたら、そこでまた多様性を獲得すればいい、というのが自分の意見です。
まとめ
Rails のフロントエンド周りは限界
Rails は文化的にパフォーマンスに対する指向を持たない
ActiveRecord の賞味期限は Rails と同じ
型による大規模化への伸びしろの有無が決定的な差になってきた
前にも書きましたが、フレームワークや言語は死んでも、そこで培われた思想は残るので…