XPathは、クエリのすべての部分に厳密に名前空間を指定しなくて済むなら、もっと良かったのに。

でも、XMLは実際にはインターネットで転送するには悪いフォーマットだよ。膨れ上がってて、帯域幅を余計に消費する。

XMLはまあまあだね。ちょっと冗長だけど、YAMLと比べるとその精度と表現力は評価してる。XPathもまあまあ。すべての構文を覚えるのは難しいけど、ちょっと試行錯誤すれば大体できる。XSLTは本当にクレイジーなナンセンスで、燃えて消えてほしい。

84年経ったけど、JSONにはXMLの「基本」が恋しいな。例えば、ちゃんとした標準化団体がないこととか。でも、スキーマのようなものはXMLの世界では（または、そう感じた）ずっとよく定義されていて、JSONの世界が追いつくのにほぼ10年かかった。私がXMLで最後にやったことは、EXIという技術で、XMLドキュメントを圧縮されたバイナリデータストリームに変換する転送方法だった。データ構造をASCIIに変換して圧縮し、HTTPで送信して、逆に同じことをするのはちょっと馬鹿げてるからね。今ではprotobufやその仲間が人気だけど、もしXMLが残っていたらどうなっていたんだろう。私の理想の考えでは、すべての互換性のある標準が互いに連携しているけど、例えばprotobuf/grpcとJSON APIの間には厳しい壁がある。良い方向に進んだのかもね？

2003年の『The Art of Unix Programming』で、著者はカスタムテキストフォーマットとそれに対するパーサーを書くことを勧めてたよね。手でXMLを書くのは、彼の言う戦争犯罪リストに入ってる。そこから、シンタックスハイライトやオートコンプリート、自動フォーマットのおかげで、手間が減ったし、寛容なパーサー（ブラウザがその代表）も悪評を受けることになった。現代のエディタでMarkdownやYAMLは存在するかな？

美しい！よくできてるね！みんながこれを自分のウェブサイトにコピーして、クリエイティブに使ってくれるといいな。

2008年にブラウザでXSLTを使ったサイトで働いてたけど、サポートは2000年代初頭からあったと思う。

ブラウザはXSLT v1.0しかサポートしてないし、聞いたところによると、廃止の話も出てるみたい。v3のサポートを導入してくれた方が、テンプレートのネイティブサポートで静的ウェブページを提供しやすくなると思うんだけど。

それ、うまくいくよ。特に目立つのは、みんなが自分のAtomやRSSフィードをスタイリングして、別々のXMLやHTMLページを表示する代わりに使ってるところだと思う。https://rknight.me/blog/styling-rss-and-atom-feeds/

エンタープライズJavaの巨大でグラグラしたタワーを作って動かすのはそんなに悪くなかったよ。私たちはTomcatといくつかのApacheライブラリを使ってた。問題なく動いたよ。私たちのCMSは、埋め込まれたHTMLを含むXMLファイルを出力していて、キャッシュしやすかった。パーソナライズとHTML（およびJS）のレンダリングはサーバーサイドでキャッシングプロキシを使って処理してた。XSL変換はキャッシュの後に実行されて、たくさんのトラフィックに対応できる速さだった。ここでのXMLのポイントは、すべての準備されたHTMLをバイナリデータとして入れて、パーソナライズが必要なものをXMLタグとして扱うことだった。だから、最終的な変換はかなり速かった。XSLトランスフォーマーはかなり最適化されていて、出力をレスポンス出力ストリームに直接ストリーミングするのがコツで、全コンテンツをメモリにバッファリングしないことが重要だった。ちなみに、これは今でも良いテクニックで、ほとんどのフレームワークはデフォルトで間違っている。メモリバッファリングはユーザーにとって簡単だからね。大きなレスポンスには大きな違いを生むことがある。最近では、もちろんブラウザで好きなものをWASM経由で動かせるけど、当時はJavaScriptがめちゃくちゃで、デザイナーはせいぜいPhotoshopファイルを渡してきた。それをフレームやテーブルに切り分けなきゃいけなかった。GoogleマップやGmailが出たばかりの頃で、私たちはCMSのためにかなりJavaScriptを使ったUIを作っていて、NetscapeとInternet Explorerの両方に対応しなきゃいけなかったんだ。どちらもやり方が全然違ったからね。

あの頃は、動かすために巨大で不安定なエンタープライズJavaのタワーが必要だった。JVMとSaxonがあればそれで十分だったけど…。

現在の技術なら、サーバー生成の昔ながらのウェブページでも対応できると思う。軽量だし、動作も速いし、メモリもあまり使わないからね。ただ、高遅延のインターネット接続があると厳しいかも。

そのタイムライン、なんか違和感あるな。JSは行動を標準化するためにあまり使われてなかったし、ユーザーエージェント検出や、レイアウトを強制するためのバグ頼みが多かった。最初はDHTMLや後のAJAXのためのインタラクティブ性が主な目的だったと思う。レイアウト関連のことに簡単にアクセスできたわけでもなかったんじゃないかな？（間違ってるかもだけど）CSSも一貫性を持たせるのにはあまり役立たなかったし、できるようになってもまだゴチャゴチャしてた。確かにCSSガーデンは素晴らしかったし、みんなセマンティックマークアップに感動してたけど、テーブルをコーディングするのが普通だったしね。最初の2つのACIDを通過するのにすごく時間がかかった。フレームワークが「一貫した見た目」に影響を与えたかは微妙だな。jQueryを使わなくなった頃には、CSSが見た目を決めるものになってたし。まあ、長い時間が経ったから、もしかしたら記憶違いかも。

現在の技術では、サーバー生成の古いスタイルのウェブページに対応できると思う。低いフットプリントで、速く動いて、メモリも少なくて済むからね。私の.NET/Kestrel/SQLiteスタックは、SSRレスポンスを約4ミリ秒以内で出力できるよ。リリースビルドで動かすと、平均応答時間は数百マイクロ秒で測定される。ページごとに複数のクエリがあって、複雑な結合を使ってビュー特有のレスポンス形状を作成することも多い。HTML文字列を補間する前にデータを適切な形に整えると、100k行のテーブルを構築するような場合にパフォーマンスが本当に向上することがある。LINQは速いけど、行ごとにコレクションを具現化するようなアプローチは、アイテム数が増えるとすごく高くつくことがある。HTMLテンプレートエンジンとデータベースをできるだけ近づけることが、私の経験ではうまくいく秘訣だよ。結局、あの複雑な構造化DOMは、クライアントに送るためのバイトのストリームに過ぎない。StringBuilderや賢いSQLクエリを使えば済むのに、複雑なASTやパーサーのアプローチを心配するのは、無駄で自己満足の業界を生んでしまった。これまでに聞いた反対意見は、開発者がHTMLエスケープ関数を正しく使えないと思っている傲慢なセキュリティホールモニターたちのものばかりだ。

AJAXとDOMの更新は「速くするため」だけにあったわけじゃなくて、「ウェブサイト」や「ウェブドキュメント」のパラダイムを変えるために実装されたんだ。ウェブはドキュメントを表示するためのものだったからね。フルページリロードは、ドキュメントパラダイムで作業しているなら意味がある。HNではこれがうまく機能しているけど、他にも人々がJSフレームワークを使う代わりにシンプルなウェブサイトを作るべき例がたくさんある。でも「みんなフルページリロードに戻れる」ってのは本当じゃない。実際には、フルページリロードがひどいUXになるような「ウェブアプリケーション」がちゃんと存在するからね。要するに、「ウェブサイト」「ウェブドキュメント」「ウェブフォーム」はほとんどフルページリロードでやり過ごせるけど、「ウェブアプリケーション」は複雑なものを提示して操作する必要があって、フルページリロードは良い解決策じゃないってことだ。

同じく。見たことあるいくつかの有名なサイトは、サイトマップをリクエストするだけで完全にダウンさせられると思う（1分間に何度もね）。ちなみに、これは実装の問題だとはいえ、私が見たXSLTプロジェクトの100%がそれを抱えてたってことは、言うまでもないかも。

商用版のSaxon使ってる？そんなに高くないし、機能（新しい標準も含めて）やパフォーマンスを考えると、個人的には価値あると思うよ。確か昔聞いた話だと、いろいろ賢い最適化をしてくれるみたい。

私の経験から言うと、ほとんどのシンプルなウェブサイトはXSLT 1.0で十分だし、パフォーマンスの問題もないよ。

一般的に言って、あの頃の「XMLが救世主」という考え方が問題の一部で、私たちがそれを離れた大きな理由でもある。XSLTでもSOAPでも、ある意味XHTMLでも関係ないけど… あれは機械同士が話すための機械言語として定義されてて、必ず何かがうまくいかなくなる。私たちが途中で介入するために作られてるわけじゃないし、できるけど、やるべきことよりずっと大変だよ。特に、機械が「間違った」り、違う「方言」を話すこともあるって考えられてなかったからね。見た目は素晴らしいけど、デザインして実際に展開すると、すぐに火がついて、何かを止めるとまた別の問題が始まる。

おかしいよね、XSLTは明らかに長いソースXMLを処理するのが普通だった時代に作られたのに、ネストされたループは明らかに問題になるし…。

Epubって、これを一つのファイル/パッケージに圧縮したものなんだよね。だから、アマゾンみたいになれるかも ;)