?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

О JS фреймворках вообще

Posted on 2010.12.04 at 23:09
Tags: , , , ,
Вообще, особенности работы браузеров, указанные в предыдущем посте, грядущий HTML5/CSS3, и прочее "состояние+тренды", если подбить все в кучу - ведет к тому, что надо переосмыслить взгляд на JS фреймворки.


Начать можно с того, что если вы собираетесь сделать в браузере нечто сложное, то jQuery-евский тезис, что он мол "меняет ваш способ программирования на JavaScript", работать перестает. При попытке сделать оффлайновое приложение вы уже не можете игнорировать особенности браузера.

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

Хороший современный фреймворк не может это игнорировать. Работа с шаблонами, знакомая каждому веб-программисту - должна быть основным, а не добавочным способом рендеринга контента в клиентском веб-фреймворке.

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

Третий момент. Делегация событий - замечательная штука. Вернее, не так. Способ привязки событий, к которому подталкивает вас jQuery и иже с ними (выборка элементв селекторами и привязка к ним) - непрактичен, приводит к тормозам, и его следует избегать. Это, опять же, принципиальная особенность работы браузеров, которую невозможно игнорировать, если вы соберетесь писать нечто серьезное.

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

Хороший современный фреймворк должен привязывать события декларативно. Что-нибудь вроде такого:


И в контроллере пишем просто:
$root.click({
    a : function(){

    },
    b: function(){

    }
});


И останавливать bubbling событий по умолчанию.

И все. Все, блин. Никаких селекторов, и неудобоваримой "делегации".

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

Зато потребуется другое - то, чем в базовом jQuery и не пахнет.
1) Нормальная и простая в использовании модульная система, с подгрузкой модулей по локальным зависимостям. Чтобы не возникал вопрос, "how can I include JS in JS".
2) Поддержка модулей разного типа - в том числе CSS и HTML-шаблонов.
3) Не выносящий мозг способ группировать фрагменты HTML шаблонов+JS+CSS способом, пригодным к повторному использованию. То есть - определять свои виджеты, которые лежат в модулях. Чтоб это было почти так же легко, как выделить код в функцию.
4) Поддержка сетевого уровня и локального хранения данных.
5) Фьючерсы-промисы - должны быть реализованы по человечески, и лежать в основе всей системы, в том числе и сетевого уровня, пряча прямолинейные коллбэчные интерфейсы.

Описываемый подход обладает сущностью PHP. Он не прячет от программиста HTML на задворки сцены, притворяясь десктопным API, как это делает Cappuccino. И он не выглядит набором свистулек, "изменяющих ваш способ программирования", как jQuery. И не похож на навороты вроде ExtJS, при взгляде на который у многих волосы встают дыбом.

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

На самом деле, все описанное, кроме декларативной привязки событий, лично у меня уже есть, и кода во всем этом - тьфу. Почти ничего. Я вот начинаю задумываться, нахрена при всем описанном необходим такой хороший jQuery. Я вот посчитал, что из него в аппликухе используется. По факту - почти ничего. Только компоненты, отвечающие за анимацию (которую скоро можно будет делать и без него). При декларативном байндинге - его селекторы тоже не нужны. Вставка - не нужна, все равно innerHTML применяется.

Такие дела. JS фреймворки, в том виде, в котором они есть - по большому счету, просто не нужны. Времена меняются. Скоро будут нужны не они.

Вот пример фреймворка такого типа, о котором говорю я.
http://archetypejs.org/

PS: Я вообще скажу так - добавление динамики в контроллере посредством селекторов а-ля CSS, как в jQuery - зло. Почему? Да потому, что когда вы смотрите в шаблон, вы не понимаете, за что конкретно, за какие элементы зацепятся обработчики событий, ибо в контроллере может быть наворочено селекторами все, что угодно. Это очень плохо. Потому, что контракт между view и controller получается неявным.

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

В жопу селекторы.

PPS: Право слово, жаль, что у меня в ближайший год будет много менеджерской работы. Глядя на этот бардак в JS фреймворках, я сожалею, что переквалифицировался в менеджеры. Я, вероятно, не смогу исправить ситуацию лично. Но, уметь программить вообще хорошо - это дает непревзойденное ощущение понимания деталей, и эффективно заменяет прохождение теста на IQ. :)

Так что JS программирование я бросать не собираюсь. Тем более, что, думаю, придется писать свой "правильный" трекер-тайм-менеджер. А то ведь с ними беда похуже, чем с JS фреймворками.

Comments:


kurilka at 2010-12-04 23:11 (UTC) (Link)
Чтот я или слепой или не вижу даж тривиальных примеров на этом архетипе, которые можно былоб "запустить", это как-то смущает...
Неработающий багтрэкер и последние апдейты блога и файлов на sf(!) ещё более.
Или речь о демонстрации идеи?
А "внутрибраузерные шаблонные движки" - это типа твоего шаблонизатора, или речь о чём-то другом?
Gaperton
gaperton at 2010-12-05 00:47 (UTC) (Link)
> Или речь о демонстрации идеи?

Об этом.

> А "внутрибраузерные шаблонные движки" - это типа твоего шаблонизатора, или речь о чём-то другом?

Типо моего. Тысячи их, на самом деле.
Gaperton
gaperton at 2010-12-05 00:54 (UTC) (Link)
http://archetypejs.org/overview/fwk-map.html

Вот на это глянь. Отличная иллюстрация к моему посту.
sergiymovchan at 2010-12-04 23:47 (UTC) (Link)

декларативно?

2 вопроса:

1. это так красиво обозван старый-добрый onClick="function(){}"?

2. а зачем биндить разные события одним именем? то есть если у меня есть
, то у меня и клики и блуры и ховеры будут замаплены на a? а я хочу b и c... или я что-то не так с примером понял?

ну и попытки объяснить биндинг через селекторы:
огры они как лук (с) тот, кто выдаёт в html элемент
sergiymovchan at 2010-12-04 23:48 (UTC) (Link)

Re: декларативно?

ой. не надо писать угловые скобочки... :)
sergiymovchan at 2010-12-04 23:53 (UTC) (Link)

Re: декларативно?

№2 читать как:

а зачем биндить разные события одним именем? то есть если у меня есть [div handler="a"], то у меня и клики и блуры и ховеры будут замаплены на a? а я хочу b и c... или я что-то не так с примером понял?

попытки объяснить читать как:
ну и попытки объяснить биндинг через селекторы:
огры они как лук (с) тот, кто выдаёт в html элемент [textarea] может в общем случае и не знать, что кто-то другой прицепит на него визифиг.

а работает это именно потому, что всякие декораторы работают без того, что декорируемый элемент про них вообще что-то знает. а как это сделать декларативно?
Gaperton
gaperton at 2010-12-05 00:51 (UTC) (Link)

Re: декларативно?

1. это так красиво обозван старый-добрый onClick="function(){}"?

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

2. а зачем биндить разные события одним именем?

А почему бы и нет? Зачем засорять HTML избыточной хренью, не понятно, если надо, допустим, забайндить вхождение и выхождение мыши в элемент. Все равно события обрабатываются в контроллере, если следовать MVC. А ему лучше следовать.
sergiymovchan at 2010-12-04 23:49 (UTC) (Link)

дом или текст

работать с домом напрямую конечно медленно.

а строить мини-домики (именно как дом, а не как текст), которые потом вставлять куда надо, разве плохо?
(Deleted comment)
Gaperton
gaperton at 2010-12-05 00:53 (UTC) (Link)
Я смотрел prototype. И не только его. Встречный вопрос - а вы читали пост? :)
(Deleted comment)
Роман Яковлев
pr0ximo at 2010-12-05 07:55 (UTC) (Link)
Если есть идеи делайте потихоньку, с примерами, с документацией, все как должно быть в правильном фреймворке, по вашему мнению. После того, можно было бы предметно это дело обсуждать, рассуждать, на основе примеров работающего правильного фреймворка. А сейчас это просто обмен имхо по поводу, каким должен быть идеальный фреймворк и почему так плох jquery.
Gaperton
gaperton at 2010-12-05 09:37 (UTC) (Link)
Где обмен-то? :) Я никакого содержательного имха и какого-либо "обмена" им в комментах не вижу.
Майк
glader at 2010-12-06 17:04 (UTC) (Link)
Я правильно понимаю, что, ратуя за шаблоны на стороне клиента, вы забиваете на пользователей без яваскрипта?
Кот серый, средней пушистости
grey_kristy at 2010-12-07 09:11 (UTC) (Link)
Не совсем понял про привязку событий.

Ну написали div handler="a". OK. Но дальше ведь надо привязать обработчик к этому диву. То есть все равно пройти по всему DOM дереву, найти все узлы с атрибутом handler и повесить на них соответствующие обработчики (ну или один обработчик с внутренней диспетчеризацией, не суть важно).

Чем это принципиально отличается от селекторов a la jQuery?
Gaperton
gaperton at 2010-12-09 21:48 (UTC) (Link)
не надо пробегаться по дереву, и делать привязку. Используется event bubbling. Мы ловим событие наверху, и уже в js определяем, какой элемент его бросил.

Это не отличется от jquery. Это можно сделать средствами jquery.
Previous Entry  Next Entry