10年以上前からそうだったよ。趣味を仕事に持ち込むのは、ほんとに愚かで自己中心的だよね。フロントエンド開発者が気分が良くなるなら、「DevOps」の世界もあんまり良くないよ。

プロとしてやってるなら、設定は一度やれば終わりだからそんなに悪くないよ。でも、ワンオフのプロジェクトやウェブ開発がメインじゃないなら、確かに面倒だよね。とはいえ、避けることもできるよ。俺はFresh（https://fresh.deno.dev/）を使ってウェブサイトを作ったけど、それだけで十分だった。いつものNode/Webpackの混乱に比べて、信じられないくらいシンプルだし。しかも、TypeScriptで書けて、TSXも使える。もし複数人でプロジェクトを進めるならESLintを設定するかもしれないけど、他に何もなくても始められるよ。

JSのオープンさで新しいプラットフォームを作れる力には感謝してる。みんなが車輪を再発明するチャンスがあるのは素晴らしいことだよね。これらのプラットフォームは、同時にいくつか使っても大体うまく動くし、すごく拡張性があってハッカブルだし、全部をローカルでホストできるから、サイト全体が常に変わらない形で作れるって最高！でも、その力にはある程度の自制が必要だよね。できるからって、退屈な開発者や、別のやり方をしてた会社から来たばかりの人が、理由もなく新しいフレームワークを追加するのを防ぐのはチームの責任だよ。

JSで全てを書き直す目的は機能性じゃなくて、ポータビリティなんだよね。

バニラRailsを使ってサーバー生成のフォームやPOSTリクエストで次のフォームに進む時代を覚えてるよ。...10年前でも、かなり古臭く感じた。Railsはウェブアプリ用のフレームワークサポートツールを成長させたのかな？それが話してる便利さなの？ > 結局、車輪を再発明するのがJSの生き方なんだよね。これには一理あるよ。根本的な考えは「サーバーサイドとクライアントサイドでどれだけ計算するか」ってことだし、ブラウザがすべての言語を実行できるわけじゃないから、クライアントサイドの動作に最短で到達するのはJSなんだよね。だから、その意味では車輪の再発明が多いんだ。（一度コードを書いて、どちらの環境でも動かすという考え方は、波があるのを見てるよ。boardgame.ioは、ターン制の状態を持つゲームを書くためのJavaScriptフレームワークで、特定の著作権パターンを使って、サーバーとクライアントの両方でコアの動作ライブラリを実行するから、クライアントはサーバーがルールを処理してゲームの状態を更新する間に、何が起こるかを予測できるんだ。）

Ember.jsはRailsコミュニティの大物たちによって作られたんだけど、Railsのようにバッテリーが含まれたオールインワンフレームワークって大きな約束をしてたんだ。でも、他のフレームワークほど人気が出なかった理由があるよね。

たしかに、便利さはあるけど、長期的にはコードベースを更新し続けないといけないし、Railsのトレンドに追いつかなきゃいけないよね。

JSにはRailsに似たフルスタックフレームワークがいくつかあるよ。Sailsっていうフレームワークもあるし… JSで解決する問題はRailsで解決する問題とは違うから、フレームワークの見た目も違うんだ。