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つの構造化されたソース形式から、印刷、PDF、静的Webページなどの複数の公開形式への一方向のプロセスが可能な公開から生まれました。ほとんどのWebサイトはこのユースケースに適合しません。

「in 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 のセマンティクスを備えたものの、はるかに優れた構文はまったく別の問題になると思います。たとえば、いくつかの非常にクールなLispベースのXML変換言語があります。

XSLTは、ツリー書き換え言語、関数型言語、または手続き型言語のどちらにするかを決定できません。それらのすべての機能がありますが、それらのどれにもあまり得意ではありません。3つの側面のいずれについても、より優れた言語があります。

XML自体は、99.9％のケースでは時代遅れの後方互換性ジャンクのように見えるためです。

XMLにすぐに優れた置換がない唯一のユースケースは、docxやodfのようなものであり、SGMLの方が優れている可能性があります*。つまり、非常に豊富なドキュメント構造があり、あらゆる種類のものが互いに入れ子になっていて、大きな変換が適用されているため、画面とプリンターで正しく表示されます。

ほとんどの場合、XMLは構造化データの受け渡しに使用され、XSLTは構造化文書データを文書データに変換するように設計されているようです。そのユースケースは消滅しつつあります。JSONは、構造化データのXMLよりも直接優れています。**マークダウンとYAMLは、軽くフォーマットされたデータで優れています。XMLの初期段階は、JavaおよびJavacriptの組み込みパーサーでした。JSONは、JSONソースが信頼されている場合（若い頃はほとんどの場合）に組み込みのパーサーを活用することで、その障壁を打ち破りました。

そして世界は変わりました。組み込みライブラリの利点は、今では些細な利点です。XHTMLは完全に拒否され、その置換はXHTMLからではなく、その前身から継承されました。

XMLは現在、XMLを受信したい人と直接対話するために使用され、必要な形式で完全に生成されます。逆に、送信されたフォームから直接オブジェクトモデルに読み込まれ、解析されます。ストレージ形式またはユニバーサル交換形式、スキーマからスキーマへの変換は不要になりました。

*彼らは大学でSGMLが決して実装されなかったことを教えました。彼らは嘘をついた。

** JSONの不正な数値形式に関する苦情を聞いたことがあります。一方、XMLには数値形式がないため、すべてのデータ型を文字列に詰め込むだけでもXMLに勝ります。