Конечно, это скорее всего будет 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) а не разработчика виджета.

DjDiablo, всё так, но я создал в голове фоновый процесс о внедрении своего механизма биндинга, посмотрим что выйдет.

UPD: внимательно взвесив все за и против, решил, что в планируемый релиз это не войдёт, но сделаю небольшую заготовку на будущее.

Чёто я профакапил планируемые сроки, теперь на следующей недели планирую закончить :)

Кстати, уже добавил фичу для локализации:

{template foo()}
    `hello friend`!
{end}

Тоже самое, что и

{template foo()}
    {i18n('hello friend')}!
{end}

А если для метода compile задать параметр language, то замена будет сделана на этапе трансляции:

{template foo()}
    `hello friend`!
{end}

Snakeslin.compile(..., {language: {'hello friend': 'привет друг'}})

kobezzza, а правильно ли я понял, что синтаксис будет Jade-подобный ?

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

ЗЫ: я решил проблему соответствия файла шаблона с скомпилированным файлом, так что можно будет делать умный кеш :)

ЗЫЗЫ: таки будет Snakeskin 4, а не Snakeskin 3.4, т.к. было внесено 2 ломающих изменения:

1) Изменён синтаксис директивы attr

Раньше было

<div {attr 'class', 'foo bar'} {attr '-bar', 'foo'}

Стало

<div {attr 'class' => 'foo', 'bar'; '-bar' => 'foo'}

Т.е. новый синтаксис позволяет в одной директивы задавать много атрибутов, а также множество значений для одного атрибута, которые будут соединены через пробел.

2) Изменение работы модификатора контекста @ внутри with блока

Раньше было

{with foo}
    {a + @bar} /// foo.a + bar
{/}

Стало

{with foo}
    {@a + bar} /// foo.a + bar
{/}

Т.е. теперь если у идентификатора нет модификатора контекста, то он считается глобальным, а раньше было наоборот. Это нововведение было сделано, чтобы стал доступен следующий синтаксис:

{with foo}
    {@['a']} /// foo['a']
    {@[1 + 'bar']} /// foo[1 + 'bar'] и т.д.
{/}

неплохо! годные изменения.

Холовейчук, как мы знаем, ушел из ноды - фич для Jade от новых мейнтейнеров не дождемся)


дьякую некий список вопросов :

1. что делать с переменными, переданными в шаблон (я передавал их как глобальные)?
2. как задать layout для шаблона?
3. что насчёт сахарку для директив ангуляра (тут сам не додумал, но, возможно, как-то писать без префикса "ng" или группировать их)?

Я решил эту проблему в новой версии. Будешь передавать переменные как первый параметр и юзать так:

{template foo(@params)} /// @params - это сахарная форма для with params
    {@foo} /// params.foo
{/}

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

{template foo(@params, some1, some2)}
    {@foo + some1 + some2} 
{/}

Это на мой взгляд самое лучшее решение проблемы.

Имеешь ввиду, как делать include сторонних файлов? Ну пока я интегрировал Jossy, т.е.

//#include ./file1.ss
//#include ./file2.ss

Но есть задумка интегрировать include как директиву, тогда можно будет делать так:

{for var i = 0; i < 10; i++}
    {include './file' + i + '.ss'}
{/}

{attr ng-(foo1 => val1; foo2 => val2)} нормально?

отлично )
ещё одна деталь

как перевести *.ss сразу в *.html, минуя *.ss.js ?

есть ли какое-то особое имя у template, которое отличается от остальных тем, что именно оно будет запускаться при переводе *.ss в *.html ?

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

Нет, но таким именем можно сделать имя файла где лежит шаблон, т.е. если файл profile.ss и там есть template с именем profile, то он считается главным.

ЗЫ: сделал директиву include, теперь можно делать, например, так:

{fs = require('fs')}

{forEach @fs.readdirSync('...') => el}
    {include el}
{/}

{template foo()}
    ...
{/}

или тоже самое в новом синтаксисе :)

- fs = require('fs')

- forEach @fs.readdirSync('...') => el
    - include el

- template foo()
    ...

Директива работает только на этапе трансляции, также есть защита от дублирования файлов, т.е. если много раз написать include одного файла, то подключится он только один раз. Директиву можно юзать только вне тела шаблона.

примерно это же я и сделал в express-snakeskin, только если нет имени шаблона, совпадающего с именем файла, вызывается шаблон 'main', или тот, что указан в options.

а новый синтаксис можно уже юзать? будут ли какие ошибки, если попробовать подсветку Jade на файле Snakeskin ?

можно ли делать ss файл без записей template? как бы получится неявное оборачивание в template, который будет переводить в html

Ещё нет, ведь релиза 4-й версии ещё не было, но постараюсь на этой недели всё закончить и обновить доку. Если юзать ограниченно то ошибок не будет, но это идиотизм, т.к. тогда можно оставаться на Jade :) Ну а Snakeskin фишки будут варнить к сожалению. Если бы было время, то мб я бы покурил как написать плагин для WS, но его нет:(

Нет, и лучше так не делать, т.к. это убьёт многие фишки Snakeskin.

***

Когда буду обновлять доку, то сниму пару роликов про главные фичи, такие как наследование, прототипы и т.д.

Сейчас подумал, что можно сделать маску для имени шаблона, будет как раз компромисс.

base.ss

{template %filename%()}
    ...
{/}

profile.ss

{include 'base.ss'}

{template %fileName%() extends base}
    ...
{/}

Т.е. %fileName% будет реплейсится на имя файла.

Фак, похоже придётся опять на наделю релиз перенести, завтра уезжаю в Мск, иду на свадьбу гулять, наверн дня на 3-4 выпаду :)

синька - зло, я уже 10 дней потерял из-за неё, не считая сессии)

эт точно :)

Сейчас продумываю такую концепцию, как вызываемые блоки:

{template foo()}
	{forEach arr => el}
		{block elem(el)}
		    ...
		{/}
	{/}
{/}

Конструкция с block будет отрендерена как

if (!foo.elem) {
    foo.elem = function (el) {
        ...
    };
}

foo.elem(el);

Т.е. создаётся функция, которая сохраняется как свойство функции-шаблона. Это решает проблему, когда нужно создать подшаблон, который должен иметь доступ к переменным замыкания главного шаблона и быть доступен для повторного вызова "вне шаблона", т.е. из JS, но в тоже время будет являться структурной единицей Snakeskin, т.е. можно явно переопределять в дочернем шаблоне и использовать директиву super.

Добавил поддержку генераторов.

{template *foo(data)}
    <div class="bar">
        {forEach data => el}
            {apply row(el)}
            {yield}
        {/}
    </div>
{/}

Директива yield будет отрендерена как

yeild __RESULT__;
__RESULT__ = '';

т.е. каждый "тик" (вызов next) будет возвращать кусок отрендеренного шаблона.

Зачем я это добавил: у меня в проекте есть места, где данные из БД возвращаются асинхронными чанками из разных сегментов и сейчас мне приходится ждать пока появятся все данные, затем выполнить шаблон (который вернёт огромную строку, и также может надолго залочить поток, т.к. внутри большой цикл) и уже потом отправлять клиенту.

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

Также генераторы позволят легко "дробить" тяжёлый шаблон на куски с помощью setImmediate, чтобы не лочить поток.

ЗЫ: напоминаю, что пока, чтобы юзать генераторы в ноде, то нужно запускать её с флагом --harmony.

Чего то ппц затянулся этот релиз :(

Сегодня заканчиваю активную разработку, завтра финальный review и тесты и начинаю работать над докой.

ЗЫ: самое глобальное обновление за всю историю проекта, количество коммитов почти равно общему количеству коммитов всех предыдущих версий :) Собственная кодовая база увеличилась на 3к строк кода (8.2к), а с учётом сторонних либ почти 14к (а ведь первая версия была примерно 400 строк :D), жесть в общем :)

Но полученным результатом я очень доволен и наверное даже горжусь, пускай это звучит громко, но Snakeskin 4 будет объективно самым продвинутым "классическим" (т.е. без привязки к определённой технологии или окружению) шаблонным движком из существующих для JS.

та не, у тебя всё нормально
а вот я будто в астрале пребываю)

Алилуйя, я закончил фазу активной разработки. Теперь приступаю к обновлению доки и выкатываю релиз :)

Добавлю сюда тоже, релизная версия видео-мана по настройке вотчеров.

Планирую также снять видео по основам и по наследованию, а остальное будет только в текстовом виде в вики, которая уже пилится :)

kobezzza,
статья из первого поста не доступна ;(

Действительно, надо потереть ссылку, спс:)

Дело в том, что там была статья про версию 1, которая вышла 1.5 года назад и статья была удалена, т.к. сильно устарела.

Сейчас идёт работа над документацией к готовящейся версии Snakeskin 4 (которая уже по сути готова и находится в стадии RC), т.е. закончу доку и релизю.

***

Решил разбить ман по основам Snakeskin на части:

1) http://www.youtube.com/watch?v=wVt_L...ature=youtu.be
2) http://www.youtube.com/watch?v=tFJVP...ature=youtu.be

kobezzza,
как я понимаю, Змеешкур изначально был для личных целей, а теперь ты решил не только пустить его в паблик, но и создавать коммьюнити и т.д?

Дело было так: во времена, когда я работал в Яндексе, то тема шаблонов для нас была очень больна: с одной стороны решений было много, но все либо походило на набор костылей (ejs и т.д.), либо xslt контуженые (bemhtml и т.д.), либо очень простые (mustache, handlebars) и практически никто не давал никаких решений для code-reuse (ну, за исключений xslt like). Я уже молчу про то, что не все умели делать прекомпиляцию. Велосипедов была пропасть :) Часто разработчики обсуждали, что же должен уметь движок и как это должно выглядеть. Потом я уволился из Яндекса, чтобы посвятить себя своему проекту и имея горький опыт решил, что в моём проекте движок должен быть один как на сервере, так и на клиенте и полностью решать все мои хотелки.

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

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

Честно говоря, я думал предложить кому-нибудь с форума помочь мне с продвижением, т.е. писать статьи, улучшать доку, а если было бы желание, то и вносить изменения в код, но сомневаюсь, что кто согласиться, т.к. у всех свои дела и заботы. Но с другой стороны - участие в проектах с кодовой базой 12к+ и количеством коммитов 1к+ может быть хорошим плюсом в портфолио :)

это ты кого так зовёшь? :)

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

Ну тех, кому это может показаться интересным :) Имена тех святых будут написаны в README.md, а те, кто возвысится в ранг кодо-мучеников получат право коммита:)

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

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

<флейм>
Хэй! Не надо так! Они, конечно, все хромают, но декларативная шаблонизация — наше все!
</флейм>

kobezzza, и между тем, ты ни разу ещё не написал roadway проекта - то, к чему он идёт

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

Хотя конечно, я бы мог писать roadmap при начале работы над новой версией.