cnCt — клиентский js шаблонизатор

[@IonDen]

Хочется увидеть реальные тесты производительности. А код все равно выглядит несколько хаотично. И не нравятся сокращения вроде e, c и т.п. Конечно понятно что они означают, но в больших блока кода их будет трудно выискивать и не реально делать поиск по ним.

[@SerDIDG]

Когда был очень зелёный то написал для проекта-хобби подобного рода дом билдер. Функция возвращала объект нодов, с ключами по id \ классу. На больших по объёму контента страницах было очень не удобно.

Сейчас использую маленькую функцию, типа:
cm.Node('div', {'class': 'close'}, config['langs']['close']);
И не знаю проблем.

[@chill84]

Не, не, спасибо. 5 лет назад вдоволь «наигрались» c prototype.js и его Element.

[@alecksey]

Мы такое писали в году эдак 2006, к сожалению Html остается html, верстальщикам и людям, которые будут это читать после вас, проще понять и работать с html. А если вам нужна генерация как на фронте так и на бекенде, всетаки проще работать с html

[@dom1n1k]

Тут дело даже не в малообразованных верстальщиках, которые хорошо знают HTML и плохо JS. Большинство из них умеет читать JS на уровне, достаточном для понимания происходящего в вышеприведенном коде.
Но… HTML — это тот конечный продукт, который непосредственно отображается браузером. И именно в HTML страница верстается, дебажится на предмет кроссбраузерности и т.д. Поэтому шаблон должен быть именно на нём (+ включения прозрачного мета-языка). Если увести шаблон на другой уровень абстракции, то читать/править/дебажить его станет резко неудобно. Это не вопрос квалификации, это вопрос адекватности задач и технологий, а также лишних сущностей.
Поэтому

Плюсы:
Чистый js
Абстрагирование от html

как плюс ну никак не воспринимается.

[@Zibx]

Забавно что когда яндекс использует подобный шаблонизатор и пишет об этом пост на хабру — все прутся тому что теперь дерево генерируется на жс, а тут всё наоборот и абстрагирование от хтмл кажется минусом.

[@dom1n1k]

Не видел того поста (ссылку можно?)
Но слова «дерево генерируется» наводит на мысль, что там у них узкая специфичная задача.

[@yroman]

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

В вашем же случае это сплошная мешанина, обычный html маркап намного понятнее и прозрачнее, даже при условии наличия там конструкций вида {{}}

Все на правах имхо.

[@creage]

каждый уважающий себя javascript-программист должен написать:
1. собственную реализацию классов
2. собственный шаблонизатор
3. ________
4. ________
…

[@VasiliyIsaichkin]

3. собственный DOM-манипулятор (свой jQuery)
4. собственную реализацию MvvM паттерна (свой Angular)

[@Upward]

А так же после прогона через регулярочки всё это вставляется с помощью innerHTML

Как ваш шаблонизатор решает эту проблему?

[@Zibx]

AppendChild.

[@Upward]

Что мешает вам сделать это с другими шаблонизаторами? Задача шаблонизатора отдать вам HTML, с которым вы потом можете делать все, что угодно, хоть appendChild, хоть innerHTML.

[@corristo]

вместо преобразования шаблон -> html -> DOM имеем преобразование шаблон -> DOM

[@KeepYourMind]

Did you see facebook.github.io/react/index.html?

[@darkrain]

Попробуйте взглянуть на эту шаблонку github.com/BorisMoore/jsrender

[@aplic]

Согласен что в определенных задачах с сильной динамикой структуры документа обычная шаблонизация может превратиться в ад. Я вот тоже свой шаблонизатор http://aplib.github.io/controls.js/ в итоге написал и теперь проблем не знаю. Несмотря на то что закончено на треть только, удобная штучка получилась и есть шикарные идеи по его более широкому применению. Вот к примеру вот тут http://aplib.github.io/markdown-site-template/docs/editor.html?edit он используется для разбора html и генерации документа с примененными правками. И не только, концепт оказался настолько удачным что я думаю использовать его в других задачах, задумки интересные. Призываю в проект участников.

[@dom1n1k]

Когда в шаблонах оказывается слишком много логики и ветвлений — у меня зарождается подозрение, что во вьюху зачем-то вылезла часть функций контроллера.

[@aplic]

Ну это естественно при обычной шаблонизации, если вьюха разрослась и непонятно что с ней делать, декомпозицию-то не просто сделать, нужно модели перепроектировать, шаблоны переписывать, связность, ага. Вот и думаешь как это в рамках уже реализованной модели. Ну перетащишь часть лапши в контроллер, проблему-то это не решает. А вот с js шаблонизацией с декомпозицией вообще проблем нет, в любой момент как хотите без ограничений и без последующих багов, любую часть можно выделить в компонент или в отдельный модуль.

[@Pilat]

Мне представляется сейчас так: Самый лучший и правильный шаблонизатор — это не тот, который делает всё быстро, красиво и правильно. Самый лучший — это тот, который либо знает большинство, либо тот, который большинство может и готово изучить за 5 минут. Всё остальное это маргинальщина для особых условий использования.

Так что John Resig ejohn.org/blog/javascript-micro-templating/, Underscore и подобные!

[@spmbt]

А неделя шаблонизаторов тогда таки удалась:
habrahabr.ru/post/201684/ — чт,14 ноября
habrahabr.ru/post/201592/ — пн,11 ноября
И много про другие самописные шаблонизаторы в комментах отозвались.

creage: «каждый уважающий себя javascript-программист должен написать:
1. свою реализацию классов
2. свой шаблонизатор
3. свой jQuery
4. свой Angular)»