Rails7がもつフロントエンドへの「答え」

Rails7のアルファ版がリリースされました。
https://weblog.rubyonrails.org/2021/9/15/Rails-7-0-alpha-1-released/

最近、Railsニューリリースの記事をみてもテンションがあがらなかったのですが（個人開発ではもっぱらNext.jsとかFlutterのお世話になってました）、下記のDHHによるデモが久々に 「Railsっていいかも」 って思える内容だったので、背景も含めて解説します。

https://www.youtube.com/watch?v=JsNtLiph87Y

Railsの存在意義

みなさんは、どうやってRails使い始めましたか？ 自分はRails3.1あたりで独学でウェブアプリ開発をはじめました。そのときに「簡単に始められて」「ビジネスロジックが増えても生産性が落ちない」 というあたりで、他に浮気する理由がなかった、というのが私の理由です。

それから数年が経ちますが、最近のRailsのアップデートは Basecamp(Railsの基となった製品)が必要としている機能がポートされているだけ という印象でした。

アプリケーションの複雑さがフロントエンドに移行する中で、Railsは最適解を見つけられていなかったように思います。

Webpackerどうよ？

Webpackerはその試行錯誤の一つで、「RailsがWebpackをまるまるっと覆っただけ」の構成でした。Webpacker -> Webpack -> NPM librariesという不必要に長い依存関係を発生させるものとして、敬遠していた人も多いのではないでしょうか。（このあたり、自分の経験が少ないのでどなたか補足コメントいただければありがたいです）

冒頭の動画の中で、DHHは「フロントエンド、ブラウザまわりの環境が成熟してきた」ことを理由に、Webpackerから別れをつげます。

もっとも大きな理由として3点。

1. レガシーブラウザの絶滅 - IEのサポートが来年に正式に終了します。ユーザーサポートの観点で、ES6をビルド（transpile）する理由が無くなりました。
2. HTTP2のおかげで、Asset packagingの理由がなくなる - Http1で複数のJS/CSSファイルを送るのはパフォーマンスを低下させる大きな原因でした。
3. Import Mapを使えば、ES Moduleがブラウザネイティブで使える。

この着眼点をみて、DHH・Railsが求めるものは 「Nodeに依存しないフルスタック開発」 であることがわかります。「Node moduleはどうするの？」ということに関しても、彼は「https://unpkg.com/ 等のCDNを使えば良いでしょう」と言っています。

Nodeレスに移行するまでのつなぎとしての "bundling-rails" gem

とはいっても、いきなりその世界観に移行するのには抵抗があります（会社でサービス開発してたら、CDN導入とか大変ですよね）。 それまでの答えとして、彼は https://github.com/rails/jsbundling-rails と https://github.com/rails/cssbundling-rails を紹介しています。

これは、Railsの魅力であるところの「設定より規約」を達成するための薄いブリッジライブラリです。Tailwindやesbuildなどを別プロセスで動かし、そのビルド結果を app/assets/builds 以下に書き出すことで、RailsのAsset pipelineの使い心地 を提供しようというものです。

この設定より規約（Convention over Configuration）の世界観が、DHHが絶対に手放したくないRailsのUX だという印象が強く伝わりました。

今後のRails

とりあえず、「サーバーサイドロジックがある程度複雑化することが見えている」アプリケーションのプロトタイピングは、Railsが培ってきた文化にぴったりハマるでしょう。コミュニティが注力すべきオーディエンスも、そこにあると思います。

サービスとしてスケールし、その先のRails * フロントエンドの付き合い方で一番本質的な記事は
https://zenn.dev/mizchi/articles/d33a4174cca886#フロントエンドパフォーマンスと-rails-way だと思っていて、これはもう「組織の問題」だと思っています。

現在自分は Shopify という世界でもっともでかいRailsモノリスを持つ会社で働いています。もしも誰かがチームとユースケースを明らかにせず「RubyなのかGoなのかRustなのか」「HotwireなのかReactなのか」という議論をするならば、それは片手落ちです。そういった技術スタックだけに終始した議論が盛り上がることはまずありません。（社内のSlackで観測できる範囲）

その組織がそれまでに培ってきた「資産と負債がごちゃまぜになったコードベース」を正確に理解し、エンジニアとプロダクトのロードマップを策定、実行することが正しいアクションです。

Takeaway

ということで、伝えたいことは

• Railsがオワコンという戯言には惑わされなくてよい。
• Rails７でフルスタック開発はまた楽しくなりそうなので、個人開発・０からサービス立ち上げる人は捗りそう。
• ブラウザが何を可能にするのか、ユーザーは何を求めているのか、というところに常に立ち返るべき（そこらへんに言及するDHHは偉いなぁ）

あたりです。RubyやRailsを触らない人でも、こういったフレームワークの技術選定の立ち回りは参考になると思います。ウェブアプリ開発者同士、仲良くしましょう :) Happy Coding!