Perché XSLT è così raramente usato sul web? [chiuso]

XSLT è uno standard maturo, ampiamente accettato.

Può essere utilizzato nei browser (anche nel vecchio IE) e sul lato server (nginx ha un modulo XSLT, che può essere usato dai linguaggi di programmazione, ovviamente). Le sue implementazioni sono compilate e, pertanto, dovrebbero essere molto più veloci di Python o JS. L'implementazione di JS Saxon JS può essere utilizzata, almeno, come fallback. I modelli Jinja, Angular, Ruby's Slim, ASP e PHP non sono nemmeno vicini.

Un modello XSL può essere facilmente convalidato in un IDE. Quanti IDE possono aiutare con Jinja o Angular?

Sembra che sia un'idea perfetta per decomporre l'interfaccia utente e i dati con XSLT.

Certo, le implementazioni possono dare risultati diversi in alcuni casi angolari, ma è un problema solo con il modello sul lato client. Ed è lo stesso con HTML, CSS e tutto ciò che viene fatto sul lato client.

Quindi, perché non XSLT?

XSLT non ha davvero un ruolo utile nel moderno web interattivo. Lo scopo di XSLT è trasformare da un linguaggio XML in un altro, ma in realtà non è mai necessario farlo. Quanto sia potente, veloce e ben supportata una tecnologia è irrilevante se non si ha il problema che la tecnologia è progettata per risolvere.

Esistono diversi motivi per cui il caso d'uso per XSLT è scomparso:

• HTML ha vinto. XSLT doveva essere utile per trasformare il contenuto "rich text" in un formato di markup semantico in HTML. Ma l'HTML è di per sé un formato perfetto, quindi perché non utilizzarlo per il contenuto in primo luogo e saltare la trasformazione?
• CSS è diventato molto più potente. Una delle promesse di XSLT era che potevi mantenere il markup di origine pulito e semantico e poi trasformarlo in "HTML di presentazione" che funzionava su più browser e dove puoi riorganizzare gli elementi e così via. Ma in questi giorni non hai davvero bisogno di HTML per presentazioni, puoi usare HTML semantico e CSS per eseguire lo stile e il layout necessari.
• XML non è diventato il formato onnipresente per i dati. Quando si recuperano dati SQL da un database, è molto più semplice unirli direttamente in un modello, anziché trasformarli prima in XML e poi trasformarli tramite XSLT. E JSON ha praticamente sostituito XML per dati strutturati sul lato client.
• XSLT è progettato per trasformare un intero documento alla volta. Ma nelle moderne pagine Web interattive, piccoli frammenti di dati vengono scaricati frammentariamente in ogni momento e uniti alla pagina.
• I dati non sono così complessi. Per la maggior parte dei casi d'uso, i formati di modello più semplici con segnaposto e ripetitori risolvono il problema. XSLT è molto più potente, ma raramente hai bisogno di quella potenza extra e ha un costo elevato in termini di complessità e bruttezza.

XSLT è cresciuto dalla pubblicazione in cui è possibile avere un processo unidirezionale da un formato sorgente strutturato a più formati di pubblicazione come stampa, PDF e pagine Web statiche. La maggior parte dei siti Web non si adatta a questo caso d'uso.

Dipende da cosa intendi per "nel Web".

XSLT è molto usato. Per quanto possiamo giudicare da metriche come il numero di domande StackOverflow, è tra i primi 30 linguaggi di programmazione, il che probabilmente lo rende il miglior linguaggio di programmazione specifico per modello di dati dopo SQL.

Ma XSLT non è ampiamente utilizzato sul lato client, cioè nel browser. Di solito viene utilizzato sul lato server per fornire contenuti su richiesta in risposta alle richieste HTTP, oppure viene utilizzato in modalità batch come parte di un flusso di lavoro di pubblicazione. Viene anche usato, ovviamente, in molte applicazioni che hanno ben poco a che fare con il web, ad es. Nell'editoria cartacea.

Esistono diversi motivi per cui XSLT non è ampiamente utilizzato nel browser. Il motivo principale è che un buon supporto XSLT conforme è stato molto lento proveniente dai fornitori di browser; nessuno voleva usarlo fino a quando non era disponibile su tutti i browser, e quando era disponibile su tutti i browser, le cose che la gente voleva fare nel browser erano passate (ricordi "Web 2.0"?) e le implementazioni XSLT nel browser non ti ha aiutato a creare applicazioni interattive o a recuperare dati utilizzando AJAX.

Saxonica (dichiarazione di non responsabilità, questo è il mio prodotto) ha tentato di colmare queste lacune con Saxon-JS, ma il prodotto è un ritardatario per la festa e lo sviluppo web sul lato client è molto orientato alla moda, quindi non è sufficiente solo avere un prodotto che spunta tutte le caselle tecniche. Parte dell'essere orientati alla moda è che la maggior parte dei siti orientati ai dati (distinti da quelli orientati ai documenti) si sono spostati verso JSON piuttosto che su XML, soprattutto perché JSON è molto più facile da manipolare da Javascript.

L'altro problema è che XSLT è un linguaggio che ama o odia. Il suo paradigma dichiarativo, basato sulle regole e orientato al funzionamento fa appello a molti a causa della sua natura di alto livello, ma può essere scoraggiante per coloro la cui unica esperienza di programmazione è scrivere codice imperativo che dice al computer esattamente cosa fare e in quale ordine.

Sto girando avanti e indietro tra la risposta a questa domanda e la chiusura come principalmente basata sull'opinione pubblica. Quindi, ecco il mio rovescio:

In breve, perché XML rende un linguaggio di programmazione scadente. Qualcosa con la semantica di XSLT ma una sintassi molto migliore sarebbe una questione completamente diversa, penso. Esistono alcuni linguaggi di trasformazione XML basati su Lisp davvero interessanti, per esempio.

XSLT non può decidere se vuole essere un linguaggio di riscrittura dell'albero, un linguaggio funzionale o un linguaggio procedurale. Ha le caratteristiche di tutti questi, ma non è davvero buono in nessuno di essi. Per uno dei tre aspetti, ci sono lingue migliori là fuori.

Perché l'XML stesso sembra una spazzatura obsoleta di retrocompatibilità per il 99,9% dei casi.

L'unico caso d'uso per il quale XML non ha sostituzioni immediatamente superiori sono cose come docx o odf, ed è possibile che SGML sarebbe stato migliore *. Cioè, abbiamo una struttura del documento incredibilmente ricca con tutti i tipi di cose annidate l'una all'interno dell'altra con grandi trasformazioni applicate in modo che appaiano corrette sullo schermo e sulla stampante.

Quasi sempre, XML viene utilizzato per il trasferimento di dati strutturati e sembra che XSLT sia progettato per trasformare i dati strutturati in documenti. Quel caso d'uso si sta estinguendo. JSON è direttamente superiore a XML per i dati strutturati. ** Sia markdown che YAML sono superiori ai dati leggermente formattati. Il leg-up iniziale di XML era il parser integrato in Java e Javacript. JSON ha superato quella barriera sfruttando un parser incorporato per i casi in cui la fonte JSON è attendibile (che era la maggior parte di loro quando era giovane).

E il mondo è cambiato. Il vantaggio della libreria integrata è ora un vantaggio banale. XHTML è stato completamente respinto e la sua sostituzione non ha ereditato da esso ma dal suo predecessore.

XML è ora usato per parlare direttamente con il ragazzo che vuole riceverlo, ed è generato in tutto il tessuto nel formato desiderato, o viceversa viene letto e analizzato nel modello a oggetti direttamente dal modulo in cui è stato inviato. Dal momento che non è più un non è più necessario un formato di archiviazione o un formato di interscambio universale, trasformandolo da schema a schema.

* Hanno insegnato al college che SGML non è mai stato implementato. Hanno mentito.

** Ho sentito le lamentele sui formati di numeri errati in JSON. D'altra parte, XML non ha un formato numerico, quindi il solo riempimento di tutti i tipi di dati nella stringa vince ancora su XML.