XSLT — un système de build natif et sans configuration pour le web

• XSLT est un outil de build natif pour le web, utilisable immédiatement sans système de build complexe
• La plupart des systèmes de build pour sites statiques posent des problèmes de complexité, de compréhension difficile et de dépendance à un framework
• En utilisant XML et XSLT, il est possible de générer du HTML directement dans le navigateur, ce qui facilite le traitement de données dynamiques et la génération de balisage
• Tous les principaux navigateurs prennent en charge les transformations basées sur XSLT, ce qui permet une utilisation sans JavaScript supplémentaire ni outil séparé
• Ce n’est pas une solution parfaite, mais c’est une alternative simple et souple, fondée sur les standards du web, avec une forte valeur pratique

---

Introduction et constat

• La plupart des développements de sites web statiques reposent sur des fichiers de données (.json, .md, .txt), un système de build séparé (Hugo, Next.js, Astro, etc.) et une structure de sortie HTML
• Les systèmes de build gagnent en complexité, et même un petit blog devient de plus en plus difficile à comprendre et à exploiter
• Lorsqu’on écarte les frameworks pour travailler simplement avec du HTML, du CSS et des standards (HTTP, URI, HTML), on se heurte à des limites de maintenance, comme la répétition des en-têtes ou des pieds de page
• Des tentatives ont été faites avec les HTML imports ou les web components, mais les premiers ne sont pas pris en charge et les seconds ne constituent pas une alternative satisfaisante à cause de leur dépendance au moteur JavaScript

Utiliser le navigateur web comme système de build

• L’idée part du fait que le navigateur web lui-même prend en charge diverses transformations de données (text/html, text/markdown, application/xml, etc.)
• En examinant en profondeur les spécifications du web, l’auteur a cherché une solution sans outils externes ni frameworks inutiles

L’usage de XSLT

• En voulant afficher joliment un flux RSS, l’auteur a découvert la spécification XSLT
• XSLT est une technologie standard officielle qui permet d’exprimer à la fois les données XML et la structure de sortie HTML
• Son utilisation est simple
  • Par exemple, organiser les données dans blog.xml
  • Puis lier une feuille de style XSLT ainsi
    • <?xml-stylesheet type="text/xsl" href="blog.xsl"?>
  • Dans blog.xsl, écrire le template HTML et les règles de correspondance des données
• Templates, boucles, variables, import de fichiers externes et la plupart des fonctions d’un système de build sont pris en charge

Exécution et avantages

• Sans outil supplémentaire, il suffit d’ouvrir le fichier XML dans un navigateur web pour que le résultat de la transformation soit rendu immédiatement
• Le format XML ressemble au HTML, ce qui le rend lisible par l’humain et facile à maintenir ; son usage à la place de JSON reste peu contraignant
• Tous les principaux navigateurs web prennent nativement en charge les transformations XSLT, ce qui permet au client de voir directement le résultat
• Le fait qu’il ne faille ni JavaScript, ni outil de build séparé, ni bundler est un avantage majeur
• XSLT n’est pas une solution universelle ultime, mais une alternative de build web simple et extensible

Conclusion

• Redécouverte de la valeur des anciennes technologies (XSLT) et des standards clairs
• Utiliser le navigateur web comme système de build est une option utile à ajouter à la boîte à outils du développeur web

[GN⁺]

Commentaires sur Hacker News

• L’entreprise où j’ai travaillé utilisait énormément XSLT dans des templates XML, et il est probable que ce soit encore le cas aujourd’hui. Honnêtement, ce n’était pas un bon choix, et ils auraient sans doute voulu migrer vers autre chose si cela avait été possible

  1. XSLT a des standards modernes, mais c’est encore la version 1.0 qui domine ; elle est limitée et pleine d’aspects bizarres par rapport aux standards plus récents
  2. Les problèmes de performance dans les templates XSLT sont extrêmement difficiles à résoudre. Comme XSLT est un langage fonctionnel Turing-complet, le coût des performances est peu visible. Pour la plupart des documents, ça passe, puis dès qu’on reçoit 100 lignes, tout explose. Le code qui traite le tableau a une complexité en O(N^2), donc c’est presque impossible à optimiser. Par exemple, il peut y avoir un XPath en O(N) dans chaque ligne. Si je me souviens bien, ce template mettait plus de 7 minutes à traiter un seul document.
     JS a aussi ses problèmes, mais au moins on n’est pas coincé à ne pas pouvoir corriger ce genre de complexité algorithmique

  • XSLT/XPath ont beaucoup progressé depuis la 1.0. Diverses fonctions comme key (index) ont été ajoutées et ont considérablement accéléré le traitement. Si on utilise une implémentation XSLT de qualité comme Saxon, les problèmes de performance sont aussi bien moindres. Pour transformer du XML vers autre chose, je trouve qu’il y a peu d’outils aussi pratiques que XSLT pour structurer la logique

  • XSLT est assez difficile à apprendre. C’est un peu comme un Prolog onirique, et quand on le maîtrise vraiment, on ressent presque l’excitation d’une grille de sudoku qu’on résout. Mais dans la plupart des cas, on n’a pas besoin de templates aussi complexes, donc ça a du mal à devenir un choix standard. Et puis XML lui-même n’est pas un format que tout le monde aime

  • J’ai du mal à comprendre l’idée que XSLT 1.0 soit encore autant utilisé. Déjà en 2013, la 1.0 était presque considérée comme obsolète, et Saxon, qui permettait d’utiliser XSLT 2, était gratuit et très performant. Je n’ai jamais eu de problème de performance en transformant des documents, qu’ils soient gros ou petits

  • L’époque où XSLT est arrivé était justement celle où il était normal de traiter des XML dont le corps était très long. Cela dit, dès qu’on imbrique ce genre de boucles répétitives, il est logique que ça finisse par casser

  • Je me demande si vous utilisez la version commerciale de Saxon. Ce n’est pas très cher et, entre le support des nouveaux standards, les performances et les diverses fonctionnalités, IMHO ça vaut vraiment le coup. Quand je l’utilisais, il me semble qu’il y avait des optimisations assez intelligentes

• Dans les années 90-2000, les navigateurs avaient chacun leur comportement, donc on a commencé à introduire du JS pour uniformiser le fonctionnement
  En réalité, ce qu’on voulait, c’était surtout de jolis styles CSS, mais à l’époque on ne pouvait pas vraiment les utiliser correctement
  Puis, avec le temps, un navigateur a pris l’ascendant et les autres sont devenus beaucoup plus similaires (règle du Highlander, même si Firefox se défend encore assez bien)
  Les frameworks étaient déjà devenus la norme, et se sont installés comme moyen d’obtenir la même UI sur tous les navigateurs. Ensuite, tout le paradigme a glissé vers le rendu de données JSON
  Aujourd’hui, même quand on génère des pages web traditionnelles côté serveur, c’est rapide et peu gourmand en mémoire
  Si j’y pense, c’est parce que j’ai récemment remigré un système legacy et j’ai redécouvert un site qui fonctionnait avec des requêtes HTTP page par page, comme on le faisait dans les années 2000. Il fallait recharger la page à chaque action, mais malgré ça, c’était bien plus rapide qu’un système utilisant React
  Les raisons :

  1. Internet est devenu très rapide
  2. Les téléphones ont beaucoup de mémoire, et les frameworks JS la gaspillent
  3. Le back-end, hier comme aujourd’hui, c’est CRUD, CRUD, CRUD (+ pagination, + transactions)

  • AJAX et la mise à jour du DOM ne sont pas apparus simplement pour aller plus vite. C’était pour sortir du paradigme du web comme « site web/document web ». Le rechargement complet de la page est une approche qui a du sens dans un paradigme centré sur le document. Pour des exemples simples comme HN, cette structure fonctionne très bien. Beaucoup de sites peuvent parfaitement s’en sortir ainsi sans framework JS.
    Mais dire que « tout le monde pourrait revenir au rechargement complet de page » est loin de la réalité. Pour de vraies « applications web » qui demandent des interactions complexes, recharger toute la page est une très mauvaise UX.
    En résumé,
    pour les « sites web », « documents web », « formulaires simples », le rechargement complet de page suffit souvent,
    mais pour les « applications web » qui nécessitent des écrans de données et des manipulations complexes, ce n’est pas le cas

  • Mon souvenir de la chronologie est un peu différent. On n’utilisait pas JS principalement pour uniformiser les navigateurs, mais dès le départ pour les éléments interactifs (DHTML, AJAX, etc.). La mise en page, elle, reposait vraiment sur des astuces et de la détection d’agent utilisateur selon le navigateur. Même quand CSS est devenu plus puissant, les problèmes de cohérence ne se sont pas réglés facilement. C’était l’époque de CSS Zen Garden, du balisage sémantique, des tableaux partout, et il a fallu un temps fou avant même le premier passage réussi des tests ACID. Je suis sceptique sur l’impact réel des frameworks sur la cohérence UI — à partir de jQuery, c’est surtout CSS lui-même qui a porté la cohérence visuelle.
    Mais c’est peut-être juste mon souvenir personnel

  • Je suis d’accord pour dire qu’avec les stacks modernes, les pages web traditionnelles rendues côté serveur sont rapides et légères
    Sur ma stack .NET/Kestrel/SQLite, il est difficile de dépasser 4 ms pour une réponse SSR. La plupart du temps, on est plutôt dans les centaines de microsecondes. Chaque page utilise plusieurs requêtes et des jointures complexes pour donner aux données la forme attendue par la vue
    Même dans des cas extrêmes comme la génération d’un tableau de 100 000 lignes, les performances montent fortement si le traitement des données est bien fait avant la composition des chaînes HTML. Les performances de LINQ sont excellentes, mais si on crée des collections ligne par ligne, cela devient au contraire très inefficace quand le volume de données augmente
    D’après mon expérience, pour optimiser les performances, il vaut mieux rapprocher au maximum le moteur de template HTML et la base de données. Au final, le DOM n’est qu’un flux d’octets. Pas besoin de construire un AST/parser complexe quand un StringBuilder et quelques requêtes SQL suffisent.
    La seule objection récurrente à cette approche simple, c’était toujours le débat côté sécurité : « on ne peut pas faire confiance aux développeurs pour échapper correctement le HTML »

  • Dire qu’« avec les technologies modernes, le serveur peut largement gérer à l’ancienne des pages web classiques » devient une tout autre histoire si la latence réseau est élevée
    Lien de référence

• Dans les années 2000, l’XML d’entreprise est devenu tellement énorme que la technologie a fini par paraître datée, et tout le monde est tombé sous le charme de la « propreté » du JSON. En réalité, des technologies comme XSLT et XPath étaient déjà très abouties et résolvaient beaucoup de problèmes sur lesquels on se casse encore la tête aujourd’hui
  Moi aussi, j’ai énormément abusé de include en XSLT ; j’utilisais des wrappers de flux PHP avec des trucs comme <xsl:include href="mycorp://invoice/1234">
  Honnêtement, ça peut sembler un peu rétro aujourd’hui, mais je reste encore méfiant à l’idée de laisser le navigateur traiter du XSLT localement. À l’époque, c’était un vrai champ de mines côté compatibilité

  • Les éléments « de base » de XML me manquent encore dans JSON. Par exemple, le fait d’avoir une vraie spécification standardisée, ou la définition de schémas : sur ces points, XML était largement supérieur, et il a fallu presque 10 ans à JSON pour rattraper son retard
    La dernière fois que j’ai vraiment manipulé du XML, c’était avec une technologie de transport appelée EXI. Elle transformait les documents XML en flux binaire compressé ; il fallait faire structure ↔ ASCII ↔ compression/transfert ↔ conversion inverse, ce qui était bien sûr fastidieux. Aujourd’hui, protobuf et gRPC dominent, mais si XML était resté au centre, on aurait peut-être vécu dans un monde (du moins dans mon imaginaire idéal) où tout reposait sur des standards interopérables. En pratique, un énorme fossé s’est créé entre protobuf/gRPC et les API JSON, mais c’est peut-être finalement une bonne chose

  • Je trouve que XML est un bon format. C’est volumineux et verbeux, mais comparé à YAML, c’est bien supérieur en précision et en expressivité
    XPath est difficile à apprivoiser, mais quand on expérimente un peu, on finit par pouvoir faire ce qu’on veut
    XSLT, en revanche, est un concept complètement dingue. Ça devrait disparaître

  • Le jeu Rimworld stocke toutes ses données de configuration en XML et permet le modding via XPath. Cette combinaison est vraiment puissante. Pour personnaliser des données locales, c’est difficile de faire mieux. Mais la plupart des jeux semblent éviter ce genre de chose parce que XML a été étiqueté comme « dépassé »
    Documentation officielle du modding XPath de Rimworld

  • C’est tout à fait vrai de dire que l’XML d’entreprise du début des années 2000 a énormément enflé. À l’origine, XML était une version simplifiée de SGML pour pouvoir l’utiliser sur le web, avec pour but de transporter du balisage et d’étendre des vocabulaires. Au final, seuls SVG et MathML ont vraiment survécu. Emportés par la vague du web, le W3C et Microsoft ont déversé à la chaîne SOAP, les specs WS-*, etc. C’était une époque de pure folie où on forçait même des langages comme XSLT, avec leur squelette de Scheme, à entrer dans le moule XML. Même JavaScript doit son nom à cette logique d’analogie avec Java

  • XPath est frustrant parce que les espaces de noms obligent à écrire des requêtes interminables

• J’utilise encore XSLT aujourd’hui pour styliser mon flux.
  Exemple de flux RSS
  Exemple de XSLT

  • En voyant ça, on se dit presque qu’un blog aurait toujours dû être simplement un flux RSS

  • J’oublie toujours que XML sait faire ce genre de chose à l’origine. Il y a quelque chose qui paraît intuitivement un peu étrange

  • C’est vraiment très bien réalisé. J’aimerais que davantage de gens adoptent ce genre d’exemple de façon créative

• À mon premier emploi (à 19 ans), on m’avait confié la personnalisation de Google Search Appliance. C’était un projet consistant à installer CentOS sur ces serveurs Dell jaunes à plusieurs milliers d’euros, à mettre en place de la recherche plein texte sur des documents CIFS avec du Python « à la Google »
  Vers 2011, XHTML était à la mode, et dans Google Search Appliance, les données XML du back-end étaient transformées en XHTML via XSLT. J’ai explosé les templates d’exemple pour bricoler une UI monstrueuse adaptée à notre intranet, en recyclant et en recollant des bouts de Coldfusion, StackOverflow, W3Schools et d’autres ressources existantes
  J’ai vite effacé cette expérience de mon CV. Ensuite, des sous-traitants du DoD (ministère de la Défense) n’arrêtaient pas de me contacter en me présentant comme un « expert XML » pour des projets de modernisation de systèmes documentaires, et c’était épuisant
  La prochaine fois que vous soupirerez en écrivant du JSX pour boucler sur un tableau de JSON vers des interfaces TypeScript, pensez à mon histoire. C’est toujours mieux que de faire ça en XSLT

• Oui, je suis bien un partisan de la simplicité. J’aime les documents simples comme un readme d’homme des cavernes. Parfois, j’ai même l’impression de taper sur le clavier comme un homme des cavernes. Je ne fais pas de sites web et je connais mal XSLT. Il m’arrive de bricoler avec XML, et j’ai envie de montrer aux utilisateurs quelque chose de lisible. Il y a trop de formats de fichier et ça me donne mal à la tête. Mais j’aime quand c’est beau à regarder. Je pourrais bien utiliser ça moi aussi
  Merci d’avoir lu la spécification, et merci d’avoir créé l’outil

• Beaucoup disent que XML a l’air verbeux et complexe, mais quand on le manipule directement, c’est un excellent format
  On peut le valider avec un DTD et produire une sortie lisible par des humains avec XSLT
  Pour moi, XML est au format texte ce que C++ est aux langages : mature, « batteries included », puissant, et connectable à n’importe quel langage
  Comme pour les vieux langages matures, je trouve dommage qu’il soit devenu tendance de traiter XML de contenu pour excentriques. Si ça ne convient pas au cas d’usage, il suffit de ne pas l’utiliser, mais il n’y a pas lieu de le détester à ce point

  • Pourquoi ne pas utiliser XSD plutôt que DTD ? Je suis curieux

• Je trouve fascinant d’entendre que « XSLT fonctionne directement dans le navigateur ». La dernière fois que j’ai utilisé XSLT, c’était il y a 20 ans, et à l’époque j’avais l’impression que toute l’esthétique propre à XSLT se faisait écraser par l’énorme complexité de l’enterprise Java.
  Mais si XSLT fonctionne nativement dans le navigateur, est-ce qu’on avait déjà presque sous la main le Graal d’un vrai templating statique sans framework hôte ?

  • Les navigateurs ne prennent en charge que XSLT 1.0. Et même cela pourrait disparaître un jour, d’après certaines discussions. C’est dommage : si les navigateurs allaient jusqu’à la 3.0, cela deviendrait extrêmement utile pour générer des pages web statiques

  • Je n’ai pas toujours eu l’expérience selon laquelle il fallait absolument cette tour de « grosse enterprise Java ». Nous, on utilisait seulement Tomcat et quelques bibliothèques Apache, et ça marchait plutôt bien. Le CMS produisait du HTML à partir de XML, la personnalisation était injectée sous forme de balises XML, et grâce à un proxy de cache côté serveur, les transformations étaient rapides et supportaient beaucoup de trafic. Le point clé, c’était d’envoyer immédiatement le flux de sortie XSLT au client, sans tout bufferiser en mémoire.
    Aujourd’hui, avec wasm, on peut faire tourner n’importe quoi dans le navigateur, mais au début JS était catastrophique, et les designers étaient déjà contents quand ils nous donnaient un PSD Photoshop exploitable. L’époque de Google Maps et Gmail, où il fallait construire des UI très chargées en JavaScript tout en supportant à la fois Netscape et Internet Explorer, c’était un véritable enfer

  • Si l’engouement pour XHTML a commencé, c’était justement à cause de ce « Graal du templating statique ». Mais ceux qui savaient de quoi il s’agissait en parlaient à demi-mot, comme un argot, et personne ne l’énonçait vraiment ouvertement

  • J’ai travaillé en 2008 sur un site XSLT exécuté dans le navigateur, et c’était déjà pris en charge au début des années 2000

  • Chrome embarque libxslt, Firefox embarque un moteur 1.0 appelé Transformiix. Chrome ne prend en charge que exsl:node-set, tandis que Firefox gère diverses extensions EXSLT (pas toutes)
    J’ai aussi publié un petit outil qui indique des informations simples sur le processeur XSLT et la liste des extensions disponibles.
    GitHub - xslt-detect-ext
    On peut glisser le fichier out/detect.xslt dans le navigateur pour consulter ces informations (Chrome, Firefox). Safari ne le faisait pas sur son ancienne version Windows

• Quand j’étais lycéen dans les années 90 et qu’on m’appelait « webdesigner », j’utilisais un pipeline de dialectes DSSSL pour générer automatiquement des sites à partir de flux d’actualités. J’aime encore aujourd’hui les transformations XSLT. J’utilise aussi moi-même des outils comme bananas XI reader pour de vraies transformations de texte et du travail sur templates
  Mais très peu de gens ont vraiment aimé ce type d’outillage, et quand quelqu’un d’autre prenait ma place, la technologie mise en place disparaissait souvent très vite
  bananas XI reader

• Pour montrer à quel point la vague XML/XSLT était forte au début des années 2000 : dans l’entreprise où je travaillais, nous sommes allés jusqu’à fabriquer un ASIC capable de parser du XML à vitesse réelle et même de traiter du XSLT directement sur la puce. À l’époque, on croyait que tout l’internet du futur fonctionnerait en XML/XSLT
  En pratique, l’entreprise a été rachetée par Intel, et cette technologie s’est retrouvée du côté des accélérateurs SSE

  • J’imagine à quel point les sites web seraient rapides aujourd’hui si ce genre d’architecture, capable d’interpréter XML et même XSLT directement sur ASIC, était devenu courant

  • IBM vend encore du matériel intégrant des fonctions comparables (DataPower Gateway)