あなたはRailsをうまく使えていない
(bananacurvingmachine.com)- Rails 8とViteの統合をめぐる2人の開発者の会話を通じて、不必要に複雑化した現代のWeb開発環境を風刺している
- 1人は Vite, React, Babel, Tailwind, Docker, Husky など数多くのツールを追加し、「モダン」なスタックだと主張する
- 一方でもう1人は、何の設定もなく 素のRailsだけで即座に動くアプリを見せ、シンプルさの効用を示す
- 複雑なツールチェーンに依存する現在の状況を皮肉り、**「とにかくRailsを使え」**というメッセージを強調しながら、シンプルさの美徳を思い出させる
- Rails本来の目的だった 生産性、一貫性、開発の楽しさ が忘れられつつあることを指摘する
> “Just F#$%^& use Rails”
原文の会話翻訳
Kevin: おい、Rails 8向けのVite使ってみた？ めちゃくちゃ速いよ。
John: 聞いたことはある。ビルドツールだろ？ Railsにはもうそういうのがあったんじゃないの？
Kevin: あったよ。でもViteのほうがもっとモダンなんだ。Nodeとnpmを入れて、いくつかスクリプトを設定する必要はあるけど、それだけの価値はある。
John: ちょっと待って、Railsって今はNodeが必要なの？
Kevin: うん、Reactを使うならね。今どきみんなReactを使うだろ。
John: Railsにそういうの、なかったっけ？
Kevin: あったけど、今はReact Refreshと一緒にViteを使わなきゃいけない。そうするとコンポーネントが即座にリフレッシュされる。TypeScriptを使うなら、その設定も必要だし。
John: 聞いてるだけで複雑そうだな。
Kevin: いやいや、大したことないよ。Babelを入れて、.babelrc を設定して、vite-plugin-ruby を追加して、スタイルはPostCSSを使えばいい。
John: PostCSS？
Kevin: そう。それにもちろんTailwindも使わないと — まさかCSSを一つひとつ手で書きたいわけじゃないだろ。
John: そりゃそうだ。
Kevin: その次はESLintとPrettierでコードを整えて、コミット前にHuskyでフックも仕込めば完璧。
John: じゃあ、Vite、React、Babel、PostCSS、Tailwind、ESLint、Prettier、Husky。これで全部？
Kevin: ほぼね。サーバーサイドレンダリングまでやるならNext.jsかRemixを使わないと。
John: ちょっと待って、まだRailsの話をしてるんだよね？
Kevin: もちろん。今はハイブリッドスタックが主流だからね！ JavaScriptフレームワークなしでリアクティブなコンポーネントを使いたいなら、StimulusReflexやHotwireも悪くない。
John: StimulusReflex？ マーベルのキャラクター名みたいだな。
Kevin: はは、本当にあるんだよ。リアルタイム更新用さ。ただ、ActionCableの設定が必要だし、Redisもいる。
John: Redis？
Kevin: そう、pub/subレイヤーが必要なんだ。心配しなくていい、Dockerコンテナをもう1つ立ち上げればいいだけ。
John: Dockerも使わなきゃいけないの？
Kevin: もちろん。依存関係を分離するには必須だよ。完全な環境再現のためにはDocker ComposeとFly.ioへのデプロイ、GitHub Actionsでパイプラインも回さないとね。
John: それは…かなり複雑だな。
Kevin: ただの現代的なWeb開発だよ、友よ。シンプルだろ。君は何をやってるの？
John: ただ触ってるだけ。
(Johnがコマンドを1つ実行する。アプリは即座に起動する。フォームも動き、読み込みも速く、画面遷移も電光石火だ。)
Kevin: うわ、かなり複雑そうに見えるけど。スタックは何を使ってるの？
John: ただの（Vanilla）Rails。
> Just F#$%^& use Rails.
3件のコメント
私はどちらも大好きなツールです。2つのツールはエコシステムや目的が重なる部分はあるものの、完全に同じツールではないので、難易度を基準に評価されるべきではありません。viteで書けばスクリプトを幅広く精密に組めますし、StimulusやHotwireはスクリプト開発を最小限にするのにより適しています。
内容の大半がフロントエンド開発にフォーカスされているようですが…
Hacker Newsの意見
この記事は10年以上書き直され続けている
いわゆる「複雑性」というのは、それぞれ特定の問題を解決するツールの一覧にすぎない
ツール自体が問題なのではなく、現代のWeb開発に本質的な複雑さがあるというのが現実だ
ASP.NETやデスクトップGUIフレームワークなどでも、似たような「隠れた」複雑性を見ることができる
たとえばRailsをAPIバックエンドとして使い、フロントエンドをReactが担当するなら、従来のRailsモノリスとはまったく別のアーキテクチャになる
Vite、React、Prettierのようなツール群は、まったく別の問題を狙った選択肢だ（フロントエンドにもRailsを使いたいなら、ただRailsを使えばよい。中間形態はあまり好きではない）
本当の問題は学び方にある
最近の開発者は、Webの基本（HTML、CSS、サーバーサイドロジック、データベース）を身につける前にフレームワークから学ぶことが多い
各ツールにはそれぞれ存在理由があり、どれも現代のWebに必要な道具だ
「多すぎる」といった見方は、業界の現実をきちんと見ていない
複雑性はWeb開発に本質的なものではない
むしろ今は、より少ないものでより多くのことができるようになっている
Hotwireはほぼ素のRailsのように動作し、WebSocket経由でリアルタイムにコンテンツが更新されるモダンな体験を1行で構成できる
RailsでJSを配布する一般的な方法も、import mapsのおかげで非常に簡単になった（別途ビルド工程は不要）
Tailwindも非常に簡単に追加できる
デプロイすらkamalでずっと簡単になった
だから複雑さが本質だという話には同意しないし、Hotwireは複雑性を下げる役割を果たしている
学習は「より多くを学ぶ」ことではなく、「より少ないものでより多くをする」ことを学ぶ方向であるべきだ
20種類の言語やサーバーを使えることより、4つで3人のチームとして1000人を上回るほうが本当の技術力だ
人々はツールの存在そのものに反対しているのではなく、誰もがそれを必ず使うべきだという空気に反発を感じているのだと思う
どのチュートリアルも、YouTube動画のタイトルも「必ず使うべきMONGOOSEスタック！」のような調子なので、ベーキングブログにredisを無理やり入れようとする初心者まで出てくる
実際には、ほとんどのサイトは特別なスタックなしで十分だ
だがそういう話は誰も宣伝しないので、実際には多くのジュニア開発者がその事実を知らない
基本技術の学習を優先すべきだという点には同意するが、企業が各種サービスを売り込む隙間でそのメッセージを伝えるのは簡単ではない
私はRailsはかなり初心者だが、他言語の経験は10年ほどある
必要ならツールを追加するのは構わない（実際に必要かどうかは別として）
ただ、RailsはもともとORMからコンソール、スキャフォールディングのコード生成まで全部入りの巨大な万能フレームワークだ
追加ツールが必要なら、むしろRails自体を見直すべきなのではないか？
もっとモジュラーなもののほうがよいかもしれない
「素のRails」という言い方が警告サインに見える。あれほど巨大なフレームワークをどうしてバニラと呼べるのか疑問だ
この記事の要点は、最初から「モダンなWebアプリケーション」が本当に必要なのか自分で考えず、素のRailsでも十分だということを知らない場合が多い、ということだ
素のRailsのデフォルトの選択肢を自分で理解しようとする努力が足りない
「現代Web開発の複雑性」に言及するのは、単に問題状況を描写しているだけで、必須条件ではない
単にデータベースといくつかのSQLクエリで成り立つサイトにnpmパッケージを何千個も持ち込むなら、何かを間違えている
2007年からRailsのコードを書いてきた
スタックが複雑化したのにはそれなりの理由があり、本文の基準で「ちゃんとやった」チームは実際ほとんどない
Omakaseフレームワーク（Railsのように大半を決めてくれる方式）の問題点は、初期選択だけでなく後からの選択にもずっと付き合い続け、チーム全体をそれに乗せなければならないことだ
Railsは強力だが、メンテナたちも完璧に未来を見通せるわけではない
だから今では素のRailsに戻ったアプリはほとんどない
昔はDocker以前、Railsのデプロイは本当に面倒だった。rsyncやtarballの代わりにCapistranoのようなデプロイシステムが必要だった。
Dockerやk8sも便利だが、昔と比べて特に悪くなったわけではない
pre-Docker時代のRailsデプロイを「rsyncしてtarballを展開すること」として記憶しているなら、本当にひどいセットアップだったということだ
「昔の」Capistranoでデプロイするほうがはるかによかった
「rsyncやtarballで複数インスタンスに配ること」の何が具体的に問題だったのか、もう少し説明してほしい
聞く限りでは、そこまで深刻なことにも思えない
だから私はいつもSinatraに愛着がある
Railsが提供するout-of-the-boxのユーティリティを、JSの世界ではいまだに置き換えられていないのが残念だ
ほとんどのJS開発者はこの点をよく知らない
だがJSは常に車輪の再発明をするエコシステムだ
JSの大きな利点は、誰にでも新しいプラットフォームを作る機会があることだ
複数のJSプラットフォームを同時に組み合わせても何とか動くのは、非常に拡張可能でハックしやすく、すべてをローカルで永続的にビルドして固定サイトを作ることすら可能だからだ
ただし、こうした自由には節度が必要だ
いつでも新しいフレームワークを持ち込みたがる同僚を止めるのは、チームの役目になる
Ember.jsはRails陣営の大物たちが作ったオールインワンフレームワーク（「バッテリー同梱」）だ
しかし、他のフレームワークほど成功しなかったのには、それなりの理由がある
JSエコシステムにもAdonisJSのように全部入りのバックエンドフレームワークは存在する
ただ、NodeJSエコシステムはRailsやDjangoのような型にはまったフレームワークへの反動としてマイクロフレームワークから出発した
Expressのコンセプトも「素早く雑に」作って使うというものだった
JSにもRailsに似たフルスタックフレームワークはいくつもある
Sailsというフレームワークもある
JSはRailsが解決する問題とは別の問題を解いているので、フレームワークの見た目も違って当然だ
Railsはユーティリティが多いが、長期的には定期的にコードベースも更新しなければならず、Railsのトレンドを追い続けるのがしんどいこともある
StimulusとHotwireがいまや「rails way（正道）」として定着している
ドキュメントを一生懸命読んでも、なおかなり分かりにくい
どうにもJSコンポーネントを毎回手で作り直している感じがする
私としては、Rails 8 + Inertia.js + Reactの組み合わせのほうが、むしろ「車輪の再発明」を減らしてくれる。特にshadcnコンポーネントを使うならなおさらだ
この点には同感だ
うちもHotwireフロントエンドをInertiaに置き換えたが、本当に雲泥の差だった
本当に100%一人で小規模プロジェクトをやるのでない限り、Hotwireはすぐにチーム全員が手を出せない混沌になってしまう
私はむしろStimulusがとても気に入って、RailsからPhoenixアプリにもそのまま持ち込んだ
ただ問題は、このツールに対する誤解だと思う
StimulusはReactの代替ではない
何万行ものJSアプリに慣れているなら、Reactのほうが合っているかもしれない
だがサーバーサイドが主役のアプリで、数十行のJSでUXを磨きたいときにはStimulusがぴったりだ
Phoenixでは、静的HTMLと動的LiveViewsのあいだにちょうどよく差し込めるミニマルなソリューションだ
StimulusでSPAを作れと言った人は誰もいないし、そうすれば間違いなくつらいことになると思う
Stimulusは本当に小さく、HTML hookを持つイベントシステムなので、Railsのrequest lifecycleと相性がよい
誰かStimulusで非常に複雑なものをうまく作った経験があるのか気になる
私の感覚では、そこまでやるにはかなり厳しいように思えた
私もRailsファンボーイと言っていいが、StimulusとHotwireの現状は残念だ
概念は素晴らしいし、実装もおそらくよいのだろう
だがドキュメントがひどく不足していて、始める気にすらなれず、プロジェクトごとに「これで始めると後で袋小路に入るのではないか」という疑問に答えられる情報がない
StimulusはSymfonyと組み合わせて小さなインタラクションに使ったことがあるが、小さくてよく設計されたAPIでかなりよかった
Turbo/Hotwire全体はまだ使っておらず、複雑だったり状態管理が必要だったりするページには普通Vueを使っている
どうせ今はグリーンフィールドのプロジェクト（最初から新規構築するプロジェクト）はほとんど消えたも同然だ
創業者でもない限りグリーンフィールド自体がまれで、何かを売るならほぼ99%はShopifyラッパーかそれに類するもので済ませる
大企業でもグリーンフィールドは各種の考慮事項や社内フレームワークに縛られていて、「rails new」から始めることはない
こういう議論はあまり意味がなく、似たような論争や記事がこの10年、15〜20年ずっと繰り返されているので、うんざりで退屈だ
新しい記事ではなく、新しいものを実際に作ってほしい
完全に同感だ
Ruby/Railsで10年間働いてきたが、いちばん「最新」だったコードベースですらすでに5年以上前のものばかりだった
正直、新しいグリーンフィールドRailsアプリを作ったことはあるが、それもAPI専用のマイクロサービスで、フロントエンドは必要なかった
ある程度の規模の会社では、Railsのフロントエンドソリューションは最初から無視される
Hotwireを使えるエンジニアは見つからなくても、ReactやVueの開発者はいくらでも見つかる
RailsのFEスタックもしょっちゅう変わるので追いづらく（たとえばCoffeeScript時代を覚えている）、まともなドキュメントもほとんどなく、現実的な影響力もない
だからこういう議論自体が現実とはかけ離れている
「グリーンフィールドプロジェクトは創業者以外ほぼ存在しない」という主張には同意できない
古い大企業のモノリスやFortune 500だけを例にすると、全体平均から外れたごく一部にすぎない
むしろ「rails new」がsaneでそのまま使えるデフォルトを整えている努力はすごいと思う
このアプローチはHello Worldと簡素すぎるAPIドキュメントのあいだをうまく埋めている
Railsを必ずしも使わないとしても、こうした部分は見習う価値がある
かわいらしくはあるが、1つのRailsアプリが成長するにつれてbundler、webpacker、sprockets、Propshaft、importmaps、jsbundlingへと移っていかなければならない現実には触れていない
autoloaderからzeitwerk、TurboからHotwireなど、実際にはこうして変わった部分が本当に多い
それどころかRailsニュースレターの広告を見るだけでも、「専門家がRailsアプリのアップグレードを手伝います」というものが多い
こういう点に触れてくれてありがたい
「ただ素のRailsを使おう」と言うのは簡単だが、この5年間だけでもRailsはバージョンごとにJS管理の方法が完全に変わってきた
いまだにsprockets依存のgemも多く、Rails流にやっても結局は複雑なJSの塊にならざるを得ない
今は本当に混乱した状態だ。いつかはよくなるかもしれないが、Rails側の責任も明らかに大きい
CoffeeScriptも忘れてはいけない
つい最近まで、私が働いていた会社でもまだCoffeeScriptの移植を先延ばしにしていて、新しいコードはVueで書いていた
30人を超える開発者が異なる専門分野で同時に関わるようなプロジェクトでない限り、わざわざフロントエンド/バックエンド分離が持ち込む複雑さは不要だと実体験から学んだ
フリーランス時代に1〜2人規模のチームでも無駄に過剰設計してみたが、結局いまはDjangoにTailwindを少し載せる程度で使っている
今年Django開発者を採用したが、応募者のほぼ全員がDjangoで薄いAPIバックエンドだけを作り、フロントエンドはReactで大きく構成していた（しかもビジネスロジックまでフロントに寄せていることが多かった）
理由を聞いても、ほとんど説明できなかった
結局、サーバーサイドレンダリングだけを使っていた数少ない応募者だけが残った
本当にインタラクションの多いフロントエンドが必要なら、どうするか考える必要はあるかもしれない
私も同意する
業界の大半では、超高度なスケーラビリティやマイクロサービスが必要か、それとも単なるモノリスとPostgreSQLで十分かを、顧客の立場でそれほど気にしていない
最新技術だけを追いかけて無限の拡張性を目指したセットアップをする人が多いように思う
実際にはRailsはシンプルな設計でも非常に有用で、「退屈だ」「面白くない」という理由で過剰設計してしまうことが多い
だがRailsは本当にバッテリー同梱型で、オーバーエンジニアリングをやめれば普通によく動く
ある時点から、生産性こそがいちばん重要な価値だと感じるようになった
今のほうが複雑になっただけで、こういう概念自体は別に新しくない
15年前にDjangoを学んだときも、チュートリアルが特定バージョンのVagrant、VirtualBox、Chefのインストールを要求してきて、ほとんど気が狂いそうだった
今でもDjangoは好きで使い続けているが、そうしたツールは別に気にしていない
Django Rest Frameworkも、むしろ集中を散らす存在だった
「Web開発ツール疲れ」は非常に現実的だ
10年前にも現実だったし、こうした混乱はたいてい開発者が趣味の嗜好を職場に持ち込んだ結果だ
付け加えるなら、フロントエンドだけの話ではなくDevOpsのほうも似たような状況だ
その結果、関連分野に応募するにはすべてのツールを知っていて、さらに10年の経験、さまざまなバックエンドとSQL、Dockerまで要求されるような空気になっている
専門でやるなら一度セットアップすれば終わりだが、単発のプロジェクトやWeb開発が本業でない場合は、確かにしんどい
ただ、こういう形で避けることもできる
私はFresh(https://fresh.deno.dev/)というフレームワークでWebサイトを作ったが、これだけで十分だった
一般的なNode/Webpackの組み合わせよりはるかにシンプルで、TypescriptとTSXまで使えた
複数人で作業していたならESLintのようなものを追加したかもしれないが、なくても非常に簡単に始められた