Snakeskin

[Aetae]

Это избавило бы разработчики от необходимости следить за изменениями в коде счётчика,

Зато заставило следить за этим автора движка.) И скорость реакции на внезапные критические изменения таки будет медленней.

[kobezzza]

Зато заставило следить за этим автора движка.) И скорость реакции на внезапные критические изменения таки будет медленней.

Тоже верно, посмотреть есть ли API у сервисов для получения кода счётчика, хотя можно парсить страничку с примером, но это не надёжно, т.к. вёрстку могут также поменять.

[kobezzza]

Вообще для Snakeskin прям напрашивается boilerplate либа, которая реализует, например, макеты на bootstrap и пласт полезных функций, аля

- proto base->icon(type)
    < span class = fa #{type}

-template base()
    - doctype
    < html
        < head
            < title :: {title = 'Заголовок' ?}
            - block scripts
                < cdn bootstrap
                < cdn fontawesome
        < body
            - block body

- proto classic->menu(list)
    - forEach list => @el
        ...

-template classic() extends base
    - block scripts
        - super
        < cdn jquery-ui

    - block body
        /// Тут идёт вёрстка макета и разбинение на блоки для наследования

И уже при самой разработке можно было бы просто подключать нужный файл и наследовать шаблон от него.

Тоже самое и для UI, причём шаблоны удобно делать как метод класса UI контрола,

- template Button.prototype.tpl() extends Base.prototype.tpl
    ...

- template SuperButton.prototype.tpl() extends Button.prototype.tpl
    ...

[melky]

Как считаете?

имхо, не нужно переизобретать стандарт Web Components (не то чтобы ты этим занимаешься, но эти директивы уже на 99% похожи на кастомный элемент, а это уже другая стизя)

есть ли способ дополнить этот стандарт или засахарить его?

и ещё .. подсветка кода!!!

[kobezzza]

имхо, не нужно переизобретать стандарт Web Components (не то чтобы ты этим занимаешься, но эти директивы уже на 99% похожи на кастомный элемент, а это уже другая стизя)

Но ведь это не директивы UI, а снипеты подключения, например cdn bootstrap подключит с CDN твиттера сразу и jquery, bootstrap.js, bootstrap.css последней версии, это же оч удобно.

и ещё .. подсветка кода!!!

Ну, в WS хужо бедно всё норм: подсветка и автокомплит настраиваются, обработка ошибок на уровне FileWatcher и отладчика SS.

В notepad++ подсветку также настроить легко через настройки->добавить язык. А вот в sublime я просто хз, но я не думаю, что там что прям эпик.

Вот что действительно нужно добавить, т.к. это флаг --watch для компилятора, чтобы он сам пересобирал необходимые шаблоны, т.к. всякие File Watcher -ры делают это не совсем корректно, например,


base.ss

...

foo.ss

- include 'base.ss'

Файл foo.ss зависит от base.ss и при изменении base.ss нужно перекомпилить также foo.ss, но простой Watcher это не сделает, т.к. он не в курсе про граф отношений файлов - это знает только SS.

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

[kobezzza]

имхо, не нужно переизобретать стандарт Web Components

Стандарта ещё нет толком и не факт, что он будет конфетой.

Я в своём проекте использую похожий подход, есть

.styl

.b-button {
    @extends i-base;
    ...
}

.ss

- template bButton.prototype.tpl() extends iBase.prototype.tpl
   ...

.js

// ES6 торт :)
class bButton extends iBase {
   ...
}

А подключение того или иного модуля делается через b-button.json, где описаны зависимости и т.д.

{
	"block": "b-button",
	"extends": "i-base",
	"use": [
		"logic",
		"style",
		"tpl"
	]
}

Вызов такого блока в другом шаблоне выглядит примерно так:

/// директива bem - это часть фреймворка
- bem b-button value: '...', size: 'xxl', style: 'dark'

Дополнительная крутость в том, что SS поддерживает БЭМ и локализацию на уровне синтаксиса, а блок может быть полностью отрендерен как на сервере, так и на клиенте без внесения изменений в код. Восхваляемый всеми Jade не умеет и 1/10 от фич SS - это объективный факт.

Удобнее такого подхода за 7 лет проганья на JS я пока не видел

[kobezzza]

Для меня в WebComponents самое ценное - это Shadow DOM, а остальное странные приблуды (те же кастомные элементы уже 100 лет как можно юзать, и более того их уже давно юзают, см гугло или яндекс карты). В лучшем случае эти модули можно будет использовать как пласт для более абcтрактных фреймворков, а не как конечный API.

[kobezzza]

Улучшил доку, добавил новые главы.

[kobezzza]

Одной из новых фич, которые войдут в будующий релиз Snakeskin будет новый вариант трансляции шаблонов - в императивный DOM, т.е.

< span.foo
    hello world!

Превратится в

var _ = document.createElement('span');
_.setAttribute('class', 'foo');
_.appendChild(document.createTextNode('hello world'));

Такое расширение уже поддерживается движком Snakeskin, поэтому фича довольно легко реализуемая.

[kobezzza]

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

- include 'foo.ss' as placehoder
- include 'foo.ss' as interface

Т.е. все шаблоны в подключаемом файле будут представлены либо как placeholder, либо как interface.

Также появится возможность задавать флаги компилятора для каждого файла отдельно, причём работать они будут по принципу наследования-переопределения родительских свойств (т.е. свойств файла родителя).