世界を動かす技術を、日本語で。

XSLT – ウェブのためのネイティブでゼロコンフィグのビルドシステム

2025年6月27日原文(github.com)

概要

XSLTは1999年登場の ネイティブ なWeb向けビルドシステム。 現代の複雑なフレームワーク不要で 静的サイト 構築が可能。 XMLデータから HTML出力、ループや変数など多彩な機能。 主要ブラウザで クライアントサイド変換 対応、配布も容易。 シンプルなWeb制作の 有力な選択肢 として再評価。

XSLT:Webのためのネイティブ・ゼロコンフィグ・ビルドシステム

  • XSLT は1999年に標準化された、 XML→HTML変換 用の技術
  • 静的Webサイト制作でよくある構成
    • データ (.json, .md, .txtなど)
    • ビルドシステム (Hugo, Next.js, Astroなど)
    • 出力 (静的HTML)
  • 既存のビルドシステムは 複雑 で、理解や運用が大変
  • シンプルなHTML+CSSで作りたいが、 共通パーツ (ヘッダー・フッター)の管理が手間
  • ページ数増加で コピペ運用 が破綻
  • HTML importやWeb Componentsは JavaScript依存、純粋なHTMLだけでは困難

XSLTとの出会いとその特徴

  • ブラウザ 自体がビルドシステムになり得る発想
  • ブラウザは 多様なデータ形式 (text/html, application/xml等)を理解
  • RSSフィード の見た目改善をきっかけに XSLT に注目
  • XMLはHTMLに似ており、 データ記述が直感的
  • スタイルシート指定 も簡単
    • 例: <?xml-stylesheet type="text/xsl" href="blog.xsl"?>
  • XSLTで ループ・変数・インポート など、ビルドシステムに必要な機能を網羅
  • HTML出力 が容易に実現

XSLTの実践方法

  • XMLデータ例
    • <blog><post id="42" ...>...</post></blog>
  • XSLTスタイルシート例
    • <xsl:stylesheet version="1.0" ...>
    • <xsl:output method="html" indent="yes" />
    • <xsl:template match="/"> ... </xsl:template>
  • HTMLテンプレート として柔軟に変換
  • 動的データ も親XMLから参照可能
    • 例: <xsl:value-of select="title" />
  • 実行方法
    • XMLファイルをブラウザで開くだけ (例:Safariでblog.xmlを開く)
    • ブラウザが 自動でHTMLに変換・表示

XSLTのメリット・デメリット

  • メリット
    • ビルドツール不要、ゼロコンフィグで動作
    • 全ブラウザ対応、クライアントサイドで完結
    • 配布が容易、静的ファイルのみで運用可能
    • JavaScript不要、純粋なWeb標準のみで実現
    • XMLはHTMLに近く、直感的な記述が可能
  • デメリット
    • JSON非対応 (XMLデータ前提)
    • 高度な動的機能 や大規模サイトには不向き
    • 現代的な開発体験 にはやや古さも

まとめ:XSLTの再評価

  • XSLT は現代のフレームワーク全盛時代においても、 静的Webサイト 制作のための シンプルで強力な選択肢
  • Webブラウザ+XSLT で、 手軽かつ堅牢な クライアントサイド・ビルドシステム を実現
  • 古き良き仕様 が、今もなお 有用な道具 であることの証明

Hackerたちの意見

俺はシンプルな男。原始人のリードミー見たら、好きになった。時々、キーボード叩いてる原始人みたいな気分になるけど、いいこともある。ウェブサイトとかウェブ関連のことはやらないけど、XSLTについては知らない。XMLをちょっといじることはあるけど、ユーザーに何か見せたい時もある。いろんなファイル形式があって頭が痛くなるけど、きれいなものは好きだ。これ使うかも。仕様を読んでくれてありがとう。ツールを作ってくれてありがとう。

2000年代のエンタープライズXMLの肥大化が、技術を古臭く見せて、みんなを「クリーンな」JSONに向かわせたのは悲しいことだよね。XSLTやXPathはすごく成熟していて、今でも他のフォーマットで苦労している問題を解決してくれたのに。俺も悪い習慣に加担してるかもしれないけど、昔PHPのストリームラッパーを使ってXSLTのインクルードを(悪用して)楽しんでた思い出がある。これが古いバイアスかもしれないけど、ブラウザにローカルでやらせるのはちょっと不安なんだよね。昔は互換性の地雷原だったから。

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は存在するかな?

プロのソフトウェアエンジニアとしての最初のプロジェクトの一つは、19歳の時に雇い主が買ったGoogle Search Applianceをカスタマイズすることだった。彼らはCentOSを動かす黄色い顔のDellサーバーに何十万ドルも投資して、膨大なCIFSドキュメントストアのフルテキスト検索がビジネス開発プロセスを効率化すると思ってたんだ。2011年頃はXHTMLが流行っていて、GSAの運用方法はバックエンドからXMLで提供される検索結果をXSLTでXHTMLに変換することだった。俺はそのテンプレートを使って、企業のイントラネットポータルに似たものを、ColdFusionのアプリケーションページやStackOverflow、W3Schoolsのチュートリアルから盗んだアセットとマークアップを使って作り上げた。LinkedInで「XMLの専門家」としていろんなDoDの契約者から連絡が来た時、この経験は履歴書から外すべきだとすぐに学んだ。次に、JSONレスポンスからデシリアライズされたTypeScriptインターフェースの配列をJSXで反復処理する時、この投稿を思い出してほしい。俺はXSLTで同じことをやってたんだよね。

最近はXSLTを使ってフィードをスタイリングしてる。例えば: https://susam.net/feed.xml https://susam.net/feed.xsl

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

「XSLTがブラウザでネイティブに動く」って何それ?最後にXSLTを使ったのは20年前だけど、当時はめっちゃ使ってた。あの頃は、動かすために巨大で不安定なエンタープライズJavaのタワーが必要で、それがXSLTのエレガンスを損なってた。でも、もしXSLTが本当にブラウザで動くなら、ホストどこでも静的テンプレートの聖杯がずっと目の前にあったってこと?

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

Hacker Newsで議論の続きを見る