Я тебя понял, мне просто кажется ты не проникся духом дата-биндинга :)

Проникся:) Именно поэтому я ввёл сахар {{}} (http://jsfiddle.net/NAPWB/7/), т.е. Snakeskin может сахарно генерить шаблон для либы, которая делает биндинг (у меня так и делает). Но в тоже время шаблоны у меня юзаются не только на клиенте, а также на сервере и т.д.

А в чем преимущества по сравнению с тем же RactiveJS, в котором есть все теже возможности шаблонизации (итерирование, условные операции, в.ч. для атрибутов {{ ? : }}, включение блоков, прекомпиляция)?

В наследовании, я бы и не начал писать Snakeskin, если бы например в Closure Templates был нужный функционал для наследования. Все остальные директивы просто являются уже обязательным джентельменским набором. В большинстве шаблонизаторов оно либо отсутствует в принципе (привет композиция из кучи подшаблонов), либо выполнено на детсадовском уровне (Dust, Handlebars и т.д.). Нужную мне гибкость давали только XSLT-основанные шаблоны, но меня тошнит от XSLT:) Поэтому я сделал по сути свою версию Google Closure Templates, который мне очень нравился, только в отличии от него Snakeskin работает примерно в 1000 раз быстрее (Google Closure Templates реально очень медленно работает), написан на JS, а не Java и реализует крайне мощный механизм наследования. Более того, Snakeskin писался и пишется под один конкретный проект. Ни одна из добавленных фич не была выдумана "сферически", а добавлена исходя из нужд проекта.

Snakeskin создан, чтобы использоваться не только в окошке браузера, а в любом окружении (это тоже были позаимстовано из Closure Templates). Я использую на сервере, также для генерации доки по jsDoc, для node-webkit приложений. Также Snakeskin дружит с Java.

К тому же, на клиенте Snakeskin не существует, т.к. он отваливается на этапе сборки проекта и мы работаем уже с простыми JS функциями, а для data-binding шаблонизатор нужен элементарный, но никак не 4.5к строк кода, которые в Snakeskin :)

почему? доступ к файлам шаблонов?

Если в кратце:

{template foo.bar()}
    hello!
{/}

Скомпилируется в

foo.bar = function () {
    return 'hello!';
};

И мы подключим скомпилиный файл как простой script и будем юзать, Snakeskin уже не нужен.

ЗЫ: разумеется это упрощение:)

Предварительная компиляция существенно быстрей, хотя и имеет ряд недостатков:
- время сборки и поддержка этой архитектуры (на этапе разработки желательно иметь проксю)
- объем передаваемых данных на клиент минимум на 30-40% больше (есть темплейтеры где эта цифра больше 1000%)

Грубо говоря:

{template foo(data)}
    {forEach data => value, index}
         <p>{value}</p>
    {end}
{/}

Будет транслировано в:

var foo = function (data) {
    var html = '';

     data.forEach(function (value, index) {
          html += '<p>'  + value + '</p>';
     });
    
     return html;
};

неплохо! наверное этот вопрос уже задавался, но .. а если мы получили с сервера неоткомпиленный шаблон?

Откомпиль его на клиенте, скорость трансляции в Snakeskin очень высокая, но придётся дополнительно грузить транслятор, а это 11 дополнительных килобайт (под гзипом + минификация).

Такие ошибки должны выявляться на этапе разработки и тестирования.

К примеру, у нас шаблоны на дев-серверах все компилирется в на клиенте, а на тестовых серверах, собираются в сборки.