Yet Another Template
Engine.
Есть мнение,
что нынешние веб-фреймворки, вроде RoR и
Django, которые MVC (Model, View, Controller), это хорошо
и даже круто. А еще есть мнение, что скоро
из MVC на клиента (в браузер) переберется
View и даже, может быть, местами — Controller.
Ибо зачем напрягать сервер, для которого
и так работа найдется, рендерингом
веб-страниц? Пусть рендерингом занимаются
браузеры, утилизируя невероятную
вычислительную мощу нынешних и будущих
десктопов/терминалов.
Чтобы быть
готовым к такому повороту, подумайте —
как убрать работу с шаблонами с сервера.
На сервере должна остаться только
генерация пакетов данных в формате
JSON.
Некоторые уже
подумали, причем раньше других:
в Яндекс.Почте
появился новый интерфейс, в котором
используется шаблонизация данных в
браузере. Немногие крупные сервисы
отваживались на это, но мы и сейчас
считаем такое решение наиболее удачным.
Оно не только ускорило работу интерфейса,
но и позволяет экономить трафик
пользователя и эффективнее расходовать
процессорное время серверов.
…
Недавно мы
перевели всю Почту на JS-шаблонизатор и
JSON-данные.
…
Почти сразу
стало очевидно, что императивные
шаблонизаторы (handlebars, jade, dust) не могут
сравниться по удобству разработки с
декларативными, их код превращался в
«кашу», в которой всё сложнее было
разбираться. К тому же мы привыкли к
гибкости XSL и сильному разграничению
данных и логики отображения, поэтому
нам было удобнее работать с шаблонизаторами
похожей семантики.
Таким образом,
в финале оказались yate и ajaxslt. Но, несмотря
на все старания наших разработчиков,
ajaxslt не смог приблизиться к производительности
yate
…
Yate — проект,
созданный и развиваемый фронтэнд-архитектором
Почты. Этот шаблонизатор уже успешно
зарекомендовал себя на нескольких
готовых, но ещё не представленных
проектах Яндекса. Yate очень похож на XSL:
при более лёгком и js-подобном синтаксисе
в нём используются те же парадигмы
(match, apply), поддерживаются предикаты, а
также есть jpath — аналог XPath для навигации
по JSON. Шаблоны компилируются в обычный
javascript и использовать их можно как на
клиенте, так и на сервере.
Вот так
выглядит один и тот же шаблон на XSL и на
yate:
остальное тут:
http://habrahabr.ru/company/yandex/blog/151700/
И нам пора
выносить V на клиента.
original post http://vasnake.blogspot.com/2014/02/yate.html
Этот комментарий был удален автором.
ОтветитьУдалитьИнтересно, а как у YATE c xslt-функцией document(), т.е. как брать нужные json. Покапался в документации и не нашел ничего. На входе подается один единственный json? Подгрузка не предполагается?? Тогда это слабое место.
ОтветитьУдалитьЭто не бага, это фича :)
УдалитьПо любому, я бы не стал рекомендовать YATE к использованию вне Яндекса. Это их внутренний продукт, для их внутренних целей. Они так привыкли, им так удобно.
Все остальные активно юзают всякие ангуляры с редуксами и т.д. и т.п.
Да, по видимому рассчитывать на Yate не стоит. Яндекс-почта - это круто, но походу ее специфическими потребностями все и ограничилось. Но это же жесть...
УдалитьВ плане обеспечения декларативного языка вполне устраивает XSLT (особенно в союзе с EXSL), но только не в плане XML-нотации. Последняя не только убивает избыточностью, но и просто стремительно устаревает. Показательна кухня весьма консервативного semantic-web. Десять лет они карпели над моделью данных RDF в xml-окружении, но вот уже и там новый фаворит - JSON-LD. Это та же RDF, но без XML. ...Через какое-то время о XML просто будет стыдно говорить. И фиг бы с ним, но нужна замена XSLТ. Вместе с водой выливается и мальчик! )
Как показывает практика (http://stackoverflow.com/questions/1618038/xslt-equivalent-for-json), связка JSON + Javascript закрывает все потребности.
УдалитьКак в старом анекдоте: почему у вас черную икру не продают -- спроса нет, никто не спрашивает.
Вероятно это так для сильных кодеров, но для таких как я удивительная доступность XSLT (при сохранении полезности для бизнеса) слишком важна.
ОтветитьУдалитьСпасибо за ссылку. Вариантов оказывается много. Оформились даже группы:
1. "Есть аналог". Примеры: Yate, XJST, JSLT, DefiantJS, JSON-Transforms. Увы, все слабы.
2. "Аналога нет, но можно на ходу преобразовать json в xml". Не вариант.
3. "Аналога нет, но есть частичная его заменена". Примеры: tempo, jsonT и масса других. Не то.
4. "Лучший аналог - JavaScript, т.к. он у него все для этого есть". Да, но сложно.
5. "Аналог не нужен, т.к. XSLT в версии 3 умеет работать с json". Да, но у xsl-процессоров и с второй-то версией проблемы.
Походу отказываться от XML/XSLT рано. Другое дело, что NoSQL-СУБД должна в основном оперировать JSON, а ответы на запросы выдавать по разному и в том числе в XML. Это правда, ставит преграду перемещения бизнес-кода на сторону браузера. ...Что наверное хорошо с точки зрения MVC.