Сообщение от Gozar
|
Оно серверное? Есть пример применения именно на сервере? Как со скоростью? Хотелось бы шуструю шаблонку, т.к. нагрузка предполагается большая.
На пыхе я плевался 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++ это делается очень просто: заходим в настройки, добавляем новый язык, ассоциируем его с расширением и добавляем список ключевых слов и усё
Про другие редакторы я хз, т.к. не использую их.