Комментарии 147
Прекрасная статья.
А выложить в public ваш чудесный шаблонизатор не хотите? ;)
А выложить в public ваш чудесный шаблонизатор не хотите? ;)
Уже — github.com/mailru/fest
На него есть ссылка в статье, но добвил блок в конце статьи.
У Gmail прогресбар «почта загружается».
Но, допустим мы решаем что это приемлимо, всеравно будут блоки с шаблонизацией на сервере.
Но, допустим мы решаем что это приемлимо, всеравно будут блоки с шаблонизацией на сервере.
даже если откажутся, все равно будут поддерживать noscript версию, у гмэйла же есть
все таки почта это не развлекательный ресурс и требовать от человека включенный JS для использования основного функционала — написания и чтения писем — не очнеь хорошо. Хоть и выключенный JS бывает крайне редко
все таки почта это не развлекательный ресурс и требовать от человека включенный JS для использования основного функционала — написания и чтения писем — не очнеь хорошо. Хоть и выключенный JS бывает крайне редко
Веб-интерфейс в браузере, клиентская часть? Субъективно, кажется, что так и есть.
Загружается gmail дольше — факт.
А работает оно также, это с учетом того что пинг до mail.ru всяко меньше.
А работает оно также, это с учетом того что пинг до mail.ru всяко меньше.
Потому что загружает сразу много данных. Если обратите внимание, письма на первой странице открываются сразу без дополнительных запросов.
Просто у Gmail немного иной подход, который позволяет вдобавок работать в офлайне.
Просто у Gmail немного иной подход, который позволяет вдобавок работать в офлайне.
Занятно, только увы не реюзабельно, ведь всё завязано на вашу архитектуру и окружение.
Ничуть, готовый шаблон это файл с js функцией.
Это достаточно легко встраивается в любую архитектуру.
Но, тем не менее, основной поинт что JavaScript на сервере это уже сегодня, и мы тоже это проверили на себе.
Это достаточно легко встраивается в любую архитектуру.
Но, тем не менее, основной поинт что JavaScript на сервере это уже сегодня, и мы тоже это проверили на себе.
Отличная статья! Не так часто можно посмотреть кухню больших компаний, а ведь кто еще сможет рассказать об опыте работы с по-настоящему большими нагрузками.
Последнее время Mail.ru приятно удивляет. И разработчиков думающих набирают.
Что-то же должно меняться к лучшему.
Что-то же должно меняться к лучшему.
Когда б они уже к этой красоте сделали бы доступ по https…
Скоро сделаем. Потерпите немного.
Никак не мог понять, что вам до этого-то всё мешало SSL запустить? Ну не нехватка же ресурсов?!
Ничего не мешало. Надо было просто за нее взяться. Запуск SSL — это гигантская по объему техническая задача. Нужно перелопатить всю верстку, в поисках httpшных картиной и js'ов, заменив их на schemeless (чтобы браузеры не ругались). Нужно корректно выкусить из серверной части все темные углы, где такое закардкожено. Нужно разработать прокси-сервер для показа сторонних картинок в письмах. Нужно научить показывать рекламу и баннеры по https, и автоматически и интеллектуально защитить админку рекламной сети от заноса туда баннеров, на которые браузер будет ругаться на httpsной версии. Нужно оценить рост нагрузки на сервера (поддерджка SSL — это такая задача для процессора, что на нем можно жарить яичницу). Нужно в конце-концов решить организационные задачи, типа доработки тест-планов у тестировщиков. И т.д., и т.п. И это все на фоне новой разработки, запуска фич, без ущерба для старого и только что созданного функционала.
Я правильно понял, что для клиентской шаблонизации на клиент уходят уже скомпилированные шаблоны?
Привет, Рубаха!
Напоминает меня.
Уже давно разрабатываю свой шаблонизатор под NodeJS. Для меня сразу было очевидно, что управляющие конструкции должны быть в формате XML.
Сначала шаблон компилировался в структуру. Когда же была готова стабильная версия, решил сравнить производительность с Dust. Оказалось, что такая архитектура шаблонизатора изначально тупиковая — сказываются накладные расходы при обработке полученной структуры.
Сейчас же допиливается версия компиляции в функцию и уже выигрывает у Dust в 3-5 раз.
Ну и плоский хеш это, конечно, жестоко.
Уже давно разрабатываю свой шаблонизатор под NodeJS. Для меня сразу было очевидно, что управляющие конструкции должны быть в формате XML.
Сначала шаблон компилировался в структуру. Когда же была готова стабильная версия, решил сравнить производительность с Dust. Оказалось, что такая архитектура шаблонизатора изначально тупиковая — сказываются накладные расходы при обработке полученной структуры.
Сейчас же допиливается версия компиляции в функцию и уже выигрывает у Dust в 3-5 раз.
Ну и плоский хеш это, конечно, жестоко.
Dust, по вашей ссылке — давно заброшенный проект. Интересно сравнение весрии LinkedIn-a — github.com/linkedin/dustjs, с вашим шаблонизатором.
Для меня сразу было очевидно, что управляющие конструкции должны быть в формате XML.
Странная очевидность. Лично для меня очевидно, что это плохое решение. Если нам надо значение вставить в параметр, то вся структура xml рушится:
<a href="/user/<fest:value>json.user.name</fest:value>">Go to <fest:value>json.user.name</fest:value> profile</a>
Да и смотрится оно просто блевотно в сравнении с, например
<a href="/user/{json.user.name}">Go to {json.user.name} profile</a>
Фигурные скобки в аттрибутах мы поддерживаем.
А рассуждать понятиями блевотно/не блевотно очень странно для технического человека.
Понятия поддерживаемость, интеграция, валидация куда ближе.
А рассуждать понятиями блевотно/не блевотно очень странно для технического человека.
Понятия поддерживаемость, интеграция, валидация куда ближе.
На самом деле рассуждать так совершенно не странно. Программирование — это не только тяжёлая рутинная работа, но ещё и творчество и удовольствие, потому люди выбирают не только инструменты «лучше», но и инструменты «приятнее».
Есть такое понятие, как усталость от кода. Чем больше усталость — тем меньше КПД программиста. Чем меньше КПД программиста — тем хуже «поддерживаемость, интеграция, валидация».
А усталость — вещь субъективная, как и «блевотно/не блевотно».
Такая позицитая достаточно аргументирована для технического человека?
Есть такое понятие, как усталость от кода. Чем больше усталость — тем меньше КПД программиста. Чем меньше КПД программиста — тем хуже «поддерживаемость, интеграция, валидация».
А усталость — вещь субъективная, как и «блевотно/не блевотно».
Такая позицитая достаточно аргументирована для технического человека?
Такая достаточно.
Еще люди выбирают инструмены у которых свойства «проще прочитать», «быстрее написать» и «интуитивней понять» максимальны.
Для меня fest это ЯП на XML, который транслируется в JavaScript. XML транслируется в JavaScript… ок — сейчас что только в JavaScript ни транслируется.
«проще прочитать» — получает минус (XML читается хуже)
«быстрее написать» — получает минус (XML)
«интуитивней понять» — на уровне
и как бонус микс декларативности и функциональности…
Если бы мне хотелось добавить строгости и ограничить возможности я бы постарался написать некий диалект JavaScript, который будет понятен и разработчикам и верстальщикам. И транслировался бы он в такой же шустрый код.
Для меня fest это ЯП на XML, который транслируется в JavaScript. XML транслируется в JavaScript… ок — сейчас что только в JavaScript ни транслируется.
«проще прочитать» — получает минус (XML читается хуже)
«быстрее написать» — получает минус (XML)
«интуитивней понять» — на уровне
и как бонус микс декларативности и функциональности…
<fest:script>
var text = "mail.ru"
</fest:script>
<fest:value>text</fest:value>Если бы мне хотелось добавить строгости и ограничить возможности я бы постарался написать некий диалект JavaScript, который будет понятен и разработчикам и верстальщикам. И транслировался бы он в такой же шустрый код.
<ul>
items.forEach((v, i, all) =>
<li>all[i]</li>
)
items.forEach(v =>
<li>v</li>
)
</ul>Об этом я писал ниже.
Если нам надо значение вставить в параметр, то вся структура xml рушится:
<a href="/user/<fest:value>json.user.name</fest:value>">Go to <fest:value>json.user.name</fest:value> profile</a>
Там все несколько сложнее, почти как в xsl:
<a>
<fest:attributes>
<fest:attribute name="href">/user/<fest:value>json.user.name</fest:value></fest:attribute>
</fest:attributes>
Go to <fest:value>json.user.name</fest:value>
</a>
Мне в этом вопросе, больше понравился подход LinkedIn-a — они вместо написания своего велосипеда, проанализировали уже готовые решения и выбрали подходящее им. Подробнее в их блоге — engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more
Тоже сейчас занимаюсь реализацией шаблонизатора, который умеет собираться на сервере и на клиенте
Серверная часть компилится в PHP — код, клиентская в Js — код.
Примечательно, что Js шаблон реализован точно так же в виде функции, которая возвращяет HTML и использует для генерации нативный js.
По поводу шаблона в виде XML: я в своё время отказался от это идеии ввиду невозможности написать так
Как видно, я остановился на синткасисе а-ля Smarty. К тому же во всех нормальных IDE всё прекрасно подсвечивается и подсказывается.
Серверная часть компилится в PHP — код, клиентская в Js — код.
Примечательно, что Js шаблон реализован точно так же в виде функции, которая возвращяет HTML и использует для генерации нативный js.
По поводу шаблона в виде XML: я в своё время отказался от это идеии ввиду невозможности написать так
<div class="bla {if $active} active{/if}">
Как видно, я остановился на синткасисе а-ля Smarty. К тому же во всех нормальных IDE всё прекрасно подсвечивается и подсказывается.
Если немного подумать, то могут быть и другие решения, например как в fest с тегом attribute. Но мне такое решение не по душе, я сделал так:
А в атрибут уже выводится так:
<tsn:var name="className" expr="active ? 'active' : ''" />
А в атрибут уже выводится так:
<div class="bla &tsn.echo.className;" />
Да, там стандартное экранирование.
Но если нужна прям логика то можно ее обернуть в <fest:script/>
Но если нужна прям логика то можно ее обернуть в <fest:script/>
Проблемы компиляции.
Мы должны в скомпилированном коде написать
А теперь вопрос, в каком месте надо написать
Как понять что секция с атрибутами закончилась и можно закрыть тег?
<input type="checkbox">
<fest:attribute name="class">cbx</div>
<fest:if test="false">
<fest:attribute name="checked">checked</fest:attribute>
</fest:if>
</input>
Мы должны в скомпилированном коде написать
html += '<input type="checkbox"';
html += ' class="cbx"';
fest_if = node.attributes.test
if (fest_if){
html += ' checked="checked"';
}
А теперь вопрос, в каком месте надо написать
html += '/>';
Как понять что секция с атрибутами закончилась и можно закрыть тег?
Пока не планируем.
Она очень сильно зависит от реализации проекта.
Плюс вы можете сделать JS функцию lang('key') и прекрасно с этим жить.
Она очень сильно зависит от реализации проекта.
Плюс вы можете сделать JS функцию lang('key') и прекрасно с этим жить.
У нас тоже в свое время встал вопрос о шаблонизации.
Ситуация усугублялась тем, что бизнес логика была реализована на php, а кусочек ее — демон — на Ноде.
В качестве шаблонизатора на пхп части мы использовали толковую штуку Twig, которая является реализацией Джанговских шаблонов.
Перебирая возможные движки для Ноды, с удивлением наткнулись на SWIG, который, за исключением некоторых мелочей, умел все, что нужно.
Теперь изучаем, как серверный SWIG плавно перенести в браузер.
Ситуация усугублялась тем, что бизнес логика была реализована на php, а кусочек ее — демон — на Ноде.
В качестве шаблонизатора на пхп части мы использовали толковую штуку Twig, которая является реализацией Джанговских шаблонов.
Перебирая возможные движки для Ноды, с удивлением наткнулись на SWIG, который, за исключением некоторых мелочей, умел все, что нужно.
Теперь изучаем, как серверный SWIG плавно перенести в браузер.
Мы у себя используем SWIG для трансформации на ноде и в браузере. Далее поток мыслей — январь 2012 года (в феврале его обновили хорошо, но я не смотрел, что там сделали). В браузер перенес небольшим допиливанием. Ужасно объемный код на выходе, который получает в итоге клиент. Из-за того что, все конструкции заворачиваются в замыкания, то нет возможности установить переменную внутри конструкции if, а затем к ней обратиться извне. В Opera проблемы из-за того, что в скомпилированном шаблоне все обращения к переменным проходят в итоге через window, а Opera создает в window переменные указатели на input с именами аттрибутов name и получаем строки [Object HTMLInputElement] в выдаче.
Вроде как twigjs более точно повторяет оригинальный Twig. И нормально работает в браузере.
Так в каком месте у вас 1ms?
Главная mail.ru вижу сейчас собирается за 67ms.
Главная mail.ru вижу сейчас собирается за 67ms.
Пользуясь случаем, хочу спросить. Планирует ли Mail.ru переработать веб-агент? Дело в том, что он включен по умолчанию и при открытии почты в бразерах IE, начинает грузить процессор под 100%. При отключенном веб-агенте такой нагрузки нет.
Техподдержка рекомендует сменить браузер, но, к сожалению, это не приемлемо в корпоративном секторе.
Техподдержка рекомендует сменить браузер, но, к сожалению, это не приемлемо в корпоративном секторе.
Насчет статьи Игоря Сысоева — читал эту статью уже давноб но с тех пор уже много воды утекло и NodeJS стал другой и V8. Интересно что сейчас Игорь об этом думает?
По сравнению со старым, по функциональности, мы сильно выиграли.
Там нет переопределения (set и get), там нет средств работы с данными.
Там нет переопределения (set и get), там нет средств работы с данными.
Если честно Использование set и get выглядит очень избыточно, по сравнению с возможным решением:
Результат:
Параметры foo и bar берутся либо из:
— функции (имя функции прописывается как _fn=«some_function»)
— наследуются от родительского элемента
— переменных окружений
— явно назначаются (если задать значение параметру типа foo=1, то так и будет)
Если параметра нет и его значение явно не задано, то название параметра не будет выведено.
<#:tag _name="a" _action="mail" _params="foo,bar">link</tag:#>Результат:
<а httр://mail.ru?foo=1&bar=2">link</а>Параметры foo и bar берутся либо из:
— функции (имя функции прописывается как _fn=«some_function»)
— наследуются от родительского элемента
— переменных окружений
— явно назначаются (если задать значение параметру типа foo=1, то так и будет)
Если параметра нет и его значение явно не задано, то название параметра не будет выведено.
Вы зачем такой узкий пример привели?
В get может находится целый кусок функционала.
В get может находится целый кусок функционала.
А для чего вообще хранить логику в шаблоне?
/page.xml
<html>
<head>...</head>
<body>
<fest:get name="content"/>
</body>
</html>
<fest:set name="content">404</fest:set>
/index.xml
<fest:include src="page.xml"/>
<fest:set name="content">
<div class="page">Hello habr</div>
</fest:set>
/info.xml
<fest:include src="page.xml"/>
<fest:set name="content">
<div class="page">Have a nice day!</div>
</fest:set>
Это хранение логики в шаблоне или нет?
Напомнило zpt.sourceforge.net/
Я бы не хотел писать эти шаблоны.
А почта работает действительно быстро.
Я бы не хотел писать эти шаблоны.
А почта работает действительно быстро.
Но в Mail.Ru Group есть целая команда высококвалифицированных людей, знающих JS, способных самостоятельно написать инструмент, а самое главное — они же им и будут пользоваться.Как я понял: Либо высококвалифицированные специалисты знающие JavaScript будут кодить на xslt-подобном языке с javascript-вставками, либо вы привираете насчет квалификации :) В любом случае что-то не сходится…
С виду тот же xslt, только свой велосипед(сейчас не идет речь о том как он летает). И как человек работавший с xslt и пишуший сейчас на JavaScript скажу, что на xml-подобном синтаксисе писать очень не благодарное дело.
Вы узнавали у ваших разработчиков нравится ли им fest (если они, конечно еще, писали на чем-то кроме xslt)? Были ли альтернативы синтаксиса? Вообще вы спросили их в каком виде им приятнее писать?
Разработчики — это самый дорогой ресурс и их время и нервы нужно экономить.
P.S. А почему не стали транслировать в Cи? Была бы ракета!
В Си на сервере, раз у вас для v8 и так используются спец конструкции, то и наверно результат трансляции разный.
Что не сходится? Есть люди обладающие желанием и квалификацией писать инструмент для себя.
Т.е. получается, что высококвалифицированные специалисты знающие JavaScript будут кодить на xslt-подобном языке?
Это же шаблонизатор, не более, он мог быть написан на любом языке, просто в этом случае серверный язык JS.
Не кодить а шаблонизировать.
Кодить будут на JS.
Кодить будут на JS.
И еще раз повторю, мы сами долго думали XML или велосипед.
Пока выбрали XML как проверенное решение.
Что будет завтра как знать?
Пока выбрали XML как проверенное решение.
Что будет завтра как знать?
Да, попробуйте узнать у своих разработчиков, что бы они хотели видеть в качестве шаблонизатора. Как они видят шаблонизатор, как бы ИМ удобныее было писать шаблоны (выкиньте на время все эти «плюшки» xml). Любой шаблонизатор можно переделать так или иначе в ракету, сделать строгим, расширяемым, главное, чтобы разработчикам было приятно с ним работать. Надеюсь, вы меня поняли :)
Я не верю, что класный JavaScript с радостью бы стал писать шаблоны на xml если у него были бы альтернативы.
Я не верю, что класный JavaScript с радостью бы стал писать шаблоны на xml если у него были бы альтернативы.
Мы вместе его и разрабатывали.
Вообще как я предполагал дисскуссия свалилась в XML не XML, это хорошо, значит по основному вопросу разногласий нет. Если вы не заметили в заголовке статьи ни слова про fest и XML.
Вообще как я предполагал дисскуссия свалилась в XML не XML, это хорошо, значит по основному вопросу разногласий нет. Если вы не заметили в заголовке статьи ни слова про fest и XML.
Летает быстро — это хорошо, но немаловажна скорость и комфорт разработки, которые вытекает из синтаксиса шаблонизатора.
Использовать nodejs для шаблонизации и отсутствия дублирования кода — мысль здравая
Использовать xml как шаблонизатор — мысль НЕ здравая
Использовать xml как шаблонизатор — мысль НЕ здравая
Меня поражает ваша самоуверенность.
Я не работаю в Mail.ru, но мне тоже нравится этот вариант синтаксиса шаблонизатора. Скажу больше — такие шаблонизаторы существуют уже давно.
Все «минусы» xml вытекают сугубо из личных предпочтений.
Например: долго набирать. Но ведь autocomplete и ZenCoding никто не отменял. Не читается? Но ведь тысячи web-разработчиков используют HTML и XML в повседневной разработке и вполне неплохо себя чувствуют.
Все остальные минусы, как-то: поломка синтаксиса при использовании тегов в значениях атрибутов или хранение логики в шаблонах — исключительно минусы реализации, но не как самого XML как такового.
Не нужно преподносить своё мнение как единственно верное.
И уж тем более ничего «больного» в xml я не вижу.
Я не работаю в Mail.ru, но мне тоже нравится этот вариант синтаксиса шаблонизатора. Скажу больше — такие шаблонизаторы существуют уже давно.
Все «минусы» xml вытекают сугубо из личных предпочтений.
Например: долго набирать. Но ведь autocomplete и ZenCoding никто не отменял. Не читается? Но ведь тысячи web-разработчиков используют HTML и XML в повседневной разработке и вполне неплохо себя чувствуют.
Все остальные минусы, как-то: поломка синтаксиса при использовании тегов в значениях атрибутов или хранение логики в шаблонах — исключительно минусы реализации, но не как самого XML как такового.
Не нужно преподносить своё мнение как единственно верное.
И уж тем более ничего «больного» в xml я не вижу.
Хорошая статья. Потмоу, что я сам не раз ломал голову, как решить проблему возникающую в любом продвинутом аякс-приложении:
> два набора совершенно разных шаблонов на сервере и на клиенте.
От себя добавлю: не только шаблоны, если нужна офлайн работа, придется еще и модельки, их валидацию и хранилище дублировать. Мне пришли в голову такие идеи:
1) сделать Xml-based язык шаблонов и компилировать его в PHP (или что-нибуль Си-подобное если требуется скорость) и JS для клиента — заведомо FAIL, так как после богатых возможностей PHP с циклами, вызовами хелперов, константами, массивами на нем невозможно будет программировать
2) сделать шаблоны на PHP, а для клиента сделать транслятор PHP subset в JS — это во-первых, сложно, во-вторых, мало перенести конструкии языка, ведь в шаблонизаторе используются модели (класссы на PHP) и хелперы (PHP-функции) — их-то как перенести, а? Дублировать всю логику на клиентсайде что ли?
3) (не выход) перенести всю логику на клиента — не подходит, так как без яваскрипта не будет работать.
4) перейти на сторону тьмы и использовать уродливый тяжелый GWT — опять же, без JS он вроде нормально не работает.
Таким образом, проблем много, а решения я не вижу никакого. Выхода, как говорится, нет. Стоит отказаться от JSON и гонять с сервера шаблонизированные данные видимо.
Потому ваш подход все же не впечатляет. Node.JS вместо компиляции в Си++ на сервере, плюс слабые возможности, плюс нельзя в шаблоне использовать хелперы и серверные классы. Слишком много недостатков.
> два набора совершенно разных шаблонов на сервере и на клиенте.
От себя добавлю: не только шаблоны, если нужна офлайн работа, придется еще и модельки, их валидацию и хранилище дублировать. Мне пришли в голову такие идеи:
1) сделать Xml-based язык шаблонов и компилировать его в PHP (или что-нибуль Си-подобное если требуется скорость) и JS для клиента — заведомо FAIL, так как после богатых возможностей PHP с циклами, вызовами хелперов, константами, массивами на нем невозможно будет программировать
2) сделать шаблоны на PHP, а для клиента сделать транслятор PHP subset в JS — это во-первых, сложно, во-вторых, мало перенести конструкии языка, ведь в шаблонизаторе используются модели (класссы на PHP) и хелперы (PHP-функции) — их-то как перенести, а? Дублировать всю логику на клиентсайде что ли?
3) (не выход) перенести всю логику на клиента — не подходит, так как без яваскрипта не будет работать.
4) перейти на сторону тьмы и использовать уродливый тяжелый GWT — опять же, без JS он вроде нормально не работает.
Таким образом, проблем много, а решения я не вижу никакого. Выхода, как говорится, нет. Стоит отказаться от JSON и гонять с сервера шаблонизированные данные видимо.
Потому ваш подход все же не впечатляет. Node.JS вместо компиляции в Си++ на сервере, плюс слабые возможности, плюс нельзя в шаблоне использовать хелперы и серверные классы. Слишком много недостатков.
Компиляция в два языка рассматривалась, но она мне очень не нравится.
Если мы говорим про JS то с обновлением движков как v8 так и остальных, мы будем бесплатно получать новые фичи в шаблонизаторе.
При компиляции в два языка это не возможно.
Плюс вы и правда думаете в Mail.ru на сервере только один язык? Сколько компиляторов тогда надо сделать?
Если мы говорим про JS то с обновлением движков как v8 так и остальных, мы будем бесплатно получать новые фичи в шаблонизаторе.
При компиляции в два языка это не возможно.
Плюс вы и правда думаете в Mail.ru на сервере только один язык? Сколько компиляторов тогда надо сделать?
Непонятно, зачем придумывать что-то на устаревшем, де факто, XML, когда есть JSON. too enterprisy.
И вообще, пока лучшего шаблонизатора для JS, чем Jade, я пока не видел.
И вообще, пока лучшего шаблонизатора для JS, чем Jade, я пока не видел.
Я привел целый ряд причин за XML, думаю есть смысл на них ответить.
Второе, имея JS на сервере сменить один JS шаблонизатор на другой задача на порядок проще задачи притащить JS на сервер.
Второе, имея JS на сервере сменить один JS шаблонизатор на другой задача на порядок проще задачи притащить JS на сервер.
Андрей, нет причин для использования XML, кроме унаследованных приложений и поддержки корпоративных протоколов (SOAP-based).
XML более многословен и менее быстр для формирования и парсинга.
Пора принять JSON как аксиому.
XML более многословен и менее быстр для формирования и парсинга.
Пора принять JSON как аксиому.
Я в этом уже который год пытаюсь убедить разработчиков Icecast2(там xml и конфиг и вывод статистики)
Скорость парсинга не важна, на продакшене XML нет.
JSON хорош, мы его используем для данных.
А Jade это не JSON, не надо лукавить.
JSON хорош, мы его используем для данных.
А Jade это не JSON, не надо лукавить.
JSON — это формат обмена данными, к организации когда он никакого отношения не имеет. Но вы наверное имеете ввиду само представление данных.
У меня как раз есть модуль для генерации CSS из словаря, думаю добавить еще HTML.
У меня как раз есть модуль для генерации CSS из словаря, думаю добавить еще HTML.
Плюсы XML с вашей статьи:
1. Подсветка синтаксиса и оформление XML на IDE
2. Валидация XML на IDE
— все языки/разметки так умеют
3. XML Napespaces для расширения и использования разных языков
— это никак не ставит xml выше других — другие языки тоже отлично расширяются
4. Инструменты для обработки xml: XSD и DTD…
— все это относится к валидации, другие языки тоже отлично валидируются
5. XML легко читать
— да, парсерам легко читать.
6. Экранировение и фильтрация из коробки
— т.е. заведомо испорченные данные с XSS-уязвимостью XML спасет (xml который уже транслирован в JS)? Или я не так понял?
Вы и вправду считаете, что на XML удобно и весело писать код(даже с такой кучей «плюшек» со стороны)?
1. Подсветка синтаксиса и оформление XML на IDE
2. Валидация XML на IDE
— все языки/разметки так умеют
3. XML Napespaces для расширения и использования разных языков
— это никак не ставит xml выше других — другие языки тоже отлично расширяются
4. Инструменты для обработки xml: XSD и DTD…
— все это относится к валидации, другие языки тоже отлично валидируются
5. XML легко читать
— да, парсерам легко читать.
6. Экранировение и фильтрация из коробки
— т.е. заведомо испорченные данные с XSS-уязвимостью XML спасет (xml который уже транслирован в JS)? Или я не так понял?
Вы и вправду считаете, что на XML удобно и весело писать код(даже с такой кучей «плюшек» со стороны)?
— все языки/разметки так умеют
Какие все? Конкретный пример JS шаблонизатора, забудем про скорость, который умеют все IDE
— это никак не ставит xml выше других — другие языки тоже отлично расширяются
ок
— все это относится к валидации, другие языки тоже отлично валидируются
На первое место я как раз не валидацию ставлю а SAX и XSLT
— да, парсерам легко читать.
тут пример пожалуйста, я хочу вывести
В fest чтобы это вывести нужно ровно это и написать.
— т.е. заведомо испорченные данные с XSS-уязвимостью XML спасет (xml который уже транслирован в JS)? Или я не так понял?
Не так XSS это экранирование другого уровня.
Я имею ввиду отсутвие обратных слешей для экранирования кавычек, например.
Какие все? Конкретный пример JS шаблонизатора, забудем про скорость, который умеют все IDE
— это никак не ставит xml выше других — другие языки тоже отлично расширяются
ок
— все это относится к валидации, другие языки тоже отлично валидируются
На первое место я как раз не валидацию ставлю а SAX и XSLT
— да, парсерам легко читать.
тут пример пожалуйста, я хочу вывести
<div class="page" data-base="base">
<a href="#">link</a>
<script>console.log()</script>
</div>
В fest чтобы это вывести нужно ровно это и написать.
— т.е. заведомо испорченные данные с XSS-уязвимостью XML спасет (xml который уже транслирован в JS)? Или я не так понял?
Не так XSS это экранирование другого уровня.
Я имею ввиду отсутвие обратных слешей для экранирования кавычек, например.
Про валидацию пропустим, я имел в виду, что подсветка синтаксиса любого языка имеется в любом IDE — то, что IDE расставляет переносы в XML и подсвечивает атрибуты ничего не дает — у вас как и у любого шаблонизатора нет автокомплита и прочих радостей из коробки.
> SAX и XSLT
Вы используете XSLT для генерации оптимизированного кода v8?
> пример
Любой шаблонизатор (не HAML-подобный) выведет такой же код. Речь же идет о куче дополнительной писанины, которую несет XML:
> SAX и XSLT
Вы используете XSLT для генерации оптимизированного кода v8?
> пример
Любой шаблонизатор (не HAML-подобный) выведет такой же код. Речь же идет о куче дополнительной писанины, которую несет XML:
<ul>
<fest:foreach iterate="json.items" index="i">
<li><fest:value>json.items[i]</fest:value></li>
</fest:foreach>
</ul>
Slim:
div.page data-base="base"
a href="#" link
:javascript
console.log();
XML дает валидацию через всякие Relax NG (альтернатива: писать и вымучивать код валидации шаблона руками, тратя гораздо больше времени). XML дает возможность легко делать всякие блоки с параметрами и много других вещей.
А Jade (хотя такой синтаксис по моему впервые использовался в HAML) — интересная вещь, но я бы не рискнул его применять, пока сам не потестировал и посмотрел на плюсы/минусы. Как минимум, при его использовании надо полученную от верстальщика HTML-верстку почти целиком переделывать в блоки — это надо либо автоматизировать, либо это лишняя работа. В то время как XML и HTML — братья-близнецы.
А Jade (хотя такой синтаксис по моему впервые использовался в HAML) — интересная вещь, но я бы не рискнул его применять, пока сам не потестировал и посмотрел на плюсы/минусы. Как минимум, при его использовании надо полученную от верстальщика HTML-верстку почти целиком переделывать в блоки — это надо либо автоматизировать, либо это лишняя работа. В то время как XML и HTML — братья-близнецы.
А mail.ru наконец-то стала делать нормальные проекты?
> Версия 3.6 ведет себя по памяти прекрасно.
Андрей, а чего версия? Если node, то 6.3, может быть?
Андрей, а чего версия? Если node, то 6.3, может быть?
Не кто ж так картинки вставляет? ;)
Андрей, вставлять в текст статьи картинку размером в 2 мегабайта — storage.futubra.com/preview/262162/1345.png — не очень правильно.
Из статьи не понял чем XSLT не подошел…
Скорость, я не говорю что XSLT в принципе медленный но тут он проигрывает. И в XSLT нет нормальной возможности поработать с входными данными, например преобразовать timestamp в красивую дату.
Ну и наконец почему многие пропускают фразу про единые шаблоны на клиенте и на сервере? ))
Ну и наконец почему многие пропускают фразу про единые шаблоны на клиенте и на сервере? ))
Насчет скорости ок, возможно.
Поработать с входными данными можно если добавить расширенные XPath функции. Но сомневаюсь что на клиенте это можно легко сделать.
Ничего я не пропускаю про единые шаблоны. Единые шаблоны для сервера и клиента? А разве Яндекс-почта не так работает? habrahabr.ru/company/yandex/blog/99473/. Вот вам пример XSL шаблонов с почты
mailstatic.yandex.net/neo2/5.8.10/66072434/hubs/jane/_jane.ru.xsl
mailstatic.yandex.net/neo2/5.8.10/66072434/daria/hubs/mail/_mailbox.ru.xsl
Вот статья на хабре про XSLT в браузере habrahabr.ru/post/50974/ вот презентация с Яндекс-субботника (видео narod.ru/disk/22589070000/S.Reznikov_JS_Templating.avi.html слайды download.yandex.ru/company/experience/subbotnik/JS_Templating_Stepan_Reznikov.pdf).
Поработать с входными данными можно если добавить расширенные XPath функции. Но сомневаюсь что на клиенте это можно легко сделать.
Ничего я не пропускаю про единые шаблоны. Единые шаблоны для сервера и клиента? А разве Яндекс-почта не так работает? habrahabr.ru/company/yandex/blog/99473/. Вот вам пример XSL шаблонов с почты
mailstatic.yandex.net/neo2/5.8.10/66072434/hubs/jane/_jane.ru.xsl
mailstatic.yandex.net/neo2/5.8.10/66072434/daria/hubs/mail/_mailbox.ru.xsl
Вот статья на хабре про XSLT в браузере habrahabr.ru/post/50974/ вот презентация с Яндекс-субботника (видео narod.ru/disk/22589070000/S.Reznikov_JS_Templating.avi.html слайды download.yandex.ru/company/experience/subbotnik/JS_Templating_Stepan_Reznikov.pdf).
Это что, пост вот про эти 500 строк JS-кода? github.com/mailru/fest/blob/master/lib/compile.js 0_o остальное там — парсер XML и деобфускатор JS, я правильно понял?
Зачем вам XML? Не проще было сразу шаблоны на JS писать декларативно? Парсить XML в JS довольно расточительно. Если вам быстрее парсить XML чем разбирать какой-нибудь нативный для JS формат, то вы определенно что-то делаете не так.
Вообще, это KISS во всей красе. До этого ведь у вас был XScript-подобный велосипед с пасьянсом и актрисами? Теперь осталось выкинуть ещё либо XML, либо JS. И будет хорошо.
Либо выкинуть всё, взять что-то вроде sourceforge.net/projects/libctemplate за основу, да зафигачить шаблонизатор встроенный в nginx.
Зачем вам XML? Не проще было сразу шаблоны на JS писать декларативно? Парсить XML в JS довольно расточительно. Если вам быстрее парсить XML чем разбирать какой-нибудь нативный для JS формат, то вы определенно что-то делаете не так.
Вообще, это KISS во всей красе. До этого ведь у вас был XScript-подобный велосипед с пасьянсом и актрисами? Теперь осталось выкинуть ещё либо XML, либо JS. И будет хорошо.
Либо выкинуть всё, взять что-то вроде sourceforge.net/projects/libctemplate за основу, да зафигачить шаблонизатор встроенный в nginx.
«Зачем вам XML? Не проще было сразу шаблоны на JS писать декларативно? Парсить XML в JS довольно расточительно. Если вам быстрее парсить XML чем разбирать какой-нибудь нативный для JS формат, то вы определенно что-то делаете не так.»
Расточительно, если вы хоть на секунду подумали что xml существует хоть где-то кроме девелопмента то плохо. Если вы так делаете у себя еще хуже.
Нативный JS формат. Люди очень любят кидаться такими фразами не приводя ничего в пример.
«Вообще, это KISS во всей красе. До этого ведь у вас был XScript-подобный велосипед с пасьянсом и актрисами? Теперь осталось выкинуть ещё либо XML, либо JS. И будет хорошо.»
Тут я не понял смысл, откуда в Mail.ru XScript? И в старом шоблонизаторе точно не было ни XML ни JS.
«Либо выкинуть всё, взять что-то вроде sourceforge.net/projects/libctemplate за основу, да зафигачить шаблонизатор встроенный в nginx.»
А фразу про единые шаблоны на клиенте и на сервере вы вообще пропустили.
Расточительно, если вы хоть на секунду подумали что xml существует хоть где-то кроме девелопмента то плохо. Если вы так делаете у себя еще хуже.
Нативный JS формат. Люди очень любят кидаться такими фразами не приводя ничего в пример.
«Вообще, это KISS во всей красе. До этого ведь у вас был XScript-подобный велосипед с пасьянсом и актрисами? Теперь осталось выкинуть ещё либо XML, либо JS. И будет хорошо.»
Тут я не понял смысл, откуда в Mail.ru XScript? И в старом шоблонизаторе точно не было ни XML ни JS.
«Либо выкинуть всё, взять что-то вроде sourceforge.net/projects/libctemplate за основу, да зафигачить шаблонизатор встроенный в nginx.»
А фразу про единые шаблоны на клиенте и на сервере вы вообще пропустили.
Либо выкинуть всё, взять что-то вроде sourceforge.net/projects/libctemplate за основу, да зафигачить шаблонизатор встроенный в nginx.
habrahabr.ru/post/119582/
habrahabr.ru/post/119582/
Что-то мне все страшнее и страшнее становится видя надпись Mail.ru. Эпикфейл с CAS ничему не учит (похож максимум на дипломную работу, некоторый код меня просто вверг в такой ступор и истерический хохот, что я долго не мог успокоиться), так и здесь, все даже читать не стал, уже хватило типичной ошибки верстки, когда в контентный шаблон инклудится хедер и футер, что приводит к очень большим проблемам при поиске незакрытого тега, когда шаблонов набирается много, этот процесс затягивается на часы. Я так же раньше делал, когда только пришел в веб, когда же я сделал шаблоны законченные (если тег открыт в шаблоне, значит в нем же и должен быть закрыт) разработка стала проще в разы, а тут видя такое у компании с многолетним опытом.
Я правильно понимаю, что это такой PHP для v8?
Андрей, я подозреваю что вы должны были проводить исследования на предмет того, чем пользуются коллеги по user hammering'у. Поделитесь с сообществом своим анализом, пожалуйста :)
Отличная работа! Весёлые иллюстрации!
Одна мелочь: почему проигравший Райан вместо .004 получает .00Ч?
Одна мелочь: почему проигравший Райан вместо .004 получает .00Ч?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JavaScript на сервере, 1ms на трансформацию