🫥
フロントエンドのリプレイスに、いつまでかけるんだ？
一時期Ruby on RailsのERB + jQueryベースのフロントエンドをReactやVueのモダンフロントエンドにリプレイスするのが流行りました。私も現場でこういう例を複数見ています。
しかしどれも途中で止まっています。半分にも届かないぐらいのところで
"ERB + jQuery"だったものが
"ERB + jQuery + React + Next.js"とか"ERB + jQuery + Vue"になっています。
複雑度はむしろ明確に増しています
そこで、こういう結末が一般的なのかどうか、ウェブを検索して調べてみました。
タイミー社の例
- Rails (多分ERB) + jQueryが出発点
- 30画面
- Next.jsのSPAに移行
- 3年間かかった （2年弱の時点で一回中断）
クックパッド社の例
- 2020年にRails (多分ERB) + CoffeeScript/jQueryを Next.js + GraphQLに移行開始
- 2023年時点でまだ移行中
- 2024年に、グローバルのサービス(ERB + Hotwire)に統合される
スタメン社
- ベースはRails ERB + jQuery
- これに加えて、React (Node v8), React + TypeScript (Node v12)、さらに本記事ではNext.jsを導入中とのこと
ENECHANGE社
- ベースはRails ERB + jQuery
- Next.jsにリプレイスしたい
- 最初の1ページを作るのに４ヶ月。さらに４種類のページを作るのに半年
- ERBコードはまだたくさん残っている
食べログ
- しっかりと検討を重ね、現実路線で考えています
- ページごとにリプレイスするのではなく、各ページの小さなコンポーネント単位でのリプレイスをしています
感想
どうやら私が感じたことは一般的なことのようです
- RailsのERBをReactなどのモダンフロントエンドにリプレイスするプロジェクトは、一般に複数年かかります。それでも終わらなかったりします
- これだけ長期にわたると、ビジネス的にはごく当たり前なことですが、中断されやすくなります
- ここでは公開されているものだけをピックアップしましたが、同様の例は他にもあります
- ページ単位のリプレイスではなく、コンポーネント単位の方が現実的かもしれません。ただし見方によっては完全なリプレイスを諦めているとも捉えられそうです
- 特に最後のスタメン社の例では、Reactで作ったページがERBのものと区別がつかないとのこと。そうなると当然ビジネス側から見たら「何のためにやっているの？」って話になってしまいます。(私も複数プロジェクトで同じことを思いました）
そうなると、技術的負債を解消する方法はいわゆるモダンフロントエンドで書き換えることではなく、ERBやjQueryのコードを整備・リファクタリングすることではないでしょうか？
少なくとも真っ当なビジネス感覚を持っている人ならそう言ってしまうのではないかと私は思います。
Discussion
すごく参考になりました！
すごくためになりました！
エンジニア採用の観点で「フロントエンドもモダン（にしたいと思っている）」アピールしたいだけかもですね。
僕もそう思っていて「jQueryを使っているが年収は高い」「React/Vueを使っているが、年収は前者より低い」これらを選択するのは、僕ならおそらく後者になる気がします⋯
jQueryを書くストレスが、年収の差分に見合うかですね
jQueryで育ってきた人なら、問題なく？ 前者を選びそう？
SPAはクソ
Nuxt（や、おそらくらNext.jsなども）SSGなどで非SPAを書けるが、そういう話ではない⋯？
？？
なぜjQueryをやめ、ReactやNext.jsにリプレイスしようとしているのか、そのあたりの背景などある程度深掘りしないと、ただ意味もなくモダンにしたいような印象になってしまいますね。jQueryとReactを具体的な技術で比べてメンテナンスコストがどれだけ違うのか。リプレイスコストとjQueryでそのままやっていくコストを天秤にかけた結果、リプレイスをしようとそのプロダクトたちは判断しているのではないでしょうか？なぜ多くの企業がそこまでコストをかけてリプレイスしたがるのか、共通した理由があると思うので、批判をするのであれば理由を考えるのも必要だと思います。その上で批判を述べたほうが主張が増すと思います。
ありがとうございます。
私が注目しているのはまさにおっしゃる天秤のところです。Reactリプレイスする正当な理由がそれなりにあるのは間違いないと思います。しかし一方でリプレイスするのに要するコストが大幅に過小評価されているのではないかと思っています。
もしリプレイスプロジェクトの当初から例えば5年かかるということが分っていて、その間は新機能開発が遅れますと正確に見積もった上でビジネスも納得していたのなら問題ないでしょう。
しかし通常のビジネス感覚では、それはあり得ません。そんな呑気な会社は滅多にありません。そこに疑問を持っているわけです。
おそらくは、そして私も見ている限りでは、エンジニア側が正確な見積もりを出していないと思います。数倍ほど過小評価している可能性があります。そこをしっかりと客観的に見つめようというのが本記事の趣旨です。
よって、おっしゃるような、5年かけてでもReactにする理由は企業側には無いと思っています。加えて、UI/UXでは明確な差が見えないことが多いように思います。悪意はないにしても、経営陣はエンジニアに騙されたと思っているはずです。
確かに5年ものあいだ新機能開発が遅れるのであればとても問題だと思います。
しかし、今回ご紹介された5社の記事からはリプレイスのせいで新機能開発が遅れたと書かれたものはありませんでした。リプレイスしたことによって保守しやすくなった等プラスのことが書いてありました。リプレイスの結果、新規機能の開発に遅れた、延期になった等は書かれていませんでした。むしろ新規機能開発にあわせるためリプレイスを遅らせたりなどさまざまな配慮を見受けられました。5社とも立派なビジネス感覚を持っていらっしゃり、売上を出している企業だと思います。呑気な会社ではないと思います。リプレイスの前提として、ビジネスにマイナスの影響を出させないという条件はどの企業も共通することだと思います。
ビジネス面で迷惑がかかっていないかつ、エンジニアが開発をしやすくなるのであれば企業側にはReactにするメリットがあるのではないかと思いました。むしろそのように両者のメリットの享受に配慮をしているからこそ、時間で妥協しているのではないのか思いました。
リプレイスに時間がかかっているという主張は事実なのであっていると思います。しかし、エンジニアもリプレイスは簡単にうまくいくなんて恐らく考えていないです。そこの時間的コストは重々見積もっていると思います。jQueryからReactへの移行なんて結構な大掛かりなものですから。
そして今後新機能開発をしていく上で、開発者が既存のコードを負債と判断しReactを採用してリプレイスしたほうが開発スピードが速く、そしてメンテナンスがしやすいと判断したのであればビジネス的に迷惑が掛からない限りある程度の時間がかかってでもリプレイスするメリットはあるのではないのでしょうか？
紹介されたリプレイスの記事を読む限りは、メンテナンス性が上昇した等書いてあるのでむしろ成功例に思えました。
個人的な感想ですが、リプレイスができる環境なのであればjQueryを頑張ってリファクタリングするよりもReactに移行したほうが、コンポーネント指向UIなのでコードが非常に見やすくなるのでメンテナンスがしやすくなったり、そしてReact Hook Formなどさまざまな強力的なライブラリを利用できたり、長期的な開発コスト的には断然メリットがあると考えています。もちろん、Railsを使っているのであればhotwireにしていくのもありだと思います。
あと、他に思ったことなのですが、スタメン社で出している例が、リプレイス後に困ったことなのかと思ったら実際の記事で読むとリプレイス前の話でした。なぜerbとReactが混在するフロントエンドになっているのか、これがリプレイスのために行われた結果なのかどうなのかは書いていないためわかりませんが。
この部分が最初元記事を読んでいないせいで、リプレイスしたあとに困ったことのように見えてしまいました。
お返事、ありがとうございます。
実際にReactへの書き換えを試みた現場に足を踏み入れて、コードを見ないとわからないこともたくさんあると思います。今回の記事も、単に想像だったら書きませんでした。React/Vueへの書き換えに何年もかけて頓挫した複数の現場に、私自身が参画した経験があったので、この記事を書く資格があると判断した上でのことです。逆も軽くなら経験しています。
そしてそれらの会社がこれらの件の反省を受けて、参画当時にどのような戦略で進んでいたかも把握しています。申し訳ありませんが、ここら辺は公開できません。
全ての会社が同じ状態とは言いませんが、そういう経験と、私のビジネスの経験を合わせるとこの記事の内容になります。
一つだけ言うと、実際に担当したエンジニア側は必ず「リプレイスして良かった」と言います。自分が主導したことですので、自分を批判的に言える人は稀です。少なくとも私の場合はそう言う部分を差し引いて記事を読みます。今回もなるべくそこは避けて、どれぐらいかかったかの数字だけを見るようにしています。あと、ポロッと言ったことを大事にします。
技術的には全く以てご指摘の通りだと思うのですが、多分採用・ 求職観点で jQuery を使い続けるリスクが高過ぎるのだろうと思います。それこそ数年かけてものリプレイスにすら見合うレベルで。
企業側からすれば jQuery をやろうという意欲のあるエンジニアで、かつある程度以上のスキルがある人を採用する難易度はかなり高くなっているでしょうし、被雇用者側の開発者から見ても jQuery のフロントエンドエンジニア求人なんてほぼないので、jQuery のポジションにベットするのはハイリスクノーリターンです。
私のように能力が高くない者に至っては、jQuery で数年を過ごしてしまうともう転職がかなり厳しくなってしまいます。(2010年代後半に3年程 jQuery や VanillaJS をやっていた者の実体験)
仮にも技術者として、こういった本質的でない理由で技術選定を行うべきではないと自省するところはあるのですが、ここまで React がフロントエンドでデファクト化してしまうと、さすがに私にも生活があるので jQuery のポジションはちょっと…ということになってしまうのが現実です。
勿論 @naofumik さんとしては、そういう現実に一石を投じるためにこの記事を書かれたという面もあるとは思うのですが…
ありがとうございます。
採用・ 求職観点の観点はものすごく重要だと私も思っています。一生の問題なので
ただ自分の感覚として、jQueryもVanillaJSもStimulusも、そしてReact/Vueとかも、最近は全部同じに見えてきました。どの技術を使っても、メンテナンス性を高める工夫をしていくと、結局は似たパターンに収束していくと思います。この辺りはモダンなjQueryに挑戦してみようでも少し言及しています。
どの技術で書いてもフロントエンドがやることは、HTMLとくっついて、イベントを受け取って、ロジックを少し加えて、DOMに反映させることなので、それぞれが明確だとわかりやすいコードになると感じています。どの技術でやっても、フロントエンドのコアコンセプトの理解につながっていくように思います。
幸いなことに、今回挙げた例も私が実際に参画した現場も、jQueryとモダンフロントエンドが混在しています。そして双方の技術で修正・メンテナンスが発生します。違うのは新規開発をどっちでやるかだけです。したがってjQueryができるということで参画しつつ、モダンフロントエンドを学習し、モダンフロントエンドの経験を積んでいくことも可能ではないかと想像しています。
ここ最近なら、Devinに全部移行してもらえば人間の作業はレビュー作業とQAだけなので（「だけ」とは？ という気もしますが。）、もしかしたら半年以内に終わるかも？
もしくはNuxt Layerやbun (npm) workspaceなどを使って、ページごとに徐々に移行すれば、リプレイスも現実的かもしれません
どちらも両立できるので、Devinを使って、ページごとにjQueryからNuxt/Next.js（Vue/React）に移行すると、現実可能性が見えてきそうな気がします！
夢がある話を、ありがとうございます❣️
でもDevinに任せるのであれば、逆にどのライブラリを使うかは関係なくなりますので、jQueryでもよくね？って話にもなりそうな気がします
もちろん、jQueryを選択するのであれば、それでよいと思います👍️✨
ただエンジニアの採用に力をいれるのであれば、React/Vueなどのモダンなフレームワークに置き換えておくと、エンジニアが会社を選択しやすくなるかなと思います！
ありがとうございます。
実は上で私がお話しした内容は、jQueryを選択するべきかReact/Vueを選択するべきかという議論ではないと思っています。仮にReact/Vueを選択したとしてもjQueryのコードの駆逐は現実的ではなく、いつまで経っても大量のjQueryのページが残りますよという話のつもりです。どっちを選択するかではなく、選択肢は他にないでしょ？って話だと思っています。
エンジニア採用については、部分的にReactのリプレイスをして、「うちはモダンフロントエンドを取り入れている、イケている会社です」ってPRするだけで十分だと思います。現実的には大半のページがjQueryだったとしても、採用面接を受けにくるエンジニアには、「いずれレガシーはすべてなくす方針です」とか、テキトーに言えば十分かと思います。現実にそのように言っている会社は少なからずあるという認識です。
誠実とは言えませんが、それが現実ではないかと思います。
Smart HRの例が見つかったのでリンクしておきます。
プロセスは下記の通り
有志メンバーによるサイドプロジェクトとはいえ、おそらく有志メンバーは複数人いたと思われるのと、スクショを見てもリプレイスした画面が本当にシンプルなものであったのを考慮する必要があると思います。
１か月に１画面というのは、実際にかかる時間としてはよく聞く数字のように思います。
なかなか短期間でjQueryをReact化した記事を探すのが難しく、見つかっても規模や内容が不明なものがある中で、今日見つけたのはこれ。
この記事で注目したのはコントローラには最小限だけ手を入れ、
render json: @modelでJSON APIを作らせているように見えること。つまりJSON APIの作り込みをしなかったのではないかと想像されます。またチームが小さく、もしかしたら一人？という口調にも見えます。これが功を奏したのではないかと私は想像しています。