Warum wird XSLT im Web so selten verwendet? [geschlossen]

XSLT ist ein ausgereifter, weit verbreiteter Standard.

Es kann in Browsern (auch im alten IE) und auf der Serverseite verwendet werden (nginx hat ein XSLT-Modul, das natürlich von Programmiersprachen verwendet werden kann). Die Implementierungen sind kompiliert und sollten daher viel schneller als Python oder JS sein. Die JS-Implementierung Saxon JS kann zumindest als Fallback verwendet werden. Jinja, Angular, Ruby's Slim, ASP und PHP-Vorlagen sind nicht einmal eng miteinander verbunden.

Eine XSL-Vorlage kann problemlos in einer IDE validiert werden. Wie viele IDEs können mit Jinja oder Angular helfen?

Es sieht so aus, als wäre es eine perfekte Idee, Benutzeroberfläche und Daten mit XSLT zu zerlegen.

Zugegebenermaßen können Implementierungen in einigen Eckfällen zu unterschiedlichen Ergebnissen führen, dies ist jedoch nur beim Templating auf der Clientseite ein Problem. Das Gleiche gilt für HTML, CSS und alles andere, was auf der Client-Seite ausgeführt wird.

Warum also nicht XSLT?

XSLT spielt im modernen interaktiven Web keine wirklich nützliche Rolle. Der Zweck von XSLT besteht darin, von einer XML-Sprache in eine andere zu transformieren - aber das müssen Sie eigentlich gar nicht erst tun. Wie leistungsfähig, schnell und gut unterstützt eine Technologie ist, ist unerheblich, wenn Sie nicht das Problem haben, für dessen Lösung die Technologie entwickelt wurde.

Es gibt mehrere Gründe, warum der Anwendungsfall für XSLT weggefallen ist:

• HTML hat gewonnen. XSLT sollte nützlich sein, um "Rich Text" -Inhalte in semantischen Markup-Formaten in HTML umzuwandeln. Aber HTML ist an sich schon ein perfektes Format. Warum also nicht einfach das für den Inhalt verwenden und die Umwandlung überspringen?
• CSS ist viel leistungsfähiger geworden. Eines der Versprechen von XSLT war, dass Sie das Quell-Markup sauber und semantisch halten und es dann in "Präsentations-HTML" umwandeln können, das browserübergreifend funktioniert und bei dem Sie Elemente neu anordnen können und so weiter. Aber Sie brauchen heutzutage nicht wirklich Präsentations-HTML, Sie können semantisches HTML verwenden und CSS kann das notwendige Styling und Layout ausführen.
• XML ist nicht das allgegenwärtige Format für Daten geworden. Wenn Sie SQL-Daten aus einer Datenbank abrufen, ist es viel einfacher, sie direkt in eine Vorlage einzufügen, als sie zuerst in XML und dann über XSLT zu transformieren. Und JSON hat XML für strukturierte Daten auf der Clientseite so gut wie ersetzt.
• XSLT dient zur gleichzeitigen Transformation eines gesamten Dokuments. In modernen interaktiven Webseiten werden jedoch immer kleine Datenausschnitte stückweise heruntergeladen und auf der Seite zusammengeführt.
• Daten sind einfach nicht so komplex. In den meisten Anwendungsfällen lösen einfachere Vorlagenformate mit Platzhaltern und Repeatern die Aufgabe problemlos. XSLT ist viel leistungsfähiger, aber diese zusätzliche Leistung wird selten benötigt, und die Komplexität und Hässlichkeit sind erheblich.

XSLT ist aus der Veröffentlichung entstanden, bei der Sie einen Einwegprozess von einem strukturierten Quellformat zu mehreren Veröffentlichungsformaten wie Druck-, PDF- und statischen Webseiten durchführen können. Die meisten Websites passen nicht zu diesem Anwendungsfall.

Kommt darauf an, was du mit "im Web" meinst.

XSLT ist sehr weit verbreitet. Soweit wir anhand von Metriken wie der Anzahl der StackOverflow-Fragen beurteilen können, befindet es sich in den Top-30-Programmiersprachen, was es wahrscheinlich zur Top-Programmiersprache für Datenmodelle nach SQL macht.

Aber XSLT ist clientseitig, dh im Browser, nicht weit verbreitet. Es wird normalerweise entweder serverseitig verwendet, um Inhalte bei Bedarf als Antwort auf HTTP-Anforderungen bereitzustellen, oder es wird im Batch-Modus als Teil eines Publishing-Workflows verwendet. Es wird natürlich auch in vielen Anwendungen verwendet, die sehr wenig mit dem Web zu tun haben, z. B. im Print-Publishing.

Es gibt eine Reihe von Gründen, warum XSLT im Browser nicht häufig verwendet wird. Der Hauptgrund ist, dass eine gute konforme XSLT-Unterstützung von den Browserverkäufern sehr langsam war. Niemand wollte es verwenden, bis es in jedem Browser verfügbar war, und bis es in jedem Browser verfügbar war, waren die Dinge, die die Leute im Browser tun wollten, weitergegangen (erinnern Sie sich an "Web 2.0"?) und die XSLT-Implementierungen im Browser hat Ihnen nicht geholfen, interaktive Anwendungen zu erstellen oder Daten mit AJAX abzurufen.

Saxonica (Haftungsausschluss, dies ist mein Produkt) hat versucht, diese Lücken mit Saxon-JS zu schließen, aber das Produkt ist ein Latecomer auf der Party, und die clientseitige Webentwicklung ist sehr modisch, sodass es nicht ausreicht, nur eine zu haben Produkt, das alle technischen Anforderungen erfüllt. Modegetrieben ist auch, dass die meisten datenorientierten Websites (im Gegensatz zu dokumentenorientierten) auf JSON anstatt auf XML umgestellt wurden, vor allem, weil JSON mithilfe von Javascript viel einfacher zu bearbeiten ist.

Das andere Problem ist, dass XSLT eine Love-It-Or-Hass-It-Sprache ist. Das deklarative, regelbasierte und funktionsorientierte Paradigma spricht viele aufgrund seines hohen Niveaus an, kann jedoch diejenigen abschrecken, deren einzige Programmiererfahrung darin besteht, einen zwingenden Code zu schreiben, der dem Computer genau sagt, was und in welchem ​​Umfang zu tun ist welcher Reihenfolge.

Ich wechsle zwischen der Beantwortung dieser Frage und dem Schließen als primär meinungsbasiert hin und her. Also, hier ist mein Flip:

Kurz gesagt, weil XML eine beschissene Programmiersprache ist. Etwas mit der Semantik von XSLT, aber viel besserer Syntax, wäre eine ganz andere Sache, denke ich. Es gibt zum Beispiel einige wirklich coole Lisp-basierte XML-Transformationssprachen.

XSLT kann nicht entscheiden, ob es sich um eine Baumumschreibungssprache, eine Funktionssprache oder eine prozedurale Sprache handeln soll. Es hat Eigenschaften von all diesen, aber es ist in keinem von ihnen wirklich gut. Für jeden der drei Aspekte gibt es bessere Sprachen.

Weil XML selbst für 99,9% der Fälle wie veralteter Abwärtskompatibilitätsmüll aussieht.

Der einzige Anwendungsfall, für den XML nicht sofort überlegene Ersetzungen bietet, sind Dinge wie docx oder odf, und möglicherweise wäre SGML besser gewesen *. Das heißt, wir haben eine unglaublich umfangreiche Dokumentstruktur, in der alle möglichen Dinge ineinander verschachtelt sind und große Transformationen angewendet werden, damit sie auf dem Bildschirm und dem Drucker korrekt angezeigt werden.

Fast immer wird XML zum Weitergeben strukturierter Daten verwendet, und anscheinend wurde XSLT entwickelt, um strukturierte Dokumentdaten in Dokumentdaten umzuwandeln. Dieser Anwendungsfall stirbt aus. JSON ist XML für strukturierte Daten direkt überlegen. ** Sowohl Markdown als auch YAML sind bei leicht formatierten Daten überlegen. Das erste Standbein von XML waren die in Java und Javacript integrierten Parser. JSON hat diese Barriere durchbrochen, indem ein integrierter Parser für die Fälle eingesetzt wurde, in denen der JSON-Quelle vertraut wurde (was die meisten von ihnen waren, als sie noch jung waren).

Und die Welt ist verändert. Der eingebaute Bibliotheksvorteil ist jetzt ein unbedeutender Vorteil. XHTML wurde sofort abgelehnt und seine Ersetzung erbte nicht von ihm, sondern von seinem Vorgänger.

XML wird jetzt verwendet, um direkt mit demjenigen zu sprechen, der es empfangen möchte, und es wird im gesamten Stoff in dem gewünschten Format generiert oder es wird umgekehrt eingelesen und direkt aus dem gesendeten Formular in das Objektmodell analysiert Ein Speicherformat oder ein universelles Austauschformat, das von Schema zu Schema umgewandelt werden muss, ist nicht mehr erforderlich.

* Sie lehrten im College, dass SGML nie implementiert wurde. Sie haben gelogen.

** Ich habe die Beschwerden über schlechte Zahlenformate in JSON gehört. Auf der anderen Seite gibt es in XML kein Zahlenformat. Wenn Sie also alle Datentypen in Zeichenfolgen einfügen, gewinnen Sie trotzdem gegen XML.