LINUX.ORG.RU

Coffee библиотека redtea - прошу либить и жаловать

 ,


0

2

## Почему наши web-интерфейсы такие медленные и сложные?

Если вы помните как писались древние пхп сайты (еще до того как туда притащили rails-way фрэймворки), то это была жуткая мешанина html, sql, php и т.д... Но кто объяснит чем это

html
<li ng-repeat="todo in todos | filter:statusFilter track by $index" ng-class="{completed: todo.completed, editing: todo == editedTodo}">
  <div class="view">
    <input class="toggle" type="checkbox" ng-model="todo.completed" ng-change="toggleCompleted(todo)">
    <label ng-dblclick="editTodo(todo)">{{todo.title}}</label>
    <button class="destroy" ng-click="removeTodo(todo)"></button>
  </div>
  <form ng-submit="saveEdits(todo, 'submit')">
    <input class="edit" ng-trim="false" ng-model="todo.title" todo-escape="revertEdits(todo)" ng-blur="saveEdits(todo, 'blur')" todo-focus="todo == editedTodo">
  </form>
</li>
лучше? Кто вообще объяснит, почему управление содержимым страницы **на клиенте** должно осуществляться через xml?

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

...

И далее в readme (код, примеры, панцея).
https://github.com/special-k/redtea

как по мне лучше мешанина кода с хтмл чем это вырвиглазное говно шаблонизаторное.

Dron ★★★★★
()

На моей памяти уже был яркий пример, когда пытались программировать HTML - БЕМ. Ну его популярность какбэ намекает.

Vit ★★★★★
()
Ответ на: комментарий от Vit

программировать HTML - БЕМ

Вряд ли есть хоть что-то общее, это БЭМ, как раз, напоминает ангуляр

<div class="menu menu_theme_islands menu_mode_check menu_size_m menu__control i-bem" data-bem='{"menu":{}}' role="menu" tabindex="0">
    <div class="menu-item menu-item_checked menu-item_theme_islands i-bem" data-bem='{"menu-item":{"val":1}}' role="menuitemcheckbox" id="uniq14560758484501" aria-checked="true">Отдых в горах</div>
    <div class="menu-item menu-item_theme_islands i-bem" data-bem='{"menu-item":{"val":2}}' role="menuitemcheckbox" id="uniq14560758484502" aria-checked="false">Отдых на море</div>
</div>

special-k ★★★
() автор топика
Ответ на: комментарий от Vit

в ангуляр

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

special-k ★★★
() автор топика
Ответ на: комментарий от special-k

Это ж проект пхпшников

Аргумент поражает своей техничностью. Но пока react-todomvc выглядит в 9000 раз аккуратнее и представляет структурированный код, а не лапшу как у тебя, очень смахивающую на PHP код. 500 строк лапши ради тривиальной задачи, на кофе! На кофе блжад! Плюс у тебя даже близко нет удобной ментальной модели, просто jquery-переросток.

anonymous
()
Ответ на: комментарий от special-k

Странное деление. А почему именно этот критерий а не VirtualDom? А почему ты не учитываешь requestAnimationFrame? и т.п.

Насчет «долой шаблоны» я тебе уже приводил пример. Яндекс свой бем до сих пор пыжится продвигать. И будет пыжыться вечно. Потому что не для людей.

Vit ★★★★★
()
Ответ на: комментарий от Vit

А почему ты не учитываешь requestAnimationFrame?

Не очень понял вопрос, ты хочешь сказать, что лаг, перед показом большого количества задач в тех примерах (в несколько секунд) связан с requestAnimationFrame? Или речь не об этом?

Насчет «долой шаблоны» я тебе уже приводил пример.

Давай определимся, с понятием «шаблон» и «шаблонизатор».

Шаблон - это текст.

Шаблонизатор - это функция, которая возвращает текст.

С этой т.з., если я правильно понимаю о чем идет речь https://ru.bem.info/libs/bem-components/v2.4.0/desktop/button/ bemjson - это 100% шаблон. И это все с м.т.з. две похожие фиговины, одна из которых популярна, а другая не очень.

долой шаблоны

Я говорю не «долой шаблоны», я говорю долой xml при работе с DOM. Я говорю - давайте работать с DOM-элементами, как с объектами. Давайте работать с DOM-элементами, как с объектами на одном языке (coffeescript) используя DSL (потому что на js и без DSL это не удобно).

special-k ★★★
() автор топика
Последнее исправление: special-k (всего исправлений: 1)

о, коль уж тут такая пьянка - хочу нанять верстальщика для верстки попутных проектов. Что для верстальщиков проще - React или Angular? С точки зрения процесса разработки ангуляр видится проще - код и вьюха разнесены по файлам, версталы даже джуны понимают что такое усы, и почему их лучше не трогать. Как с этим в реакте дела?

dib2 ★★★★★
()
Ответ на: комментарий от special-k

Не очень понял вопрос, ты хочешь сказать, что лаг, перед показом большого количества задач в тех примерах (в несколько секунд) связан с requestAnimationFrame? Или речь не об этом?

Я хочу сказать что очень много зависит от того, как именно ты апдейтишь DOM. Это отдельная тема, как правильно обновить список из нескольких тысяч элементов. Там и requestAnimationFrame, и отделение записи от чтения и много чего другого.

Я говорю не «долой шаблоны», я говорю долой xml при работе с DOM. Я говорю - давайте работать с DOM-элементами, как с объектами. Давайте работать с DOM-элементами, как с объектами на одном языке (coffeescript) используя DSL (потому что на js и без DSL это не удобно).

Ну и чем то что ты предлагаешь лучше VirtualDom? К нему заодно приходят все, кому надо чтобы рендеринг работал и на сервере тоже.

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

Vit ★★★★★
()
Ответ на: комментарий от dib2

С точки зрения процесса разработки ангуляр видится проще - код и вьюха разнесены по файлам

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

A1
()
Ответ на: комментарий от Vit

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

МБ, и пока я, действительно никак этого не контролирую, хотя, полагаю у меня есть неплохие варианты.

от чтения

К слову, я вообще не читаю DOM, я сохраняю реальные DOM-элементы в объектные переменные `виджетов` в момент их создания, одновременно с этим выстраивается StorageItem иерархичная структура, так что во много задача решена, но, в основном, по принципу `не делать лишнего`.

Ну и чем то что ты предлагаешь лучше VirtualDom?

Производительностью, и удобством разработки (1 язык, полный контроль генерации дом-структуры, единый для всего обсервер и т.д.). В целом, думаю, совокупность таких сущностей у меня, как Widget, StorageItem и StorageCollection можно было бы гордо окрестить «легковесный virtual dom»(TM)

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

А это ведь очень простое приложение.

special-k ★★★
() автор топика
Ответ на: комментарий от Vit

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

Заменить, в данном случае, реальные DOM-элементы на виртуальные очень легко.

Вообще, производительности виртуального DOM я, объективно, не наблюдаю. В производительность генерации DOM на сервере вообще не верю. По-моему маркетинг постепенно берет верх над здравым смыслом.

special-k ★★★
() автор топика
Ответ на: комментарий от special-k

и удобством разработки

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

anonymous
()
Ответ на: комментарий от Vit

есть более удобные и менее напрягающие инструменты

Чем удобные-то.. тем что вызывают лаги по несколько секунд? Ну да, удобненько..

special-k ★★★
() автор топика
Ответ на: комментарий от anonymous

В реакте удобно думать что страница перерисовывается заново на каждом фрейме

Я не могу думать как пхпшник.

special-k ★★★
() автор топика
Ответ на: комментарий от special-k

К слову, я вообще не читаю DOM, я сохраняю реальные DOM-элементы в объектные переменные

Это все круто ровно до того момента, пока тебе не потребуется апдейтить diff-ы. И тут ты воткнешься головой в бетон. Потому что ты пытаешься решить проблемы в тех местах, где их нет.

Производительностью, и удобством разработки

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

Лично мне было бы понятно, если б ты взял несколько разных фреймворков, и аргументированно объяснил, что твой подход лучше во всем. А прикопаться к старичку-ангуляру много ума не надо.

Vit ★★★★★
()
Ответ на: комментарий от special-k

А ты руки вытяни, и проверь что между ними нет дуги :)

До 1К элементов лагов нет.

Vit ★★★★★
()
Ответ на: комментарий от Vit

Это все круто ровно до того момента, пока тебе не потребуется апдейтить diff-ы.

Апдейтить diff-ы с сервера? Но зачем?

Потому что ты пытаешься решить проблемы в тех местах, где их нет.

Нет проблем с производительностью веб-интерфейсов?

До 1К элементов лагов нет.

Вообще это очень мало, а ведь еще есть различные хилые девайсы.

special-k ★★★
() автор топика
Ответ на: комментарий от special-k

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

anonymous
()
Ответ на: комментарий от special-k

Апдейтить diff-ы с сервера? Но зачем?

Причем тут сервер? diff-ы моделей. У тебя массив на 1000 строк таблицы. 300 изменилась. Что делать?

Нет проблем с производительностью веб-интерфейсов?

Нет проблем с производительностью интерфейсов там, где ты пытаешься их найти. Апдейты надо пакетировать. Поэтому твое кроилово на манипуляциях по 1 элементу нахер никому не надо.

Вообще это очень мало, а ведь еще есть различные хилые девайсы.

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

Vit ★★★★★
()
Ответ на: комментарий от special-k

JSX это сахар для React.DOM.div(props, children)/MyComponent(props, children)*. Как завернуть в свой виджет менеджер сам разберешься.

*) На самом деле уже нет, но сути дела это не меняет.

zz ★★★★
()
Ответ на: комментарий от Vit

Апдейты надо пакетировать. Поэтому твое кроилово на манипуляциях по 1 элементу нахер никому не надо.

Кулстори бро.
http://special-k.github.io/repaint
http://special-k.github.io/repaint/index3.html

Первый тест показывает, что банальное бережное отношение к DOM лучше всей этой вашей галиматьи.

Второй тест просто рвет всех в клочья - там ограничено применен requestAnimationFrame.

http://special-k.github.io/repaint/index2.html
Показывает, что 300 nodeValue= раз в 5-7 раз эффективнее одного innerHTML

аргументированно объяснил, что твой подход лучше во всем

Единственный адекватный в то время как мир сошел с ума, лол.

special-k ★★★
() автор топика
Последнее исправление: special-k (всего исправлений: 3)
Ответ на: комментарий от special-k

Ты по-моему сам себе придумал, что если люди описывают внешний вид на XML, то оно в дом фигачится так же. Дык вот, связи тут нет от слова совсем.

Насчет тестов я тебе так скажу - от for-писькомерок мало толку в реальных проектах. В разработке и поддержке кода на первом месте обычно совсем другие вопросы. Поэтому если ты упираешь на скорость, но предлагаешь весьма стрёмную нотацию и не решаешь других проблем - «зима не будет» (с)

Vit ★★★★★
()
Ответ на: комментарий от Vit

В разработке и поддержке кода на первом месте обычно совсем другие вопросы.

Ну.. я, как бы, не первый день в отрасли.

Я обозначил тут 2 проблемы:
1. то, что медленно;
2. то, что неудобно. Все преимущество в скорости, которое появляется, фактически связано с удобной генерацией DOM-структур и удобного же data-биндинга.

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

Многие проблемы решены: дата-биндинг, обсервер, концепция управляющих сущностей (менджеры), виджеты и т.д.

special-k ★★★
() автор топика
Ответ на: комментарий от special-k

Ну.. я, как бы, не первый день в отрасли.

Я в курсе, и именно поэтому мне странно видеть от тебя такую подачу материала.

Я обозначил тут 2 проблемы:

Не совсем так. Ты написал «я сделал клевую хреновину». Верю. Но нормального сравнения с тем что на рынке нет, поэтому непонятно, стоит ли тратить на нее время.

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

Как твое поделие поведет себя на апдейте очень длинных списков тоже не очень понятно.

Vit ★★★★★
()
Ответ на: комментарий от Vit

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

Но это же не я писал. Там много примеров на ангуляре, неужели все они написаны ламерами..

Но нормального сравнения с тем что на рынке нет

Да, пожалуй. На это явно нужно больше времени ^_^

Как твое поделие поведет себя на апдейте очень длинных списков тоже не очень понятно.

Опиши задачу - можно попробовать.

special-k ★★★
() автор топика
Ответ на: комментарий от special-k

Но это же не я писал. Там много примеров на ангуляре, неужели все они написаны ламерами..

Примеры писались под другие задачи. А ты их тупо заскейлил и решил что этот способ сравнения корректен.

Опиши задачу - можно попробовать.

Любое отображение длинных таблиц, где можно несколько строк поменять. Длинных - это когда строк больше 2К.

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

Vit ★★★★★
()
Ответ на: комментарий от Vit

А ты их тупо заскейлил и решил что этот способ сравнения корректен.

Так я-то тоже не применял никакой оптимизации. В том-то и суть! Что ты не делаешь ничего особенного, но получается быстро. Ведь мы всегда должны писать быстрые интерфейсы. Это же печально посреди крупного проекта, обнаружить, что интерфейс тормозит просто потому, что тормозит.

Там кстати плохо со скоростью :)

Помнится, там не DOM тормозит, а сама инфраструктура фреймворка.

Любое отображение длинных таблиц, где можно несколько строк поменять. Длинных - это когда строк больше 2К.

Это будет чрезвычайно быстро.

Ну или зайди на ту же фонтеллу, где иконки селектят.

Можно сделать похожий пример.

Вообще, производительность с requestAnimationFrame мне понравилась, конечно, надо думать в этом направлении. Тут понятно что есть относительно безопасные асинхронные операции: установки классов, стилей, значений текстовых узлов и т.п. (только если не опираться потом на их значение в основном потоке), но добавление новых узлов - безопасной асинхронной операцией никак не назовешь, будут ограничения. Можно запилить костыли вроде asyncSetValue, а можно запилить полноценные прокси-объекты. Не пойму пока стоит ли оно того.

special-k ★★★
() автор топика

Почему наши web-интерфейсы такие медленные и сложные?

Потому что вообще не должно существовать такой штуки, как «web-интерфейсы».

t184256 ★★★★★
()
Ответ на: комментарий от special-k

Так я-то тоже не применял никакой оптимизации. В том-то и суть!

Я тебе говорил уже, что в этом месте оптимизации как неуловимый джо - нафик никому не нужны. Они нужны на пакетировании апдейтов и virtualdom. А то что ты сделал туда не применимо.

Я не говорю, что то что ты сделал плохо, я говорю что твои сравнения не репрезентативны. А без нормального позиционирования - голова уже трещит разбираться во всем подряд :)

Vit ★★★★★
()

По-моему кто-то переизобретает coffeekup.

heilkitty ★★
()
Ответ на: комментарий от Vit

А без нормального позиционирования - голова уже трещит разбираться во всем подряд :)

Я подробно прошелся по каждой сущности, надеюсь получилось понятнее https://github.com/special-k/redtea

А еще я нашел способ реализации пакетного обновления DOM - об этом написано в самом конце.

special-k ★★★
() автор топика
Последнее исправление: special-k (всего исправлений: 1)
Ответ на: комментарий от special-k

Кто вообще объяснит, почему управление содержимым страницы на клиенте должно осуществляться через xml?

А кто тебе сказал, что XML в лоб льют на DOM? Это входной формат, потому что многим людям так удобно подавать информацию. Но никто не мешает тебе это перекомпилить во что угодно.

В redtea не принято сканировать DOM-структуры в поисках нужного узла. Ссылку на любой узел/виджет можно получить в момент его создания - это является краеугольным камнем производительности redtea.

Но чем это отличается от VirtualDOM?

Про шаблонизаторы там по-моему пурга. Никто не заставляет переливать весь шаблон целиком. Собсна, вообще неизвестно, что там внутри после того как шаблоны закомпилялись. Это ты сам додумал, «как оно бы работало если бы делал ты».

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

Vit ★★★★★
()
Ответ на: комментарий от Vit

А кто тебе сказал, что XML в лоб льют на DOM?

Да никто не говорил.

Но чем это отличается от VirtualDOM?

Это не VirtualDOM, это объекты-обертки вокруг реальных DOM-структур. Без понятия причем здесь VirtualDOM.

Собсна, вообще неизвестно, что там внутри после того как шаблоны закомпилялись.

Ну... в том-то наверно и прикол, что «вообще неизвестно». А вообще, хорошо когда все известно, понятно и подконтрольно в каждой операции.

обрезал кучу фич

Да ладно)) Фичи.. https://facebook.github.io/react/docs/thinking-in-react.html {this.props.product.name} Это дата-биндинг у них такой, лол. Сквозь 10 компонентов прокидывать вереницу свойств.

У меня сбитая отточенная концепция: создания объектов с привязанными DOM-структурами, организацией взаимодействия между этими объектами, организацией проброски данных в объекты (и в DOM-структуры соответственно). И все это наглядно и в купе с лютой производительностью (а не миллионом тормозной черной магии).

побенчмаркал захардкоженный вариант апдейта

И чем он захардкожен?)

special-k ★★★
() автор топика
Ответ на: комментарий от special-k

У меня сбитая отточенная концепция: создания объектов с привязанными DOM-структурами, организацией взаимодействия между этими объектами, организацией проброски данных в объекты

Ты уже придумал как сделать «ненужный» рендеринг на сервере?

Ты уже придумал как дать людям описывать виджеты в привычном HTML без кофескрипта?

Хендлеры евентов в итоге как описывать?

И чем он захардкожен?)

Тем что ты у себя привинтил апдейт одной ноды, а на «другом фреймворке (tm)» не привинтил.

Насчет сравнений - все по прежнему. Их нет :). Выбор «упоминаний» - странноват. Был ангуляр, стал рекат. Взял бы что-то соразмерное. На ум приходят riot.js и knockout.js. Если я правильно понял, у тебя пока только биндинг вьюмоделей, без мапинга на бизнес-модели и связки с сервером. Это чтобы было понятно, почему я именно те библиотеки назвал.

Vit ★★★★★
()
Ответ на: комментарий от special-k

Почему у тебя монитор там плохо рендерится?

Второй тест просто рвет всех в клочья - там ограничено применен requestAnimationFrame.

У меня в хроме 2fps разница между первым и вторым, это нормально?

бережное отношение к DOM

Не очевидно сколько это займет времени на менее тривиальных примерах.

zz ★★★★
()

Но кто объяснит чем это лучше?

А кто сказал, что это - лучше? Это полное говно. И как не назови код на JS, виджетом, менеджером или ещё как - он останется говном из за фундаментальной убогости.

Alve ★★★★★
()
Ответ на: комментарий от Vit

Ты уже придумал как сделать «ненужный» рендеринг на сервере?

Я пока не понимаю в чем смысл данной операции. Что должно получиться в итоге на клиенте, и почему это лучше, чем передавать json? Вообще можно передавать прям так:

@superTable ->
  @row storageData: ...

Ты уже придумал как дать людям описывать виджеты в привычном HTML без кофескрипта?

Можно сделать конвертер по типу js2coffee.

Хендлеры евентов в итоге как описывать?

Подписка на обсервер.

@a().bi 'click', someFunc
@a().bi RTC.CLICK, someFunc, context: someContext
@a().bi RTC.CLICK, 'someFunc', context: someContext #удобно при unit-тестировании, т.к. при таком описании функция легко заменяется на шпиона.

#одинаково с виджетами и менеджерами.
@someWidget().bi 'someEvent', 'someFunc', context: someContext 

Фичастый реакт

var boundClick = this.handleClick.bind(this, i);
return (
  <Todo onClick={boundClick} key={i} title={item} ref={'item' + i} />
);
Удобненькая каша -_-

Тем что ты у себя привинтил апдейт одной ноды

Что значит одной ноды? Там обновляются сотни нод.

На ум приходят riot.js и knockout.js.

Ок. Там есть knockout.js с ним все точно так же. http://todomvc.com/examples/knockoutjs/#/

var t = [], count = 1000;
for(var i = 0; i < count; i++ ) {t.push({title: 'task ' + i, completed: false})}
localStorage.setItem('todos-knockoutjs', JSON.stringify(t));

special-k ★★★
() автор топика
Ответ на: комментарий от zz

Почему у тебя монитор там плохо рендерится?

Не знаю, думаешь это принципиально?

У меня в хроме 2fps разница между первым и вторым, это нормально?

Многое зависит от параметров запуска браузера и параметров системы.

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

special-k ★★★
() автор топика
Последнее исправление: special-k (всего исправлений: 1)
Ответ на: комментарий от special-k

Я пока не понимаю в чем смысл данной операции. Что должно получиться в итоге на клиенте, и почему это лучше, чем передавать json? Вообще можно передавать прям так:

Когда придет бот индексировать сайт, тоже ему будешь json вместо html отдавать?

Только не рассказывай что гуглоботы научились яваскрипт понимать. На них свет клином не сошелся. И запустить на сервере тормозной phantomjs для перегона в html тоже предлагать не надо.

Vit ★★★★★
()
Ответ на: комментарий от special-k

Не знаю, думаешь это принципиально?

Хз.

К вопросу о потерянных фичах, было бы интересно добавить в db monster что-нибудь что требует добавление/удаление/перемещение строк с базами, и html контент для части из запросов. Например <b>time</b> вместо warn_long.

Олсо твое демо не реагирует на изменение ENV.rows.

zz ★★★★
()
Ответ на: комментарий от Vit

Когда придет бот индексировать сайт

Т.е. биндинги событий на элементах передавать не надо? Тогда нужен специальный серверный виртуалдом.

special-k ★★★
() автор топика
Ответ на: комментарий от special-k

Ну дык тебе о том и талдычат :). Нужна прослойка виртуалдом. Типа у самых модных посонов уже имеется.

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

Vit ★★★★★
()
Последнее исправление: Vit (всего исправлений: 1)
Ответ на: комментарий от Vit

Ну дык тебе о том и талдычат :)

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

special-k ★★★
() автор топика
Ответ на: комментарий от special-k

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

Насчет кодинга дома на кофескрипте - ХЗ. Непривычно очень. От обычного html я тоже не в воссторге, пока jade используем. У него, кстати, есть AST, и реально прицепить компилятор во что-то другое.

Кстати, у изоморфных виджетов, несмотря на виртуалдом, так и не решена проблема, как ими рулить совсем прозрачно. Например, сбацали html на сервере, и продолжили в браузере. Если сможешь это решить - можешь рассчитывать на ковер и телевизор :)

Vit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.