`<br>` タグで振り返るWebの30年
(artmann.co)- 1990年代の静的Webから2010年代のJavaScript中心のWeb、2020年代のAI時代のWebまでの変化をたどりながら、Web開発がどのように進化してきたのかを整理した文章
<br>タグとFTPで始まったWebは、PHP・MySQLを経て、誰もが作れるプラットフォームへと急速に拡大した- 2000年代にRails、Git、Herokuを転機として、Web開発は構造化・自動化・協業中心の産業へと再編され、クラウドとモバイル時代の土台を築いた
- 2010年代にはReactとビルドチェーン、Docker、Nodeエコシステムの登場により、Webは文書ではなく本格的なアプリケーションプラットフォームとして定着した
- 2020年代にはChatGPTとCopilotがコードの書き方を変え、AIが開発生産性を増幅する新たな転換点となった
- こうしたすべての変化は、複雑さを代償としながら、より多くの人がより大きなものを作れるようにするWebの大衆化の過程へとつながっている
The Static Web - 静的Webの時代
> "View Source was how you learned"
- 1990年代後半(late 90s) のWebは、何になるのか誰にもわからないフロンティアのような状態で、その不確かさ自体が魅力として作用していた
- 個人Webサイトは、会社や組織ではなく個人サーバーとフォルダ単位で始まった
- Unixサーバー上の個人ディレクトリに、HTMLファイルとFTPクライアントさえあれば、インターネット上に自分の場所を持つことができた
- Notepadのようなシンプルなテキストエディタだけで文章を書き、そのまま公開することもできた
- この時代のWebは、検閲者や承認プロセスのない創作空間だった
- 料理、恐竜、歌など、関心事を中心に自由に投稿できた
- 「今週興味があるもの」をそのまま載せられる構造だった
- 学び方は徹底して自分で見て真似する方式だった
- YouTubeチュートリアルやStack Overflowは存在しなかった
- 他のサイトが気になれば右クリック → View Source が基本の学習ツールだった
- さらに深い内容は実際の紙の本で学んだ
- Core Java のような数百ページに及ぶ技術書を脇に置き、コードと本を行き来しながら学ぶやり方が一般的だった
- 遅くはあったが、知識が長く残る学習体験だった
- HTMLは構造とスタイルが混ざった状態だった
<table>、<font>、<center>タグがレイアウトとスタイルを同時に担っていた- 1x1の透明GIF（spacer GIF）で余白を調整していた
- 粗く非効率的ではあったが、動いてはいた
- CSSは存在していたが、事実上まだ主流ではなかった
- ほとんどのスタイルはインライン属性やHTMLタグそのもので処理していた
- レイアウトは入れ子のテーブルで解決していた
- 動的な機能には極めて高い参入障壁があった
- ゲストブックや訪問者カウンターのような基本機能にもCGIスクリプトが必要だった
- PerlやCで書く必要があり、URLパラメータを1つ処理するだけでも多くのコードが必要だった
- この複雑さが動的Webの普及を強く制限していた
- 共通レイアウトの問題には、ほとんど解決策がなかった
- ヘッダー・ナビゲーション・フッターをすべてのHTMLファイルにコピー＆ペーストしていた
- 変更時には全ファイルの修正が必要だった
<iframe>で共通要素を挿入する方法もあったが、副作用が大きかった
- ブラウザ互換性はすでに深刻な問題だった
- Netscape Navigator(1994) と Internet Explorer(1995) でレンダリング結果が異なっていた
- 特定のブラウザや解像度を明記する警告文が実際に必要だった
- それでも、この時代のWebには強い引力があった
- 印刷設備や放送設備がなくても世界中に公開できた
- Webは表現手段の大衆化を初めて実現した
- GeoCities(1994)、Angelfire(1996) のような無料ホスティングサービスは、数百万人に創作の場を提供した
- Webリング（web ring）を通じてファンサイトやコミュニティがつながった
- 混沌としていながらも生き生きとした生態系が形作られた
- 企業にはまだ「Webチーム」という概念がほとんどなかった
- Webサイトがあるとしても、「コンピュータに詳しい人」が作っている場合がほとんどだった
- Web開発者が職業として定着する直前の段階だった
- ツールは原始的で、サイトも粗雑だったが、
- 誰もが作って共有できる空間という中核となるアイデアが、この時期に根付いた
<br>タグと情熱で支えられたこの時代が、その後のあらゆるWeb進化の出発点となった
LAMPスタックとWeb 2.0
"Everything was PHP and MySQL"
- 2000年のドットコムバブル崩壊後もWebは成長を続け、この時期は何かを作りたい人たちにとって参入障壁が急激に下がった転換点となった
- 静的Web時代の最大のブレークスルーは**PHP(1995)**だった
- CGIのためにCやPerlで数百行を書いていた時代に、URLパラメータを
$_GET['name']の1行で読める体験は決定的な変化だった - コンパイル、メモリ管理、難解なエラーメッセージなしに、保存してリロードするだけで動作した
- XAMPP(2002) はApache・MySQL・PHPを一度にインストールできるようにし、ローカル開発環境の構築を画期的に簡素化した
- PHPは静的Web時代のレイアウト再利用の問題を初めてきちんと解決した
include 'header.php'の1行で共通ヘッダー・フッターを管理可能- 一度の修正で全ページが変わる体験は大きな興奮を呼んだ
- 言語的な欠点にもかかわらず、PHPの強みはアクセシビリティだった
- HTMLとロジックが混ざり合い、関数の命名に一貫性がなく、セキュリティAPIも粗雑だったが
- 週末に学んで実際のサービスを作ることができた
- 共有ホスティング(月5ドル) と cPanel(1996)、phpMyAdmin(1998) が標準で提供され、オンライン参入障壁は歴史上もっとも低くなった
- CGIのためにCやPerlで数百行を書いていた時代に、URLパラメータを
- PHPと事実上一体だったデータベースはMySQL(1995)
- ほぼすべてのチュートリアル・ホスティング・CMSがMySQLを前提に構成されていた
- 機能的には十分だったが、国際化テキストの処理では苦痛の連続だった
- デフォルトエンコーディングがlatin1で、UTF-8を正しく使うには
- データベース設定、接続エンコーディング、HTMLのcharset宣言をすべて揃える必要があった
- 「ä の代わりに ä」問題は、この時代を象徴するトラウマとして残った
- WordPress(2003) はWebの性格そのものを変えた
- コーディングを知らなくても、5分インストール後すぐに公開できた
- テーマの選択と記事作成だけでサイトを運営できた
- Webサイト制作の大衆化を実質的に実現した
- 非技術ユーザーにとってWordPressは解放だった
- ブロガー、小規模事業者、アーティスト、飲食店まで誰もがWebサイトを持てるようになった
- **「ブロガー」**という新しいアイデンティティが登場した
- WordPressの管理画面がそのまま「Webサイトエディタ」と認識されるレベルまで広がった
- 開発者にとってWordPressはほぼ万能ツールになった
- ブログ、ポートフォリオ、企業サイト、コミュニティ、ECまで全部WordPress
- WooCommerce(2011) でeコマースまで取り込んだ
- 素早い実装の代償として、プラグインの乱立とテーマカスタマイズを基盤とする技術的負債が蓄積した
- Webの可能性を根本的に再定義した出来事はGmail(2004) の登場だった
- 既存のHotmail、Yahoo Mailが数MBの保存容量しか提供していなかった時代に
- 1GB無料ストレージは衝撃的な数字だった
- 「削除するな、検索せよ」というメッセージが新しい利用スタイルを提示した
- Gmailの本当の革新は保存容量ではなく体験だった
- ページを再読み込みせずにメールの閲覧・作成・切り替えができるインターフェース
- AJAX(XMLHttpRequest) ベースの非同期通信を全面的に活用
- Webが文書ではなくアプリケーションになり得ることを証明した
- Google Maps(2005) はこの可能性をさらに一段引き上げた
- クリックとドラッグで地図を移動
- タイルをバックグラウンドで読み込む自然なインタラクション
- この時点でWeb 2.0という用語が本格的に定着
- リロードなしのUI、角丸、グラデーション、影がWebの基本言語になった
- メディアとソーシャル領域でも決定的な変化が続いた
- 動画領域ではYouTube(2005) が勢力図を変えた
- RealPlayer・QuickTime・Windows Media Playerのようなプラグイン地獄が終わった
- Flashベースではあったが、「クリックすればすぐ再生される」体験を提供した
- 動画は技術的問題ではなく表現手段になった
- Twitter(2006) は140字マイクロブログで新しいコミュニケーションの形を提示した
- Facebook(2006) が一般ユーザーに開放され、ソーシャルネットワークが主流へ移行した
- Webは消費型メディアから参加型プラットフォームへ転換した
- 誰もが発信者でありクリエイターにもなれる構造が形成された
- 動画領域ではYouTube(2005) が勢力図を変えた
- こうした変化にもかかわらず、JavaScriptは依然としてつらいものだった
- ブラウザ間でのDOM・イベント・AJAX実装差異とIE6互換問題により、デバッグは終わりがなかった
- jQuery(2006) はこの混乱を事実上終わらせた
$('#el').hide()がすべてのブラウザで同じように動作した$.ajax()で非同期通信を簡素化- 多くの開発者にとってjQueryはそのままJavaScriptそのものだった
- 同時に、ブラウザの動作原理を直接理解しなくても済む緩衝材の役割も果たした
- この時代の問題は、後になってようやく問題として認識された
- SQL InjectionやXSSがチュートリアルレベルで蔓延していた
- ユーザー入力をそのままクエリに連結するコードが一般的だった
- バージョン管理はSubversion(2000) が主流
- コミットは重く、ブランチは敬遠の対象だった
final_final_REALのようなフォルダ名が日常的だった
- 実行環境の標準化も欠けていた
- ローカルはWindows + XAMPP
- サーバーはLinux + 別のPHPバージョン
- 「works on my machine」が繰り返された
- パッケージマネージャーの概念もなかった
- JSはZIPをダウンロードして
/jsフォルダで手動管理 - PHPライブラリはファイルコピー前提
- JSはZIPをダウンロードして
- チーム構成と開発プロセスは非常に非公式だった
- PM・EMの役割はほとんどなかった
- コードレビューなし
- FTPでアップロードして即座に本番反映
- 障害発生時は本番サーバー上でその場修正
- それでもこの時代のエネルギーは強烈だった
- PHPと安価なホスティングで誰でもデプロイ可能
- AJAXで「本物のアプリ」を作れるという感覚が広がった
- ソーシャルプラットフォームによって誰もがオーディエンスを持てるようになった
- Web開発の職業化と構造化が始まりつつあった時点でもある
- Ruby on Rails(2004) が「Convention over Configuration」によって、より構造化された次の時代を予告した
- この時期の開発者たちはLAMPスタックとjQueryプラグイン、そして
- **「次の大きなサービスを作る」**という期待感の中でWebを作っていた
フレームワーク戦争
"Rails changed everything, then everyone copied it"
-
2000年代後半（late 2000s）、Webアプリケーションの規模が大きくなるにつれ、従来のPHPスクリプトと手作業中心の構造は限界に達した
-
この時期の解決策として フレームワーク中心の開発方式 が台頭し、その流れを決定づけた存在が Ruby on Rails(2004) だった
- RoRの実際の影響力は 2007–2008年 ごろから本格化した
- 「Convention over Configuration」という哲学により、ファイル構造、命名、接続方法をフレームワークが代わりに決めた
- 開発者はルールに従うだけでよく、それは制約ではなくスピードをもたらす解放として受け止められた
-
Railsはその後、Web開発の基本文法となる概念をまとめて提示した
- データベース変更をコードで管理する マイグレーション
- SQLへの依存度を大きく下げた ORM
- テストが標準で含まれた開発フロー
- MVC(Model–View–Controller) 構造の実質的な標準化
- MVCは 1970年代のSmalltalk に由来する概念だったが、Railsを通じてWeb開発の基本形として定着した
- Railsの成功以後、ほぼすべての言語エコシステムがこの定式を取り入れた
- Django(2005) はPythonで、Laravel(2011) はPHPでRails型の構造を定着させた
- CakePHP(2005)、CodeIgniter(2006) も同じ流れの上で発展した
- 生産性向上は誇張ではなかった
- 個人開発者が週末に作れる範囲が、以前ならチーム単位の作業に相当した
- スタートアップ環境では、素早い実験と反復に最適なツールとして機能した
- 実際に複数の代表的なサービスがRailsの上で成長した
- Basecamp(2004)、Twitter(2006)、GitHub(2008)、Shopify(2006)、Airbnb(2008)
- Railsはやがて スタートアップのスピードの象徴 のように認識されるようになった
-
フレームワークは生産性を引き上げたが、デプロイは依然としてボトルネック だった
- PHP時代のデプロイはFTPアップロードが一般的で、1回のミスでサービスが壊れかねない構造だった
- もう少し良い場合でも、SSH + SVN pull + Apache再起動 のような作業を手動で処理していた
- リリースディレクトリを分けてシンボリックリンクを切り替える方式など、すべての工程が カスタムで脆弱 だった
-
この問題を根本から変えたのが Heroku(2007) で、2009–2010年 ごろから本格的に広まった
git push heroku mainの1行でデプロイが終わる体験を提供した- サーバー設定、Webサーバーの再起動、スケーリングをプラットフォームが代行した
- Herokuはその後 PaaS(Platform as a Service) と呼ばれる概念を実質的に定着させた
- 開発者はインフラではなくコードだけに集中する役割へ移行した
- Twelve-Factor App(2011) の原則を普及させ、statelessプロセス、環境変数ベースの設定、ログのストリーム化など、クラウドネイティブな考え方を広めた
-
同じ時期に 協業の進め方の大転換 も起きた
- Git(2005) は分散バージョン管理モデルを導入し、ローカルで自由なコミット・ブランチ・マージ を可能にしたことで、ブランチのコスト がほぼなくなり、実験と巻き戻しが日常的な作業 になった
- 従来の Subversion(2000) は中央集権型構造でブランチが重く、マージは恐怖の対象 であり、多くのチームがトランク中心開発に依存していた
- Gitはツールレベルの革新だったが、GitHub(2008) が公開リポジトリの探索、フォークベースの開発、Pull Request 中心の協業を結びつけ、それを文化として定着させた
- GitHubは コードレビュー文化を標準化 した
- PRをマージする前に、誰かが必ずコードを見る構造
- この流れは社内開発にも広がった
- コードがそのまま本番に行っていた時代の終わり
- オープンソースへの貢献方法は、メーリングリストにパッチ を送る流れから ボタンをクリックしてPRを提出 する方式へ移り、参加のハードルが大きく下がった
-
この時期の後半には、Webのアイデンティティを揺さぶる変化も現れた
- iPhone(2007) と App Store(2008) の登場でネイティブアプリが急浮上した
- 当時のモバイルWebは非常に貧弱だった。デスクトップ向けサイトを縮小して無理やり見る体験で、横スクロールと拡大・縮小の繰り返しだった
- 一部は m.example.com のような別個のモバイルサイトを構築したが、限界は明らかだった
- ネイティブアプリは高速で、オフライン対応やプッシュ通知を備え、"There’s an app for that" というスローガンとともに未来のように見えた
- Web開発者たちは アイデンティティの危機 を感じ始めた：Webを続けるべきか？ Objective-Cを学ぶべきか？ Webは消えるのか？
-
この混乱への答えとして Responsive Web Design(2010) が登場した
- Ethan Marcotte(2010) はCSSメディアクエリを活用して、画面サイズに応じてレイアウトを調整する方法を示し、モバイルとデスクトップを1つのコードベースに統合する方向性を提示した
- 当初はツールの未成熟さと追加作業の負担から普及は遅かったが、Webが進むべき方向そのものは明確になった
-
Bootstrap(2011) はレスポンシブWebを実際の現場で使われるものにしたきっかけだった
- Twitterの社内ツールとして始まり、グリッドシステム、基本タイポグラフィ、フォームスタイルをまとめて提供し、デザイナーのいない開発者でもすぐ使えるUIを提供した
- その結果、Webは次第に似た見た目になっていったが、多くの開発者にとってBootstrapは最初のコンポーネントライブラリであり、デザインシステム体験でもあった
- この流れはその後 Material Design(2014) など、体系的なデザインシステムの普及へとつながっていく
-
インフラも同時期に急激に変化した
- 物理サーバーを事前に購入または賃借する方式から 仮想サーバー(VPS) 中心の構造へ移行し、必要なときにサーバー資源を作成する方式が可能になった
- AWS(2006) は最初に登場したが、複雑でエンタープライズ志向の性格から、個人開発者には負担が大きかった
- DigitalOcean(2011) は5ドルのDroplet、直感的なUI、迅速なサーバー作成体験によってインフラへのアクセス性を大きく下げ、個人開発者にも大企業に近い柔軟性を与えた
-
ファイル保存の問題は Amazon S3(2006) が事実上解決した
- サーバー台数に関係なくスケール可能なストレージと、アップロード後すぐにURLを返すシンプルなモデルを提供した
- ユーザーアップロード、バックアップ、複数サーバー環境でのファイル管理の問題が一気に整理された
-
Node.js(2009) はWeb開発者たちに別の衝撃を与えた
- Chrome V8 エンジンを基盤にサーバー上でJavaScriptを実行できるようになり、フロントエンド開発者には魅力的な選択肢に見え、バックエンド開発者からは懐疑的な反応を呼んだ
- ノンブロッキングI/Oモデルはリアルタイムアプリケーションに強みを見せ、多くのチュートリアルがチャットアプリの例に行き着いた
- この時期のNodeはまだ本番の主流というより好奇心の対象に近く、実際のサービスは依然としてRails・Django・PHP中心で、npm エコシステムも初期段階だった
- ただし、その後のNodeの本当の影響力はサーバーよりも、ビルドツールと開発環境の実行基盤として先に現れることになる
-
データベース分野では NoSQL の流れが台頭した
- MongoDB(2009) はドキュメントベースのデータモデル、スキーマの柔軟性、JSONフレンドリーな構造で注目を集めた
- 高速なプロトタイピングとスケーラビリティ、JavaScriptスタックとの相性で強みを見せたが、すべてのサービスに適していたわけではなかった
- 「いつかスケールするかもしれない」という理由で選ばれたものの、数千ユーザー規模の段階でトランザクションの限界を実感するケースも珍しくなかった
-
スタートアップのエコシステムはこの時期に本格的な成長局面へ入った
- Marc Andreessen(2011) の "Software is eating the world" 宣言と Lean Startup(2011) 手法の広がりにより、MVP → 計測 → 反復のサイクルが定着した
-
ツールの成熟により、少人数チームの競争力が実際に機能し始めた
-
開発プロセスもまた変化した
- Agile Manifesto（2001） と Scrum が普及し、スタンドアップ、スプリント、レトロスペクティブが標準のように導入された
- 原則よりも形式だけが残ったチームも数多く現れた
- コードレビューと自動テストは推奨から基本的な期待値へと移り、CI システムがコミットごとにテストを実行しながら、ソフトウェア開発の職業化と専門化が加速した
-
ただし、今日では当然とみなされる役割は、まだ定着前だった
- 2012年 時点では、エンジニアリングマネージャー、プロダクトマネージャー、体系的なバックログやチケット管理のないチームが珍しくなかった
- 小さなチームとフラットな組織構造が一般的で、「シニア開発者」が3年目というケースも珍しくなかった
-
2013年 ごろには、Web は完全に別の姿になっていた
- 強力なフレームワーク、簡単なデプロイ、ソーシャルなコード協業、モバイル対応、安価なインフラ、JavaScript の全面的な普及が同時に成立した
- モバイル危機を乗り越えた Web はむしろさらに強くなり、次の段階である JavaScript がすべてを掌握する時代 を迎える準備を終えた
JavaScriptルネサンス
"Everything is a SPA now"
- 2013年前後、WebはすでにGmail・Google Mapsのような事例を通じて「本物のアプリケーション」を支えられることを証明していたが、従来のjQuery + サーバーレンダリング方式は次第に限界に突き当たっていた :contentReference[oaicite:0]{index=0}
- 中核的な問題は 状態（state）管理 だった
- サーバーがHTMLを生成し、jQueryで相互作用を付け足す構造では、データとUIを複数箇所で一貫して保つことが急激に難しくなった
- コメント、カウント、通知バッジのように同じ状態が複数のUIに反映されるほど、コードが絡み合ってスパゲッティ構造へと変わっていった
- これに対する共通した結論は、レンダリングをすべてクライアントへ移そうというものだった
- サーバーはJSONを返すAPIの役割へと縮小
- ブラウザでJavaScriptがUI全体を管理する SPA（Single Page Application） 構造が台頭
- 初期のSPAフレームワークがこの時期に登場した
- Backbone.js（2010） はモデルとビューの概念で最小限の構造を提供
- Angular（2010） は双方向データバインディングと依存性注入を導入し、エンタープライズ的アプローチを試みた
- Ember.js（2011） はルーティング・データ・テンプレートをすべて含む「JavaScriptのRails」を目指し、強い規約を提示した
- これらのフレームワークは前進ではあったが、共通して DOMとデータ同期の複雑さ という問題を完全には解決できなかった
- 特に双方向バインディングは更新フローの追跡を難しくし、デバッグコストを押し上げた
- 転換点は React（2013） の登場だった
- Facebookがオープンソースとして公開した当時、JSX構文は関心の分離を逆行させるように見え、反発を招いた
- しかしReactはDOMを直接操作せず、状態に応じたUIの結果を宣言的に記述する 新しい考え方を提示した
- Reactの核は 宣言的モデル と Virtual DOM だった
- 状態が変わると、Reactが最小限のDOM変更だけを計算して反映
- 開発者はDOM操作を気にせず状態管理に集中できる
- コンポーネント という概念も決定的だった
- Button、UserAvatar、CommentListのような小さな単位を組み合わせてUIを構成
- 各コンポーネントは独立して考えられ、再利用可能
- Reactは徐々に広まり、2015年ごろには主流に定着 した
- Vue.js（2014） は似た概念をより親しみやすい文法で提供し、代替案として浮上
- フレームワーク戦争は新たな局面へ突入
- SPAの拡大は、JavaScript量の爆発的増加 を意味していた
- 問題は、開発者が書きたいJavaScriptとブラウザが理解するJavaScriptが異なっていた点だった
- ES6 / ES2015（2015） はアロー関数、クラス、モジュール、Promiseなど大規模な言語改善を導入
- コールバック地獄と
var self = thisパターンが消え、JavaScriptがようやく現代的な言語らしく感じられ始めた
- コールバック地獄と
- しかしブラウザ対応は遅れており、そのまま配布することはできなかった
- Babel（2014） は最新のJavaScriptをES5へ変換するトランスパイラとしてこの問題を解決
- その代償として、JavaScript開発では ビルド工程 が必須要素になった
- ファイル修正後にリロードするだけで済んでいた時代の終わり
- この過程で Node.js（2009） はサーバーではなく、開発ツールの実行環境 としてあらゆる開発者マシンを支配するようになった
- バックエンドにNodeを使わなくても、ビルドツールのためにNodeのインストールは必須になった
- ビルドツールチェーンも急速に進化した
- Grunt（2012） はタスクランナーとして複雑なビルド工程を設定ファイルで管理
- Gulp（2013） はコードベースのパイプラインでこれを簡素化しようとしたが、それでも複雑だった
- 決定的な変化は Webpack（2014） だった
- 単なるタスクランナーではなく モジュールバンドラ として依存関係グラフを理解
- JavaScript、CSS、画像、フォントまですべてをモジュールとして扱う
- コード分割、ホットモジュールリプレースメントのような概念を導入
- 強力さの代償として設定は悪名高くなった
- Webpack設定はミームになり、チームごとに「これを理解している一人」が存在した
- その人が去ると、設定は手を入れるのが怖い遺物として残った
- 同時に npmエコシステム が爆発的に成長した
- ライブラリを直接ダウンロードしていた方式から
npm install中心へと移行 - moment、lodash、さらには left-pad のような極小ユーティリティまでパッケージ化
- left-pad事件（2016） はエコシステムの脆弱性を露呈した
- わずか11行のパッケージが削除され、数千のプロジェクトのビルドが同時に失敗
- ReactとBabelさえインストール不能な状態に陥った
- npmが前例のない形でパッケージを強制復旧し、事態を収拾
- 利便性は維持されたが、依存地獄の現実 を誰もが認識するようになった
- ライブラリを直接ダウンロードしていた方式から
- 2016年、複雑性は頂点に達した
- 「How it feels to learn JavaScript in 2016」という風刺文が広まった
- 単純なWebページを作るためにReact、Webpack、Babel、Reduxなど数多くのツールが必要だという疲労感が拡大
- エコシステムの変化速度があまりに速く、学んだ知識がすぐ旧式になった
- それでも成果物は明白だった
- 以前は不可能だった水準のインタラクティブなWebアプリケーションを作れるようになった
- 複雑性は 野心のコスト として受け入れられた
- 一方で Docker（2013） はまったく別の問題を解決し始めた
- 「works on my machine」問題をコンテナで解決
- Dockerfileで実行環境を定義し、どこでも同一に実行可能
- 初期にはMac環境での性能問題やネットワーキングの混乱により導入は容易ではなかった
- Docker Compose、Docker Swarm、そして後の Kubernetes（2014） が登場し、オーケストレーション戦争が発生
- 2017年ごろ には、コンテナが未来であることだけは明らかになった
- これとともに マイクロサービス のトレンドも拡大した
- サービス分離と独立デプロイという利点を提供
- その代わり、サービスディスカバリ、ロードバランシング、分散トレーシングなど新たな複雑性が発生
- 多くのチームは、モノリスの複雑性を分散システムの複雑性へ交換していたことを後になって認識した
- この時期、Webアプリケーションの完成度は目に見えて向上した
- Slack（2013） は高速で検索可能な協業ツールとしてメールを置き換えた
- Figma（2016） はブラウザベースの共同デザインツールとしてデスクトップアプリの領域に踏み込んだ
- Notion（2016） などとともに、Webがデスクトップ級ソフトウェアを実現できることを証明
- これらの事例は、React・Webpack・ビルドチェーンの複雑さを正当化する根拠になった
- 組織構造もまた成熟段階へ移行した
- 2016年前後、プロダクトマネージャーとエンジニアリングマネージャーが標準的な役割として定着
- 初期のフラットなチーム構造は次第にプロセス中心の組織へ転換
- Scrumとアジャイルの儀式が広く浸透し、チームによっては道具にも形式にもなった
- 2017年、エコシステムは徐々に安定局面へ入った
- Reactは事実上の勝者となり
- ES6は基本文法となり
- WebpackとDockerは苦痛を伴いつつも標準として受け入れられた
- 次の段階はすでに予告されていた
- TypeScript の台頭
- Next.js のようなメタフレームワーク
- よりシンプルなデプロイ体験
- しかし前提は一つだけだった
- この JavaScriptルネサンスの混乱をくぐり抜けた開発者たちだけが、その次の段階へ進むことができた
TypeScript時代
"Types are good, actually"
- JavaScriptルネサンス以後、ツールの乱立が落ち着き、エコシステムが成熟段階へ入り始める転換点にTypeScriptが位置していた
- TypeScript(2012) はJavaScriptに静的型を導入したが、当初は動的言語の哲学やビルド工程の追加負担から長らく敬遠されていた
- アプリケーション規模が大きくなるにつれ、動的タイピングの限界が次第に明確になっていった
- 関数シグネチャ変更後、呼び出し側を追跡するコストが増加
- オブジェクトの形状を把握しにくいことによるコード可読性の問題
- 単純なタイプミスが本番障害につながる事例の繰り返し
- 2017–2018年を境にTypeScript採用が急速に広がった
- 自動補完と静的解析によってリファクタリングの安全性を確保
- インターフェースがコードと同期した強制されたドキュメントの役割を果たした
- 主要フレームワークの受け入れが転換点として機能した
- AngularはTypeScript優先戦略を採用
- Reactの型定義が成熟し、Vue 3がTypeScriptベースで書き直されたことで事実上の標準と見なされるようになった
- 2020年頃からは純粋なJavaScriptによる新規プロジェクトがほとんど選ばれなくなった
- TypeScriptはコードベースのアクセスしやすさを大きく改善した
- 新しく参加した人でも型定義を読むだけでドメインモデルを把握可能
- 暗黙知への依存が減り、チーム拡大のコストが緩和
- アプリケーション規模が大きくなるにつれ、動的タイピングの限界が次第に明確になっていった
- VS Code(2015) との結び付きが開発体験を決定的に変えた
- インテリジェントな自動補完、インラインのエラー表示、信頼できるリファクタリングを提供
- Sublime Text、Atomは次第に影響力を失っていった
- Reactの上にさらに別の抽象化レイヤーが形成された
- ReactはUIライブラリとして、ルーティング・データフェッチ・SSRに対する基本的な解決策を持っていなかった
- Next.js はファイルベースルーティング、サーバーサイドレンダリング、APIルート、自動コード分割を標準提供するメタフレームワークとしてこの空白を埋めた
- Nuxt、Remix、SvelteKit、Gatsbyなど、さまざまな対抗フレームワークが登場
- ReactエコシステムではNext.jsが事実上の基本選択肢として定着した
- メタフレームワークの普及により、前時代のツール断片化疲れは大きく緩和された
- webpack・Babel設定を自分で組み立てていた工程がデフォルトに吸収された
- デプロイ環境もまた急速に単純化された
- Vercel、Netlify はGitHub接続だけで自動デプロイとプレビュー環境を提供
- デザイナー・PM・QAがマージ前に実環境で変更内容を確認できるようになった
- Herokuの影響力は弱まり、Railway、Render のような新世代PaaSが台頭した
- AWS Lambda(2014) を中心にServerlessの概念が広まった
- 使用量ベースの課金と自動スケーリングを提供
- コールドスタート、状態管理、デバッグの限界により、万能な解決策ではなかった
- Cloudflare Workers はエッジ実行モデルでこれを拡張した
- CSS領域でも静かな転換が進んだ
- Sass・Less以後、CSS-in-JSを経て Tailwind CSS(2017) が広く採用された
- ユーティリティクラスベースのアプローチは
- クラス命名の負担を除去
- cascade・specificityの問題を軽減
- 結果として小さなスタイルシートの維持につながった
- GraphQL(2015) は複雑なデータ構造を扱うアプリケーションで強力な解決策として注目された
- 正確なデータクエリ、型ベースのスキーマ、ツールエコシステムという利点を提供
- サーバーレイヤーの複雑さやキャッシュの難しさにより、単純なCRUDには過剰な選択となった
- 一部のチームはRESTを維持するか、tRPCのようなシンプルな代替案を選択した
- コンテナオーケストレーション競争は2018年前後にKubernetesの勝利へと収束した
- 強力だが、高い学習コストと運用の複雑さを伴った
- 多くのチームにとっては過剰な解決策であり、PaaS再浮上の背景となった
- COVID(2020) はWeb開発需要を急激に拡大させた
- リモートワーク、電子商取引、コラボレーションツールが必須となった
- 開発者需要の急増と開発ツール企業の急成長につながった
- リモート環境では非同期コラボレーションとドキュメント化の重要性が高まった
- コードレビュー、PR説明、社内ドキュメントの品質が重要要素として浮上した
- 組織面でも成熟が進んだ
- エンジニアのレベル体系が定着
- ICトラックの正当性が確立
- PM・EM・テックリードの役割が分化
- Developer Experience(DX) が独立した投資対象として認識されるようになった
- 内部プラットフォームチーム、高速なCI、オンボーディング改善が生産性の中核要素として浮上
- 2022年頃、Web開発は複雑ではあるが管理可能な状態に到達した
- TypeScriptのデフォルト化
- Next.js中心のエコシステム
- デプロイ自動化と成熟したツール体系
- そしてすべてが変わってしまった: OpenAIという会社が ChatGPT と呼ばれるものをリリースした
AIの瞬間
"Wait, I can just ask it to write the code?"
- ChatGPT(2022) の登場を機に、質問を入力するだけで説明・コード・デバッグ結果が返ってくる体験が現れ、開発のルールが変わった
- 量子物理の説明からPythonデバッグまでこなせて、完璧ではないが十分に実用的な水準であることが衝撃だった
- 開発者たちはすぐに実験を始め、Reactコンポーネント作成、エラー原因の分析、言語間コード変換がドキュメント検索やフォーラム探索なしに数秒で可能になった
- GitHub Copilot(2022) はエディタ内で自動補完の形によるコード生成を提供し、コメントだけで実装を提案する超強力な自動補完体験を広めた
- AI提案を素早く評価・採用・修正・却下する新たなメタスキルが開発者の中核能力として登場した
- 繰り返しの多いボイラープレート、テスト作成、エッジケース処理のような作業が急速に速くなり、流れを切らさない開発が可能になった
- Cursor(2023) はAIを機能ではなく前提条件として統合したIDEで、コード選択後のリファクタリング依頼、自然言語による説明ベースの複数ファイル修正、コードベースとの対話が可能になった
- この変化によってシニアリティの意味は揺らいだが、実際には何を作るかを決め、要件・制約・副作用を判断する能力の重要性がさらに高まった
- AIはコードを書くことはできても、問題を定義し正しい方向を選ぶことはできない
- 極端には「プログラミングの終焉」と「役に立たない流行」という両極端の反応があったが、実際の結果はAIを使う開発者の生産性増幅として現れた
- 個人・サイドプロジェクトの参入障壁が急激に下がり、以前なら試さなかった領域(ML・ゲーム・新しいフレームワーク)にも対話ベースの学習でアクセス可能になった
- この流れはWebの長年の方向性である創作の大衆化を加速する段階として機能した
- コードを知っていることから、何を作りたいかを知っていることへと重心が移った
- 非開発者もプロトタイプ制作に参加し、PM・デザイナー・ドメイン専門家が直接ツールを作るようになり、技術/非技術の境界が曖昧になった
- インディーハッカーやソロビルダーが増え、一人でも実質的な製品を作れる環境が現実のものとなった
- 同時にReact Server Components、htmx、改善されたCSS・JavaScript標準、Bun のようなツールが「プラットフォームそのものを使おう」という流れを強めた
- 2022–2023年の大規模採用ブームの後に構造調整が重なって市場は揺れたが、AIは開発者を置き換えず、AI活用能力は基本的な期待値となった
- 2025年時点でWeb開発はアイデアからデプロイまでの速度が史上最速の状態にあり、
- クラウド・フレームワーク・AIが結び付いた環境の中で、個人はかつてなく強力な創作者となった
<br>タグから始まったWebの約束、「誰もが作って共有できる」という原則はAI時代にさらに強い形で続いている- 今はWeb開発をするのに本当に良い時代だ
6件のコメント
歴史書のようで、とても面白く読めました。
Cafe24でサーバーホスティングを1つ借りて、ZeroBoardを載せてそれなりにコミュニティっぽく作って遊んでいた、あの頃（笑）
楽しく読みました。死ぬ前に走馬灯のようにいろいろよみがえる感じでした（笑）
楽しく読みました。
開発環境まで広げると、VS CodeとLSPの登場、そしてTabnineのAI時代以前のツールにまでつながっていきそうですね。
JavaScript의 간략한 역사
この記事とあわせて読むとよさそうです
Hacker Newsの意見
すべてのページに同じヘッダー、ナビゲーション、フッターが必要だったのに共有する方法がなかった、というのは完全には正しくない
Webサーバーには Server Side Includes(SSI) の機能があり、それを使いたくなければ単に
cat header body > fileコマンドでも解決できた関連文書: NCSA SSIチュートリアル (1997)
文章の最後が「...そしてそのすべての過程の中でも、つつましい
<br>タグは今なおその役割を果たしている」のような一文で終わっていたらよかったのに、と思った昔働いていた会社では、デプロイのたびに新しいフォルダを作り、シンボリックリンク を最新版に切り替える仕組みを使っていた
手動ではあったが、各サーバーで アトミックな切り替え が可能で、ロールバックも簡単だったので、本当にエレガントな方式だと感じていた
それ以前は数十台のサーバーに手作業でファイルをコピーし、10〜20段階のコマンドを直接実行しなければならなかったが、それに比べればはるかに安全で単純だった
後になって自動化ツールも使ってみたが、設定が複雑で不透明だったため、むしろより 脆弱なデプロイプロセス になっていた
「CGIスクリプトを書くにはPerlかCを学ばなければならなかった」という話があるが、本当に数百行も必要だったのか疑問だった
実際には、簡単なC関数でもURLパラメータを読み取れる
私は最近 純粋なCでアンケートWebサイト を作ったが、以前作ったHTML生成ライブラリのおかげでかなり楽だった
OSのCGIライブラリをリファクタリングして使い、SQLiteを静的リンクして 単一バイナリ として配布した
Webサーバーなしでもstdin/stdoutでテストできた
結論として、CRUDなWebサイトはCでも十分簡単で、HTMLはツリー構造なのだから 文字列補間(string interpolation) は誤ったアプローチだと思う
<param>で終わる最初のパラメータをマッチさせているので、正確一致しない可能性があり、パーセントエンコーディング も処理していないただ、30年経った今でもなお、文字列補間がいちばん一般的な道具のように感じられる
本当に 包括的でよく書かれた文章 だった
著者は楽観的だが、私にはWeb開発が 場当たり的対応の積み重ね でできた不安定な塔のように見える
Webの標準化が少数のブラウザベンダーに握られ、根本問題を解決せず上塗りだけを続けてきた結果だと思う
最近の生成AIツールも、こうした複雑さを迂回するための一時しのぎの解決策にすぎない
結局、この塔はいずれ崩れるだろうと思う
この記事はおそらく 古典として残る記事 になると思う
今どきの開発者たちが見落としてきたWeb技術の歴史を簡潔に収めている
「Virtual private servers changed this…」の部分を読みながら思い出した
実は最初のVPS提供者は2001年ごろの JohnCompanies で、FreeBSD jailをベースにしていた
顧客はリモートバックアップを求め、rsync を好んでいた
そこで4年後、私は
rsync.netドメインを登録した（rsync/sambaの作者たちから許可を得ていた）1998年から2012年までWeb開発をしていたが、この記事を読みながら 思い出の旅 をしている気分になった
それ以降の変化をひと目で見渡せる要約でもある
記事の内容は、私が記憶しているWeb技術の流れとほぼ一致している
PHP以前のCGIは煩雑ではあったが、mod_perl と FastCGI のおかげで実用的だった
コンパイル言語でCGIを書くのはほとんど マゾヒズム に近く、PHPはその点で軽くて楽しかった
私は jQueryが流行する直前 にフロントエンド開発をやめた
本当に驚くべき文章だった
単に技術の年表を並べただけではなく、それぞれの時代の 時代精神(zeitgeist) を生き生きと伝えている
普通なら口伝えでしか残らない人間的な文脈を、文章として残している点が印象的だった
「なぜこんなに複雑なクラウドの世界になったのか」を批判するのではなく、各時点での 合理的な選択が積み重なった歴史的帰結 として理解させてくれる
人間史のアイロニーを技術史の中に感じることができた