- On peut utiliser XSLT comme un système de build côté client exécuté dans le navigateur Web pour transformer des données XML en HTML et réduire la complexité des générateurs de sites statiques
- Un site statique classique se compose de données comme
.json, .md, .txt, d’un système de build comme Hugo, Next.js ou Astro, puis d’une sortie HTML statique, mais les gros frameworks peuvent apporter une complexité excessive même pour un simple blog en Markdown
- Si l’on veut s’en tenir à HTML et CSS uniquement, il faut copier manuellement les en-têtes et pieds de page sur plusieurs pages ; il n’existe pas de HTML import, et les Web Components exigent un moteur JavaScript
- En ajoutant
<?xml-stylesheet type="text/xsl" href="blog.xsl"?> à un document XML et en écrivant des templates XSLT, le navigateur peut générer une sortie HTML au moment de la visite
- Cette approche peut être déployée sous forme de fichiers statiques sans JavaScript, mais ce n’est pas une solution parfaite qui remplace tout ; c’est simplement une option supplémentaire à ajouter à la boîte à outils du développement Web
La complexité du build des sites statiques
- Le flux classique de création d’un site Web statique se divise en données, système de build et sortie HTML statique
- Les données sont stockées dans des fichiers comme
.json, .md, .txt
- Parmi les exemples de systèmes de build, on trouve Hugo, Next.js et Astro
- Le résultat final est du HTML statique
- Même si l’on veut supprimer les frameworks et n’utiliser que HTML et CSS, dès que le nombre de pages augmente, il faut continuer à recopier les en-têtes et pieds de page communs
- Les alternatives que l’on peut envisager ont chacune leurs limites
- Les HTML imports n’existent pas
- Les Web Components nécessitent JavaScript, et donc un moteur JavaScript
L’idée d’utiliser le navigateur comme système de build
- Le navigateur Web sait déjà comprendre plusieurs formats comme
text/html, text/markdown et application/xml
- Si l’on utilise le navigateur comme système produisant du HTML à partir de données, on peut créer un flux fondé sur les standards du Web sans outil de build séparé
- En cherchant à mieux afficher un flux RSS, l’auteur a découvert que l’on pouvait utiliser XSLT comme feuille de style pour les documents XML
- XML ressemble à HTML, mais c’est un format de représentation de données qui ne se limite pas aux données du Web ; on peut le vérifier dans la spécification XML
Transformer du XML en HTML
- Un document XML peut contenir des données comme des articles de blog
<?xml version="1.0"?>
<blog>
<post id="42" publishedAt="2025-06-26">
<title>Hello XSLT</title>
<tags>…</tags>
</post>
</blog>
- On peut ajouter au document XML une déclaration liant une feuille de style XSL
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="blog.xsl"?>
<blog>
<post id="42" publishedAt="2025-06-26">
<title>Hello XSLT</title>
<tags>…</tags>
</post>
</blog>
- Un template XSLT prend une entrée XML et produit une structure HTML
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">;
<xsl:output method="html" indent="yes" />
<xsl:template match="/">
<html>
<head> … </head>
<body> … </body>
</html>
</xsl:template>
</xsl:stylesheet>
- XSLT peut être vu comme
(XML) => HTML et fournit des fonctions de système de build comme les boucles, les variables et les imports
- Les données du document XML parent peuvent être récupérées dans XSLT et affichées dynamiquement
<head>
<xsl:value-of select="title" /> | Blog
</head>
Exécution et déploiement
- On peut lancer la transformation XSLT en ouvrant le fichier XML dans le navigateur
open blog.xml -a Safari
- Tous les navigateurs Web prennent en charge la transformation XSLT lors de la visite d’une page et affichent le HTML résultant
- Cette approche fonctionne comme un système de build côté client exécuté sur l’ordinateur de l’utilisateur
- Elle est facile à déployer sous forme de fichiers statiques et fonctionne sans JavaScript
Limites et positionnement
- Les données du blog doivent être stockées en XML plutôt qu’en JSON, mais XML ressemble à HTML, est facile à parser, flexible et pris en charge nativement sur le Web
- L’approche XSLT n’est pas parfaite et ne remplace pas tout
- En exploitant d’anciens standards, spécifications et fonctionnalités des navigateurs, elle devient un autre outil possible pour créer des sites Web statiques simples
1 commentaires
Avis de Hacker News
J’ai travaillé dans une entreprise qui utilisait beaucoup XSLT pour des modèles XML ; ce n’était pas une bonne expérience, et si cela avait été possible, nous aurions probablement migré ailleurs.
Même avec de nouveaux standards, XSLT 1.0 reste dominant, et il est limité et étrange par rapport aux standards plus récents.
Résoudre les problèmes de performance des modèles XSLT relève presque de l’enfer. C’est un langage fonctionnel Turing-complet, mais les performances y sont très abstraites : un modèle qui fonctionne bien sur la plupart des documents peut exploser sur un simple tableau de 100 lignes. On se rend compte que le modèle de traitement du tableau est en O(N^2), voire pire, et que pour chaque ligne, XPath peut à nouveau être en O(N), voire pire, sans méthode d’optimisation évidente. De mémoire, traiter un seul document avec XSLT prenait plus de 7 minutes.
JS a sans doute d’autres problèmes, mais l’incapacité à résoudre les problèmes de complexité algorithmique n’en fait pas partie.
On peut désormais accélérer fortement les traitements avec des fonctionnalités comme key (index), et de bonnes implémentations XSLT comme Saxon aident aussi clairement côté performances.
Pour transformer du XML vers d’autres formats, XSLT est assez pratique, car il permet de structurer la logique.
En 2013, j’utilisais beaucoup XSLT, et à l’époque, 1.0 était déjà complètement mort partout où je regardais. Saxon était gratuit pour XSLT 2 et excellent.
J’ai transformé à la fois d’énormes documents et un grand nombre de petits documents, sans aucun problème de performance.
Une fois maîtrisé, cela donne la satisfaction de résoudre un sudoku, mais en général, on peut atteindre l’objectif avec beaucoup moins d’outils, ce qui rend difficile d’en faire l’approche standard pour le build ou les templates.
En plus, XML n’est pas non plus un format apprécié de tout le monde.
Si je me souviens bien, elle faisait aussi des optimisations assez intelligentes.
C’est peut-être une hypothèse assez hasardeuse, mais dans les années 1990-2000, les navigateurs se comportaient tous différemment, donc on a commencé à utiliser JS pour obtenir le même comportement partout, alors qu’en réalité ce dont on avait besoin, c’était de bons styles CSS et d’un comportement cohérent.
Avec le temps, les navigateurs ont commencé à se comporter de manière similaire, mais nous étions déjà habitués aux frameworks qui rendaient les pages identiques dans tous les navigateurs, et le paradigme avait basculé vers le rendu de données JSON.
Avec le niveau technologique actuel, les pages web à l’ancienne générées par le serveur sont tout à fait gérables ; elles ont une empreinte plus faible, sont plus rapides et consomment moins de mémoire.
Lors d’une migration récente d’un système legacy, j’ai vu une architecture des années 2000 du type « une page par requête HTTP » : même si toutes les actions comme ajouter/supprimer exigeaient un rafraîchissement, c’était beaucoup plus rapide qu’un système React. Internet est devenu plus rapide, la mémoire des téléphones est gaspillée par les frameworks JS, et le backend reste essentiellement du CRUD, de la pagination et des transactions.
Pour un site simple comme HN, un rechargement complet de page convient très bien, et il existe de nombreux cas où un simple site web suffit au lieu d’un framework JS.
Mais il est faux de dire que tout le monde pourrait revenir aux rechargements complets de page. Dans de véritables applications web, un rechargement complet peut donner une expérience utilisateur épouvantable.
En gros, les sites web, documents web et formulaires web peuvent fonctionner avec des rechargements complets, mais ce n’est pas adapté aux applications web qui doivent afficher et manipuler des choses complexes.
À l’époque, on s’appuyait sur la détection de l’agent utilisateur et toutes sortes de quirks pour ajuster la mise en page, et je n’ai pas l’impression que JS donnait facilement accès aux éléments liés au layout.
CSS n’a pas non plus apporté immédiatement de cohérence. Même une fois les fonctionnalités en place, c’était le bazar, et c’était l’époque où tout le monde s’extasiait devant CSS Zen Garden tout en écrivant encore le code réel avec des tableaux.
Je ne sais pas non plus si les frameworks ont vraiment joué un grand rôle dans l’« apparence cohérente ». Au moment où l’on s’éloignait de jQuery, CSS s’occupait déjà de l’apparence.
C’est avec plusieurs requêtes par page et beaucoup de jointures complexes pour produire des formes de réponse dédiées à la vue. Récupérer les données dans la bonne forme avant de les interpoler dans une chaîne HTML aide beaucoup les performances dans des cas limites comme un tableau de 100 000 lignes.
D’expérience, plus le moteur de templates HTML et la base de données sont proches, mieux c’est. Au final, un DOM structuré n’est lui aussi qu’un flux d’octets à envoyer au client.
Je pense qu’une industrie sophistiquée, inutile et devenue sa propre fin est née du fait de réfléchir à des approches AST/parseur complexes là où un StringBuilder et des requêtes SQL intelligentes suffisent. L’argument inverse se résumait généralement à une posture de gardien de sécurité considérant que les développeurs ne savent pas utiliser correctement une fonction d’échappement HTML.
Il est regrettable que la lourdeur du XML d’entreprise des années 2000 ait donné à cette technologie une image vieillotte, et que tout le monde se soit rué vers le JSON, plus « propre »
XSLT et XPath sont très matures et ont déjà résolu beaucoup de problèmes que d’autres formats rencontrent encore aujourd’hui
J’ai aussi de bons souvenirs d’avoir abusé autrefois des wrappers de flux PHP et des include XSLT
C’est peut-être un vieux préjugé, mais laisser le navigateur traiter ça en local me met encore un peu mal à l’aise. À l’époque, c’était un champ de mines côté compatibilité
Des choses comme les schémas côté XML étaient bien mieux définies, et j’ai l’impression qu’il a fallu presque dix ans à JSON pour rattraper son retard
La dernière technologie XML que j’ai vraiment manipulée était EXI, un mode de transport qui transformait les documents XML en flux de données binaires compressées. Parce que convertir des structures de données en ASCII, les compresser pour les envoyer en HTTP, puis les reconvertir, c’est un peu absurde
Aujourd’hui, la famille protobuf est plus populaire, mais si XML était resté dominant, on aurait peut-être eu tout un monde de standards compatibles et interconnectés. À l’inverse, il existe une barrière solide entre protobuf/gRPC et les API JSON, et c’est peut-être mieux ainsi
XPath n’est pas mal non plus. La syntaxe est difficile à retenir entièrement, mais avec un peu d’expérimentation on arrive généralement là où on veut
XSLT est un délire totalement insensé qui devrait brûler en enfer
Comme combinaison permettant des modifications locales relativement stables des données, XML + XPath est sérieusement sous-estimé. Sans doute à cause de la réputation « ringarde » de XML, je ne l’ai pas beaucoup vu dans d’autres jeux, mais pour cet usage c’est un système très robuste
https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
Mais quand la frénésie du Web a pris de l’ampleur, le W3C et Microsoft ont créé des choses comme SOAP et WS-*, et plusieurs langages de programmation fondés sur XML sont apparus, dont XSLT
Il ne faut pas le dire aux gens de HN, mais XSLT était à l’origine du Scheme, sauf qu’il devait absolument être en XML ; c’était la même époque de folie où JavaScript devait emprunter le nom de Java
Ces temps-ci, j’utilise XSLT pour mettre en forme des flux
Par exemple https://susam.net/feed.xml et https://susam.net/feed.xsl
À 19 ans, l’un de mes premiers projets comme ingénieur logiciel professionnel consistait à personnaliser deux Google Search Appliance achetées par l’entreprise
L’entreprise pensait que pouvoir faire de la recherche plein texte dans son énorme dépôt de documents CIFS améliorerait le processus de développement commercial, et elle a dépensé des centaines de milliers de dollars dans des racks de serveurs Dell à façade jaune, avec CentOS et du Python à la sauce Google
Vers 2011, XHTML était à la mode, et GSA fonctionnait en transformant, via XSLT, les résultats de recherche fournis en XML par le backend en XHTML
J’ai pris le template par défaut et, avec des ressources et du balisage piqués dans des pages d’applications ColdFusion rendues, StackOverflow et des tutoriels W3Schools, j’ai fabriqué une sorte de monstre ressemblant à un portail intranet d’entreprise
Par la suite, plusieurs sous-traitants du DoD m’ont contacté sur LinkedIn pour participer à des projets de modernisation documentaire après avoir vu mon « expertise XML », et j’ai vite appris qu’il valait mieux retirer cette expérience de mon CV
Quand vous soupirez en itérant en JSX sur des tableaux d’interfaces TypeScript désérialisées depuis des réponses JSON, pensez à moi qui faisais la même chose en XSLT
Beaucoup se plaignent que XML est verbeux et, de loin, il peut sembler complexe, mais j’aime le fait qu’on puisse créer de bons formats de fichiers à base de XML, les valider avec une DTD, puis, si besoin, les formater avec XSLT pour les rendre lisibles par des humains
XML est un peu le C++ des formats de fichiers textuels. Il est mature, batteries incluses, puissant, et utilisable depuis pratiquement n’importe quel langage si on le souhaite
Comme pour les vieux langages matures que l’on critique pour leurs bizarreries, dénigrer XML est devenu à la mode. S’il ne convient pas à un usage, il suffit de ne pas l’utiliser, mais ce n’est pas une raison pour le traiter de monstre
Pour illustrer jusqu’où XML et XSLT étaient allés au début des années 2000, une entreprise où j’ai travaillé fabriquait un ASIC capable de parser du XML à la vitesse du lien et d’exécuter XSLT nativement sur la puce
C’est parce qu’elle pensait que l’avenir d’Internet serait entièrement XML/XSLT. Intel a racheté l’entreprise, et la technologie interne a été intégrée à des accélérateurs SSE
Ce qui m’étonne, c’est la « magie » du fait que “XSLT fonctionne nativement dans le navigateur”
La dernière fois que j’ai utilisé XSLT remonte à environ 20 ans, mais à l’époque je m’en suis énormément servi pendant plusieurs années. À ce moment-là, pour le faire fonctionner, il fallait une énorme tour Java d’entreprise toute bancale, ce qui amoindrissait l’élégance propre de XSLT
Mais si XSLT fonctionne vraiment dans le navigateur, cela voudrait dire que le Graal des templates statiques hébergeables partout était sous notre nez depuis le début
Si la prise en charge de la v3 arrivait plutôt, il me semble que cela faciliterait la publication de pages web statiques grâce à un support natif des templates
Le CMS produisait des fichiers XML contenant du HTML intégré, et ça se mettait très bien en cache. La personnalisation et le rendu HTML/JS étaient gérés côté serveur, avec un proxy de cache
Les transformations XSL s’exécutaient derrière le cache et étaient assez rapides pour absorber beaucoup de trafic. Ici, le but de XML était de mettre le HTML déjà prêt sous forme de blob, et de ne garder en balises XML que les parties nécessitant de la personnalisation
La transformation finale était assez rapide, et le point clé était de ne pas placer la sortie du transformateur XSL dans un buffer mémoire complet, mais de la faire passer directement dans le flux de sortie de la réponse. Pour les grosses réponses, c’est encore une bonne technique aujourd’hui, mais beaucoup de frameworks passent par défaut par un buffering en mémoire et ratent cet aspect
Bien sûr, de nos jours, on peut faire tourner ce qu’on veut dans le navigateur avec wasm. Mais à l’époque, JavaScript était catastrophique, et les designers nous fournissaient au mieux des fichiers Photoshop. Il fallait les découper en frames et en tableaux, et à l’époque où Google Maps et Gmail venaient tout juste d’apparaître, nous construisions une UI de CMS assez lourde en JavaScript tout en prenant en charge à la fois Netscape et Internet Explorer
Firefox a notamment un bug particulièrement pénible : quand il faut
disable-output-escapingpour rendre du HTML dans le document comme un vrai DOM, cela ne fonctionne pas correctement et le HTML brut est rendu comme du texteIl y a longtemps, dans un projet dystopique très lointain, quelqu’un, pessimiste sur la capacité de l’équipe à synchroniser le développement Java avec un workbook qui changeait rapidement, a proposé une solution
La structure était la suivante : Visual Basic transformait un workbook créé avec Excel en XML, puis des fichiers XSLT généraient automatiquement les classes Java chargées de traiter les actions Struts définies dans ce XML
https://raganwald.com/2008/02/21/mouse-trap.html
Discussion HN : https://news.ycombinator.com/item?id=120379 · https://news.ycombinator.com/item?id=947952