Pull to refresh

Comments 147

Прекрасная статья.
А выложить в public ваш чудесный шаблонизатор не хотите? ;)
На него есть ссылка в статье, но добвил блок в конце статьи.
UFO just landed and posted this here
У Gmail прогресбар «почта загружается».

Но, допустим мы решаем что это приемлимо, всеравно будут блоки с шаблонизацией на сервере.
UFO just landed and posted this here
Кстати, мне тут Миша Сабуренков подсказал плагинчик, который показывает почту в виде простенькой таблички до того как GMail прогрузился. Инженерное решение, блин.
даже если откажутся, все равно будут поддерживать noscript версию, у гмэйла же есть
все таки почта это не развлекательный ресурс и требовать от человека включенный JS для использования основного функционала — написания и чтения писем — не очнеь хорошо. Хоть и выключенный JS бывает крайне редко
Думаю, в наше время, требовать включенный js для чего угодно вполне нормально
UFO just landed and posted this here
Веб-интерфейс в браузере, клиентская часть? Субъективно, кажется, что так и есть.
Загружается gmail дольше — факт.

А работает оно также, это с учетом того что пинг до mail.ru всяко меньше.
Потому что загружает сразу много данных. Если обратите внимание, письма на первой странице открываются сразу без дополнительных запросов.

Просто у Gmail немного иной подход, который позволяет вдобавок работать в офлайне.
Занятно, только увы не реюзабельно, ведь всё завязано на вашу архитектуру и окружение.
Ничуть, готовый шаблон это файл с js функцией.
Это достаточно легко встраивается в любую архитектуру.

Но, тем не менее, основной поинт что JavaScript на сервере это уже сегодня, и мы тоже это проверили на себе.
Удивительная фраза «JavaScript на сервере это уже сегодня». JS на сервере — это даже не вчера, это позавчера. Был ASP (где были JScript и VBScript на сервере), был веб-сервер у Нетскейпа, где был серверный JS.
Было, я начинал с проекта aptana jaxer.
Но было не значит работало.
А я на ASP и сайты делал. Работало.
Да, это суровая правда. Редко универсальные решения бывают очень эффективными, сносным, не более. Как правило эффективное решение разрабатывается для частных случаев.
Отличная статья! Не так часто можно посмотреть кухню больших компаний, а ведь кто еще сможет рассказать об опыте работы с по-настоящему большими нагрузками.
Последнее время Mail.ru приятно удивляет. И разработчиков думающих набирают.
Что-то же должно меняться к лучшему.
Когда б они уже к этой красоте сделали бы доступ по https…
Скоро сделаем. Потерпите немного.
Никак не мог понять, что вам до этого-то всё мешало SSL запустить? Ну не нехватка же ресурсов?!
Ничего не мешало. Надо было просто за нее взяться. Запуск SSL — это гигантская по объему техническая задача. Нужно перелопатить всю верстку, в поисках httpшных картиной и js'ов, заменив их на schemeless (чтобы браузеры не ругались). Нужно корректно выкусить из серверной части все темные углы, где такое закардкожено. Нужно разработать прокси-сервер для показа сторонних картинок в письмах. Нужно научить показывать рекламу и баннеры по https, и автоматически и интеллектуально защитить админку рекламной сети от заноса туда баннеров, на которые браузер будет ругаться на httpsной версии. Нужно оценить рост нагрузки на сервера (поддерджка SSL — это такая задача для процессора, что на нем можно жарить яичницу). Нужно в конце-концов решить организационные задачи, типа доработки тест-планов у тестировщиков. И т.д., и т.п. И это все на фоне новой разработки, запуска фич, без ущерба для старого и только что созданного функционала.
Я предполагал по наивности, что достаточно поставить https-фронтенды и кроме большой нагрузки на процессор, ничего остального даже не придётся трогать.
К сожалению, httpsные фронтенды не заменят по волшебству httpшные картинки в верстке.
Я правильно понял, что для клиентской шаблонизации на клиент уходят уже скомпилированные шаблоны?
Скорее так, не скомпилированные шаблоны есть только в девелопменте. Дальше все и везде скомпилированое
Напоминает меня.
Уже давно разрабатываю свой шаблонизатор под NodeJS. Для меня сразу было очевидно, что управляющие конструкции должны быть в формате XML.
Сначала шаблон компилировался в структуру. Когда же была готова стабильная версия, решил сравнить производительность с Dust. Оказалось, что такая архитектура шаблонизатора изначально тупиковая — сказываются накладные расходы при обработке полученной структуры.
Сейчас же допиливается версия компиляции в функцию и уже выигрывает у Dust в 3-5 раз.

Ну и плоский хеш это, конечно, жестоко.
Dust, по вашей ссылке — давно заброшенный проект. Интересно сравнение весрии LinkedIn-a — github.com/linkedin/dustjs, с вашим шаблонизатором.
Спасибо, а то я думаю что же они не убирают require.paths.unshift из кода…
Для меня сразу было очевидно, что управляющие конструкции должны быть в формате 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)
«интуитивней понять» — на уровне
и как бонус микс декларативности и функциональности…
<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>
О ужас! Мои глаза! И кто может посчитать ЭТО хорошим решением?
Пока нет в документации, но можно делать так
<a href="/user/{json.user.name}">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: я в своё время отказался от это идеии ввиду невозможности написать так

<div class="bla {if $active} active{/if}">


Как видно, я остановился на синткасисе а-ля Smarty. К тому же во всех нормальных IDE всё прекрасно подсвечивается и подсказывается.
Если немного подумать, то могут быть и другие решения, например как в fest с тегом attribute. Но мне такое решение не по душе, я сделал так:

<tsn:var name="className" expr="active ? 'active' : ''" />


А в атрибут уже выводится так:
<div class="bla &tsn.echo.className;" />
В любом случае синтаксис Smarty выглядит более компактным и удобным.
А мне синтаксис XML кажется более «говорящим».
А мне синтаксис XML кажется более «говорящим».

Согласен! И он говорит: «Нет, не ломай себе глаза, человек, который меня придумал — просто издевается над тобой! Иди и убей его!»
По вашему верстальщикам нужно доплачивать за «особые условия работы»?
UFO just landed and posted this here
Да, там стандартное экранирование.
Но если нужна прям логика то можно ее обернуть в <fest:script/>
UFO just landed and posted this here
Проблемы компиляции.

    <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 += '/>';

Как понять что секция с атрибутами закончилась и можно закрыть тег?
UFO just landed and posted this here
так вот и начался fest:if а закрывать рано.
UFO just landed and posted this here
Возможно, но что делать, когда нужно fest:choose использовать?
UFO just landed and posted this here
Если для вас незакртые теги стандартная ситуация, не используте fest.
Это возможно но лучше поискать другой инструмент, мы не претендуем на универсальность.
UFO just landed and posted this here
Пока не планируем.
Она очень сильно зависит от реализации проекта.
Плюс вы можете сделать JS функцию lang('key') и прекрасно с этим жить.
Как вариант — запилить отдельный тег для этого. Такое я встречал в одном Java-шаблонизаторе.
У нас тоже в свое время встал вопрос о шаблонизации.
Ситуация усугублялась тем, что бизнес логика была реализована на php, а кусочек ее — демон — на Ноде.

В качестве шаблонизатора на пхп части мы использовали толковую штуку Twig, которая является реализацией Джанговских шаблонов.

Перебирая возможные движки для Ноды, с удивлением наткнулись на SWIG, который, за исключением некоторых мелочей, умел все, что нужно.

Теперь изучаем, как серверный SWIG плавно перенести в браузер.

Мы у себя используем SWIG для трансформации на ноде и в браузере. Далее поток мыслей — январь 2012 года (в феврале его обновили хорошо, но я не смотрел, что там сделали). В браузер перенес небольшим допиливанием. Ужасно объемный код на выходе, который получает в итоге клиент. Из-за того что, все конструкции заворачиваются в замыкания, то нет возможности установить переменную внутри конструкции if, а затем к ней обратиться извне. В Opera проблемы из-за того, что в скомпилированном шаблоне все обращения к переменным проходят в итоге через window, а Opera создает в window переменные указатели на input с именами аттрибутов name и получаем строки [Object HTMLInputElement] в выдаче.
Вроде как twigjs более точно повторяет оригинальный Twig. И нормально работает в браузере.
Посмотрел Вашу ссылку — последние изменения датированы 7 месяцами назад и npm не находит проект в репозитории (намекает на несовместимость с актуальными версиями Ноды).

Вы его использовали где-то в работе? Каковы ощущения, если да?
Я своими немногими местами не везде перелез на 0.6. Может гляну, настолько ли они несовместимы, судя по всему влияет ограничение в package.json и всё.

Когда я смотрел Swig там не хватало некоторых конструкций/автопеременных по части циклов, так что не удалось его сразу начать применять.
Так в каком месте у вас 1ms?
Главная mail.ru вижу сейчас собирается за 67ms.
Не путайте собирается и доставляется браузеру.
Вы же не думаете что данные по сети мгновенно приходят.
Плюс я пишу именно про шаблонизацию, а именно превращение данных в HTML.
Доходят он за несколько ms согласно firebug. Возможно ещё несколько ms тратится на сжатие.
Пользуясь случаем, хочу спросить. Планирует ли Mail.ru переработать веб-агент? Дело в том, что он включен по умолчанию и при открытии почты в бразерах IE, начинает грузить процессор под 100%. При отключенном веб-агенте такой нагрузки нет.

Техподдержка рекомендует сменить браузер, но, к сожалению, это не приемлемо в корпоративном секторе.
Менять ничего не надо, значит у нас баг.
Напишите мне ваш логин на mail.ru на адрес andrewsumin@corp.mail.ru будем разбираться.
Насчет статьи Игоря Сысоева — читал эту статью уже давноб но с тех пор уже много воды утекло и NodeJS стал другой и V8. Интересно что сейчас Игорь об этом думает?
В Node.js это изначально не было проблемой из-за того что контекст сохранялся.
UFO just landed and posted this here
По сравнению со старым, по функциональности, мы сильно выиграли.
Там нет переопределения (set и get), там нет средств работы с данными.
UFO just landed and posted this here
У нас на входе либо json, либо мы используем get('key') дальше операция с данными на JS.
<fest:script>
var items = json.data.filter(function(){});
</fest:script>
<fest:foreach iterate=«items» index=«i»>

</fest:foreach>
Если честно Использование set и get выглядит очень избыточно, по сравнению с возможным решением:

<#: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 может находится целый кусок функционала.
А для чего вообще хранить логику в шаблоне?
/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>


Это хранение логики в шаблоне или нет?
В данном случае никакой логики нет.
Просто я не понял что вы имеете ввиду под хранением функционала (копия куска кода aka Here document)?
Но в Mail.Ru Group есть целая команда высококвалифицированных людей, знающих JS, способных самостоятельно написать инструмент, а самое главное — они же им и будут пользоваться.
Как я понял: Либо высококвалифицированные специалисты знающие JavaScript будут кодить на xslt-подобном языке с javascript-вставками, либо вы привираете насчет квалификации :) В любом случае что-то не сходится…

С виду тот же xslt, только свой велосипед(сейчас не идет речь о том как он летает). И как человек работавший с xslt и пишуший сейчас на JavaScript скажу, что на xml-подобном синтаксисе писать очень не благодарное дело.

Вы узнавали у ваших разработчиков нравится ли им fest (если они, конечно еще, писали на чем-то кроме xslt)? Были ли альтернативы синтаксиса? Вообще вы спросили их в каком виде им приятнее писать?

Разработчики — это самый дорогой ресурс и их время и нервы нужно экономить.

P.S. А почему не стали транслировать в Cи? Была бы ракета!
В Си на сервере, раз у вас для v8 и так используются спец конструкции, то и наверно результат трансляции разный.
Что не сходится? Есть люди обладающие желанием и квалификацией писать инструмент для себя.
Т.е. получается, что высококвалифицированные специалисты знающие JavaScript будут кодить на xslt-подобном языке?
Это же шаблонизатор, не более, он мог быть написан на любом языке, просто в этом случае серверный язык JS.
Не кодить а шаблонизировать.
Кодить будут на JS.
И еще раз повторю, мы сами долго думали XML или велосипед.
Пока выбрали XML как проверенное решение.

Что будет завтра как знать?
Да, попробуйте узнать у своих разработчиков, что бы они хотели видеть в качестве шаблонизатора. Как они видят шаблонизатор, как бы ИМ удобныее было писать шаблоны (выкиньте на время все эти «плюшки» xml). Любой шаблонизатор можно переделать так или иначе в ракету, сделать строгим, расширяемым, главное, чтобы разработчикам было приятно с ним работать. Надеюсь, вы меня поняли :)

Я не верю, что класный JavaScript с радостью бы стал писать шаблоны на xml если у него были бы альтернативы.
Мы вместе его и разрабатывали.

Вообще как я предполагал дисскуссия свалилась в XML не XML, это хорошо, значит по основному вопросу разногласий нет. Если вы не заметили в заголовке статьи ни слова про fest и XML.
Летает быстро — это хорошо, но немаловажна скорость и комфорт разработки, которые вытекает из синтаксиса шаблонизатора.
Использовать nodejs для шаблонизации и отсутствия дублирования кода — мысль здравая
Использовать xml как шаблонизатор — мысль НЕ здравая
Меня поражает ваша самоуверенность.

Я не работаю в Mail.ru, но мне тоже нравится этот вариант синтаксиса шаблонизатора. Скажу больше — такие шаблонизаторы существуют уже давно.

Все «минусы» xml вытекают сугубо из личных предпочтений.
Например: долго набирать. Но ведь autocomplete и ZenCoding никто не отменял. Не читается? Но ведь тысячи web-разработчиков используют HTML и XML в повседневной разработке и вполне неплохо себя чувствуют.
Все остальные минусы, как-то: поломка синтаксиса при использовании тегов в значениях атрибутов или хранение логики в шаблонах — исключительно минусы реализации, но не как самого XML как такового.

Не нужно преподносить своё мнение как единственно верное.
И уж тем более ничего «больного» в xml я не вижу.
Меня исключительно бесит пихание такого уродского стандарта как xml всюду и вся и я искренне надеюсь, что когда-то эта мания прекратится.
Я уже понял как вы любите xml. Вам нужно в ряды W3C, глядишь и жизнь станет лучше.
Я w3c не люблю ещё больше, чем xml)
Хорошая статья. Потмоу, что я сам не раз ломал голову, как решить проблему возникающую в любом продвинутом аякс-приложении:

> два набора совершенно разных шаблонов на сервере и на клиенте.

От себя добавлю: не только шаблоны, если нужна офлайн работа, придется еще и модельки, их валидацию и хранилище дублировать. Мне пришли в голову такие идеи:

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 на сервере только один язык? Сколько компиляторов тогда надо сделать?
Непонятно, зачем придумывать что-то на устаревшем, де факто, XML, когда есть JSON. too enterprisy.

И вообще, пока лучшего шаблонизатора для JS, чем Jade, я пока не видел.
Я привел целый ряд причин за XML, думаю есть смысл на них ответить.

Второе, имея JS на сервере сменить один JS шаблонизатор на другой задача на порядок проще задачи притащить JS на сервер.
Андрей, нет причин для использования XML, кроме унаследованных приложений и поддержки корпоративных протоколов (SOAP-based).

XML более многословен и менее быстр для формирования и парсинга.

Пора принять JSON как аксиому.
Я в этом уже который год пытаюсь убедить разработчиков Icecast2(там xml и конфиг и вывод статистики)
Скорость парсинга не важна, на продакшене XML нет.
JSON хорош, мы его используем для данных.

А Jade это не JSON, не надо лукавить.
Jade — это язык. Речь о том, что XML уступает JSON по фану всегда и везде. Нет причин его использовать.
Вот мы данные в виде JSON принимаем, в чем противоречие?
Как я понимаю, у вас XML — язык разметки? И это мне как раз и не нравится, ибо он неудобен для человека. Тут удобнее Jade, Builder или иные удобные шаблонизаторы.

Равно как не нравится, как источник данных, тут удобнее JSON.
JSON — это формат обмена данными, к организации когда он никакого отношения не имеет. Но вы наверное имеете ввиду само представление данных.
У меня как раз есть модуль для генерации 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 удобно и весело писать код(даже с такой кучей «плюшек» со стороны)?
— все языки/разметки так умеют
Какие все? Конкретный пример 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:
<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 — братья-близнецы.
А mail.ru наконец-то стала делать нормальные проекты?
Почему «наконец-то»? А Tarantool?
Ну вот, любители МоегоМира стали минусовать
Программисты там лучшие, они ведь не виноваты что у их начальства кривое видение проектов…
Начальство тоже когда были программистами.
> Версия 3.6 ведет себя по памяти прекрасно.

Андрей, а чего версия? Если node, то 6.3, может быть?
Версия v8, NodeJS у нас на продакшене нет, по краней мере пока.
Не кто ж так картинки вставляет? ;)
Из статьи не понял чем 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).
Я в курсе про яндекс почту, многих там знаю лично.
Но просто скажу что килентсике XSLT это очень сложно.
Это что, пост вот про эти 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 формат, то вы определенно что-то делаете не так.»

Расточительно, если вы хоть на секунду подумали что 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/
Мм, круто. Не знал. Спасибо.
Что-то мне все страшнее и страшнее становится видя надпись Mail.ru. Эпикфейл с CAS ничему не учит (похож максимум на дипломную работу, некоторый код меня просто вверг в такой ступор и истерический хохот, что я долго не мог успокоиться), так и здесь, все даже читать не стал, уже хватило типичной ошибки верстки, когда в контентный шаблон инклудится хедер и футер, что приводит к очень большим проблемам при поиске незакрытого тега, когда шаблонов набирается много, этот процесс затягивается на часы. Я так же раньше делал, когда только пришел в веб, когда же я сделал шаблоны законченные (если тег открыт в шаблоне, значит в нем же и должен быть закрыт) разработка стала проще в разы, а тут видя такое у компании с многолетним опытом.
Я правильно понимаю, что это такой PHP для v8?
Можно подробнее?
Я совсем не понял мысль.

JavaScript это язаык PHP тоже язык, а что значит фраза «Я правильно понимаю, что это такой PHP для v8?»
что именно вас интересует?
Конечно пробовали, очень нравится, но пока не укладывается нужное нам время.
Андрей, я подозреваю что вы должны были проводить исследования на предмет того, чем пользуются коллеги по user hammering'у. Поделитесь с сообществом своим анализом, пожалуйста :)
Отличная работа! Весёлые иллюстрации!
Одна мелочь: почему проигравший Райан вместо .004 получает .00Ч?
Sign up to leave a comment.