Dlaczego XSLT jest tak rzadko używany w sieci? [Zamknięte]

XSLT jest dojrzałym, powszechnie akceptowanym standardem.

Można go używać w przeglądarkach (nawet w starym IE) i po stronie serwera (nginx ma moduł XSLT, którego oczywiście można używać z języków programowania). Jego implementacje są kompilowane i dlatego powinny być znacznie szybsze niż Python lub JS. Implementacja JS Saxon JS może być wykorzystana przynajmniej jako awaria. Szablony Jinja, Angular, Ruby's Slim, ASP i PHP nie są nawet blisko.

Szablon XSL można łatwo sprawdzić w środowisku IDE. Ile IDE może pomóc w Jinja lub Angular?

Wygląda na to, że to idealny pomysł na dekompozycję interfejsu użytkownika i danych za pomocą XSLT.

Co prawda implementacje mogą dawać różne wyniki w niektórych przypadkach narożnych, ale jest to problem tylko w przypadku szablonów po stronie klienta. To samo dotyczy HTML, CSS i wszystkiego innego, co dzieje się po stronie klienta.

Dlaczego więc nie XSLT?

XSLT nie ma tak naprawdę użytecznej roli we współczesnej interaktywnej sieci. Celem XSLT jest przekształcenie jednego języka XML w inny - ale tak naprawdę nigdy nie musisz tego robić w pierwszej kolejności. Jak mocna, szybka i dobrze obsługiwana technologia jest nieistotna, jeśli nie masz problemu, który technologia ma rozwiązać.

Istnieje kilka powodów, dla których przypadek użycia XSLT zniknął:

• HTML wygrał. XSLT miał być przydatny do przekształcania treści „tekstu sformatowanego” w jakimś semantycznym formacie znaczników w HTML. Ale HTML sam w sobie jest znakomitym formatem, więc dlaczego nie wykorzystać go w pierwszej kolejności i pominąć transformację?
• CSS stał się znacznie potężniejszy. Jedną z obietnic XSLT było to, że możesz utrzymać znacznik źródłowy w czystości i semantyczny, a następnie przekształcić go w „prezentacyjny HTML”, który działał w różnych przeglądarkach i gdzie można zmieniać układ elementów i tak dalej. Ale obecnie tak naprawdę nie potrzebujesz prezentacji HTML, możesz użyć semantycznego HTML, a CSS może wykonać niezbędne stylizacje i układ.
• XML nie stał się wszechobecnym formatem danych. Podczas pobierania danych SQL z bazy danych o wiele łatwiej jest po prostu bezpośrednio połączyć je w szablon, zamiast najpierw przekształcić je w XML, a następnie przekształcić za pomocą XSLT. A JSON prawie zastąpił XML dla danych strukturalnych po stronie klienta.
• XSLT jest zaprojektowany do przekształcania całego dokumentu na raz. Ale na nowoczesnych interaktywnych stronach internetowych małe fragmenty danych są cały czas pobierane fragmentarycznie i łączone na stronie.
• Dane po prostu nie są tak złożone. W większości przypadków użycia prostsze formaty szablonów z symbolami zastępczymi i repeaterami rozwiązują zadanie dobrze. XSLT jest o wiele bardziej wydajny, ale rzadko potrzebujesz tej dodatkowej mocy, a jego koszt i złożoność są ogromne.

XSLT wyrósł z publikowania, w którym można było przeprowadzić proces jednokierunkowy z jednego ustrukturyzowanego formatu źródłowego na wiele formatów publikacji, takich jak druk, PDF i statyczne strony internetowe. Większość stron internetowych nie pasuje do tego przypadku użycia.

Zależy, co rozumiesz przez „w sieci”.

XSLT jest bardzo szeroko stosowany. O ile jesteśmy w stanie ocenić na podstawie wskaźników, takich jak liczba pytań StackOverflow, znajduje się on w 30 najpopularniejszych językach programowania, co prawdopodobnie czyni go najlepszym językiem programowania specyficznym dla modelu danych po SQL.

Ale XSLT nie jest powszechnie używany po stronie klienta, to znaczy w przeglądarce. Zwykle jest używany po stronie serwera do dostarczania treści na żądanie w odpowiedzi na żądania HTTP lub jest używany w trybie wsadowym jako część procesu publikowania. Jest również stosowany oczywiście w wielu aplikacjach, które mają bardzo niewiele wspólnego z Internetem, np. W publikacjach drukowanych.

Istnieje wiele powodów, dla których XSLT nie jest szeroko stosowany w przeglądarce. Głównym powodem jest to, że dobra zgodna obsługa XSLT była bardzo powolna od dostawców przeglądarki; nikt nie chciał z niego korzystać, dopóki nie był dostępny w każdej przeglądarce, a zanim był dostępny w każdej przeglądarce, rzeczy, które ludzie chcieli robić w przeglądarce, przeszły (pamiętasz „Web 2.0”?) i implementacje XSLT w przeglądarce nie pomogło Ci tworzyć interaktywnych aplikacji ani pobierać danych za pomocą AJAX.

Saxonica (zrzeczenie się odpowiedzialności, to mój produkt) próbował wypełnić te luki za pomocą Saxon-JS, ale produkt jest spóźniony na imprezę, a tworzenie stron internetowych po stronie klienta jest bardzo modne, więc nie wystarczy mieć produkt, który zaznacza wszystkie pola techniczne. Częścią bycia opartym na modzie jest to, że większość witryn zorientowanych na dane (w odróżnieniu od zorientowanych na dokumenty) przeniosła się w kierunku JSON zamiast XML, głównie dlatego, że JSON jest znacznie łatwiejszy w obsłudze z JavaScript.

Innym problemem jest to, że XSLT jest językiem uwielbiającym lub nienawidzącym. Jego deklaratywny, oparty na regułach, funkcjonalnie zorientowany paradygmat przemawia do wielu ze względu na jego wysoki poziom, ale może zniechęcać tych, których jedynym doświadczeniem w programowaniu jest pisanie imperatywnego kodu, który mówi komputerowi dokładnie, co ma robić jaka kolejność.

Przerzucam się między odpowiedzią na to pytanie a zamykaniem go, opierając się głównie na opiniach. Oto moja klapka:

Krótko mówiąc, ponieważ XML tworzy gówniany język programowania. Myślę, że coś z semantyką XSLT, ale znacznie lepsza składnia , to zupełnie inna sprawa. Na przykład istnieje kilka naprawdę fajnych języków transformacji XML opartych na Lisp.

XSLT nie może zdecydować, czy chce być językiem przepisującym drzewo, językiem funkcjonalnym czy językiem proceduralnym. Ma wszystkie te cechy, ale w żadnym z nich nie jest zbyt dobra. W każdym z tych trzech aspektów istnieją lepsze języki.

Ponieważ sam XML wygląda jak przestarzałe śmieci kompatybilne wstecz dla 99,9% przypadków.

Jedynym przypadkiem użycia, w którym XML nie ma natychmiastowych lepszych zamienników, są rzeczy takie jak docx lub odf, i możliwe, że SGML byłby lepszy *. Oznacza to, że mamy niewiarygodnie bogatą strukturę dokumentu z wszystkimi rodzajami rzeczy zagnieżdżonymi w sobie, z dużymi transformacjami, dzięki czemu może wyglądać poprawnie na ekranie i drukarce.

Niemal cały czas XML jest używany do przesyłania danych strukturalnych i wydaje się, że XSLT jest zaprojektowany do przekształcania danych dokumentu strukturalnego w dane dokumentu. Ten przypadek użycia wymiera. JSON jest bezpośrednio lepszy od XML dla danych strukturalnych. ** Zarówno markdown, jak i YAML są lepsze w przypadku lekko sformatowanych danych. Początkową wersją XML były wbudowane parsery w Javie i Javacript. JSON przełamał tę barierę, wykorzystując wbudowany parser dla przypadków, w których źródło JSON jest zaufane (co było większością z nich, gdy było młode).

A świat się zmienia. Zaletą wbudowanej biblioteki jest teraz trywialna zaleta. XHTML został całkowicie odrzucony, a jego zastąpienie nie odziedziczyło po nim, ale od jego poprzednika.

XML jest teraz używany do bezpośredniej rozmowy z facetem, który chce go otrzymać, i jest generowany w całej strukturze w pożądanym formacie, lub odwrotnie, jest wczytywany i analizowany w celu modelowania obiektu bezpośrednio z formy, w której został wysłany. Ponieważ nie jest już format przechowywania lub uniwersalny format wymiany, przekształcanie go ze schematu do schematu nie jest już wymagane.

* Nauczali na studiach, że SGML nigdy nie został wdrożony. Kłamali.

** Słyszałem skargi na złe formaty liczb w JSON. Z drugiej strony XML nie ma formatu liczb, więc tylko upychanie wszystkich typów danych w łańcuchu nadal wygrywa z XML.