Twitter открыл (http://twitter.github.com/hogan.js/) код нового шаблонизатора Hogan.js, написанного на языке JavaScript. Код открыт (https://github.com/twitter/hogan.js) под лицензией Apache. В качестве языка для написания шаблонов поддерживается Mustache (http://mustache.github.com/). Среди целей создания новой библиотеки для обработки шаблонов называется желание обеспечить высокую производительность в сочетании с возможностью манипулирования отдельными объектами шаблонов и предоставлением API для доступа к функциям парсера.Шаблоны компилируется в готовые JavaScript-объекты HoganTemplate, для отображения которых в объектах предусмотрен специальный метод. Особенностью Hogan также является разделение фаз сканирования шаблонов, парсинга и генерации кода, что, например, позволяет добавлять новые возможности, такие как новые способы генерации кода, не трогая сканер и парсер. Сканирование и парсинг реализованы в виде отдельных методов, что позволяет предварительно обрабатывать шаблоны на сервере, а на стороне клиента использовать их в виде, скомпилированном в JavaScript.
URL: http://twitter.github.com/hogan.js/
Новость: http://www.opennet.me/opennews/art.shtml?num=32649
Интересно. Работает шаблонизатор на node.js в асинхронном режиме? Подозреваю что у него производительность, которая PHP и Python может только сниться.
Парсинг и популяция шаблонов это не то место где можно работать асинхронно. По крайней мере с видимым эффектом. А вот прекомпиляция это хорошо.
А ты потестируй. С интересом обнаружишь как твой любимый нод.жс сливает питону на таких задачах. Хотя чего уж там, ведь он даже сливает там для чего изначально разрабатывался http://mrjoes.github.com/2011/12/15/sockjs-bench.html#compar...
Кому вообще может в голову прийти мысль ещё и на сервер пихать такой язык как жаваскрипт, когда существуют более вменяемые альтернативы.
> Хотя чего уж там, ведь он даже сливает
> там для чего изначально разрабатывался http://mrjoes.github.com/2011/12/15/sockjs-bench.html#compar...По указанной вами ссылке на графике node.js на голову обгоняет cpython по числу одновременно обработанных запросов. Так что вы опозорились своими категоричными заявлениями :-)
Там еще дальше
>With 2000 clients and reasonable rates, approximate memory usage was:sockjs-node around 36 MB
sockjs-tornado on CPython around 52 MB
sockjs-tornado on PyPy around 100 MB.выжрать в 2-3 раза больше памяти - классическое поведение питона.
Товарисч читать не умеет? Целью исследования было, кто больше всех отработает запросов с максимальным временем ответа 200msecsockjs-node starts to slow down around 45,000 messages.(>200msec)
CPython starts to slow down around 55,000 messages per second.
Woohoo, PyPy was able to keep mean response time under 200ms for rate of 150,000 outgoing messages per second. For concurrency level of 200, it was able to pump 195,000 messages in the same time frame.
просто в школе английский на уровне intermediate еще не преподают
Многие компании переходят на node.js. Особенно те которым нужно быстродействие и маштабируемость.
По словам CTO voxer-а, http://voxer.com/ - полноценное voip решение с полумиллионом пользователей, переход с python на node.js дал им ускорение в 4-10 раз.
> Многие компании переходят на node.js. Особенно те которым нужно быстродействие и маштабируемость.Уже даже майкрософт признала, что если нужна производительность, то гораздо проще разрабатывать на Си, чем пытаться выжимать что-то из более высокоуровневых языков/платформ.
Спасибо за совет.
Пойду переписывать все вои сервисы с node на С.
Ну когда принимают такие решения, то у меня как-то сразу возникают сомнение о вменяемости людей, которые устроили переход с одной тормозной платформы на другую, которая так же отвратительно справляется с задачей, когда нужно обслуживать много voip потоков.
Нужно просто сразу понимать что нод.жс тормозной, так же как и питон. А что самое ужасное - это наблюдать за тем как люди на этих тормозных платформах начинают с помощью хаков пытаться всё это ускорить, когда на Си можно было бы обойтись обычным чистым кодом, без всяких пулов/отключений гц и прочих подробностей платформы, и при этом всё работало бы значительно быстрее тех костылей, которые приходится наблюдать(особенно это заметно в java и .net мире).
А на ассемблере то можно?
Что может быть лучше написания web сайта на С?
Только написание его на ассемблере.
> когда существуют более вменяемые альтернативы.Это вы намекаете на PHP?
>Это вы намекаете на PHP?Ну если хочется жить в примерно тех же парадигмах как жаваскрипт, то выбор в сторону питона, руби.
>рубиВы это серьезно?
>питонаПочему не следует использовать питон хорошо напискано тут: http://journal.paul.querna.org/articles/2011/12/18/the-switc.../
Это одна из крупнейших облачных компаний (Rackspace) переходит с питона на node.js.
Если коротко - медленный, плохорасширяемый, со слабыми фреймворками.
>Интересно. Работает шаблонизатор на node.js в асинхронном режиме? Подозреваю что у него производительность, которая PHP и Python может только сниться.Вот бы потестировать с шаблонизаторами под mod_perl.
Что-то заоткрывался твиттер... Ну и хорошо)
Ну наконец то создатели шаблонов озаботились скоростью.
>http://twitter.github.com/hogan.js/
>npm install hoganОшибочка у них на сайтике.
Правильно
npm install hogan.js
Но качать стоит с гитхабика, а то братик, невзначай, того ...
Я что-то не догоняю, для каких задач используется этот шаблонизатор? Если он да JavaScript, то работает явно не на серверной стороне web приложения (если нужна скорость, для этого есть CTPP). А если эта штука работает на стороне клиента, то такую страницу не сможет индексировать гугл (он ожидает HTML код, насколько я понимаю, а не JSON, который надо вставить в некий шаблон).Кто-нибудь может привести пример, когда имеет смысл использовать этот шаблонизатор? Для каких задач его создали?
>Если он да JavaScript, то работает явно не на серверной стороне web приложенияNode.js работает именно на серверной
>Если он да JavaScript, то работает явно не на серверной стороне web приложенияNode.js работает именно на серверной стороне.
> А если эта штука работает на стороне клиента, то такую страницу не сможет индексировать гуглТо что страницу не может индексировать Google это хорошо или плохо? Вот у twitter - а все страницы такие, и что? Пока никто не умер.
Классический пример - веб-приложения. В самом приложении индексировать особо и нечего, а вот для разработки шаблоны удобны.Ну а на серверной стороне шаблоны сто лет как применяются, начиная с PHP (который изначально языком шаблонов и был) и заканчивая темами/движками отображения в CMS. Разница только в том, что здесь шаблонизатор на JS.