フロントエンド技術はなぜここまで複雑になったのか
Webは1989年、CERNのティム・バーナーズ＝リーが研究文書をリンクでつなぐために作った共有システムとして出発しました。1991年にHTML、URL、HTTPの三つが登場した時点では、Webページはリンク付きのテキストにすぎませんでした。飾りたいという要求から1996年にCSSが構造と表現を分離し、反応する画面のために1995年、JavaScriptがわずか10日間で作られました。
コードが爆発すると、2006年にjQueryがブラウザごとに異なっていたDOM操作を統一し、それでも足りなくなると、2013年にFacebookが「データが変われば画面は自動で変わる」という哲学のReactを公開しました。部品を持ってきて使うためにnpmが生まれ、ブラウザが読めない最新文法を変換し、散らばったファイルを束ねるためにトランスパイル・バンドル・ツリーシェイキングといったビルド工程が生まれました。すべての技術は、前の技術が生んだ問題への答えです。
概念を知るとAIへの指示はどう変わるのか
package.jsonがなぜ生まれるのかと尋ねる人と、「部品リストを記録するファイルだ」と理解している人とでは、同じツールを使っても結果が違います。前者の指示は「ボタンをきれいにして」にとどまり、後者は「このデータが変わったら、あの画面も一緒に変わるようにして」、つまり状態管理を要求するレベルまで上がります。
カートに入れた商品がページを移動しても残っているべきだという要求がまさに状態（state）であり、カードの型を一つ作って1,000回打ち出すのがコンポーネントです。この概念が頭にあれば、AIが書いたコードのどこがこじれたのかも指摘できます。
SPAに行ってなぜSSRに戻ってきたのか
アプリのようにちらつきなく画面が切り替わってほしいという要求から、一つのHTMLファイルの中でJavaScriptが画面を差し替えるSPAが生まれました。しかし検索エンジンのクローラーはJavaScriptが実行される前の空っぽの殻だけを見て去り、初回ロードは目に見えて遅くなりました。
そこで、サーバーが完成したHTMLを先に届けるSSRが再び注目されました。静的なHTMLにJavaScriptを注入して生き返らせるハイドレーション、ページごとに二つの方式を混ぜるNext.js型のハイブリッドが今日の標準です。KakaoTalkにURLを貼ったときに出るプレビューも、SSR環境でなければまともに動きません。技術は常にトレードオフであり、問題を解けば新しい問題が生まれる形で進化します。
非開発者のバイブコーダーはまず何を学ぶべきか
文法の暗記ではなく、この進化の地図が先です。地図があれば、npm installがアプリストアから部品を取り寄せて組み立てる過程であること、自分が書いたコードと実際にデプロイされるコードがビルドを経て別物になることが自然に理解できます。SH Consultingがバイブコーディング教育でツールの使い方より技術の歴史を先に持ち出す理由もここにあります。概念を知らなければ、AIに任せられる仕事のレベルはそこで止まります。