Конечно, это скорее всего будет 1-2 новых директивы для сахара и дополнительный модуль в Snakeskin.live.

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

{template Widget.prototype.tpl()}
    hello {this|bind 'name'}
{end}

Widget.prototype.foo = function () {
    this.name = 'Вася' // шаблон сам сделает обновление
};

Snakeskin.Filters.bind = function () {
    // Тут для this.что-то создаётся set и get методы
};

Вставка текста и парсинг его браузером быстрее, чем создание DOM элементов

Да нифига подобного. Предположим что есть таблица из 1000 строк, в модели добавилась только одна строка. Шаблонизатор заточенный под клиент(reactive к примеру) добавит только одну строку, шаблонизатор кобеззы выплюнет 1001.

Что касается разовой генерации html то вот замеры скорости. innerHtml разве что в IE предпочтителен.

Ну, Snakeskin я юзаю для первичной генерации тела шаблона, а дальнейшая работа с ним у меня делается другой либой, так что заменять 1000 я не буду :) (примерный пример есть выше)

Но вообще твой позыв я услышал, я добавлю механизм из коробки, но он будет опциональным.

ЗЫ: Ребят, отдельная просьба, если вы юзаете мои разработки, то не молчите, т.к. иначе я веду разработку только с оглядкой на свои требования. Вот например огромное спасибо melky за интеграцию Snakeskin с Express: сейчас она выглядит неуклюже, но мы обсудили пути улучшения и уже совсем скоро этих проблем не будет.

да, быстрее

выплюнет 1, кот. будет зааппенден к остальным :)

будет зааппенден к остальным
Интересно где ты будешь искать эти остальные :)
И как удаление gпары строк будешь отрабатывать? что шаблонизатор выплюнет в этом случае ?

Мне казалось это очевидно :)

{template Widget.prototype.tplRow(params)}
    ...
{/}

{template Widget.prototype.tpl(list)}
    <div class="foo">
        {forEach list => el}
            {call this.tplRow(el)}
        {/}
    </div>
{/}

Widget.prototype.appendRow = function (params) {
    this.find('.foo').append(this.tplRow(params));
}

Ты же блин в конец просто вставил, об этом речи не идет

Задача звучала примерно так
между 13м и14м появило 10 новых элементов, а начиная с 112, 20 элементов исчезли.

Неужели не ясно в чем заключается ограничение шаблонизатора :(

В чём проблемы, или после появления data-binding все забыли как раньше писали код?)

атрибуты, классы, делегирование, т.е. проблемы тут нет, просто другой подход к организации кода.

Причём тут шаблонизатор? То что Snakeskin не умеет сам что-то биндить - это я сказал сразу. Но если ты утверждаешь, что логика, которую реализуют всякие Ангуляры нельзя написать как простое АПИ на уровне виджета, то тут ты не прав :)

Посмотри тот же нокаут, где все биндинги описываются как дата-атрибуты, а в качестве шаблонки юзается простой jQ template, который тоже плюётся текстом и не про какие биндинги не знает :)

Тут уже какой подход больше по душе.

Блин да если написать как раньше то шаблонизатор вообще непотребуется :)

Я этого не утверждал, еще как можно :)

Но по итогу на reactive решение обговоренной задачи уместится в несколько строчек.

{{#superheroes:num}}
    <tr>
      <td>{{ num + 1 }}</td>
      <td><a href='{{info}}'>{{name}}</a></td>
    </tr>
{{/superheroes}}

И здесь уже есть все, и удаление строк и добавление в любое место произвольного количества, и любая комбинация из удалений, изменения, и добавлений.
А на snakeskin нужен бубен, цикл там есть но он абсолютно бесполезен для поставленной задачи.

Собственно я уже забыл о чем спорю и зачем ))))

Но суть твоей мысли я понял, понашмякать виджетов использующих низкоуровневый шаблонизатор snakeskin а дальше собирать интерфейс из виджетов реализовав биндинг силами виджета. Здесь все нормально я делаю все тоже самое.

При использовании snakeskin все вопросы по быстродействию переносятся с шаблонизатора на разработчика виджета.
Последний момент и является камнем приткновения так как я считаю что производительность это забота шаблонизатора (по образцу react и reactive) а не разработчика виджета.