Чому XSLT так рідко використовується в Інтернеті? [зачинено]

XSLT - зрілий, широко прийнятий стандарт.

Його можна використовувати в браузерах (навіть у старих IE) та на стороні сервера (у nginx є модуль XSLT, який, звичайно, можна використовувати з мов програмування). Її реалізація компілюється і, отже, повинна бути набагато швидшою, ніж Python або JS. Реалізація JS Saxon JS може бути використана, принаймні, як резервна. Шаблони Jinja, Angular, Ruby's Slim, ASP та PHP навіть не близькі.

Шаблон XSL можна легко перевірити в IDE. Скільки IDE можуть допомогти Jinja або Angular?

Схоже, це ідеальна ідея розкласти інтерфейс і дані за допомогою XSLT.

Правда, реалізація може давати різні результати в деяких кутових випадках, але проблема полягає лише в шаблонуванні на стороні клієнта. І те ж саме з HTML, CSS та всім іншим, що робиться на стороні клієнта.

Отже, чому б не XSLT?

XSLT насправді не має корисної ролі в сучасній інтерактивній мережі. Метою XSLT є перетворення з однієї мови XML в іншу, але вам насправді ніколи цього не потрібно робити. Наскільки потужна, швидка і добре підтримувана технологія не має значення, якщо у вас немає проблеми, яку ця технологія покликана вирішити.

Існує кілька причин, чому випадок використання для XSLT відійшов:

• Перемогла HTML. XSLT повинен був бути корисним для перетворення вмісту "насиченого тексту" в якомусь семантичному форматі розмітки в HTML. Але HTML сам по собі є прекрасним форматом, то чому б не просто використовувати це для контенту в першу чергу і пропустити перетворення?
• CSS став набагато потужнішим. Однією з обіцянок XSLT було те, що ви зможете зберегти розмітку джерела чистою та семантичною, а потім перетворити її на "презентаційний HTML", який працював між браузером і де ви могли переставити елементи тощо. Але презентаційний HTML вам не потрібен справді, ви можете використовувати семантичний HTML, а CSS може виконати необхідну стилізацію та компонування.
• XML не став повсюдним форматом даних. При отриманні даних SQL з бази даних набагато простіше просто об'єднати їх у шаблон, а не спочатку перетворити їх у XML, а потім перетворити через XSLT. І JSON має все, крім заміненого XML, для структурованих даних на стороні клієнта.
• XSLT призначений для трансформації всього документа за один раз. Але на сучасних інтерактивних веб-сторінках невеликі фрагменти даних весь час завантажуються по частинах і об'єднуються в сторінку.
• Дані просто не такі складні. У більшості випадків використання більш прості формати шаблонів із заповнювачами та ретрансляторами вирішують завдання. XSLT є набагато більш потужним, але вам рідко потрібна додаткова потужність, і вона має круті витрати у складності та потворності.

XSLT виріс із публікації, де ви могли провести односторонній процес від одного структурованого вихідного формату до декількох форматів публікації, таких як друк, PDF та статичні веб-сторінки. Більшість веб-сайтів не відповідає цьому випадку використання.

Залежить від того, що ви маєте на увазі під "Web".

XSLT дуже широко використовується. Наскільки ми можемо судити з таких показників, як кількість запитань StackOverflow, він знаходиться в топ-30 мов програмування, що, ймовірно, робить його найпопулярнішою мовою програмування, характерною для моделі даних після SQL.

Але XSLT не широко використовується на стороні клієнта, тобто в браузері. Зазвичай він використовується або на стороні сервера для доставки вмісту на вимогу у відповідь на HTTP-запити, або використовується в пакетному режимі як частина робочого процесу публікації. Він, звичайно, також використовується у багатьох програмах, які мають дуже мало спільного з Інтернетом, наприклад, у друкованому виданні.

Існує ряд причин, коли XSLT широко не використовується в браузері. Основна причина полягає в тому, що хороша підтримка XSLT, яка відповідає, була дуже повільною від постачальників браузера; ніхто не хотів користуватися ним, поки він не був доступний у кожному веб-переглядачі, і до того моменту, коли він був доступний у кожному браузері, те, що люди хотіли зробити у браузері, перейшло (пам’ятаєте «Веб 2.0»?) та реалізації XSLT у веб-переглядачі не допомогли створити інтерактивні програми або отримати дані за допомогою AJAX.

Saxonica (відмова, це мій продукт) намагалася усунути ці прогалини із Saxon-JS, але продукт є запізненкою для партії, а веб-розробка веб-сторінок дуже орієнтована на моду, тому недостатньо просто мати продукт, який галочує всі технічні коробки. Частина модного моменту полягає в тому, що більшість сайтів, орієнтованих на дані (на відміну від документоорієнтованих) перемістилися до JSON, а не до XML, значною мірою тому, що JSON набагато простіше маніпулювати Javascript.

Інша проблема полягає в тому, що XSLT - це мова, яку люблять або ненавидять. Його декларативна, на основі правил функціонально орієнтована парадигма подобається багатьом через її високий рівень, але може бути відмінна для тих, чий єдиний досвід програмування - написати імперативний код, який повідомляє комп'ютеру, що саме потрібно робити який порядок.

Я перевертаю між собою відповіді на це запитання і закриваю його як головне на основі думки. Отже, ось мій фліп:

Коротше кажучи, тому що XML робить хитру мову програмування. Щось із семантикою XSLT, але набагато кращим синтаксисом було б зовсім інше питання, я думаю. Наприклад, є кілька класних мов перетворення XML на основі Lisp.

XSLT не може вирішити, чи хоче вона бути деревою, що переписує дерево, функціональною мовою чи процедурною мовою. Він має особливості всіх цих, але це не дуже добре в жодному з них. Для будь-якого з трьох аспектів є кращі мови.

Оскільки XML сам по собі виглядає як застарілий недоброзичливий смітник у 99,9% випадків.

Єдиний випадок використання, у якому XML не має негайно покращених замін, - такі речі, як docx або odf, і можливо, що SGML був би кращим *. Тобто ми маємо неймовірно багату структуру документів з усіма видами речей, які вкладаються всередину один одного з великими перетвореннями, що застосовуються, щоб вони могли виглядати правильно на екрані та принтері.

Майже весь час XML використовується для передачі структурованих даних навколо, і, здається, XSLT призначений для перетворення структурованих даних документа в дані документа. Цей випадок використання вимирає. JSON безпосередньо перевершує XML за структурованими даними. ** Як відмітка, так і YAML є кращими у легких форматованих даних. Початковою ланкою XML були вбудовані аналізатори Java та Javacript. JSON подолав цей бар'єр, використовуючи вбудований аналізатор для випадків, коли джерелу JSON довіряють (що було більшістю з них, коли він був молодим).

І світ змінився. Перевага вбудованої бібліотеки зараз є тривіальною перевагою. XHTML було відхилено прямо, і його заміна не успадкувала його, а його попередник.

XML зараз використовується для спілкування безпосередньо з хлопцем, який хоче його отримати, і він генерується цілим полотном у потрібному форматі, або, навпаки, він читається та аналізується для об'єктної моделі безпосередньо з форми, яку вона надсилає. Оскільки це вже не формат зберігання або універсальний формат обміну, перетворення його зі схеми в схему більше не потрібно.

* Вони навчали в коледжі, що SGML ніколи не був реалізований. Вони брехали.

** Я чув скарги на поганий формат чисел у JSON. З іншого боку, XML не має формату чисел, тому просто заповнення всіх типів даних у рядку все ще виграє проти XML.