XSLT – ein natives, Zero-Config-Build-System fürs Web

 (github.com/pacocoursey)
2 Punkte von GN⁺ 2025-06-28 | 1 Kommentare | Auf WhatsApp teilen
  • XSLT ist ein sofort nutzbares, nativ verfügbares Build-Tool fürs Web, ganz ohne komplexes Build-System
  • Die meisten statischen Website-Build-Systeme leiden unter Komplexität, schwerer Verständlichkeit und Abhängigkeit von Frameworks
  • Mit XML und XSLT lässt sich HTML direkt im Browser erzeugen, was dynamische Datenverarbeitung und Markup-Generierung erleichtert
  • Alle wichtigen Browser unterstützen XSLT-basierte Transformationen, sodass keine zusätzliche JavaScript-Logik oder separate Tools nötig sind
  • Es ist keine perfekte Lösung, aber als einfaches und flexibles, auf Webstandards basierendes Alternativmodell sehr wertvoll

Einführung und Problemstellung

  • Die Entwicklung der meisten statischen Websites besteht aus Dateien für Daten (.json, .md, .txt), einem separaten Build-System (Hugo, Next.js, Astro usw.) und einer HTML-Ausgabestruktur
  • Build-Systeme werden immer komplexer, und selbst ein kleiner Blog wird zunehmend schwerer zu verstehen und zu betreiben
  • Wenn man auf Frameworks verzichtet und nur mit einfachem HTML, CSS und Standardspezifikationen (HTTP, URI, HTML) arbeitet, stößt man bei der Wartung schnell an Grenzen, etwa bei wiederkehrenden Headern oder Footern
  • HTML Imports und Web Components wurden ebenfalls ausprobiert, aber Ersteres wird nicht unterstützt und Letzteres ist wegen der Abhängigkeit von der JavaScript-Engine keine echte Alternative

Den Webbrowser als Build-System nutzen

  • Der Ausgangspunkt ist die Erkenntnis, dass der Webbrowser selbst verschiedene Datentransformationen unterstützt (text/html, text/markdown, application/xml usw.)
  • Durch eine genauere Betrachtung der Webspezifikationen wurde nach einem Weg gesucht, das Problem ohne unnötige externe Tools und Frameworks zu lösen

Einsatz von XSLT

  • Beim Versuch, einen RSS-Feed ansprechend darzustellen, wurde die XSLT-Spezifikation entdeckt
  • XSLT ist eine offizielle Standardtechnologie, mit der sich sowohl XML-Daten als auch HTML-Ausgabestrukturen beschreiben lassen
  • Die Verwendung ist einfach
    • Zum Beispiel werden die Daten in blog.xml organisiert
    • Anschließend wird das XSLT-Stylesheet wie folgt eingebunden
      • <?xml-stylesheet type="text/xsl" href="blog.xsl"?>
    • In blog.xsl werden dann HTML-Templates und Regeln für das Daten-Mapping definiert
  • Templates, Schleifen, Variablen, Imports externer Dateien und viele weitere Funktionen klassischer Build-Systeme werden unterstützt

Ausführung und Vorteile

  • Ohne zusätzliche Tools genügt es, die XML-Datei einfach im Webbrowser zu öffnen, und das Ergebnis der Transformation wird sofort gerendert
  • Das XML-Format ähnelt HTML und ist daher menschenfreundlich und leicht wartbar; selbst als Ersatz für JSON ist es kaum unpraktisch
  • Alle wichtigen Webbrowser unterstützen XSLT-basierte Transformationen nativ, sodass Clients das Ergebnis direkt sehen können
  • Besonders wichtig ist, dass kein JavaScript, kein separates Build-Tool und kein Bundler erforderlich sind
  • XSLT ist keine ultimative Universallösung, aber eine einfache und zugleich erweiterbare Alternative für Web-Builds

Fazit

  • Eine Wiederentdeckung des Werts älterer Technologien (XSLT) und klar definierter Standards
  • Den Webbrowser als Build-System zu verwenden, ist eine nützliche Option, die in den Werkzeugkasten der Webentwicklung gehört

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-28
Hacker-News-Kommentare

  • Das Unternehmen, in dem ich gearbeitet habe, nutzte XML-Templates mit XSLT sehr intensiv, und vermutlich ist das bis heute noch so. Ehrlich gesagt war das keine gute Entscheidung, und wenn möglich hätten sie wohl gern auf etwas anderes migriert.

    1. Obwohl es neuere Standards für XSLT gibt, dominiert immer noch Version 1.0, und diese Version ist im Vergleich zu neueren Standards eingeschränkt und an manchen Stellen seltsam.
    2. Performance-Probleme in XSLT-Templates sind extrem schwer zu lösen. XSLT ist als turing-vollständige Sprache im funktionalen Stil hinsichtlich Performance wenig transparent. Für die meisten Dokumente ist das okay, aber bei 100 Zeilen explodiert es plötzlich. Der Code zur Tabellenverarbeitung kann O(N^2)-Performance haben, und Optimierung ist fast unmöglich. Zum Beispiel kann in jeder Zeile ein O(N)-XPath stecken. Soweit ich mich erinnere, brauchte das betreffende Template mehr als 7 Minuten, um ein Dokument zu verarbeiten.
      JS hat auch Probleme, aber man ist dort zumindest nicht in einer Situation, in der sich solche algorithmische Komplexität gar nicht beheben lässt.

    • XSLT/XPath hat sich seit 1.0 ziemlich weiterentwickelt. Es kamen viele Features wie key(index) hinzu, wodurch die Verarbeitung deutlich schneller wurde. Wenn man hochwertige XSLT-Implementierungen wie Saxon verwendet, sind Performance-Probleme auch viel seltener. Ich denke, wenn man XML in etwas anderes umwandelt, gibt es nur wenige Dinge, die sich für eine logisch strukturierte Transformation so gut eignen wie XSLT.

    • XSLT ist ziemlich schwer zu lernen. Es wirkt fast wie ein traumartiges Prolog, und wenn man wirklich gut darin wird, fühlt es sich so befriedigend an wie Sudoku zu lösen. In den meisten Fällen braucht man aber keine derart komplexen Templates, daher taugt es kaum als Standardwahl. Und XML selbst ist auch kein Format, das jeder mag.

    • Ich verstehe nicht ganz, warum XSLT 1.0 angeblich noch so weit verbreitet ist. Schon 2013 galt 1.0 praktisch als Auslaufmodell, und Saxon, mit dem man XSLT 2 nutzen konnte, war kostenlos und hatte eine sehr gute Performance. Ich habe nie Performance-Probleme erlebt, weder bei großen noch bei kleinen Dokumenten.

    • Die Zeit, in der XSLT aufkam, war eine, in der man selbstverständlich sehr lange XML-Dokumente verarbeitete. Wenn sich dann solche Schleifen verschachteln, ist es nur natürlich, dass es irgendwann kracht.

    • Mich würde interessieren, ob vielleicht die kommerzielle Version von Saxon verwendet wird. Sie ist nicht teuer, und wegen Unterstützung neuer Standards, Performance und vieler Features ist sie IMHO ihr Geld wirklich wert. Als ich sie früher benutzt habe, erinnere ich mich an ziemlich clevere Optimierungen.

  • In den 90ern und 2000ern verhielten sich Browser alle unterschiedlich, daher begann man JS einzusetzen, um das Verhalten anzugleichen.
    Eigentlich wollten wir nur ansprechende CSS-Styles, aber damals konnte man sie nicht richtig nutzen.
    Mit der Zeit wurde ein Browser dominant, und die anderen wurden ihm ähnlicher (Highlander-Prinzip, auch wenn Firefox sich ziemlich gut hält).
    Frameworks waren da schon selbstverständlich geworden und etablierten sich, um in allen Browsern dieselbe UI zu erzwingen. Außerdem verlagerte sich das Paradigma hin zum Rendern von JSON-Daten.
    Heute leben wir in einer Zeit, in der selbst traditionell serverseitig erzeugte Webseiten schnell sind und wenig Speicher verbrauchen.
    Warum ich daran denke: Ich habe kürzlich bei einer Migration aus einem Legacy-System wieder eine Site erlebt, die mit seitenweisen HTTP-Requests arbeitete, also dem Standard der 2000er. Für jede Aktion war ein Reload nötig, aber trotzdem war sie viel schneller als Systeme mit React.
    Die Gründe sind:

    1. Das Internet ist sehr viel schneller geworden.
    2. Smartphones haben reichlich Speicher, und JS-Frameworks verschwenden ihn.
    3. Das Backend ist damals wie heute CRUD, CRUD, CRUD (+Paginierung, +Transaktionen).

    • AJAX und DOM-Updates kamen nicht einfach nur auf, um schneller zu sein. Es ging darum, sich vom Web-Paradigma als „Website/Webdokument“ zu lösen. Ein kompletter Page-Reload ist im dokumentenzentrierten Paradigma durchaus sinnvoll. Bei einfachen Beispielen wie HN passt diese Struktur sehr gut. Viele Sites funktionieren auch ohne JS-Frameworks mit genau so einem Aufbau vollkommen ausreichend.
      Aber zu sagen, „alle könnten wieder zu vollständigen Page-Reloads zurückkehren“, ist realitätsfern. Für echte „Webanwendungen“ mit komplexen Interaktionen ist ein kompletter Reload eine sehr schlechte UX.
      Kurz gesagt:
      Für „Websites“, „Webdokumente“ und „einfache Formulare“ reichen vollständige Page-Reloads oft aus,
      für „Webanwendungen“ mit komplexen Datenansichten und Interaktionen aber nicht.

    • Meine Erinnerung an die damalige Timeline ist etwas anders. JS wurde nicht primär eingeführt, um Browser-Verhalten zu vereinheitlichen, sondern von Anfang an für interaktive Elemente verwendet (DHTML, AJAX usw.). Das eigentliche Layout beruhte browserübergreifend fast nur auf Workarounds und User-Agent-Erkennung. Auch als CSS mächtiger wurde, löste das die Konsistenzprobleme nicht einfach. CSS garden, semantisches Markup und exzessive Tabellenlayouts prägten diese Zeit, und selbst bis zum ersten bestandenen ACID-Test dauerte es wirklich lange. Ich bin skeptisch, welchen Einfluss Frameworks auf UI-Konsistenz tatsächlich hatten — seit jQuery war CSS selbst der Hauptfaktor für visuelle Konsistenz.
      Natürlich kann das auch einfach meine persönliche Erinnerung sein.

    • Ich stimme zu, dass traditionell servergerenderte Webseiten mit modernen Stacks schnell und leichtgewichtig sind.
      In meinem .NET/Kestrel/SQLite-Stack ist es schwer, mit SSR-Antworten über 4 ms zu kommen. Meistens liegen sie im Bereich von 100 Mikrosekunden. Auf jeder Seite laufen mehrere Queries und komplexe Joins, um die Daten genau in die Form für die View zu bringen.
      Selbst im Extremfall mit einer Tabelle aus 100.000 Zeilen steigt die Performance stark, wenn man die Daten vor dem Zusammenbauen des HTML-Strings gut aufbereitet. LINQ hat auch eine enorme Performance, aber wenn man pro Zeile Collections erzeugt, wird das mit wachsender Datenmenge sehr ineffizient.
      Meiner Erfahrung nach ist Performance-Optimierung am besten, wenn HTML-Template-Engine und Datenbank so eng wie möglich gekoppelt sind. Am Ende ist das DOM nur ein Bytestrom. Statt komplexe ASTs oder Parser zu bauen, reichen oft einfach StringBuilder und SQL-Queries.
      Der Einwand gegen diesen simplen Ansatz war immer nur die Debatte mit Security-Leuten, die Entwicklern kein korrektes HTML-Escaping zutrauen.

    • Die Aussage „Mit moderner Technik kann man auf dem Server alte klassische Webseiten problemlos liefern“ sieht völlig anders aus, wenn die Netzwerklatenz hoch ist.
      Referenzlink

  • In den 2000ern wurde Enterprise-XML so überladen, dass die Technik veraltet wirkte, und am Ende verfielen alle dem „sauberen“ Eindruck von JSON. Tatsächlich waren Technologien wie XSLT und XPath damals schon sehr ausgereift und lösten viele Probleme, über die wir auch heute noch nachdenken.
    Ich selbst habe früher XSLT-include massiv missbraucht und mit PHP-Stream-Wrappern Dinge wie <xsl:include href="mycorp://invoice/1234"> gebaut.
    Ehrlich gesagt wirkt das heute vielleicht etwas altmodisch, aber lokale XSLT-Verarbeitung im Browser fühlt sich für mich immer noch unsicher an. Früher war das ein echtes Kompatibilitätsminenfeld.

    • Ich vermisse an JSON bis heute einige der „Standard“-Elemente von XML. Dinge wie wirklich standardisierte Spezifikationen oder Schema-Definitionen waren bei XML deutlich besser, und JSON brauchte fast 10 Jahre, um aufzuholen.
      Das letzte Mal, dass ich XML ernsthaft verwendet habe, war mit EXI als Übertragungstechnik. Dabei wurden XML-Dokumente in komprimierte Binärströme umgewandelt — also Struktur ↔ ASCII-Konvertierung ↔ Kompression/Transport ↔ Rückkonvertierung, natürlich umständlich. Heute dominieren protobuf und gRPC, aber wenn XML weitergeführt worden wäre, hätten wir vielleicht eine Welt bekommen, in der alles auf kompatiblen Standards basiert — zumindest in meiner idealisierten Vorstellung. Tatsächlich gibt es zwischen protobuf/gRPC und JSON-APIs aber enorme Hürden, und vielleicht ist das am Ende sogar besser so.

    • Ich finde XML ein ordentliches Format. Es ist umfangreich und wortreich, aber im Vergleich zu YAML bei Präzision und Ausdrucksstärke deutlich überlegen.
      An XPath muss man sich erst gewöhnen, aber wenn man damit experimentiert, kommt man letztlich fast immer ans Ziel.
      XSLT halte ich dagegen für ein vollkommen verrücktes Konzept. Es sollte abgeschafft werden.

    • Das Spiel Rimworld speichert sämtliche Konfigurationsdaten in XML und macht Modding über XPath möglich. Diese Kombination ist wirklich mächtig. Für die Anpassung lokaler Daten gibt es kaum etwas Besseres. Aber die meisten Spiele scheinen so etwas zu meiden, weil XML als „veraltet“ abgestempelt ist.
      Offizielle Dokumentation zu XPath-Modding in Rimworld

    • Dass Enterprise-XML Anfang der 2000er so aufgebläht war, stimmt wirklich. XML war ursprünglich eine vereinfachte Version von SGML, um es für das Web nutzbar zu machen, gedacht zur Übertragung von Markup und zur Erweiterung von Vokabularen. Am Ende haben im Grunde nur SVG und MathML überlebt. Vom Web-Boom getrieben haben W3C und Microsoft massenhaft SOAP-, WS-*‑Spezifikationen und Ähnliches herausgebracht. Es war eine wahnsinnige Zeit, in der sogar Sprachen wie XSLT mit Scheme-Knochen gewaltsam in XML gepresst wurden. Selbst JavaScript stammt aus einer Ära, in der man schon beim Namen Anleihen bei Java nahm.

    • Bei XPath stört mich, dass man wegen Namespaces oft unerquicklich lange Queries schreiben muss.

  • Ich style meine Feeds auch heute noch mit XSLT.
    RSS-Feed-Beispiel
    XSLT-Beispiel

    • Wenn ich so etwas sehe, denke ich manchmal, dass Blogs vielleicht einfach RSS-Feeds hätten sein sollen.

    • Ich vergesse immer wieder, dass XML so etwas ursprünglich konnte. Irgendwie fühlt es sich intuitiv seltsam an.

    • Wirklich sehr schön gemacht. Ich wünschte, mehr Leute würden solche Beispiele kreativ aufgreifen.

  • In meinem ersten Job (mit 19) war ich für die Anpassung einer Google Search Appliance zuständig. Das war ein Projekt mit gelben Dell-Servern für mehrere tausend Euro, CentOS darauf, etwas Google-artigem Python und Volltextsuche über CIFS-Dokumente.
    Um 2011 war XHTML groß, und in der Google Search Appliance wurden Backend-XML-Daten per XSLT in XHTML transformiert. Ich habe die Beispiel-Templates regelrecht zerlegt und daraus ein monströses UI für unser Intranet gebaut, zusammengeflickt aus Coldfusion, StackOverflow, W3Schools und anderen vorhandenen Versatzstücken.
    Diese Station habe ich schnell aus meinem Lebenslauf entfernt. Danach wollten mich DoD-Unterauftragnehmer ständig als „XML-Experten“ für Projekte zur Modernisierung von Dokumentensystemen anheuern, was ziemlich lästig war.
    Wenn du das nächste Mal mit JSX Arrays aus JSON durchläufst, um TypeScript-Interfaces zu füttern, dann denk an meine Geschichte. Immerhin ist es immer noch besser, als das mit XSLT zu machen.

  • Ich bin definitiv ein Verfechter von Einfachheit. Ich mag simple Dokumentation wie ein README für Höhlenmenschen. Manchmal fühle ich mich selbst wie ein Höhlenmensch, der auf die Tastatur einschlägt. Ich mache nichts mit Websites und kenne mich mit XSLT nicht gut aus. Gelegentlich hacke ich etwas mit XML zusammen und will Nutzern etwas zeigen. Zu viele Dateiformate machen mir den Kopf schwer. Trotzdem mag ich Dinge, die gut aussehen. Ich werde das vielleicht selbst benutzen.
    Danke dafür, dass du die Spezifikation gelesen hast, und danke dafür, dass du das Tool gebaut hast.

  • Viele sagen, XML sei wortreich und komplex, aber wenn man direkt damit arbeitet, ist es ein hervorragendes Format.
    Man kann mit DTD validieren und mit XSLT ausgeben, sodass es für Menschen gut lesbar wird.
    Für mich ist XML unter den Textformaten wie C++: ausgereift, „batteries included“, leistungsfähig und mit praktisch jeder Sprache verbindbar.
    Wie bei alten, reifen Sprachen finde ich es schade, dass es zum Trend geworden ist, XML pauschal als Stoff für Sonderlinge abzutun. Wenn es für einen Zweck nicht passt, sollte man es eben nicht verwenden — aber so viel Hass verdient es nicht.

    • Ich frage mich, warum du DTD statt XSD verwendest.

  • Die Aussage „XSLT läuft direkt im Browser“ überrascht mich. Als ich zuletzt XSLT benutzt habe, ist das 20 Jahre her, und damals wurde seine eigene Ästhetik von kompliziertem Enterprise-Java völlig überdeckt.
    Wenn XSLT aber direkt im Browser läuft, war der heilige Gral wirklich statischer Templates ohne Host-Framework dann vielleicht zum Greifen nah?

    • Browser unterstützen nur XSLT 1.0. Und selbst das könnte künftig noch verschwinden. Würden Browser stattdessen bis 3.0 unterstützen, wäre das für die Erzeugung statischer Webseiten enorm nützlich.

    • Ich habe es auch anders erlebt: Man musste nicht zwingend einen riesigen Enterprise-Java-Turm einsetzen. Wir haben einfach Tomcat und ein paar Apache-Bibliotheken genutzt, und das funktionierte ziemlich gut. Das CMS erzeugte HTML aus XML, Personalisierung wurde in Form von XML-Tags eingebaut, und dank serverseitigem Caching-Proxy liefen die Transformationen schnell genug, um viel Traffic zu bewältigen. Der Schlüssel war, den XSLT-Ausgabestrom sofort an den Client zu senden statt alles im Speicher zu puffern.
      Heute kann man mit WASM fast alles im Browser ausführen, aber frühes JS war katastrophal, und man war schon froh, wenn Designer einem wenigstens Photoshop-PSDs lieferten. Es war die Zeit von Google Maps und Gmail, in der man verbissen JS-lastige UIs baute und gleichzeitig sowohl Netscape als auch Internet Explorer unterstützen musste — die reine Hölle.

    • Der XHTML-Boom begann tatsächlich auch wegen genau dieses „heiligen Grals statischer Templates“. Aber die Leute, die sich wirklich auskannten, sprachen fast in Andeutungen darüber, als wäre es Slang, und kaum jemand sagte es offen.

    • Ich habe 2008 an einer Site mit browserinternem XSLT gearbeitet, und Unterstützung gab es schon in den frühen 2000ern.

    • In Chrome steckt libxslt, in Firefox eine 1.0-Engine namens Transformiix. Chrome unterstützt nur exsl:node-set, Firefox diverse EXSLT-Erweiterungen, wenn auch nicht alle.
      Ich habe auch ein kleines Tool veröffentlicht, das einfache Informationen über den XSLT-Prozessor und verfügbare Erweiterungen ausgibt.
      GitHub - xslt-detect-ext
      Man kann die Datei out/detect.xslt im Browser per Drag-and-drop öffnen, um die Informationen zu sehen (Chrome, Firefox). Safari funktionierte auf älteren Windows-Versionen nicht.

  • Als ich in den 90ern als Oberschüler „Webdesigner“ genannt wurde, habe ich mit einer DSSSL-Dialekt-Pipeline Sites automatisch aus Newsfeeds erzeugt. Ich mag XSLT-Transformationen bis heute. Mit Tools wie bananas XI reader mache ich sogar echte Texttransformationen und Template-Arbeit direkt selbst.
    Aber es gab nur sehr wenige Menschen, die solche Toolchains wirklich mochten, und sobald jemand anderes meinen Platz übernahm, verschwanden die eingeführten Technologien meist sehr schnell wieder.
    bananas XI reader

  • Um zu zeigen, wie extrem der XML- und XSLT-Hype Anfang der 2000er war: Das Unternehmen, in dem ich arbeitete, baute sogar einen ASIC, der XML in Echtzeit parsen und XSLT direkt auf dem Chip verarbeiten konnte. Damals glaubte man, dass das zukünftige Internet komplett auf XML/XSLT basieren würde.
    Tatsächlich wurde die Firma später von Intel übernommen, und die Technologie floss in SSE-Beschleuniger ein.

    • Wenn sich eine Architektur durchgesetzt hätte, bei der XML und sogar XSLT direkt im ASIC verarbeitet werden, wären Websites heute vielleicht unglaublich schnell.

    • IBM verkauft immer noch Hardware mit ähnlichen Funktionen, nämlich das DataPower Gateway.