Нет конечно, я ж рукожоп, купил у художника :)

kobezzza,
а чего он такой агрессивный? Но в любом случае уже годнота)
А ты говорил с переводчиками?

Ну он чёткий ковбой Фрэнк, который должен своим видом намекать, что Jade отстой :D

Угу, заломили цену ппц под 40к, но они жуки тупо считают количество букв и не выделяют код, поэтому нужно будет всю доку для них засунуть в один файл и вырезать весь код, чтобы не наебать :D У мя ща предновогодняя лень идёт, поэтому процесс ползёт медленно.

kobezzza,
захожу на https://github.com/kobezzza/Snakeskin и не вижу лого( Оно как бы есть, но его как бы нету :)

А чего сам не переведёшь? Подумаешь будут ошибки, если что, сообщество поможет их исправить.

Не успел ещё, сёня сделаю :)

Лень, да и не хочется сильно отвлекаться от основной работы.

Выпустил очередной патч, также на гитхабе красуется лого :)

kobezzza,
только обновился до 6.5.8, а ты уже 6.5.10 запушил)

Был вечер багов :)

***

Ща пошла тенденция, что в основном баги находятся в Jade-Like парсере при обработке пробелов (tolerateWhitespace = false), а в директивах уже давно не находил багов.

Выпустил v6.5.11

Помимо исправлений ошибок был переведён на английский файл README и HISTORY. В этом году в планах полный перевод доки (комментарии в исходном коде останутся на русском, т.к. мне так проще).

kobezzza,
а как же
или у тебя длительные выходные?)

Ну, было время и было не лень :)

PS: кстати, проекту SS уже пошёл 3-й год!

Чую версию 6.5.12 с самими крупными изменениями.

:D

Да прост описание в Readme обновил и исправил парочку орфографических ошибок :)

Выпустил обновление v6.5.13 - провёл некоторые оптимизации, что дало прирост скорости трансляции на 5-10%.

***

Не могу понять: я нигде не пиарю и не рассказываю об SS (ну кроме этого ресурса), но NPM показывает какуе то бешеную статистику, например, что за последний месяц было 4+к скачек, причём за последний день 600+. Кто эти люди или это какие то боты? :)

kobezzza,
не знаю как сейчас, но раньше на npm устраивали ДДОС и оно несколько раз падало. Так что возможно да, это боты.
Мб ещё из-за того, что ты на английском readme написал :D

Маловероятно :)

Выпустил SS 6.5.19.

Помимо багфиксов порефакторил код, теперь структура файлов выглядит гораздо понятнее https://github.com/kobezzza/Snakeskin/tree/master/lib (если конечно кто-то захочет залезть в кишки :) )

***

В версии 6.6 планирую добавить поддержку sourcemap.

kobezzza,
Периодически туда захожу, понимаю, что ничего не понимаю и с грустью закрываю вкладку ;(

Не понятно что-то конкретно? Мне кажется, что за исключением парочки моментов SS написан оч просто, взять например типовую декларацию директивы:

Snakeskin.addDirective(
	'if',

	{
		block: true,
		notEmpty: true,
		group: 'if'
	},

	function (command) {
		this.startDir();
		if (this.isReady()) {
			this.append(`if (${this.prepareOutput(command, true)}) {`);
		}
	},

	function () {
		this.append('}');
	}
);

Все же просто :)

kobezzza,
Не, всё дело в объеме строк кода)

Я сейчас часто думаю, что надо было писать SS как язык, а не как препроцессор: т.е. реализовать полностью свой синтаксис (JS like), а не использовать JS, строить полное AST и разделить архитектуру на части:

1) Фронтенд: построение AST и работа с ним;
2) Бекэнд: трансляция результат в заданный язык.

Такая архитектура была бы более гибкая, с точки зрения настройки трансляции в разные языки.

Сейчас же SS работает как простой препроцессор на основе конечного автомата: т.е. в тексте ищутся директивы, они преобразуются в другие директивы и так до тех пор, пока все директивы не будут преобразованы. Такая модель проще, занимает меньше кода и работает быстрее, но менее гибкая.

kobezzza,
как я понимаю, в будущем, ты планируешь его переписать, так?

Была идея, в качестве треннинга, переписать его на Rust (мб, как часть моего ЯП), но это пока только задумки.

Сам ж понимаешь, что каждый прогер мечтает сделать свой ЯП :)

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

Касаемо планов на этот год по SS:

1) Написать большую статью на хабр и перевсти её на инглишь;
2) Перевести доку на инглишь;
3) Добавить поддержку сорсмапов.

kobezzza,
Это я помню, я же тоже это предлагал)

Не так уж и много, по сравнению с тем, что уже сделано)

Эт точно, офигеваю от объёма проделанной работы :)

По заспросу в гугле
твой SS на первйой странице)

:D

Выпустил юбилейный 100-й релиз-патч SS :)

PS: 13 января было ровно 2 года с первого коммита проекта :)

//то чувство, когда узнаёшь новости ещё до оф. объявления)

Поздравляю)

Спасибо :)

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

На пыхе я плевался 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...

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