[FINoM]

Захотим мы переписать шаблонизатор к примеру на пхп, чтобы использовать на сервере, а потом обнаружим, что в шаблоне используются очень специфичные JS конструкции и огребём гемора.

Как вариант, вместо шаблонизатора, можно переписать шаблоны (не более сложная задача). Да и юзайте node.js

Шаблонизатор не должен уметь много - это скорее недостаток, чем плюс.

Очень спорно. Люди успешно юзают EJS и не парятся.

Пришёл новый верстальщик в проект: он не знает JS и ему трудно вкурить твой синтаксис.

А вкурить синтаксис другого шаблонизатора проще?

Когда размер шаблона начинает превышать n количество строк то код превращается в месиво, особенно с таким синтаксисом.

Тоже спорно. Шаблоны, как правило, используют всего лишь each и иногда методы (.toFixed и пр.). В таком случае, шаблон на том же jQuery.tmpl будет ненамного отличаться от моего.

Лучше просто, чем сложно.

Полностью согласен

Вот есть у тебя шаблон А и есть B. И так вышло, что тело шаблона B включает в себя тело A

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

Ну и да, по поводу синтаксиса: твой синтаксис довольно сложен для верстальщика (имхо, конечно же), но в случае с тем же EJS, изучение синтаксиса, то есть обычного JS, ему будет только на пользу.

К сожалению всё приходит с опытом.

Это был сарказм.

Ты, конечно, прав, но вопрос не только в опыте, но и в том, какие задачи ты решаешь. Это очень хорошо, что ты решаешь определенную задачу, а не пишешь сферического коня (я надеюсь). Но, появись иная задача, и в твоём шаблонизаторе найдется какая-нибудь проблема, которая не решаема внутренними методами.

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