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

На пыхе я плевался html без шаблонок и хотелось бы на ноде тоже что-то очень шустрое.

Оно универсальное. Дело в том, что ты не правильно представляешь себе SS. SS - это как CoffeScript или тот же 6to5, т.е. транслятор который плюётся JS-м, а этот JS можно юзать как на сервере, так и в браузере.

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

Вообще по SS есть хорошая дока, где на все твои вопросы есть ответы:

https://github.com/kobezzza/Snakeskin/wiki
https://github.com/kobezzza/Snakeskin/wiki/faq

А если что там нет, то можно спросить у меня как на Гитхабе, так и тут.

***

Примеры использования в ноде:

1) На этапе сборки проекта / разработки транслируем и затем подключаем уже полученный JS. Статическую трансляцию можно сделать множеством способов: есть плагины для grunt и gulp, можно использовать CLI API (консолька, которая также поддерживает файл вотчинг), можно использовать файл вотчеры в ИДЕ и т.д.

Когда у нас есть скомпиленый шаблон, то

var tpl = require('./myTpl.js');

2) Использование специального АПИ для Ноды

https://github.com/kobezzza/Snakeskin/wiki/compileFile
https://github.com/kobezzza/Snakeskin/wiki/execFile
https://github.com/kobezzza/Snakeskin/wiki/exec

3) Работать на прямую с транслятором, но это не очень удобно в ноде :)

https://github.com/kobezzza/Snakeskin/wiki/compile

***

По поводу скорости: тут нужно дать определение, т.к. есть 2 показателя скорости:

1) Скорость трансляции - это сколько времени займёт процесс преобразования SS в JS. Он делается как правило один раз, либо на этапе сборки, либо в рантайме с последующим кешированием (его можно отключить, если нужно), поэтому данный показатель никак не влияет на скорость работы приложения. Трансляция делается ровно столько, чтобы о ней не думать (в моём случае, это где то 20% от общего времени сборки проекта, т.е. ерунда).

2) Скорость исполнения полученного JS: в основном она зависит от содержимого шаблона, т.е. то что напишет пользователь, а SS тут уже не причём, НО SS имеет различные плюшки, которые помогают генерить более быстрый JS, например, есть поддержка оптимизации хвостовых рекурсий. Вообще тут SS выступает также, как например C++, т.е. он имеет конструкции и режимы оптимизации + ручное управление содержимом, которые позволяют самому разработчику решать что ему важнее скорость трансляции или скорость исполнения.

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

Вот такие вот дела.

***

Если сравнивать объективно, то SS на много голов функциональнее того же Jade, я бы сказал, что это как сравнивать Stylus и LESS. С точки зрения зрелости, то сейчас есть лишь одна фича, которую я планирую добавить - это сорсмапы, а в остальном проект завершён и сейчас я занимаюсь исключительно докой и выпуском патчей.

PS: забыл сказать, что сейчас шаблоны SS возвращают либо строки, либо DocumentFragment, в зависимости от заданных настроек, которые можно также делать в самом файле шаблонов.

/// Вернёт строку
- template foo(a, b)
    < div.foo
        {a + b}

/// Вернёт DocumentFragment
- template bar(a, b) @= renderMode 'dom'
    < div.foo
        {a + b}

Подобно Stylus, SS поддерживает 2 вида синтаксиса, поэтому примеры можно переписать так:

/// Вернёт строку
{template foo(a, b)}
    <div class="foo">{a + b}</div>
{/template}

/// Вернёт DocumentFragment
{template bar(a, b) @= renderMode 'dom'}
    <div class="foo">{a + b}</div>
{/template}

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

Скорость трансляции меня никоим местом не колышет. Если я правильно понял, то трансляция делается один раз при старте эхо-сервера, а затем в получ. функцию мы передаем параметры, в зависимости от которых ф-ия плюется разным html?

Как это не при чем? :)

Сам html у меня простецкий, влезает на любой экран целиком, меняется в основном текст, которого может быть довольно много. Я хочу понять, сколько будет жрать шаблонка памяти, проца при 1 посетителе в 1 сек, при 10 и при 100?

На клиенте мне было без разницы, а вот сервер не резиновый.

Извиняюсь, если невнятно объясняю, т.к. делаю это на ноде впервые, был опыт с php и он жрал будь здоров, из-за чего пришлось бросить шаблонки и плеваться html вперемешку с php (зато быстро).

Ну не только HTML, а любым текстом или DocumentFragment :)

Ну SS практические не вносит отсебятины в код, поэтому

- template foo()
    Hello World!

Грубо говоря превратится в

function foo() {
    return 'Hello World!';
}

Конечно там будет экранирование, защита от XSS где нужно и т.д., но это реально ерунда.

А если ты, например, вставишь очень толстый цикл в шаблон, то он естественно будет долго выполнятся,

- template foo()
    - for var i = 1e9; i--;
        Hello World!

Столько же, сколько, если бы написал на голом JS без шаблонов :) Но если вдруг, выполнения шаблона реально стало узки местом, то результат его работы ты уже сам сможешь закешировать, но это очень редкий кейз, поэтому не парься)

Также SS умеет отдавать свой результат чанками, с помощью генераторов:

- template *foo()
    - for var i = 1e9, j = 0; j++, i--;
        - if j === 1e3
            ? j = 0
            - yield result

        ...

kobezzza,
В чём преимущества перед Jade/TwigJS/EJS?

Немогу понять, почему модули в NodeJs подключаются по относительному пути:

var Model = require('../model/echo');

а шаблон snakeskin от корня:

header = snakeskin.compileFile('./server/app/tpl/header.ss');

?

Я что-то не понимаю, где file watcher: node_modules/bin/snakeskin из этого видео?:
http://www.youtube.com/watch?v=TspTov7AWog

Есть Jade подобный синтаксис, но пришлось почти сразу от него отказаться.

Во первых непонравились углы, нафиг они нужны я не понял.

Во вторых я не смог написать в шаблоне:

doctype html

скомпилилось в

<doctype html="html">

что собственно неверно.

!doctype html

так тоже не проканало, дальше играть не стал.

А ещё я не нашёл File Watcher /bin/snakeskin. Можно конечно через грунт, но у меня в грунт висит сборка в браузер и вешать еще один грунт я не хочу. В принципе можно забить болт и собирать при запуске сервера, как делаю сейчас, но несовсем понятна причина отсутствия вотчера...

https://github.com/kobezzza/Snakeski...%D0%B8%D 1%81

Вообще логика такая: директивы в Jade-Like обозначаются с помощью - и # (расширенный вариант), также для тех директив, которые поодерживают шорткаты, то можно использовать их, например,

< div

или полный вариант

- tag div

Всё остальное трактуется как простой текст.

Для doctype есть отдельная директива

https://github.com/kobezzza/Snakeskin/wiki/doctype

Например,

- doctype svg 1.1 full

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

Что именно не нашёл?

https://github.com/kobezzza/Snakeski...0%BE%D0%B5-API

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

snakeskin ./tpls/ -o ./tpls --watch

Также можно использовать grunt-watch или gulp-watch для вотчинга.

На видео рассматривается настройка FileWatcher под WS, а ты что хочешь?

Можно настроить FileWatcher в WS (на видео).
Можно используя CLI --watch.
Можно через gulp-watch, grunt-watch, make...

Проверил сейчас у себя, всё ок, относительные пути работают.