Pull to refresh
55
0
Сумин Андрей @AndrewSumin

Пользователь

Send message
Версия v8, NodeJS у нас на продакшене нет, по краней мере пока.
Мы вместе его и разрабатывали.

Вообще как я предполагал дисскуссия свалилась в XML не XML, это хорошо, значит по основному вопросу разногласий нет. Если вы не заметили в заголовке статьи ни слова про fest и 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 это экранирование другого уровня.
Я имею ввиду отсутвие обратных слешей для экранирования кавычек, например.
Вот мы данные в виде JSON принимаем, в чем противоречие?
И еще раз повторю, мы сами долго думали XML или велосипед.
Пока выбрали XML как проверенное решение.

Что будет завтра как знать?
Не кодить а шаблонизировать.
Кодить будут на JS.
Скорость парсинга не важна, на продакшене XML нет.
JSON хорош, мы его используем для данных.

А Jade это не JSON, не надо лукавить.
/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>


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

Второе, имея JS на сервере сменить один JS шаблонизатор на другой задача на порядок проще задачи притащить JS на сервер.
Компиляция в два языка рассматривалась, но она мне очень не нравится.
Если мы говорим про JS то с обновлением движков как v8 так и остальных, мы будем бесплатно получать новые фичи в шаблонизаторе.

При компиляции в два языка это не возможно.

Плюс вы и правда думаете в Mail.ru на сервере только один язык? Сколько компиляторов тогда надо сделать?
Что не сходится? Есть люди обладающие желанием и квалификацией писать инструмент для себя.
Вы зачем такой узкий пример привели?
В get может находится целый кусок функционала.
У нас на входе либо json, либо мы используем get('key') дальше операция с данными на JS.
<fest:script>
var items = json.data.filter(function(){});
</fest:script>
<fest:foreach iterate=«items» index=«i»>

</fest:foreach>
По сравнению со старым, по функциональности, мы сильно выиграли.
Там нет переопределения (set и get), там нет средств работы с данными.
Менять ничего не надо, значит у нас баг.
Напишите мне ваш логин на mail.ru на адрес andrewsumin@corp.mail.ru будем разбираться.
Не путайте собирается и доставляется браузеру.
Вы же не думаете что данные по сети мгновенно приходят.
Плюс я пишу именно про шаблонизацию, а именно превращение данных в HTML.
Было, я начинал с проекта aptana jaxer.
Но было не значит работало.
Фигурные скобки в аттрибутах мы поддерживаем.
А рассуждать понятиями блевотно/не блевотно очень странно для технического человека.
Понятия поддерживаемость, интеграция, валидация куда ближе.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity