静的サイトのパラドックス
(kristoff.it)- 個人ブログや連絡先ページのようなシンプルなサイトでも、一般ユーザーは WordPress のような CMS にとどまる一方、静的 HTML サイトのほうがむしろ専門エンジニアにとって運用しやすいという逆転現象がある
- 静的サイトを自分で作るには、ドメイン購入、ホスティングの選定、DNS 設定、SSG の選択、デプロイパイプラインの構成まで、複数の中間ステップを自力で処理しなければならない
- エンジニアは GitHub Pages や Cloudflare Pages で 無料ホスティングとカスタムドメイン を活用する一方、一般ユーザーは静的で十分な場合でも、より高価で重いサービスに依存することになる
- SuperHTML はユーザーに診断を報告する初の HTML 言語サーバーとして紹介され、既存の診断ツールはたいてい特定のフロントエンドフレームワークに結びついているため、vanilla HTML だけでは使いにくい
- シンプルな Web 開発を簡単にできなければ、Web は非専門家から遠ざかり、一般ユーザーは ソーシャルネットワーク のような閉じた空間へ押しやられる
静的サイトがより難しくなる逆説
- 2つの個人 Web サイトの例が対比されている
- 1つは PHP で書かれた複雑な CMS で、Web サーバー、複数のワーカー、Redis キャッシュ、SQL データベースが必要
- フロントエンドも Single Page Application として読み込まれ、JSON 形式でコンテンツを要求した後、クライアント側で再構成される
- もう1つは静的 HTML ファイルと 1〜2 個の CSS ファイルで構成され、JavaScript はない
- 見た目には一般ユーザーがシンプルな静的サイトを使い、専門エンジニアが複雑な構成を使いそうだが、実際にはその逆に近い
- 一般ユーザーが静的サイトを自分で運用しようとすると、多くの段階を越えなければならない
- ドメイン購入
- ホスティングプラットフォーム探し
- DNS 設定
- SSG の選択または自作
- デプロイパイプラインの構成
- 逆にソフトウェアエンジニアは GitHub Pages、Cloudflare Pages などを通じて 無料ホスティング とカスタムドメイン対応を享受できる
- 結果として、静的 Web サイトで十分な 99% のケースでも、一般ユーザーはより多くの費用を払い、より多くの計算資源を使う複雑な解決策に縛られる
シンプルな Web を簡単にするツールの必要性
- Boston の SquiggleConf での発表は HTML 言語サーバー実装の経験を扱っており、結論は Web アクセシビリティ の問題へつながる
- SuperHTML はユーザーに診断を報告する初の HTML 言語サーバーとして紹介され、関連記事は Hacker News のフロントページ に掲載された
- リンターは存在し、エディタ診断も可能だが、通常は特定のフロントエンドフレームワークに結びついている
- このため、ユーザーは実際には複雑さを必要としなくてもフレームワークを選ぶことになる
- Web はソフトウェアエンジニアだけのものではなく、Web をより複雑にするほど、一般ユーザーは ソーシャルネットワークという囲い の中へ押しやられる
- スタートアップやビッグテックは経済的インセンティブが一致しないため、この問題を代わりに解決しにくく、シンプルな Web をより簡単にする取り組みが必要とされる
1件のコメント
Hacker News の意見
WordPress を捨てて静的サイトを使おうとマーケティング担当者を説得しようとして、苦い経験を何度もしてきた
結局のところ核心は編集のしやすさ。WordPress サイトはホスティング、技術担当者、経理担当者、読者ではなく編集者に最適化されていて、サイトを編集する人たちが実装方式を決めることになる
100ms 未満でレンダリングされ、完全に安全で、ホスティング費用は 0 円だが Markdown ファイルと少しの Git デプロイが必要なサイトと、遅くて高くて脆弱で継続的なメンテナンスが必要だが編集体験の良い WordPress を選ばせると、常に WordPress が選ばれる
なぜこの人たちに選択権があるのかいつも戸惑うが、同じ実験を何度やっても結果はいつも同じだった
テキストエディタと Git を覚える代わりに WordPress を選ぶのが、なぜおかしいのか分からない。実験は、優れた編集体験を提供しつつ裏側では静的サイトと Git デプロイを作るツールと、WordPress を比較する形であるべきだ。そうすれば副次的な要件であるセキュリティと速度に意味が出てくるかもしれない
ブログというより、非専門家がクリックとドラッグだけで欲しい機能に合わせて叩き上げられるカスタムアプリケーションに近い。ハッキングされたり、本物のエンジニアが必要なカスタム機能が出てくるまでは、コーディングも必要ない
Hugo や Ghost などを使うと「それには別のプラットフォームが必要です」につながり、そのプラットフォームは Shopify、会計システム、ソーシャルネットワーク／メンバーシップのプラグイン、求人掲示板などになる。WordPress は何にでも変えられるものになった
誰かがコンサルタントに望むものを伝えると「WordPress で設定します」となり、誰もが WordPress を使っているので、問題が起きたりプラグインを少し修正したりメール送信フックを付けたりできる人を見つけやすかった。PHP コンサルタントの時代が WordPress の支配力を作った
問題は、有料ソリューションまで含めて大半が完全なソリューションではない点。使い始めると、WordPress がばかげた制約を強いることにすぐ気づく。そこそこのサイズのクエリでも 5 秒かかり、最適化されていない補助クエリを 50 個も作るエンティティ／メタデータシステムの性能上の惨事の外側でオンラインストアを設計することはできない。一部のプラグインは WordPress を迂回して独自のデータベーステーブルを作ることさえある
WordPress はブログ以外ではアーキテクチャがひどいが、あらゆるもののツールとして使われている。他の CMS はそうしないので、人々は使わない
コンテンツは引き続き生成された静的ファイルとして CDN 経由で配信できる。静的サイトが Markdown と Git を要求するわけではない
技術経験がまったくないインターンでも技術的な細部に絡め取られずに修正をデプロイできるツールチェーンを長く探してきたが、まだ見つかっていない
一番近いのはヘッドレス CMS の上に静的サイトジェネレーターを載せる方式だが、正直どれもいまひとつ
2016年に地域事業者向けの紹介サイトを作るエージェンシーで働いていたとき、ある顧客から、自分たちが作ったウェブサイトに予約システム用の小さな iframe を入れてほしいと頼まれた。送られてきたのは Word 文書が1つで、実はそれを HTML にエクスポートして、安価な共有ホスティングに置いているだけだと分かった
彼らにはとても合っていた。オンラインメニューを常に最新に保てたからだ。印刷用メニューを作っていた Word 文書から、そのままエクスポートすればよかった。当時、社内では少し笑いものにしていたが、今思うと申し訳ない。レストラン経営のように、もっと重要なことが山ほどあるときには、実は天才的なやり方だ
静的サイトを作ることは今でもより簡単だ。ただし、HTML を生成するオーサリングツールは今ではあまり良くないか、良いものでもサイトを配信するためにサーバー上で動かす工程が付いてくる
私の仕事は「もっと良くできるのに」とあざ笑うことではなく、彼らのソリューションを改善し、私が提供するソリューションが既存のやり方と同じくらい、できればそれ以上にうまく動くようにしつつ、すでに得ている成功を邪魔しないことだ
多くの開発者は認めたがらないが、こうした場当たり的なウェブソリューションが、熟練したウェブ開発者が単独で実装するさまざまな戦略よりもうまく機能することは多い
重要なのは、そのビジネスが何を提供し、顧客とどのように関係を築き、やり取りしているかだ。ときには Word 文書を HTML にエクスポートするだけで十分なこともある。技術で改善することはできるが、本当の魔法は事業を運営している人たちの側にある
こうしたソリューションを改善する方法を見つけるのが、実際かなり難しい場合もある。より良いウェブサイトを作り、洗練されたインフラにデプロイすることはできるが、結局のところ顧客はそれをより好むのか。事業は良くなるのか。その部分はまったく些細ではないことがある
Word の HTML エクスポートよりも正しい HTML を作り、選択肢もより多く与えてくれる良い代替手段を、何年も探している
こういうものが好きだ。Vue template で作る単一 HTML ファイルのサイトもたくさんあるし、公開 Notion 文書として公開されたサイトや、iCloud のインライン写真ライブラリもある。ただつなぎ合わせることが、どれほど簡単で広く可能になったのかに驚かされるし、自分で一から作ろうとして、どれほど頻繁に物事を複雑にしているかも感じさせられる
時間がないときに、小さなマイクロサイトや一回限りのサイトを素早く組み合わせる用途では、mmm.page のようなものも好きだ。こうしたツールを探っていくのは楽しい
ところが一部のページの「文書」は、日付とテキストが入った表のまとまりで、顧客が自分で管理している。結局たどり着いた解決策も似たようなものだった。Word 文書に表を入れてこちらに渡してもらい、こちらが HTML/CSS にエクスポートして適切な場所に入れる
エレガントでもスケーラブルな解決策でもないが、その用途では間違いなくいちばん簡単な方法だ
あのときも驚異的だったし、今も驚異的だ。静かに、私たちはすべての人にコンピューティングを届けるという夢を実現していた
今、Asheville でこの問題を大きく経験している。携帯電話サービスがようやく戻ったときでさえ、みんな途切れがちなひどい 3G を使っていて、基本的な生存情報を得るためのウェブサイトはどれも読み込まれなかった
善意の人たちがテキスト専用のニュースサイトを作り、今日 Buncombe 郡のウェブサイトにも低帯域サイトができたのを見たが、開いてみると、依然として130KB の Bootstrap CSS と 50KB の jQuery がレンダリングをブロックしていた
人々がこういうことをしてくれるのは素晴らしいが、市民には1週間半前に必要だった。今では水、食料、飲用不可の水などをどこで手に入れるか、もう分かっている。今回の件を通じて、技術がここまでひどく失敗するのを見て、憂鬱な形で目を開かされた
電力会社の停電マップはログインの裏に隠れており、凝ったクラスタリングや UI 機能でレンダリングされるため、良好な接続でもすでに遅い。そのため、状況を確認したり停電を報告したりするのにもかなり時間がかかる
電力会社に電話することもできるが、メニュー選択がキーパッドのトーンではなく音声ナビゲーションになっていて、悪い 4G や 2G 接続で歪んだ音声をうまく認識してくれない
長い波長と低い電力が必要だ。しかしアクセスのしにくさがあまりにも大きく、それが妥当な理由によるものなのかはよく分からない
Black Mountain から Tennessee と Georgia の境界まで、通信が途絶えた。ひどい 3G でも再びつながる人が多いのかは疑問だ。私に分かるのは、そこに住む人たちと連絡を保つのが難しかったということだ
私がした最高の仕事の一部は、不安定なホテルの Wi-Fi につながった 12インチ MacBook で行ったものだ。だからページ速度にはとても気を使っている
今回の災害の苦痛を一言で要約するなら、あらゆる形でのコミュニケーション崩壊だった
「ウェブはソフトウェアエンジニアだけのものではない。私たちがウェブを複雑にすればするほど、一般ユーザーを私たちがソーシャルネットワークと呼ぶ囲いの中へ押し込んでしまう」という言葉に強く共感する
この引用が出た最近のカンファレンス Squiggle Conf に関するポッドキャストもある: https://changelog.com/jsparty/339
時間がたつにつれ、人々が「基本的なウェブサイト」に期待する機能は大きく上がった
プログラマーである私も、静的サイトジェネレーターの罠に何度かはまった
サイドプロジェクトを静的サイトジェネレーターで始めたものの、小さな機能を追加したくなった瞬間、素直に簡単な Rails や PHP アプリから始めればよかったと後悔して、いら立つことになる
最近、静的サイトが必要なときは、ただ HTML ファイルのフォルダーから始める。ツールについて机上の議論をしたり先延ばしにしたりせず、アイデアから実行までの道のりがずっと複雑でなく、速い
私は HTML と CSS を直接書くことにかなり満足しているが、全員に勧めるわけではない
もう一つ素晴らしい点は、あとで Rails に「脱出」することにしても、HTML ファイルのフォルダーを Rails の public/ フォルダーにコピーすればよいということだ。アップグレードの道筋はかなり簡単だ
Ruby 方面では Jekyll が最も有名だが、Markdown や他の軽量マークアップ言語でブログを書くという特定用途に合わせられている。他の用途に無理やり合わせることはできるが、汎用の静的サイトジェネレーターとしてはそれほど使いやすくない
Rails にコピー＆ペーストしやすいものが欲しいなら、Rack ベースの静的サイトジェネレーターである middleman がよい。最初から erb/haml と ActiveSupport で書ける
HTML と CSS を手で書くシンプルさは保ちつつ、include、部分テンプレート、リンクヘルパーのような便利機能だけが欲しいなら、nanoc は段階的に使える静的サイトジェネレーターとして悪くない。普通の HTML/CSS から始め、必要なときだけ機能を追加すればよい
たまに挙動をカスタマイズするためにコードを書くが、数年に一度程度だ。シンプルで、ただうまく動く
動的サイトで恋しくなるものはあるが、単なる HTML ファイルのフォルダーがどの点で Pelican より優れているのかはよく分からない
ウェブサイトの機能肥大を防ぐために立てた基本ルールは、自分が望むアイデンティティを決めることだった。自分がやったことのアーカイブとして置いておきたかったし、アーカイブなら時間がたっても非常に長く持ちこたえる必要がある。だからコピー、ミラーリング、どんなホスティングプラットフォームでも動かしやすい静的ファイルが合っている
多言語サイトをきちんと整えるには少し時間がかかったが、少なくとも一度だけ払えばよいコストだ
スタイル変更も、HTML ファイルにハードコードされていると問題になりうる
もっと高度な作業は Django で書く。機能を追加するのが自分にはとても簡単だ
.md→.htmlの段階を入れようか考えたことはあるが、まだ必要なかったローカルサーバーでサイトを簡単に見られるのもよい。最善は file:// でも見られることだろうが、構造を完全には解きほぐせなかったので、ファイルベース閲覧用の別コピーを作る
make localステップで落ち着いたウェブ開発者の個人ウェブサイトには、複雑にする要因がある。つまり履歴書駆動開発だ
個人のサイドプロジェクトを履歴書駆動開発に使おうとする専門家がいて、そうすれば雇用主のプロジェクトを壊す可能性が減ると考えている
例えば今朝も、まもなく公開する独立したウェブサイトがあり、主に履歴書上の理由で人気のある最新ウェブフレームワークを使っていたのだが、もはやウェブサイトを更新できなくなった
NPM パッケージの一つに重大なセキュリティ問題があり、更新しようとすると NPM が自動解決できない相互依存の衝突にぶつかった。皮肉なことに、このせいで本番サイトにセキュリティアップデートをプッシュできなかった
そのサイトは、手書きの HTML ファイル5個、少しのインライン JS、小さな Perl CGI スクリプト2個で足りたかもしれない。そうすれば25年たっても完璧に動いていただろう
代わりに NodeJS 部分だけでも NPM パッケージが129個、頻繁に必要なセキュリティアップデート、テンプレート断片と TS 設定、ハンドラーで構成された難解なソースファイルツリーがある
しかし専門家には、ばかげるほど複雑なやり方をしない余裕がない。例えば履歴書に Perl があると、就職可能性には致命傷だ。年齢差別のせいで履歴書を捨てなかった人たちでさえ、履歴書駆動開発をしなかったのは愚かだと思うだろう
私の場合、履歴書や提案にはまったく関心がないが、それでも JS/Python テンプレートから HTML を吐き出すより人間工学的な何かが欲しい。だから私のサイトは TypeScript、Mithril、Express といくつかのユーティリティライブラリの組み合わせだ
パッケージがいくつあるかは知らないし、気にもしていない。主に取り込むものが成熟していて、数分おきに新機能兼脆弱性を生み出さなければそれでよい
スタックは言っていなかったが、React とその「常に改善中だが決して終わらない」エコシステムである可能性が高そうだ。求められていない助言をするなら、偽の二分法を信じないほうがよい。純粋な HTML と最悪の泥沼の間には大きな空間があり、React 世界の状況は React に特有のものであって、外側まで代表するものではない
WordPressのキラーアプリはコメント。静的サイトジェネレーターはほぼ定義上コメントを許可しないが、WordPressブログにはほぼ必ず組み込まれている
Hugoのようなものをブログ領域で本当に流行らせたいなら、コメント付きの見栄えのよいテーマを作るだけでいい。スケールする形で解決すればよい。たとえばブログごとにシャーディングしたSQLiteを使えば、第三者が非常に安くホスティングできるかもしれない。そうすれば小さな金の卵を産むガチョウになる
記事へのコメントや議論はReddit、HN、Facebookのような第三者コミュニティにある。Substackの記事下のコメント一覧をざっと見る人と、同じ記事についてのHNコメントを1〜2ページ読む人では、どちらが多いだろうか？
技術系の記事なら、HNでの議論は特定記事のコメントスレッドより質が高いことはほぼ決まっていると思う。HNはすでにブログ全体の99.9%より広い読者層を引き寄せているからだ
ブログ記事に直接コメントする主な利点は、書き手が目にする可能性がずっと高いことだけ。HNのトップページに一時的に載っている状態は儚い
WordPressエコシステムは正反対だ。CMSやWebサイトを運営する人々が、それぞれの小さな市場ニッチで何を必要としているのかを深く理解する数十億ドル規模の事業群から成り、この市場規模はおよそ5億サイトだ
この記事を書いた人は賢いのだろうが、CMSの実用的な用途については明らかに賢くない。「静的HTMLサイトのほうが優れているが、邪悪な企業のせいで人気がない」という世界観は、Webサイトを1、2回でも有償で作ってみれば、ほぼ間違いだと分かる
静的HTMLサイトジェネレーターが、顧客の望むすべてを実現してくれる可能性はほとんどない。WordPressはこの市場がどれほど広く多様かを昔から理解しており、だからプラグイン対応を実装した
コメントが、静的サイトジェネレーターではなくCMSに近い何かをWebで使う本来の用途の一つであることには100%同意する。しかし、それ以外にも用途は百万通りある
静的HTML文書だけでは、そこまで遠くへは行けない。ミニマルな開発者ブログを離れれば、実際のユーザーや顧客が望むことをするために多くのプログラムロジックが必要になる。だから用途に合ったCMSを使い、大量のトラフィックに耐えさせるには積極的にキャッシュすればよい。それも仕事の一部だ
自分をすごいと思っている開発者たちが、キャッシュがどう動くのかを少し学んで適用する代わりに、なぜ車輪の再発明をしようとするのか、まったく理解できない。これも退屈すぎる「解決済みの問題」だからなのか？
私もHugoを使っているが、エンジニアリングの観点ではフットプリントが不必要に大きいとしても、ユーザー体験はWordPressのほうがはるかに親切だ
すべてのビジネスサイトがコメントを望むわけではないが、おそらく問い合わせフォームは欲しがるだろう。メールアドレスを公開するのも代替案だが、入力パイプラインを処理するほうがよい
静的サイトでは、送信を処理する信頼できるサービスを見つけ、サイトにきちんと組み込む必要がある。動く部品が一つ増え、別に支払う請求書になるかもしれず、業界が統合される際に対処すべき要素が一つ増える
https://hn.algolia.com/?q=%22disqus%22
Facebookも多くのサイトが使っていたコメントシステムを提供していたが、複数のスキャンダルで信頼とリーチを失った
私もその逆説に当てはまる。自分の個人Webサイトを、フレームワークやデータベースなしで現代的なPHPで書き直した
ほとんど静的サイトだが、PHPでヘッダーを付け、ブログ記事一覧のようなリストを処理している。完全に静的でないほうが少し便利だった。記事を書いてコミットし、プッシュすればすぐオンラインに上がる。ほとんどの静的サイトジェネレーターは複雑すぎると感じた
単一ページのコードはおおよそ
title = "Blog Article Title";、$this->shortTitle = "Title";、$this->date = mktime(0,0,0,1,27,2024);、if ($this->mode == PageMode::Meta) return;の後に生のHTMLコンテンツが続く、という形だルーターがサイトのヘッダーとフッターを自動で付け、フォルダーに
_layout.phpファイルを追加すれば、下位ページにレイアウトをもう一段重ねられる。ブログ一覧ページはフォルダー内の個別記事ファイルを走査してインデックスを作るここで
$this->mode == PageMode::Metaが使われる。各ファイルのコードを実行してメタデータを取得し、残りをレンダリングする前に抜ける。コンテンツが増えるとスケーラビリティは良くないだろうが、問題になれば調整するつもりだ私の「フレームワーク」のPHPコード全体は、
init.php、functions.php、Layout.php、Page.phpの4ファイルだけだ開発者の利点は、設定やデータの代わりにコードを書けることだ。コンテンツをより効率的に作成するためにもコードを使える
成果物はまだかなり未完成だが、ここにある: https://www.codaris.com/
include()で処理しているWebサイト所有者の視点でユーザー体験を考えると、これはあまりパラドックスではない。WordPressはオーバーヘッドがはるかに大きくても、作業を信じられないほど簡単にしてくれる
時間をかけてあれこれ設定することとのトレードオフだと考えるときだけ、パラドックスのように見える。たいていの人にとって代替案は、誰かにお金を払ってWebサイトを作ってもらうことだ
Hugo向けのWYSIWYGエディタを作り、ドメイン登録からサイト公開まで数クリックで終わるようにすれば、大金を稼げるはず
言いたいことは分かる。そうした会社が言っていることに近いとしても、途中の小さな手順を処理してくれるなら、誰かにとって大きな利点になるだろう
[1] https://micro.blog
「SuperHTMLを公開したとき、ユーザーに診断を報告するHTML用の言語サーバーはこれが初めてだと分かった。ブログ記事を書き、Hacker Newsのトップページに載ったが、誰も訂正しなかったので事実だ」という部分は、おそらくMicrosoftがLSPを出す前から、ほとんどのIDEが何年もやっていたことだからだろう
Vim、Neovim、Helix、Zed、VSCodeはいずれも、診断サポートのない同じ基本実装を共有していた
Helixは次のリリースからSuperHTMLをデフォルトで有効にする予定だ: https://github.com/helix-editor/helix/pull/11609