Комментарии 47
Шустрее doT пока всё-равно ничего не придумали.
Насколько я вижу, то сейчас там загружена в тестах не оптимизированная версия JsRender?
После этого инцидента:
Revision 400: published by [jsRender won through incorrect output — removed] on 12th April 2012
А во втором тесте у меня победу одержал: Kendo UI Templates (No «with» block)
После этого инцидента:
Revision 400: published by [jsRender won through incorrect output — removed] on 12th April 2012
А во втором тесте у меня победу одержал: Kendo UI Templates (No «with» block)
Смотря какую ревизию рассматривать. Например, в 413, указанной на официальном сайте doT, jsRender вроде нормальный, из официального репозитория.
По общей сводке что JsRender, что Kendo UI Templates проигрывают doT.
По общей сводке что JsRender, что Kendo UI Templates проигрывают doT.
форк DustJS от LinkedIn linkedin.github.com/dustjs/
Ага. Единственное, для поиска ошибок в шаблонах ничего не сделано.
Хорошо бы ещё написать про JsViews, вместе с которым JsRender становится действительно вкусной вещью.
С JsViews ещё не работал, дальше примеров дело не дошло, а писать о том, с чем пока не имел реальной практики я посчитал лишним. Для тех кому интересно, что такое JsViews, могут зайти на сайт и посмотреть примеры, учитывая, что JsViews базируется на основе JsRender, знакомство я бы начал с последнего.
Ответил ниже.
> Не совсем так, при генерации для установки id не следует использовать $(this).attr('id', 'foo')
Понятно, что $(this, { id: 'foo' }) проще, но в чём причина совета «не следует»?
Понятно, что $(this, { id: 'foo' }) проще, но в чём причина совета «не следует»?
Вы привели пример установки, а я говорил о получении.
Вместо:
Использовать:
Вместо:
$('a').each(function(){
console.log($(this).attr('id'));
});
Использовать:
$('a').each(function(){
console.log(this.id);
});
вы придумали Mustache.js
Было бы полезно сравнить результаты этого движка с остальными на jsPerf.
Вот я когда-то сравнивал свой KiTE с другими:
jsperf.com/dom-vs-innerhtml-based-templating/99
Кстати про KiTE. У меня используется базовый mustache синтаксис расширенный if секциями.
Template компилируется в своеобразный bytecode — массив из строк и функций. Получается в 25 раз быстрее чем mustache. Ну и это все в 180 LOC поместилось. Надо бы глянуть во что их движок вылился в результате.
Вот я когда-то сравнивал свой KiTE с другими:
jsperf.com/dom-vs-innerhtml-based-templating/99
Кстати про KiTE. У меня используется базовый mustache синтаксис расширенный if секциями.
Template компилируется в своеобразный bytecode — массив из строк и функций. Получается в 25 раз быстрее чем mustache. Ну и это все в 180 LOC поместилось. Надо бы глянуть во что их движок вылился в результате.
А есть более подробные цифры?
Ну например: «Ваши зубы белее на 20%», а «был цвет RAL1013, а стал RAL9003»
Ну например: «Ваши зубы белее на 20%», а «был цвет RAL1013, а стал RAL9003»
Конечно есть, на 1500 элементах тесты показали:
460 ms +- 10% — наши шаблоны
21 ms +- 10% — JsRender
600 элементов: 190 ms и 7 ms соответственно.
А тесты с jQuery Template есть во втором абзаце.
460 ms +- 10% — наши шаблоны
21 ms +- 10% — JsRender
600 элементов: 190 ms и 7 ms соответственно.
А тесты с jQuery Template есть во втором абзаце.
Ожидаемо.
Я недавно получил аналогичные результаты, только делал это вручную:
habrahabr.ru/post/147252/
Было
Views: 490.9ms | ActiveRecord: 14.4ms
Стало
Views: 12.9ms | ActiveRecord: 17.1ms
Я недавно получил аналогичные результаты, только делал это вручную:
habrahabr.ru/post/147252/
Было
Views: 490.9ms | ActiveRecord: 14.4ms
Стало
Views: 12.9ms | ActiveRecord: 17.1ms
Помоему сейчас столько шаблонизаторов развелось, что обсуждать преимущества одного над другим вообще смысла не имеет, мерится производительностью тоже (обычно грамотный шаблонизатор быстро работает а +- пара милисекунд не делают погоды)
Я даже больше скажу шаблонизаторы особо никому не нужны, обычно когда люди выбирают шаблонизатор — это знаит что на сайте мало js.
Если на сайте много js то люди уже выбирают средство для его структурирования, хороший фреймворк который организует код: будь то backbone или sproutcore или qooxdoo. Ну и как водится подобные рещения уже имеют свой шаблонизатор.
Так что дам совет тем кто выбирает шаблонизатор js:
1) У вам видимо небольшой сайт и не много js, 90% шаблонизаторов даже не покажут каких-либо задержек, бери любой который под рукой
2) У вас видимо реально большое приложение, где на основе тестов вы поняли что используемый шаблонизатор стал узким местом, тут мои советы излишни, вы сами знаете куда копать.
Я лично в последних проектах работал с backbone и соотвествено с шаблонизатором от underscore, тормозов не заметил, синтаксис приятен, что более нравится так там не надо заново учить новые операторы типо
{{for cast}}, зачем?? зачем этот синтаксис в шаблонизаторе, уже ведь есть js! поэтому в шаблонизаторе от undescore собственно три конструкции:
Я даже больше скажу шаблонизаторы особо никому не нужны, обычно когда люди выбирают шаблонизатор — это знаит что на сайте мало js.
Если на сайте много js то люди уже выбирают средство для его структурирования, хороший фреймворк который организует код: будь то backbone или sproutcore или qooxdoo. Ну и как водится подобные рещения уже имеют свой шаблонизатор.
Так что дам совет тем кто выбирает шаблонизатор js:
1) У вам видимо небольшой сайт и не много js, 90% шаблонизаторов даже не покажут каких-либо задержек, бери любой который под рукой
2) У вас видимо реально большое приложение, где на основе тестов вы поняли что используемый шаблонизатор стал узким местом, тут мои советы излишни, вы сами знаете куда копать.
Я лично в последних проектах работал с backbone и соотвествено с шаблонизатором от underscore, тормозов не заметил, синтаксис приятен, что более нравится так там не надо заново учить новые операторы типо
{{for cast}}, зачем?? зачем этот синтаксис в шаблонизаторе, уже ведь есть js! поэтому в шаблонизаторе от undescore собственно три конструкции:
- <%= … %> вывести значение<% … %> произвольный js<%- … %> вывести с экранированием тегов html
Фактически ничего не запоминаем нового и в тоже время пишем нужную логику без проблем.
Я не рекламирую это шаблонизатор как лучший, просто маленький пример.
Интересно было бы почитать сравнение всего многообразия строковых JS шаблонок.
Сам использую micro templating Резига
Сам использую micro templating Резига
А что там справнивать, я вот лично не собо понимаю, уточните
Есть ли какая-то разница между ними )
Не поверите!
1) библиотека лежащая в основе (jq template логично предположить без jq работать не будут, как и underscore)
2) Синтаксис
3)Скорость
Если будите выбирать то поступаем так:
1) Смотрим на то какая библиотека js используется в нашем проекте
2) Смотрим какие для этой библиотеки есть шаблонизаторы, выбираем самый приятный по синтаксису и функциям, по мне чем проще тем лучше, изучать дебри синтаксиса шаблона совсем не охота
Собственно все! На производительность смотреть только в том случа если они дает о себе знать ибо обычно в 97% это 5-10 шаблонов который выводят мелочь и их быстродействие ниоем образом не мешает юзеру. Вот когда вам в секунду 50 шаблонов рендерить придется тогда и задуматься стоит. А до этого ставьте на первое место удобство разработки и поддержки
1) библиотека лежащая в основе (jq template логично предположить без jq работать не будут, как и underscore)
2) Синтаксис
3)Скорость
Если будите выбирать то поступаем так:
1) Смотрим на то какая библиотека js используется в нашем проекте
2) Смотрим какие для этой библиотеки есть шаблонизаторы, выбираем самый приятный по синтаксису и функциям, по мне чем проще тем лучше, изучать дебри синтаксиса шаблона совсем не охота
Собственно все! На производительность смотреть только в том случа если они дает о себе знать ибо обычно в 97% это 5-10 шаблонов который выводят мелочь и их быстродействие ниоем образом не мешает юзеру. Вот когда вам в секунду 50 шаблонов рендерить придется тогда и задуматься стоит. А до этого ставьте на первое место удобство разработки и поддержки
1) библиотека лежащая в основе (jq template логично предположить без jq работать не будут, как и underscore)
в данном случае предположение является ложным, вот пример без зависимостей: JsRender without jQuery
в данном случае предположение является ложным, вот пример без зависимостей: JsRender without jQuery
О чем предположение? Вы наверное плохо читали. я имелл виду что выбор надо основывать учитывая библиотеку лежащую в основе приложения.
Используя бекбон у меня уже есть undersсore template зачем мне подключать еще один? Используя dojo у вас там тоже есть нативный шаблонизатор от dojo, у sproutcore также есть свой шаблонизатор, так зачем подключать в проект еще один?
Если нет серьузной причины используйте тот шаблонизатор что уже есть, вот когда он объективно не будет устраивать стоит думать о замене
Используя бекбон у меня уже есть undersсore template зачем мне подключать еще один? Используя dojo у вас там тоже есть нативный шаблонизатор от dojo, у sproutcore также есть свой шаблонизатор, так зачем подключать в проект еще один?
Если нет серьузной причины используйте тот шаблонизатор что уже есть, вот когда он объективно не будет устраивать стоит думать о замене
А зачем подписываться на библиотеко-зависимую шаблонку?
Вы тоже коментарии не читаете? Или вы любите пложить множество непонятных библиотек чтобы потом весейлей с ними жилось?
Перечитайте внимателней оба мои коментария выше.
Перечитайте внимателней оба мои коментария выше.
Кладешь шаблонку без зависимостей, в чем проблема?
Цель шаблонки как я её понимаю, передать нечто и получить строку готового кода, тут не нужно, с моей точки зрения никаких либ.
Цель шаблонки как я её понимаю, передать нечто и получить строку готового кода, тут не нужно, с моей точки зрения никаких либ.
Проблема в том что если функционал создания щаблонов уже заложен в библиотеку, а он заложен во многие фреймворки, подключать что-то сторонее как минимум глупо и в 99% случаем вы будити идиотом сделав это.
А оставшийся 1% я ждумаю вам не встретится никогда.
А оставшийся 1% я ждумаю вам не встретится никогда.
Ну вот я пользуюсь jQuery, в каком месте там встроенный шаблонизатор?
Уважаемый, вы совсем дурак? Читайте мои коментарии лучше. Вы не удосужились!
А речь шла о том, что если в вашем фреймворке уже есть возможность работы с шаблонами, то надо в первую очередь использовать имено её, а не подключать еще одну не понятную библиотеку.
И поверьте на одной jQuery жизнь не кончается.
А речь шла о том, что если в вашем фреймворке уже есть возможность работы с шаблонами, то надо в первую очередь использовать имено её, а не подключать еще одну не понятную библиотеку.
И поверьте на одной jQuery жизнь не кончается.
Шаманство всё это. Плагин для jQuery без jQuery, под который нужно учить отдельный синтаксис.
Лучше Knockout-а вряд ли что-то можно придумать.
Лучше Knockout-а вряд ли что-то можно придумать.
я бы на их месте использовал бы html5 атрибут data все таки не зра его вводят, вместо своего ng
Ну, там есть такая возможность: data-ng- вместо ng-
Но сути это не меняет — Нокаут лучше из-за самого сильного механизма observables. Я могу иметь наблюдаемое проперти, которое в свою очередь возвращает в качестве значений другой наблюдаемое проперти. Причем, все они могут быть зависимыми без указания мной явных цепочек зависимостей.
Но и для многих аспектов Нокаут предоставляет гораздо более удобное и лаконичное API. Те же кастомные байндинги в Нокауте делаются одной или двумя функциями, а в angular готового рецепта нет.
Но сути это не меняет — Нокаут лучше из-за самого сильного механизма observables. Я могу иметь наблюдаемое проперти, которое в свою очередь возвращает в качестве значений другой наблюдаемое проперти. Причем, все они могут быть зависимыми без указания мной явных цепочек зависимостей.
Но и для многих аспектов Нокаут предоставляет гораздо более удобное и лаконичное API. Те же кастомные байндинги в Нокауте делаются одной или двумя функциями, а в angular готового рецепта нет.
В AngularJS есть
$scope.$watch("variable", function() { ... }) — в общем-то те-же observerables. А вот по поводу кастомных биндингов это вы совсем зря — есть же взиожность добавления кастомынх директив, даже на главной странице есть пример (про компоненты табов). Плюс за счет тех-же директив в ангуляре легко реализуются reusable-компоненты, с которыми в knockout была беда, насколько я понял (выбирал между двумя фреймворками).Соглашусь. Многие теряют из виду тот факт, что темплейты Нокаута остаются валидным HTML-кодом, а значит их может править верстальщик или дизайнер без оглядки на синтаксис разработчиков. Тем более, с учетом того, что в большинстве случаев темплейты инлайнятся в текст страницы, а не прячутся в script тагах, темплейты верстальщик может править непосредственно по готовому живому HTML прямо из браузера.
Указанные в списке ссылок статьи Джона Папа «Using JsRender with JavaScript and HTML» и «Advanced JsRender Templating Features» уже переведены на русский язык: «Использование JsRender с JavaScript и HTML» и «Более сложная функциональность шаблонов JsRender».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JsRender: Новое поколение jQuery Templates