- XSLT é uma ferramenta de build nativa para a web, que pode ser usada imediatamente sem um sistema de build complexo
- A maioria dos sistemas de build para sites estáticos sofre com problemas de complexidade, dificuldade de compreensão e dependência de frameworks
- Com XML e XSLT, é possível gerar HTML diretamente no navegador, facilitando o processamento de dados dinâmicos e a geração de marcação
- Todos os principais navegadores oferecem suporte a transformações baseadas em XSLT, permitindo o uso sem JavaScript adicional ou ferramentas separadas
- Não é uma solução perfeita, mas tem grande valor como uma alternativa simples e flexível baseada em padrões web
Introdução e problema
- O processo de desenvolvimento da maioria dos sites estáticos é composto por arquivos de dados (
.json, .md, .txt), um sistema de build separado (Hugo, Next.js, Astro etc.) e a estrutura final de saída em HTML
- Os sistemas de build estão ficando cada vez mais complexos, e até mesmo um blog pequeno vai se tornando mais difícil de entender e manter
- Ao tentar excluir frameworks e trabalhar apenas com HTML, CSS e especificações padrão (HTTP, URI, HTML), surgem limitações de manutenção, como a repetição de cabeçalhos e rodapés
- Também foram tentadas abordagens como HTML import e web components, mas a primeira não tem suporte, e a segunda não se tornou uma alternativa viável por depender do motor de JavaScript
O navegador como sistema de build
- A ideia parte do fato de que o próprio navegador já oferece suporte a várias transformações de dados (
text/html, text/markdown, application/xml etc.)
- A proposta foi analisar profundamente as especificações da web e buscar uma forma de resolver o problema sem ferramentas externas e sem frameworks desnecessários
Como usar XSLT
- Ao querer exibir um feed RSS de forma mais bonita, foi descoberta a especificação XSLT
- XSLT é uma tecnologia padrão oficial para expressar tanto os dados XML quanto a estrutura de saída em HTML
- O modo de uso é simples
- Por exemplo, organize os dados em
blog.xml
- Em seguida, conecte a folha de estilos XSLT assim
<?xml-stylesheet type="text/xsl" href="blog.xsl"?>
- Em
blog.xsl, escreva o template HTML e as regras de mapeamento dos dados
- Há suporte para templates, repetição, variáveis, importação de arquivos externos e a maioria dos recursos de sistemas de build
Como executar e vantagens
- Sem nenhuma ferramenta separada, basta abrir o arquivo XML no navegador para que o resultado da transformação seja renderizado imediatamente
- Como o formato XML é semelhante ao HTML, ele é amigável para humanos e fácil de manter, sem grande desconforto mesmo ao usá-lo no lugar de JSON
- Todos os principais navegadores suportam nativamente transformações baseadas em XSLT, permitindo que o cliente veja diretamente o resultado da transformação
- O fato de não precisar de JavaScript, ferramentas de build separadas ou bundlers é uma grande vantagem
- XSLT não é a solução universal definitiva, mas é uma alternativa de build para web simples e expansível
Conclusão
- Redescoberta do valor de tecnologias do passado (XSLT) e de padrões claros
- Usar o navegador como sistema de build é uma opção útil que vale a pena adicionar à caixa de ferramentas do desenvolvimento web
1 comentários
Comentários no Hacker News
A empresa em que trabalhei usava XSLT em templates XML pra caramba, e provavelmente ainda usa. Sinceramente, não era uma boa escolha, e imagino que teriam querido migrar para outra coisa, se possível
JS também tem seus problemas, mas pelo menos você não fica preso numa situação em que não dá para corrigir essa complexidade algorítmica
XSLT/XPath evoluíram bastante depois da 1.0. Surgiram vários recursos, como
key(índice), e isso acelerou muito o processamento. Se você usar uma implementação de qualidade como Saxon, os problemas de performance também diminuem bastante. Quando se trata de transformar XML em outra coisa, acho difícil encontrar algo tão conveniente quanto XSLT para estruturar a lógicaXSLT é bem difícil de aprender. Parece uma espécie de Prolog onírico, e quando você realmente domina dá aquela sensação de resolver um sudoku. Mas na maioria dos casos não há necessidade de templates tão complexos, então é difícil virar a opção padrão. E o próprio XML também não é um formato que todo mundo goste
Não entendo muito bem essa parte de que XSLT 1.0 ainda é tão usado. Já em 2013 o 1.0 era praticamente visto como ultrapassado, e o Saxon, que permitia usar XSLT 2, era gratuito e tinha uma performance excelente. Nunca tive problema de desempenho transformando documentos, grandes ou pequenos
Na época em que XSLT surgiu, era normal processar XMLs com corpo muito longo. Mas, claro, quando você aninha loops repetitivos assim, é natural que tudo desande
Fico curioso se você usa a versão comercial do Saxon. Não é cara, e por causa do suporte aos padrões novos, da performance e de vários recursos, IMHO vale muito a pena. Quando usei no passado, lembro que tinha otimizações bem inteligentes
Nos anos 90 e 2000 os navegadores eram cada um de um jeito, então começamos a introduzir JS para alinhar o comportamento
Na verdade, o que queríamos eram estilos CSS bonitos, mas naquela época isso não dava para usar direito
Com o tempo, um navegador passou a liderar e os outros ficaram muito mais parecidos também (a regra do Highlander, embora o Firefox ainda esteja resistindo bem)
Os frameworks já tinham se tornado algo óbvio, então acabaram se consolidando como forma de igualar a mesma UI em todos os navegadores. E o próprio paradigma migrou para renderização de dados JSON
Hoje em dia, mesmo gerando páginas web tradicionais no servidor, tudo é rápido e consome pouca memória
Penso nisso porque recentemente, ao migrar de um sistema legado, voltei a usar um site que funcionava no modelo de requisição HTTP por página inteira (o padrão dos anos 2000). Era preciso recarregar a cada ação, mas ainda assim parecia muito mais rápido que um sistema com React
Os motivos são
AJAX e atualização de DOM não surgiram só para deixar tudo mais rápido. Eles vieram para sair do paradigma da web, ou seja, de “site/documento web”. Recarregar a página inteira faz sentido dentro de um paradigma centrado em documentos. Em exemplos simples como o HN, essa estrutura funciona muito bem. Muitos sites conseguem operar perfeitamente assim, sem framework JS.
Mas dizer que “todo mundo pode voltar a recarregar a página inteira” está longe da realidade. Na prática, para “aplicações web” que exigem interações complexas, recarregar a página inteira é uma UX muito ruim.
Resumindo,
para “sites”, “documentos web” e “formulários simples”, muitas vezes o recarregamento completo da página basta
mas para “aplicações web” com telas de dados e manipulação complexa, isso não basta
Minha lembrança da linha do tempo é um pouco diferente. JS era usado desde o começo mais para elementos interativos do que para uniformizar o comportamento dos navegadores (DHTML, AJAX etc.). O que realmente se usava para layout era quase sempre gambiarra e detecção de user agent para cada navegador. Mesmo com o CSS ficando mais poderoso, os problemas de consistência não foram resolvidos facilmente. CSS garden, marcação semântica, abuso de tabelas — esse era o clima da época, e até o primeiro passe no teste ACID demorou bastante. Sou cético quanto ao impacto dos frameworks na consistência de UI — depois do jQuery, o próprio CSS era o principal responsável pela consistência visual.
Mas claro, pode ser só a minha memória
Concordo que, numa stack moderna, páginas web tradicionais renderizadas no servidor são rápidas e leves
Na minha stack .NET/Kestrel/SQLite, é difícil uma resposta SSR passar de 4 ms. A maioria fica na casa das centenas de microssegundos. Em cada página eu uso várias queries e joins complexos para moldar os dados do jeito que a view precisa
Mesmo no caso extremo de gerar uma tabela com 100.000 linhas, se você preparar bem os dados antes de montar a string HTML, a performance sobe bastante. O desempenho do LINQ também é excelente, mas se você cria coleções por linha, isso acaba ficando muito ineficiente à medida que o volume cresce
Pela minha experiência, para otimizar performance o melhor é manter o motor de template HTML e o banco o mais próximos possível. No fim das contas, o DOM é só um stream de bytes. Não precisa necessariamente construir AST/parser complexo; combinar
StringBuildercom query SQL já basta.A única crítica recorrente a essa abordagem simples sempre foi a discussão de segurança do tipo “não confio que desenvolvedores façam escape de HTML direito”
Essa ideia de que “com tecnologia moderna dá para responder bem com páginas clássicas geradas no servidor” pode mudar totalmente se a latência de rede for alta
link de referência
No mundo enterprise dos anos 2000, o XML ficou inchado demais, e isso fez a tecnologia parecer ultrapassada; no fim, todo mundo se apaixonou pela “limpeza” do JSON. Mas, na verdade, tecnologias como XSLT e XPath já eram bastante maduras e resolviam muitos problemas com os quais ainda lidamos hoje
Eu mesmo já abusei bastante de
includeem XSLT, usando coisas como<xsl:include href="mycorp://invoice/1234">via PHP stream wrapperSinceramente, hoje isso talvez pareça um pouco antiquado, mas ainda acho desconfortável deixar o navegador processar XSLT localmente. Antigamente era um campo minado de incompatibilidades
Ainda sinto falta de elementos “básicos” do XML no JSON. Por exemplo, uma especificação realmente padronizada, definição de schema etc. O XML era muito superior nisso, e o JSON levou quase 10 anos para alcançar esse nível
A última vez que mexi seriamente com XML foi com uma tecnologia de transporte chamada EXI. Ela transformava documentos XML em streams binários compactados, então havia toda aquela etapa de estrutura → ASCII → compressão/transporte → reversão, o que era trabalhoso. Hoje protobuf e gRPC são o padrão, mas às vezes penso que, se o XML tivesse continuado dominante, talvez estivéssemos num mundo (na minha imaginação idealizada) em que tudo seria compatível por ser baseado em padrões. Na prática, porém, surgiu uma barreira enorme entre protobuf/gRPC e APIs JSON, e talvez isso até seja melhor
Acho XML um formato razoável. É volumoso e verboso, mas, comparado ao YAML, é muito superior em precisão e expressividade
XPath é difícil de pegar o jeito, mas se você experimentar, no fim consegue fazer o que quer
XSLT eu acho um conceito completamente maluco. Devia ser aposentado
O jogo Rimworld salva todos os dados de configuração em XML e permite modding com XPath. Essa combinação é realmente poderosa. Para customização de dados locais, é difícil bater isso. Mas parece que a maioria dos jogos evita esse tipo de coisa porque XML ficou com fama de “ultrapassado”
documentação oficial de modding com XPath do Rimworld
Essa história de que o XML enterprise do começo dos anos 2000 ficou gigantesco é muito verdadeira. Originalmente, o XML era uma versão simplificada do SGML para poder ser usada na web, com foco em transportar marcação e expandir vocabulários. No fim, basicamente só SVG e MathML sobreviveram. Com a bolha da web, W3C/MS começaram a despejar SOAP, especificações WS-* e afins. Foi uma época insana em que até linguagens como XSLT, com ossatura de Scheme, foram forçadas a caber em XML. Até JavaScript recebeu um nome inspirado em Java, típico daquele tempo
É uma pena que em XPath você acabe escrevendo consultas tão verbosas por causa de namespaces
Até hoje eu estilizo meu feed com XSLT.
exemplo de feed RSS
exemplo de XSLT
Quando vejo isso, fico pensando se blog não deveria simplesmente ser um feed RSS
Eu sempre esqueço que XML originalmente podia fazer esse tipo de coisa. De alguma forma parece intuitivamente estranho
Ficou muito bem feito. Gostaria que mais gente adotasse exemplos criativos assim
No meu primeiro emprego (aos 19 anos), fiquei responsável por customizar o Google Search Appliance. Era um projeto com aqueles servidores Dell amarelos caríssimos, rodando CentOS, com Python “ao estilo Google” e busca full-text em documentos CIFS.
Por volta de 2011, XHTML estava em alta, e no Google Search Appliance os dados XML do backend eram transformados em XHTML via XSLT. Eu explodia os templates de exemplo para montar uma UI monstruosa adaptada à intranet da empresa, enfiando ali um remendo de Coldfusion, StackOverflow, W3Schools e outros ativos existentes
Tirei essa experiência do currículo o mais rápido possível. Depois disso, subcontratadas do DoD viviam me procurando como “especialista em XML” para projetos de modernização de sistemas documentais, e isso foi cansativo
Da próxima vez que você suspirar por estar usando JSX para iterar arrays de JSON em interfaces TypeScript, lembre-se da minha história. Ainda é melhor do que fazer isso em XSLT
Eu realmente sou do tipo que busca simplicidade. Gosto de documentação fácil, tipo README de homem das cavernas. Às vezes também sinto vontade de bater no teclado como um homem das cavernas. Não trabalho com websites e não conheço bem XSLT. De vez em quando faço umas gambiarras com XML e quero mostrar algo para os usuários. Existem formatos de arquivo demais e isso me dá dor de cabeça. Ainda assim, gosto de coisas bonitas. Talvez eu use isso também
Obrigado por ler a especificação e por criar a ferramenta
Muita gente diz que XML é verboso e parece complicado, mas quando você lida com ele diretamente, é um formato excelente
Dá para validar com DTD e gerar saídas legíveis para humanos com XSLT
Para mim, XML é como o C++ dos formatos de texto. É maduro, vem com “baterias incluídas”, é poderoso e se conecta com qualquer linguagem
Como acontece com linguagens antigas e maduras, acho uma pena que tenha virado moda tratar XML como conteúdo de esquisitão. Se não serve para o seu caso, não use, mas não há motivo para odiá-lo tanto
Acho fascinante essa ideia de que “XSLT funciona direto no navegador”. A última vez que usei XSLT foi há 20 anos, e naquela época parecia que toda a estética própria do XSLT ficava soterrada sob uma pilha enorme de Java enterprise complicada.
Mas se XSLT realmente funciona por padrão no navegador, será que o santo graal dos templates realmente estáticos estava logo ali, sem framework host?
Os navegadores só suportam XSLT 1.0. E ainda há quem diga que até isso pode desaparecer no futuro. É uma pena; se os navegadores suportassem até a 3.0, isso se tornaria muito útil para geração de páginas estáticas
Nem sempre foi obrigatório usar aquela torre de “Java enterprise gigante”. Eu já passei por uma experiência em que usávamos só Tomcat e algumas bibliotecas Apache, e funcionava muito bem. No CMS, o HTML era gerado em XML, a personalização entrava na forma de tags XML, e graças a um proxy de cache server-side as transformações também eram rápidas, então dava para lidar com muito tráfego. O ponto-chave era enviar o stream de saída do XSLT imediatamente ao cliente, sem bufferizar tudo em memória.
Hoje em dia dá para rodar qualquer coisa no navegador com wasm, mas o JS do início era desastroso, e os designers já estavam no lucro quando entregavam um PSD do Photoshop decente. Na época do Google Maps e do Gmail, havia uma guerra para fazer UIs pesadas em JavaScript, e ainda era preciso suportar Netscape e Internet Explorer ao mesmo tempo — um inferno de verdade
O próprio boom do XHTML começou, na prática, por causa desse “santo graal do template estático”. Mas, curiosamente, quem sabia do assunto falava em tom de código, como gíria, e ninguém dizia isso abertamente
Trabalhei em 2008 num site com XSLT no navegador, e isso já era suportado desde o começo dos anos 2000
O Chrome vem com
libxslt, e o Firefox com um motor 1.0 chamado Transformiix. O Chrome só suportaexsl:node-set, enquanto o Firefox suporta várias extensões EXSLT (não todas)Também publiquei uma pequena ferramenta que mostra informações simples do processador XSLT e a lista de extensões disponíveis.
GitHub - xslt-detect-ext
Você pode arrastar o arquivo
out/detect.xsltno navegador para verificar as informações (Chrome, Firefox). O Safari não funcionava na antiga versão para WindowsQuando eu era estudante no ensino médio nos anos 90 e me chamavam de “webdesigner”, usei um pipeline em dialeto DSSSL para gerar automaticamente sites a partir de newsfeeds. Até hoje gosto de transformações XSLT. Também uso ferramentas como bananas XI reader para fazer transformações reais de texto e trabalho com templates
Mas pouquíssimas pessoas realmente gostavam desse tipo de tooling, e quando alguém assumia meu lugar, a tecnologia adotada costumava desaparecer rápido
bananas XI reader
Para mostrar o tamanho da febre de XML e XSLT no começo dos anos 2000: a empresa em que trabalhei chegou a construir um ASIC capaz de fazer parsing de XML em velocidade de linha e até processar XSLT diretamente no chip. Na época, acreditava-se que o futuro da internet inteira rodaria sobre XML/XSLT.
De fato, essa empresa acabou sendo comprada pela Intel, e a tecnologia foi parar no lado dos aceleradores SSE
Se uma arquitetura em que ASIC interpretasse XML e até XSLT em tempo real tivesse virado mainstream, imagino como os sites seriam absurdamente rápidos hoje
A IBM ainda vende um hardware com capacidade parecida embutida (DataPower Gateway)