Por que o XSLT é tão raramente usado na web? [fechadas]


12

XSLT é um padrão maduro e amplamente aceito.

Ele pode ser usado em navegadores (mesmo no IE antigo) e no lado do servidor (o nginx possui um módulo XSLT, que pode ser usado a partir de linguagens de programação, é claro). Suas implementações são compiladas e, portanto, devem ser muito mais rápidas que Python ou JS. A implementação do JS Saxon JS pode ser usada, pelo menos, como substituto. Os modelos Jinja, Angular, Ruby Slim, ASP e PHP não estão nem perto.

Um modelo XSL pode ser facilmente validado em um IDE. Quantos IDEs podem ajudar com Jinja ou Angular?

Parece que é uma idéia perfeita decompor a interface do usuário e os dados com o XSLT.

É certo que as implementações podem dar resultados diferentes em alguns casos extremos, mas é um problema apenas com modelos no lado do cliente. E é o mesmo com HTML, CSS e tudo o mais que é feito no lado do cliente.

Então, por que não XSLT?


4
JSON é mais fácil que XML. Não estou brincando, ontem à noite ouvi os desenvolvedores dizerem como estavam agradecidos por nunca mais usarem o XSLT. Veja: stackoverflow.com/questions/4862310/json-and-xml-comparison
Dan Wilson

6
Você já tentou fazer algo não trivial com isso?
PlasmaHH 21/1018

9
É 'porque é agonia usar' uma resposta válida ..?
thisextendsthat 21/10

2
@thisextendsthat: Não, porque JavaScript e CSS também costumavam ser agonia, mas ainda se tornaram amplamente utilizados.
precisa saber é o seguinte

4
@ JacquesB JS e CSS ainda são uma agonia de usar.
21418 Andy

Respostas:


39

O XSLT realmente não tem um papel útil na web interativa moderna. O objetivo do XSLT é transformar de uma linguagem XML em outra - mas você nunca precisa fazer isso em primeiro lugar. O quão poderosa, rápida e bem suportada é uma tecnologia é irrelevante se você não tiver o problema que a tecnologia foi projetada para resolver.

Há várias razões pelas quais o caso de uso do XSLT desapareceu:

  • O HTML venceu. O XSLT deveria ser útil para transformar o conteúdo "rich text" em algum formato de marcação semântica em HTML. Mas o HTML é, por si só, um formato perfeitamente adequado; então, por que não usá-lo apenas para o conteúdo e pular a transformação?
  • CSS tornou-se muito mais poderoso. Uma das promessas do XSLT era que você poderia manter a marcação de origem limpa e semântica e transformá-la em "HTML de apresentação", que funcionava em vários navegadores e onde era possível reorganizar elementos e assim por diante. Mas você realmente não precisa de HTML de apresentação atualmente, pode usar HTML semântico e CSS pode executar o estilo e o layout necessários.
  • XML não se tornou o formato onipresente para dados. Ao buscar dados SQL de um banco de dados, é muito mais simples mesclá-los diretamente em um modelo, em vez de primeiro transformá-los em XML e transformá-los via XSLT. E o JSON praticamente substituiu o XML por dados estruturados no lado do cliente.
  • O XSLT foi projetado para transformar um documento inteiro de cada vez. Mas nas modernas páginas interativas da web, pequenos trechos de dados são baixados aos poucos o tempo todo e mesclados na página.
  • Os dados não são tão complexos. Para a maioria dos casos de uso, formatos mais simples de modelos com espaços reservados e repetidores resolvem bem a tarefa. O XSLT é muito mais poderoso, mas você raramente precisa dessa energia extra e possui um custo elevado em complexidade e feiura.

O XSLT surgiu da publicação, onde você pode ter um processo unidirecional, de um formato de origem estruturado para vários formatos de publicação, como impressão, PDF e páginas estáticas. A maioria dos sites não se encaixa nesse caso de uso.


Resposta muito informativa (+1).
Giorgio

1
Não sei se minha experiência é a mesma que a de outros usuários, mas um dos "pontos de venda" do XSLT, como me foi explicado, foi a largura de banda reduzida: se você tem uma página grande e regular, envia um XML ( <chapter><title><par>...) e XSLT mínimo seria "expandir"-lo com o div, table, trconforme necessário, com a adição de que poderia ser armazenada em cache. Então (novamente, eu não sei o quão difundida foi essa "vantagem" explicada), a largura de banda aprimorada também a prejudicaria (e o fato de a maioria das páginas HTML ser bastante pequena).
SJuan76

@ SJuan76: Essa é uma idéia da transformação da marcação semântica em HTML de apresentação detalhado que usa tabelas para layout. Felizmente, não é mais necessário usar tabelas para o layout, para que o caso de uso seja discutível.
JacquesB

@ JacquesB Eu usei esse casal para essa página: programaths.be/job/job.xml e foi perfeito. O XML é usado para exibir a página E verificar as respostas para o questionário gerado. Não se trata de formatação em tabelas, mas o XML me oferece uma boa abstração. Claro, eu não me importo com as pessoas trapaceando. Mas mostra que, mesmo nos tempos modernos, pode ser muito útil!
programasths

9

Depende do que você quer dizer com "na Web".

XSLT é amplamente utilizado. Tanto quanto podemos julgar por métricas como o número de perguntas sobre o StackOverflow, ele está entre as 30 principais linguagens de programação, o que provavelmente a torna a principal linguagem de programação específica para o modelo de dados após o SQL.

Mas o XSLT não é amplamente usado no lado do cliente, ou seja, no navegador. Geralmente é usado no lado do servidor para fornecer conteúdo sob demanda em resposta a solicitações HTTP ou é usado no modo em lote como parte de um fluxo de trabalho de publicação. Também é usado, é claro, em muitos aplicativos que têm muito pouco a ver com a web, por exemplo, na publicação impressa.

Existem várias razões pelas quais o XSLT não é amplamente utilizado no navegador. A principal razão é que o bom suporte XSLT conforme era muito lento vindo dos fornecedores de navegadores; ninguém queria usá-lo até que estivesse disponível em todos os navegadores, e quando estava disponível em todos os navegadores, as coisas que as pessoas queriam fazer no navegador haviam mudado (lembre-se de "Web 2.0"?) e das implementações XSLT no navegador não o ajudou a criar aplicativos interativos ou buscar dados usando o AJAX.

A Saxonica (exoneração de responsabilidade, este é o meu produto) tentou preencher essas lacunas com o Saxon-JS, mas o produto é tardio para a parte, e o desenvolvimento da Web do lado do cliente é muito orientado à moda, portanto, não basta apenas ter um produto que marca todas as caixas técnicas. Parte da moda é que a maioria dos sites orientados a dados (diferente dos orientados a documentos) mudou-se para JSON em vez de XML, principalmente porque JSON é muito mais fácil de manipular a partir do Javascript.

A outra questão é que o XSLT é uma linguagem de amar ou odiar. Seu paradigma declarativo, baseado em regras e orientado para a funcionalidade agrada a muitos por causa de sua natureza de alto nível, mas pode ser desanimador para aqueles cuja única experiência em programação é escrever código imperativo que diz ao computador exatamente o que fazer e de que maneira. Que ordem.


3

Estou alternando entre responder a essa pergunta e fechá-la como baseada principalmente em opiniões. Então, aqui está o meu flip:

Em resumo, porque o XML cria uma linguagem de programação ruim. Algo com a semântica do XSLT, mas uma sintaxe muito melhor seria uma questão totalmente diferente, eu acho. Existem algumas linguagens de transformação XML muito legais, baseadas em Lisp, por exemplo.

O XSLT não pode decidir se deseja ser uma linguagem de reescrita em árvore, uma linguagem funcional ou uma linguagem processual. Ele possui recursos de todos eles, mas não é realmente bom em nenhum deles. Para qualquer um dos três aspectos, existem idiomas melhores por aí.


Sintaxe XML de fato pode parecer detalhada. Mas, quais são os outros idiomas suportados em todos os lugares?
George Sovetov 21/10

XSLT é uma excelente linguagem funcional IMO. Onde ele cai é na maneira como combina a visão com a lógica de transformação.
precisa

4
@GeorgeSoverov, por que é importante ter suporte em todos os lugares? Ele só precisa ser suportado no seu servidor.
Esben Skov Pedersen

1
Eu acho que a feiúra de um idioma é irrelevante se servir a um caso de uso relevante. Apenas testemunhe o sucesso do JavaScript. O problema com o XSLT é o caso de uso que simplesmente não existe.
precisa saber é o seguinte

1
Bem, você certamente demonstrou que é uma questão que atrai respostas baseadas em opinião ...
Michael Kay

0

Como o próprio XML parece lixo obsoleto de compatibilidade com versões anteriores para 99,9% dos casos.

O único caso de uso para o qual o XML não possui substituições imediatamente superiores é como docx ou odf, e é possível que o SGML tenha sido melhor *. Ou seja, temos uma estrutura de documentos incrivelmente rica, com todos os tipos de itens aninhados um no outro, com grandes transformações sendo aplicadas para que possam parecer corretas na tela e na impressora.

Quase o tempo todo, o XML é usado para transmitir dados estruturados e parece que o XSLT foi projetado para transformar dados estruturados em documentos. Esse caso de uso está acabando. O JSON é diretamente superior ao XML para dados estruturados. ** Tanto o markdown quanto o YAML são superiores em dados pouco formatados. A legenda inicial do XML foram os analisadores internos em Java e Javacript. O JSON quebrou essa barreira ao alavancar um analisador interno para os casos em que a fonte JSON é confiável (que era a maioria deles quando jovem).

E o mundo mudou. A vantagem da biblioteca interna é uma vantagem trivial agora. O XHTML foi totalmente rejeitado e sua substituição não foi herdada dele, mas de seu antecessor.

Agora, o XML é usado para conversar diretamente com o cara que deseja recebê-lo, e é gerado em um pano inteiro no formato desejado ou, inversamente, é lido e analisado para o modelo de objeto diretamente do formulário enviado. Como não é mais um formato de armazenamento ou de intercâmbio universal, não é mais necessário transformá-lo de esquema em esquema.

* Eles ensinaram na faculdade que o SGML nunca foi implementado. Eles mentiram.

** Ouvi as reclamações sobre formatos de números incorretos no JSON. Por outro lado, o XML não possui formato numérico; portanto, apenas o preenchimento de todos os tipos de dados na string ainda vence no XML.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.