XSLTがWebでほとんど使用されないのはなぜですか？
XSLTは成熟した、広く受け入れられている標準です。
ブラウザー（古いIEでも）とサーバー側で使用できます（nginxにはXSLTモジュールがあり、もちろんプログラミング言語から使用できます）。その実装はコンパイルされているため、PythonまたはJSよりも高速である必要があります。JS実装Saxon JSは、少なくともフォールバックとして使用できます。Jinja、Angular、RubyのSlim、= ASPとPHPテンプレートは近くさえありません。
XSLテンプレートは、IDEで簡単に検証できます。 JinjaまたはAngularに役立つIDEはいくつありますか？
XSLTでUIとデータを分解するのは完璧なアイデアのようです。
確かに、実装によっては、一部のケースでは異なる結果が得られる可能性がありますが、問題はクライアント側でのテンプレートの場合のみです。そして、それは、HTML、CSS、およびクライアント側で行われる他のすべてと同じです。
では、なぜXSLTではないのでしょうか。
XSLTは、現代のインタラクティブWebで実際に役立つ役割を果たしていません。 XSLTの目的は、あるXML言語を別のXML言語に変換することですが、実際にそれを行う必要はありません。テクノロジーが解決するように設計された問題がない場合、テクノロジーがどれほど強力で高速で十分にサポートされているかは関係ありません。
XSLTの使用例がなくなった理由はいくつかあります。
- HTMLが勝った。 XSLTは、セマンティックマークアップ形式の「リッチテキスト」コンテンツをHTMLに変換するのに役立つはずでした。しかし、HTML自体は完全に優れたフォーマットなので、そもそもコンテンツにそれを使用して変換をスキップしないのはどうでしょうか。
- CSSはより強力になりました。 XSLTの約束の1つは、ソースマークアップをクリーンでセマンティックに保ち、それを「プレゼンテーションHTML」に変換して、ブラウザー間で機能し、要素などを再配置できることでした。しかし、最近はプレゼンテーション用のHTMLは必要ありません。セマンティックHTMLを使用でき、CSSで必要なスタイルとレイアウトを実行できます。
- XMLは、データのユビキタス形式にはなりませんでした。 SQLデータをデータベースからフェッチする場合、最初にXMLに変換してからXSLTを介して変換するよりも、直接テンプレートにマージする方がはるかに簡単です。そして、JSONはクライアント側の構造化データのXMLをほとんど置き換えました。
- XSLTは、一度にドキュメント全体を変換するように設計されています。しかし、最新のインタラクティブなWebページでは、データの小さな断片が常に断片的にダウンロードされ、ページにマージされます。
- データはそれほど複雑ではありません。ほとんどのユースケースでは、プレースホルダーとリピーターを備えたよりシンプルなテンプレート形式で問題を解決できます。 XSLTの方がはるかに強力ですが、そのような追加のパワーが必要になることはめったになく、複雑さと醜さには多大なコストがかかります。
XSLTは、1つの構造化されたソース形式から、print、PDF、静的Webページなどの複数の公開形式への一方向のプロセスを持つことができるという公開から生まれました。ほとんどのWebサイトはこのユースケースに適合しません。 。
「Web」での意味に依存します。
XSLTは非常に広く使用されています。 StackOverflowの質問の数などのメトリックスから判断できる限り、それは上位30のプログラミング言語に含まれているため、SQLに次いで、データモデル固有のプログラミング言語のトップになるでしょう。
しかし、XSLTはクライアント側、つまりブラウザで広く使用されていません。通常、サーバー側でHTTPリクエストに応じてコンテンツをオンデマンドで配信するか、公開ワークフローの一部としてバッチモードで使用されます。もちろん、Webとはほとんど関係のない多くのアプリケーションでも使用されています。印刷出版で。
XSLTがブラウザーで広く使用されていない理由はいくつかあります。主な理由は、適切な適合XSLTサポートがブラウザーベンダーからの提供が非常に遅いためです。すべてのブラウザで利用できるようになるまで誰もそれを使いたくありませんでした。すべてのブラウザで利用できるようになるまでに、人々がブラウザでやりたかったこと（「Web 2.0」を思い出してください）とXSLTの実装は進んでいました。ブラウザーでは、対話型アプリケーションの構築や、AJAXを使用したデータのフェッチには役立ちませんでした。
Saxonica（免責事項、これは私の製品です）はこれらのギャップをSaxon-JSで埋めようとしましたが、この製品はパーティーの後発品であり、クライアント側のWeb開発は非常にファッション主導であるため、単にすべてのテクニカルボックスを刻む製品。ファッション志向であることの一部は、ほとんどのデータ指向のサイト（ドキュメント指向とは異なる）がXMLではなくJSONに移行したことです。これは、主にJSONがJavaScriptからはるかに操作しやすいためです。
もう1つの問題は、XSLTが「好きか嫌いか」の言語であることです。その宣言的でルールベースの機能指向のパラダイムは、その高度な性質のために多くの人にアピールしますが、プログラミングの経験がコンピュータに何をすべきかを正確に指示する命令的なコードを書くことだけである人には不快な場合がありますどのような順序。
私はこの質問への回答と主に意見に基づくものとして閉じることの間を行ったり来たりしています。だから、ここに私のフリップがあります：
要するに、XMLは安っぽいプログラミング言語を作るからです。 XSLTのsemanticsを使用したものの、はるかに優れたsyntaxの場合は、まったく別の問題になると思います。たとえば、LISPベースの非常に優れたXML変換言語がいくつかあります。
XSLTは、ツリー書き換え言語、関数型言語、手続き型言語のいずれになりたいのかを判断できません。それはそれらすべての特徴を持っていますが、どれも実際にはあまり上手ではありません。 3つの側面のいずれについても、より優れた言語があります。
99.9％のケースでは、XML自体が廃止された下位互換性のジャンクのように見えるためです。
XMLがすぐに置き換えられない唯一のユースケースは、docxやodfのようなものであり、SGMLの方が優れていた可能性があります*。つまり、非常に豊富なドキュメント構造があり、さまざまなものが互いに入れ子になっていて、大きな変換が適用されているため、画面やプリンタで正しく表示されます。
ほとんどの場合、XMLは構造化データの受け渡しに使用され、XSLTは構造化ドキュメントデータをドキュメントデータに変換するように設計されているようです。そのユースケースは終わりに近づいています。 JSONは、構造化データのXMLよりも直接優れています。**マークダウンとYAMLはどちらも、簡単にフォーマットされたデータに優れています。 XMLの最初のレッグアップは、JavaおよびJavacriptの組み込みパーサーでした。JSONは、JSONソースが信頼されている場合（ほとんどの場合、若いころには）。
そして世界は変わりました。ビルトインライブラリの利点は、ささいな利点です。 XHTMLは完全に拒否され、XHTMLはXHTMLから継承されず、前任者から継承されました。
XMLは現在、それを受信したい人と直接話すために使用されており、必要な形式で布全体に生成されます。または、逆に、送信されたフォームから直接読み取られてオブジェクトモデルに解析されます。ストレージ形式またはユニバーサル交換形式で、スキーマからスキーマに変換する必要がなくなりました。
*彼らは大学でSGMLが実装されたことがないことを教えました。彼らは嘘をついた。
** JSONの不正な数値形式に関する苦情を聞きました。一方、XMLには数値形式がないため、すべてのデータ型を文字列に詰め込むだけでもXMLに勝ります。