過度なJavaScript中心の開発がWebを壊している
(jonoalderson.com)要約概要
過度なJavaScript中心の開発がWebを壊している
- JSフレームワークの乱用でWebサイトの複雑性が深刻化
- 開発者体験（DX）がユーザー体験（UX）を圧倒
- 単純な作業にも過剰な構造を要求
- パフォーマンス・アクセシビリティ・保守性がすべて低下
- Web本来の機能を取り戻すことが解決策
序論
開発中心のWebが抱える弊害
- ほとんどのWebサイトは過度に複雑で遅い
- JS中心の設計により、ユーザーよりも開発者中心の構造へ転換
- 簡単な変更でさえ複雑なデプロイ工程を必要とする状況が一般化
本論
アプリのように見せたい欲望が原因
- 2010年代以降、モバイルアプリの流行とともに「アプリのようなWeb」への要求が増加
- AngularなどのJSフレームワークが導入され、複雑性が急増
- 単純なコンテンツさえシステムのように開発される
開発者体験（DX）優先の文化
- 最新のフレームワークは開発者の利便性に焦点
- コンポーネントの抽象化がUXとの乖離を生む
- 「なぜブログにReactを使うのか」という問いより、SSR互換性の議論が優先される
複雑性が標準になった現実
- 単純な作業にもビルド、ルーティング、API、キャッシュなど多段階の構造が必要
- 複雑なスタックのため、非開発者はコンテンツ修正ができない
- 技術の変化が速すぎて保守が難しい
フレームワーク乱用の弊害
- SSR、キャッシュ、メタデータなど既存のWeb機能を再実装している
- パフォーマンスは低く、依存関係は増える
- 結果としてJSフレームワークでCMSを再現するという矛盾が生じる
無意味な反復とコスト
- フレームワークの導入と廃棄が繰り返され、安定した構造がない
- 実際のユーザー課題の解決より、内部の複雑性の解消に集中
- コンテンツマーケティング、SEO、実験などが遅れ、ユーザー体験は悪化
JS乱用によるユーザー・マーケターへの被害
- コンテンツ修正に開発者の介入が必要
- SEOとページ品質が低下
- ユーザーには読み込み遅延、インタラクションの不具合など不便が増す
JSは道具にすぎず、目的ではない
- JSは強力な道具だが、ほとんどのWebサイトには過剰
- 静的コンテンツにはHTML、CSS、少量のJSだけで十分
- Vanilla JS、サーバーレンダリング、最小限のスクリプトのほうが効率的
権限の集中と構造的な問題
- 複雑なスタックのため、あらゆる作業が開発者依存になる
- 組織構造上、開発者中心に権限が集中
- 技術選定がユーザーより開発者の利便性基準で行われる
結論
Webの本質を取り戻すことが解決策
- すばやく読み込まれ、検索され、保守しやすいWebサイトが必要
- サーバーレンダリングHTML、セマンティックなマークアップ、最小限のJSなど基本への回帰が答え
- 技術より結果中心のアプローチが必要
- 「なぜこの技術を使うのか？」という問いが必要
- シンプルでユーザー中心のWebこそが、性能、コスト削減、柔軟性をもたらす
23件のコメント
WordPressを見れば……上の問題への答えになる気がしますね。 市場シェアもWordPressのほうがずっと大きいですし、遅いのに……
根拠としてベンチマーク結果があれば、開発者もより共感しやすいと思います。フレームワークに過度に依存したコーディングがあれば確かにサイトは遅くなるでしょうが、個人的には、サイト内のページ遷移という点では、バニラコードで作られたサイトのほうが、最適化されたフレームワーク製サイトより遅いケースをより多く見てきたからです。もちろん、静的データだけで構成されたサイトなら HTML + CSS だけのほうが速いかもしれませんが、現代に静的データだけのサイトがどれほど一般的なのかはよく分かりません。
React や Vue のようなものがなければ、 同じ機能を実装するにしてもコードをもっと複雑に書かなければならないのでは？ 特にポップアップを扱うとき、props を 1 つ渡すだけでも純粋な JavaScript でやるとコードがかなり複雑になります。 こんな簡単なことでもコードが複雑になるなら、本当に 複雑な機能は実装しにくくなりますよね
必然的な複雑さだ。昔のような単純なテンプレートHTMLではないものを
人々が使うブラウザーなんて種類はそれほど多くないのに、なぜフレームワークはこんなに多いのでしょうか。ブラウザーを管理している会社が最適なフレームワークを作って一緒に管理するのが最善ではないでしょうか。いつまでこの悪循環を繰り返すのでしょう。
目指す開発哲学が千差万別ですからね……。
現象への共感はしますが、結論には共感しません。
現象の表面的な原因は本文でも言及されていたように、「アプリのようなWeb」への需要が増えたことであり、
今も当時もWebは「アプリのような何か」を作るのに適していたわけではないものの、無理やり工夫すれば「似たものを作ることはできる」状態だったのだと思います。
そもそもWebの成り立ち自体が、論文のような一種の「文書」を共有するために作られたプラットフォームです。
HTML の基本構成要素を見るだけでもわかります。
その後、cgi のような動的コンテンツを生成できる技術が生まれ、ブラウザ側にもスクリプト言語が組み込まれて成果物に動的な性質を与えられるようになることで、「文書としてのWeb」からの脱却が始まりました。
問題は、最初の脱却の瞬間から現在に至るまで、Webの根幹が依然として「文書」ベースのシステムだということです。
もちろん WebSocket、WebRTC、Wasm など「文書」志向から外れた新しい技術は数多く登場しましたが、現在に至るまで大半のWebサイトは従来の「文書」ベースのプラットフォームに依存して開発されています。
今なお私たちは画面を描くために div タグを積み重ねなければなりません。
ここまでが現象分析で、では答えは何かと考えるのですが、
現実性のようなものをまったく考えず、理想的な次のプラットフォームの機能を想像してみるとこうなります。
（すべてのサイトがこうあるべきという話ではなく、アプリケーション的な性格を持つサイトに限ってですが）
まずブラウザは一種のアプリランチャーになります。
一度ダウンロードしておけば、オフラインでも実行できるべきでしょう。
そしてアプリは既存の html/css/js から離れ、別の言語で実装されます。
その過程で、Android のようにブラウザが一種のフレームワークを提供できるかもしれません。
サーバーとの通信方式も、従来の web リクエストから離れて別のパラダイムを使えるかもしれません。
リアルタイム性が必要な通信であれば、従来の tcp 通信をそのまま使うこともできるでしょうし、
http プロトコルを使わない、より単純な rpc 通信を新たに作って使うこともできそうです。
「理想的なプラットフォーム」とおっしゃっていた最後の内容が、何を意味しているのかよく分かりません。
結局のところ、ネイティブプログラムをダウンロードして、そこで ActiveX を使っていた時代の話ですからね。
問題の本質は、Webという「ドキュメント」を基盤とするHTTPプロトコルの中で、アプリのようなWebを作ろうとする無理な工夫にあるということであり、
それを解決するためにアプリレベルの機能が必要なら、アプリのための新しいプロトコルとフレームワークを作ってはどうか、という意見でした。
スマートフォンで純粋なネイティブプログラムが直接動くのではなく、ある種のサンドボックス化されたアプリが動作するように、それがブラウザレベルで実行される構造です。
もちろん、ActiveXのような形にならないよう、開放性と標準化が先行されるべきでしょう。
アプリのようなWebだとしても、結論で述べられていたものに近い形を目指すべきだと思います。JavaScriptを多く使うと、クライアント側としては重くなります。
実際、そのように実装できるフレームワークがないわけでもありません。例えばNext.jsも、クライアントコンポーネントの使用を必要なときだけにして最小限に抑えれば、おおむね可能ですし、別の方が言っていたRails陣営には Hotwire(https://hotwired.dev/) があり、これは筆者が述べた結論にかなり近づけるよう、アプリのようなWebを支援するフレームワーク群（Turbo、Stimulus など）があります。
この記事の根本的な問題意識には共感しますが、いくつかの点では首をかしげたくなる部分もあります。
例えば、私の会社が運営している特定サービスのプロモーション用Webサイトは、まさにこの記事で称賛されているような単純さを保っています。幸い、このWebサイトは大半の要素が十分に静的です。フロントエンドのHTMLやCSSなどのコードは、何のフレームワークも使わず人が手で直接書いたもので、JSもjQueryとGoogle Analyticsが入っている程度です。お知らせや掲示板などはjQueryを使ったAJAXで実装されていますが、そこまで不合理だったり過度に複雑なレベルだとは思いません。私が昔、初歩的なWeb開発に入門したときにjQueryベースで実装できた程度のものだと思うからです。私の知る限り、このサイトはInternet Explorer時代から運営されていたもので、私が直接作ったわけではありませんが、悪くないと思います。
しかし、そこにはGitによるバージョン管理とCI/CDパイプラインがあり、ステージングサーバーと本番サーバーを分離しています。MainブランチにPull Requestがマージされると、パイプラインでバンドラーを回した成果物がステージングサーバーに自動デプロイされ、担当者がステージングサーバーを確認したあとでデプロイを最終承認すると、それが再び本番サーバーにデプロイされる形になっています。以前は単にFTP経由で元ファイルを本番サーバーに直接上書きする方式でしたが、関連業務が私たちのチームに移ってきたあと、このように変更しました。
これは本当に不合理な複雑さでしょうか。以前は、そのWebサイトのtitleタグを修正するには、FTP接続をサポートするAcroEdit（はい、そのサイトのHTMLを直接書いた人たちは、今でもこれを使っていました）で本番サーバーのHTMLファイルに直接入って1行だけ直して保存すれば作業完了、というものでしたから、その人たちはたぶんそう感じるのかもしれません。
しかし私としては、この程度の複雑さの追加は十分に受け入れ可能だったと思います。すべての作業がtitleタグを1つ直すのと同じ程度なわけではありません。そして、昔のコードがコメントアウトされてべたべた残っていたものを、いつでも戻せるので気兼ねなく完全削除できることや、透過的な変更追跡とロールバックが可能になったこと、バンドラーによって必要ならもう少し基本的な最適化を追加できることは、十分な利点だと私は思います。実環境にデプロイする前にプレビューできるステージングサーバーの追加も、見方によっては複雑性だと言えるかもしれませんが、私はこれが必要だったと思います。
私も、さまざまなWebサイトの内部コード構造が過度に複雑化し重くなっていることには不満が多いです。最近のWindowsのOutlookアプリはWebアプリベースですが、このところ特に重くなりました。画面上でメール本文を書いたり、本文を全選択したりするだけで引っかかったり、ひどいときには「ページ応答なし」が出るほどです。なぜだろうと思ってWeb版Outlookで開発者ツールを開いてみて驚きました。一度キャッシュを消してリロードしたら、1分後になっても何かしらのリクエストが出続けていたのです。ブラウザで確認すると、MS Officeサイト関連だけで数GBのデータが保存されていました。
ただ、この記事はさまざまな論点が混ざっていて、共感する部分もあれば、あまり共感できない部分もあります。セマンティックHTMLやアクセシビリティに関する話は、むしろ昔のほうがひどかったと私は認識しています。それに、開発者体験の向上がユーザー体験を悪化させるという話は、私がWebフロントエンド開発者ではないからかもしれませんが、まったく共感できません。ましてや、すべての権力と統制が開発者に集中したというのは、荒唐無稽な話に聞こえます。会社の中で権力を持っているのは経営陣ではなかったのでしょうか。欧米では会社の構造が韓国とはかなり違うのでしょうか。
いつもそうであるように、バランスと中庸、単純さと実用性は重要な価値であり、これを意思決定で優先すべきだという点には全面的に同意します。ただ、この記事は「すべてのWebサイトをソフトウェア製品のように扱うこと」が、まるで全面的に開発者の責任であるかのように主張しており、その点がかえって根本的な問題意識をぼやけさせていると思います。そして、体制が整っていなかった「古き良き時代」を美化しているように見える部分は、むしろ批判されるべきではないかと思います。
おっしゃっている話とは、まったく別の話ではないでしょうか？
どの部分がまったく別の話だとお考えなのでしょうか?
結局、この文章が批判しているのは、過度な複雑さと、それによって生じる肥大化だと思います。私のコメントでJavaScriptの話を持ち出していないからといって、まったく無関係なコメントだとは思いません。ある意味では、枝葉末節な部分への批判なのですから。
そして、私のコメントでも最初から触れていたように、私も元の記事の根本的な問題意識には共感しています。
元の記事の意図を誤解されているように思います。
「...ここには Git のバージョン管理と CI/CD パイプラインが組み込まれていて、ステージングサーバーと本番サーバーを分離しています。Main ブランチに Pull Request がマージされると、パイプラインでバンドラーを実行して生成した成果物がステージングサーバーに自動デプロイされ、担当者がステージングサーバーを確認した後にデプロイを最終承認すると、それが再び本番サーバーにデプロイされる形になっています。以前は単に FTP を通じて元ファイルを本番サーバーに直接上書きする方式でしたが、関連業務が私たちのチームに移管された後、このように変更しました。
これが本当に不合理な複雑さなのでしょうか?」
とおっしゃっていましたが、あまり関係のない話のように思います。デプロイや管理をそのように行う程度の話と、この記事が主張していることはかなり異なるように思います。
元の文章の意図は、単に複雑化したJSフレームワークだけを批判することではありません。
便宜上、上にある韓国語訳のリンクから引用します。
> 今では、単に見出しを1つ変えるだけでも、4人のエンジニア、3つのフレームワーク、そしてCI/CDパイプラインが必要です。Webページを公開することが、異常なほど複雑になってしまいました。
> そうして徐々に、Webは公開前にコンパイルしなければならないものになりました。ユーザーがそれを必要としているからではありません。開発者がモダンに感じたがっていたからです。
> すべてが開発者のために最適化され、その他のあらゆる人にとっては敵対的です。
> 私たちはもはや複雑さを単に我慢しているのではなく、当然のものと見なしています。すべてのサイトにビルド工程、バンドラー、ハイドレーション戦略、ルーティングレイヤー、APIレイヤー、デザインシステム、そして巧妙なキャッシュ無効化ロジックが必要だと想定しています。マイクロサービスで構築し、エッジネットワークでホスティングし、単純なコンテンツを届けるためにパイプラインをデプロイしています。
> 私たちはWordPressのようなプラットフォームの機能を作り直していますが、その結果は10倍重く、しかも使い勝手ははるかに悪くなっています。さらに悪いことに、新しいレイヤーが増えるたびに、新たなバグ、新たな互換性の問題、新たな認知的負担が持ち込まれます。今や私たちは、単にホームページをオンラインに載せるためだけに、ハイドレーションロジックとキャッシュ戦略、そしてビルドパイプラインを保守しています。
> コンポーネントライブラリに十分な柔軟性がないため、マーケティングキャンペーンは遅れます。分析レイヤーがハイドレーション戦略と互換性がないため、A/Bテストは中止されます。コンテンツの更新は、ビルドを何日も待たなければなりません。基本的なSEO調整はバックログに埋もれてしまいます。
> マーケターは、チケットを起票しなければコピーを更新したり実験を実行したりできません。コンテンツをプレビューしたり、レイアウトをテストしたり、ページを公開したりすることもできません。あらゆる変更は、開発者、パイプライン、承認、再ビルドを経なければなりません。
> マーケター、コンテンツ編集者、SEO担当者、デザイナー――彼らは皆、このプロセスから排除されています。今では簡単な作業でさえ、技術的な流暢さが必要だからです。titleタグを変えたいと言えばエンジニアに相談するよう言われ、キャンペーンを公開したいと言えば、チケットを起票して2スプリント待てと言われるでしょう。
> すべては開発チームを通じて流れます。つまり、開発チームが何が重要か、何がリリースされるか、何が優先順位を無期限に下げられるかを決めるということです。そして彼らが複雑さを増せば増すほど、彼らはより不可欠になっていきます。
韓国では、経営陣→企画担当者→開発者へと降りてくる開発文化がありますが、西洋では韓国でいう企画担当者という概念がなく、開発者が積極的にプロダクト企画などに関わる面があります。西洋のPMなどは、カバーレターと自己紹介書が完全に一致する概念ではないのと同様に、韓国の企画担当者と完全に一致するわけではありません。もちろん、創作プロジェクトの性格が強く、面白さやゲーム性が重要なゲームは、西洋でもアジアほどではないにせよ比較的フラットですが、ディレクターから開発者へと降りてくる形ではあります。
そういう違いがあるのですね。
ただ、上の内容と大きく関連する部分ではないように思います。
Railsを使おう、そうすれば幸せになれる
この記事の要旨に同意します。最近は JS があまりにも乱用されていて、i9-9900k を使っていてもサイトがもたつくことが多いです。ゲーム用や作業用としては微妙なスペックではありますが、これより低スペックな事務用コンピューターがあふれているのが現実です。
だから私は、インタラクティブな部分やインタラクティブなページナビゲーションのように、JS が本当に必要なときだけ使おうという思想のフレームワークである Astro や Hotwire が好きです。サーバーサイドでレンダリングしようというサーバーサイドレンダリングも好きです。一方で、CSR（メタタグだけをサーバーサイドでレンダリングして、残りの部分を CSR で処理するものも含みます）はとても嫌いです。サーバーがやるべき仕事をクライアントに押し付けていると見ているからです。個人的には、CSR を使う伝統的な SPA 方式は、Electron のようなアプリでローカルにフロントエンドを実行するときに使うべきだと思っています。もちろん、サーバーからフロントエンドをロードする場合には SSR を使うべきですが。
以下は投稿に対するコメント反応を5つのタイプに分類した要約です:
1. 全面的な同意と支持
主な特徴: 記事の主張に全面的に同意し、複雑なJSスタックの問題を認めている。
意見例:
2. フレームワークの濫用への懸念
主な特徴: React、Angularなどのフレームワークの過度な使用を批判し、シンプルな技術で十分だという意見。
意見例:
3. 部分的な同意 + 現実的な考慮
主な特徴: 主張には共感するが、複雑さは避けられない、または必要だと見る現実的な立場もある。
意見例:
4. 開発文化および産業構造への批判
主な特徴: フレームワーク過剰は単なる技術的問題ではなく、採用・文化・マーケティング構造の産物だと指摘している。
意見例:
5. 批判または反対
主な特徴: 記事の前提に同意しない、または一方的な主張だと批判する。
意見例:
おお、タイプ別に分けてあるので見やすくていいですね
元記事が指摘する「Webの過度な複雑さ」という問題には共感します。しかし、その原因を開発者文化やフレームワークの濫用だけに帰する診断には同意しがたいです。今日のWebの複雑さは、かなりの部分で「ビジネスモデル」が求める必然的な機能とセキュリティの影でもあるからです。この点を欠いたままでは、片手落ちの診断にとどまるほかありません。
Webはもはや「無料の展示館」ではありません。今日では公共サイトを除く大半のWebサービスは、収益創出を目的としています。したがって、技術選択における核心的な問いは「このコードは純粋か？」ではなく、「この技術は私たちのビジネスを成功させるか？」であるべきです。
この観点から見ると、元記事が理想として描く「軽量なコンテンツWeb」は、現実のビジネス要件という壁に突き当たります。たとえば、コンテンツを販売するビジネスは、単純な静的ページだけでは運営できません。有料サブスクリプションや決済を処理するには、ユーザー認証、購読状態の確認、権限管理といった状態ベースのロジックが必要であり、コンテンツ保護のためには違法コピーや不正アクセスを防ぐリアルタイムのトークン検証などのセキュリティ層が不可欠です。さらに、パーソナライズやA/Bテストを通じてユーザー体験とコンバージョン率を高めるには、動的なデータ処理も求められます。
これらはすべて「洗練されたアプリケーション」の領域であり、フレームワークはそれを実装するための現実的な道具です。
もちろん、すべての複雑さが正当化されるわけではありません。私たちは複雑さを二つに分けて考えるべきです。
必然的な複雑さ: ビジネス機能（認証、決済、パーソナライズなど）を実装するために生じる、ROIが明確な複雑さです。これは受け入れるべきコストです。
偶発的な複雑さ: 開発の都合や過度な技術的抽象化によって生じる不要な複雑さです。これは継続的に測定し、取り除くべき技術的負債であり無駄です。
成功しているサービスは、この二つを区別して現実的なアーキテクチャを構築します。つまり、マーケティングやSEOが重要な最前線はできるだけ軽くし、重要な取引やパーソナライズ機能が必要な内部領域はフレームワークベースで安定性を確保するというハイブリッド戦略によって、速度と機能性という二兎をともに追っています。
元記事は、ユーザー体験悪化の原因をフレームワーク文化にだけ集中させ、「収益モデルがもたらした必然的な要求」を排除しました。この点を除外してWeb開発を論じるのは、客のテーブルに「速くておいしい料理」を出すことだけを語りながら、肝心のその料理を作る複雑な厨房や代金を受け取るレジの存在をないものとするのと変わりません。
Webが重いからといって、やみくもにフレームワークを捨てることはできません。ビジネスが求める機能をどれだけ効率的に、最小のコストで実装し、ユーザーに価値を届けるかが論点であるべきだと思います。
韓国語訳版は以下のとおりです。
https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…