フロントエンド開発の「現在地」――気がつけば知らない言語になっていた
仕事柄、フロントエンドも普通に触る。
ReactもVueもAngularも、それぞれの時代を見てきた。
だからこそ最近思う。
「毎年ルール変わってない?」
JavaScriptが消えたわけではない。
HTMLが消えたわけでもない。
なのに数年前の知識を頼りに新しいプロジェクトへ入ると、まるで別の言語を見ているような感覚になる。
昔はHTMLを書いて、JavaScriptを書いて、jQueryで少しDOMを触れば大体終わりだった。
今は何かを表示するだけでも、
- Nodeを入れる
- npmを入れる
- TypeScriptを入れる
- Viteを入れる
- ESLintを入れる
- ビルドする
- テストする
という儀式から始まる。
もちろん技術的には進歩だ。
しかし時々、
「私はボタンを1個表示したかっただけなんだが……」
という気持ちになる。
Angularはどこへ行ったのか
そういえば昔はAngularJSが流行っていた。
今のAngularを見ると、「フロントエンドフレームワーク」というより、もはや巨大なアプリケーション基盤である。
消えたわけではないらしい。
むしろ金融や業務システムのような巨大案件では今も現役とのことだ。私は数年見ていないが。
いずれにしても、気軽に始められる存在ではなくなったようだ。
昔の「ホームページ作ります」の延長線上で触るものではない。
気がつけば専門職の世界へ進化していた印象がある。
Reactは途中で別人になった
Reactも面白い。
昔Reactを触っていた人と、今Reactを触っている人は、実はあまり会話が噛み合わない。
クラスコンポーネント時代を知っている人間からすると、Hooksが出てきたあたりで世界線が変わった。
もちろん技術的には進化だ。
コードの再利用性も高いし、状態管理も綺麗になった。
ただし副作用として、
「React経験者です」
という言葉の意味が、人によって全然違うようになった。
古いReactを知っている人と、新しいReactを知っている人では、前提そのものが違うことも珍しくない。
本当にフレームワークは必要なのか
最近、一番思うのはここだ。
ブログ。
会社案内。
ランディングページ。
問い合わせフォーム。
こういうものを作るのに、本当に巨大なフレームワークが必要なのだろうか。
HTMLとCSSと少しのJavaScript。
それだけで十分なケースは意外と多い。
むしろフレームワークを入れたことで、
- 依存関係が増える
- セキュリティアップデートが増える
- ビルド環境が壊れる
- 後任が苦しむ
という副作用の方が大きいこともある。
もちろん巨大な業務システムならReactもAngularも強力な武器になる。
問題は武器の選び方だ。
鉛筆を削るためにチェーンソーを持ち出していないか。
その問いは常に必要だと思う。
「みんな使っているから」は危険な理由
最近はSNSやYouTubeを見ていると、
「React一択です」
「Next.js以外は終わっています」
「今から始めるなら○○」
みたいな話が次々流れてくる。
だが冷静に考えてほしい。
その人たちは毎日フレームワークの話をして生活している。
新しい機能が出れば動画を作り、仕様変更があれば解説記事を書く。
それが仕事だからだ。
もちろん情報発信はありがたい。
私も参考にしている。
ただ時々、
「この人、本当に業務システム作ってるのかな?」
と思うこともある。
新機能レビュー動画を週に何本も出している人を見ると、むしろ実装している時間がないように見える。
結局のところ、現場で求められるのは最新機能を全部知っていることではなく、
「そのプロジェクトに何が必要で、何が不要かを判断できること」
だったりする。
おわりに
とはいえ、こういう話をすると必ず言われる。
「でも将来拡張するかもしれないので」
エンジニアは未来が大好きだ。
将来のためにフレームワークを入れ、 将来のためにマイクロサービス化し、 将来のためにKubernetesを入れ、 将来のためにCI/CDを組み、 将来のために監視基盤を整える。
そして数年後、そのシステムは誰にも拡張されることなく静かに閉鎖される。
もちろん未来への備えは大切だ。
ただ、私の経験上、
「将来の拡張性」のために作られた機能の大半は、一度も使われない。
フロントエンドが複雑になったのではない。
我々エンジニアが、まだ存在しない未来のために複雑さを前借りし続けた結果なのかもしれない。
そして皮肉なことに、
2026年現在、世界で最も成功しているWebページの一つは、検索ボックスが1個置いてあるだけのGoogleだったりする。