- É possível usar XSLT como um sistema de build no lado do cliente executado no navegador para transformar dados XML em HTML e reduzir a complexidade de geradores de sites estáticos
- Um site estático típico é composto por dados como
.json, .md e .txt, um sistema de build como Hugo, Next.js ou Astro, e uma saída HTML estática, mas frameworks grandes podem trazer complexidade excessiva até para um blog simples em Markdown
- Mesmo tentando usar apenas HTML e CSS, é preciso copiar manualmente cabeçalhos e rodapés em várias páginas; não existe HTML import, e Web Components têm a limitação de exigir uma engine JavaScript
- Ao adicionar
<?xml-stylesheet type="text/xsl" href="blog.xsl"?> a um documento XML e escrever templates XSLT, o navegador pode gerar a saída HTML no momento da visita
- Essa abordagem pode ser distribuída como arquivos estáticos sem JavaScript, mas não é uma solução perfeita para substituir tudo; é apenas mais uma opção para acrescentar à caixa de ferramentas do desenvolvimento web
A complexidade do build de sites estáticos
- O fluxo típico de criação de um site estático se divide em dados, sistema de build e saída HTML estática
- Os dados são armazenados em arquivos como
.json, .md e .txt
- Exemplos de sistemas de build incluem Hugo, Next.js e Astro
- O resultado final é HTML estático
- Mesmo que você queira remover frameworks e usar apenas HTML e CSS, quando o número de páginas cresce é preciso continuar copiando o mesmo cabeçalho e rodapé
- As alternativas que vêm à mente também têm limitações
- HTML import não existe
- Web Components exigem JavaScript e, portanto, uma engine JavaScript
A ideia de usar o navegador como sistema de build
- O navegador já entende vários formatos, como
text/html, text/markdown e application/xml
- Se o navegador for usado como um sistema que cria HTML a partir de dados, é possível montar um fluxo baseado em padrões web sem ferramentas de build separadas
- Ao tentar exibir um feed RSS de forma mais agradável, o autor descobriu que XSLT pode ser usado como stylesheet para documentos XML
- XML se parece com HTML, mas é uma forma de representação de dados que não se limita a dados da web; isso pode ser visto na especificação XML
Como funciona a transformação de XML para HTML
- Um documento XML pode conter dados como posts de blog
<?xml version="1.0"?>
<blog>
<post id="42" publishedAt="2025-06-26">
<title>Hello XSLT</title>
<tags>…</tags>
</post>
</blog>
- É possível adicionar ao documento XML uma declaração que conecta uma stylesheet 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>
- Um template XSLT recebe a entrada XML e produz uma estrutura 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 pode ser visto como
(XML) => HTML e oferece recursos de sistema de build como loops, variáveis e import
- Também é possível buscar dados do documento XML pai dentro do XSLT e exibi-los dinamicamente
<head>
<xsl:value-of select="title" /> | Blog
</head>
Execução e implantação
- Ao abrir o arquivo XML no navegador, é possível executar a transformação XSLT
open blog.xml -a Safari
- Todos os navegadores suportam transformação XSLT ao visitar a página e exibem o HTML resultante
- Nesse modelo, isso funciona como um sistema de build no lado do cliente executado no computador do usuário
- A distribuição como arquivos estáticos é simples e funciona sem JavaScript
Limitações e posicionamento
- Os dados do blog precisam ser armazenados em XML em vez de JSON, mas XML se parece com HTML, é fácil de analisar, flexível e tem suporte nativo na web
- A abordagem com XSLT não é perfeita e não substitui tudo
- Ainda assim, ela aproveita padrões web, especificações e recursos de navegador antigos como mais uma ferramenta para criar sites estáticos simples
1 comentários
Opiniões no Hacker News
Já trabalhei em uma empresa que usava muito XSLT em templates XML, e não era bom; se fosse possível, provavelmente teríamos migrado
Mesmo com padrões mais novos, o XSLT 1.0 ainda domina, e é limitado e estranho em comparação com os padrões mais recentes
Resolver problemas de desempenho em templates XSLT é quase um inferno. É uma linguagem em estilo funcional, Turing-completa, mas o desempenho fica muito abstraído; um template que rodava bem na maioria dos documentos podia explodir em uma única tabela de 100 linhas. Descobríamos que o template que processava a tabela era O(N^2) ou pior, e que, para cada linha, o XPath talvez fosse novamente O(N) ou pior, sem um caminho claro de otimização. Pelo que me lembro, processar um único documento com XSLT levava mais de 7 minutos
JS também tem outros problemas, mas não conseguir resolver problemas de complexidade algorítmica não é um deles
Hoje há recursos como key (índice) que podem acelerar bastante o processamento, e boas implementações de XSLT como o Saxon também ajudam claramente no desempenho
Ao transformar XML para outro formato, o XSLT é bastante conveniente porque permite estruturar a lógica
Em 2013 eu usava bastante XSLT, e naquela época o 1.0 já estava completamente morto em qualquer lugar que eu visse. O Saxon era gratuito para XSLT 2 e era excelente
Transformei tanto documentos gigantes quanto muitos documentos pequenos, e nunca tive problemas de desempenho
Depois que você pega o jeito, dá uma satisfação parecida com resolver um sudoku, mas em geral bem menos ferramentas bastam para atingir o objetivo, então é difícil que ele se torne a abordagem padrão para builds ou templates
Além disso, XML também não é um formato de que todo mundo gosta
Se minha memória não falha, ela também fazia otimizações bem inteligentes
Pode ser uma especulação bem forçada, mas nos anos 1990 e 2000 os navegadores eram todos diferentes, então começamos a usar JS para obter o mesmo comportamento, quando na verdade o que era necessário era um bom estilo CSS e comportamento consistente
Com o tempo, os navegadores começaram a se comportar de forma parecida, mas já estávamos acostumados a frameworks que faziam a página parecer igual em todos eles, e o paradigma mudou para renderizar dados JSON
Com a tecnologia atual, páginas web à moda antiga geradas pelo servidor também são perfeitamente viáveis: têm pegada menor, são mais rápidas e usam menos memória
Recentemente, ao migrar um sistema legado, vi uma arquitetura dos anos 2000 de “uma página por requisição HTTP”; mesmo com todas as ações, como adicionar/remover, exigindo atualização da página, ela era muito mais rápida que um sistema em React. A internet ficou mais rápida, a memória dos celulares está sendo desperdiçada por frameworks JS, e o backend continua sendo, em grande parte, CRUD, paginação e transações
Em lugares simples como o HN, recarregar a página inteira funciona bem, e há muitos casos em que um site simples basta no lugar de um framework JS
Mas não é verdade que todo mundo possa voltar a recarregar a página inteira. Em algumas aplicações web reais, um reload completo vira uma experiência de usuário horrível
Em geral, sites, documentos web e formulários web podem funcionar com reload completo, mas isso não serve para aplicações web em que é preciso mostrar e manipular coisas complexas
Na época, ajustávamos layout com base em detecção de user agent e na ordem de vários quirks, e não me parece que JS tivesse acesso fácil a elementos relacionados a layout
CSS também não trouxe consistência imediatamente. Mesmo depois de ganhar recursos, continuava uma bagunça; era a época em que todo mundo se maravilhava com o CSS Zen Garden, mas o código real ainda era feito com tabelas
Também não sei se os frameworks tiveram grande impacto em “aparência consistente”. Quando começamos a sair do jQuery, o CSS já era responsável pela aparência
Isso considerando várias consultas por página e muitos joins complexos para criar formatos de resposta específicos para a view. Trazer os dados no formato certo antes de interpolá-los em strings HTML ajuda muito no desempenho em casos-limite, como uma tabela de 100 mil linhas
Pela minha experiência, quanto mais próximos estiverem o mecanismo de templates HTML e o banco de dados, melhor. No fim, um DOM estruturado também é apenas um fluxo de bytes que precisa ser enviado ao cliente
Acho que surgiu uma indústria sem sentido e autocentrada, preocupada com abordagens sofisticadas de AST/parser, quando StringBuilder e consultas SQL inteligentes bastariam. O argumento contrário geralmente acabava numa postura de vigilante de segurança que presume que desenvolvedores não conseguem usar corretamente uma função de escape de HTML
É uma pena que, por causa do inchaço do XML corporativo dos anos 2000, a tecnologia tenha passado a parecer velha e todo mundo tenha migrado para o JSON mais “limpo”
XSLT e XPath são muito maduros e já resolveram muitos problemas que outros formatos ainda enfrentam
Também tenho boas lembranças de antigamente, quando eu abusava de wrappers de stream do PHP e includes de XSLT
Pode ser um preconceito antigo, mas ainda fico um pouco desconfortável em deixar o navegador processar isso localmente. Antigamente era um campo minado de compatibilidade
Coisas como schemas do lado do XML eram muito mais bem definidas, e tenho a impressão de que o lado do JSON levou quase 10 anos para alcançar isso
A última tecnologia XML com que trabalhei de verdade foi EXI, que era uma forma de transporte que transformava documentos XML em um fluxo de dados binário comprimido. Porque transformar uma estrutura de dados em ASCII, comprimi-la, enviá-la por HTTP e depois reverter tudo isso é meio ridículo
Hoje a família protobuf é mais popular, mas, se o XML tivesse continuado, talvez tivéssemos um mundo de padrões compatíveis que se encaixassem entre si. Por outro lado, há uma barreira sólida entre protobuf/gRPC e APIs JSON, e talvez isso seja melhor
XPath também não é ruim. É difícil lembrar toda a sintaxe, mas, com um pouco de experimentação, geralmente se chega onde quer
XSLT é uma bobagem completamente insana e deveria queimar até desaparecer
Como combinação que permite modificações locais relativamente estáveis dos dados, XML + XPath é seriamente subestimado. Talvez pela reputação de o XML ser “antiquado”, não vi muito isso em outros jogos, mas para esse uso é um sistema muito robusto
https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
Mas, com o crescimento da febre da web, o W3C e a MS criaram coisas como SOAP e WS-*, e também surgiram várias linguagens de programação baseadas em XML, incluindo XSLT
Não se deve dizer isso ao pessoal do HN, mas XSLT era originalmente Scheme, só que precisava obrigatoriamente ser XML; foi a mesma época de loucura em que JavaScript precisou pegar emprestado o nome do Java
Hoje em dia uso XSLT para embelezar feeds
Por exemplo, https://susam.net/feed.xml e https://susam.net/feed.xsl
Aos 19 anos, um dos meus primeiros projetos como engenheiro de software profissional foi customizar dois Google Search Appliance que a empresa tinha comprado
A empresa achava que poder fazer busca full-text em um enorme repositório de documentos CIFS melhoraria o processo de desenvolvimento de negócios, então gastou centenas de milhares de dólares em racks de servidores Dell com frente amarela, rodando CentOS e Python no estilo Google
Por volta de 2011, XHTML estava na moda, e o GSA funcionava transformando, via XSLT, os resultados de busca fornecidos em XML pelo backend em XHTML
Peguei os templates padrão e criei um monstro parecido com um portal de intranet corporativo usando páginas renderizadas de uma aplicação ColdFusion e assets e markup roubados do StackOverflow e de tutoriais da W3Schools
Depois disso, vários contratantes do DoD entraram em contato comigo pelo LinkedIn por causa da “expertise em XML”, convidando-me para participar de projetos de modernização de documentos, e aprendi rapidamente que precisava tirar essa experiência do currículo
Quando você suspirar ao iterar em JSX sobre um array de interfaces TypeScript desserializadas de uma resposta JSON, lembre-se de mim fazendo a mesma coisa com XSLT
Muita gente reclama que XML é verboso e, visto de longe, parece complexo, mas gosto do fato de que dá para criar bons formatos de arquivo baseados em XML, validá-los com DTD e, se necessário, formatá-los de forma legível por humanos com XSLT
XML é como o C++ dos formatos de arquivo baseados em texto. É maduro, vem com baterias incluídas, é poderoso e, se você quiser, pode usá-lo em qualquer linguagem
Assim como linguagens antigas e maduras são criticadas por suas esquisitices, virou moda criticar XML. Se não serve para o seu caso de uso, não use, mas não é preciso tratá-lo como um monstro
Como exemplo de até onde XML e XSLT chegaram no início dos anos 2000, uma empresa em que trabalhei no passado criou um ASIC que parseava XML em velocidade de linha e processava XSLT nativamente no chip
Isso porque se esperava que o futuro da internet fosse todo XML/XSLT. A Intel comprou essa empresa, e a tecnologia interna foi incorporada aos aceleradores SSE
É surpreendente a “mágica” de que “XSLT roda nativamente no navegador”
A última vez que usei XSLT foi há uns 20 anos, mas naquela época usei muito durante alguns anos. Na época, para fazer funcionar era preciso uma torre corporativa Java enorme e instável, o que diminuía a elegância do próprio XSLT
Mas, se XSLT de fato roda no navegador, então o santo graal dos templates estáticos hospedáveis em qualquer lugar esteve o tempo todo bem diante de nós
Se viesse suporte à v3, acho que ficaria mais fácil servir páginas web estáticas com suporte nativo a templates
O CMS cuspia arquivos XML com HTML embutido, e o cache funcionava muito bem. Personalização e renderização de HTML/JS eram tratadas no lado do servidor junto com um proxy de cache
A transformação XSL rodava por trás do cache e era rápida o suficiente para acompanhar bastante tráfego. Ali, o propósito do XML era colocar o HTML já preparado como um blob e deixar como tags XML apenas as partes que precisavam de personalização
A transformação final era bem rápida, e o ponto crucial era não colocar a saída do transformador XSL em um buffer inteiro na memória, mas despejá-la diretamente no stream de saída da resposta. Em respostas grandes, isso ainda hoje é uma boa técnica, mas muitos frameworks escolhem buffering em memória por padrão e acabam deixando isso passar
Hoje, claro, dá para rodar o que você quiser no navegador com wasm. Mas, naquela época, JavaScript era uma bagunça, e designers, na melhor das hipóteses, entregavam arquivos do Photoshop. Era preciso fatiar aquilo em frames e tabelas e, na época em que Google Maps e Gmail tinham acabado de surgir, estávamos construindo uma UI de CMS bem pesada em JavaScript com suporte tanto a Netscape quanto a Internet Explorer
Há um bug especialmente irritante no Firefox: quando é necessário usar
disable-output-escapingpara renderizar HTML dentro do documento como DOM de verdade, ele não funciona corretamente e acaba renderizando como texto HTML brutoMuito tempo atrás, em um projeto distópico muito distante, alguém, pessimista quanto à capacidade da equipe de coordenar o desenvolvimento Java em paralelo com uma workbook que mudava rapidamente, propôs uma solução
A estrutura era: o Visual Basic transformava uma workbook escrita em Excel em XML, e arquivos XSLT geravam automaticamente as classes Java que processariam as actions do Struts definidas nesse XML
https://raganwald.com/2008/02/21/mouse-trap.html
Discussões no HN: https://news.ycombinator.com/item?id=120379 · https://news.ycombinator.com/item?id=947952