Обработчики событий в jQuery

[keltanas]

Приветствую!

Сейчас в jQuery плагин live считается устаревающим. Вместо него рекомендуется использовать конструкцию вида

$(document).on(events, selector, data, handler);

http://jqapi.com/#p=live

на сколько такая обработка событий затратна в ресурсах? Будет ли это вызывать проседание скорости работы js приложения, если везде использовать такую конструкцию для обработки событий вместо обычного?

$(selector).on(events, data, handler);

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

Edited September 12, 2012 by keltanas

[s0rr0w]

Чем больше тегов на странице, тем медленнее будет работать JS.

[keltanas]

Чем больше тегов на странице, тем медленнее будет работать JS.

Ну это само собой.

А какие еще могут быть предпосылки против?

Вот например, если тэгов не существует в момент инициализации, такая конструкция также не вызовет ошибок. А обычный вид надо оборачивать в $.each, чтобы найти эти элементы. Это также увеличивает скорость разработки, но уменьшает скорость приложения.

Если события подвешиваются в соответствии с механизмом behavior, то их придется через $(document) биндить, иначе их никак не переинициализироват будет.

[nerv]

Вместо него рекомендуется использовать конструкцию вида

на первый взгляд кажется что будет не айс.

на сколько такая обработка событий затратна в ресурсах?

ужасно? )

вместо обычного?

от обычной планируют отказаться? (я бы почитал, но не настолько хорошо знаю бусурманский)

Edited September 13, 2012 by nerv

[keltanas]

от обычной планируют отказаться? (я бы почитал, но не настолько хорошо знаю бусурманский)

Нет. Планируют отказаться от $.live(). Вроде как в jQ1.9 его уже не будет

А AngularJS кто-нибудь юзал?

Там вообще не надо подвешивать события (в клиентском коде, на самом деле они конечно подвешиваются).

Код, по идее, сокращается в разы. Многое вообще задается чисто декларативно. На видео там все ясно.

[s0rr0w]

А AngularJS кто-нибудь юзал?

Там вообще не надо подвешивать события (в клиентском коде, на самом деле они конечно подвешиваются).

Код, по идее, сокращается в разы. Многое вообще задается чисто декларативно. На видео там все ясно.

Хаха, чуваки медленно, но уверенно идут к модели StateController'а...

Я, пожалуй, еще годика два подожду, посмотрю на их эволюцию.

[keltanas]

А AngularJS кто-нибудь юзал?

Там вообще не надо подвешивать события (в клиентском коде, на самом деле они конечно подвешиваются).

Код, по идее, сокращается в разы. Многое вообще задается чисто декларативно. На видео там все ясно.

Хаха, чуваки медленно, но уверенно идут к модели StateController'а...

Я, пожалуй, еще годика два подожду, посмотрю на их эволюцию.

Не StateController'ом единым, как говориться.

Данный подход в разных фреймворках назвается по разному. Где-то Behavior. Вы его называете StateController. Кто-то еще как-то.

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

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

Есть у меня и свой велосипед на данную тему https://github.com/keltanas/SiteForeverCMS/blob/requirejs/misc/admin/app.js

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

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

Если честно, перечитывать все, что на форуме написано про StateController откровенно лень. Поэтому и не вникал в сабж.

Чем он лучше AngularJS ?

[keltanas]

от обычной планируют отказаться? (я бы почитал, но не настолько хорошо знаю бусурманский)

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

Например, это было справедливо по отношению в Татаро-монголам, или жителям Турции.

Но, я бы не стал называть янки - басурманами.

Edited September 14, 2012 by keltanas

[s0rr0w]

Не StateController'ом единым, как говориться.

Данный подход в разных фреймворках назвается по разному. Где-то Behavior. Вы его называете StateController. Кто-то еще как-то.

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

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

Если честно, перечитывать все, что на форуме написано про StateController откровенно лень. Поэтому и не вникал в сабж.

Чем он лучше AngularJS ?

Тем, что гораздо проще, но при этом решается множество задач, а именно:

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

2. Это единый способ передачи данных между различными компонентами.

3. Позволяет строить слабосвязанную архитектуру, со всеми вытекающими последствиями

4. Переносимость JS кода может достигать 90% (переделки касаются только сценариев)

5. Полный контроль разработчика над происходящим. Разработчик может сам себе придумать и реализовать способ сбора произвольной json-структуры, при этом не написав ни строчки JS-кода.

6. Отсутствие изменения поведения библиотеки от версии к версии. Код SC и смежные библиотечные функции не подвергаются изменениям годами. Там нечего менять. Счастье промышленного разработчика.

[keltanas]

s0rr0w, Вы уверены в этом? Мне так не показалось, что SC проще.

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

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

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

Edited September 14, 2012 by keltanas

[s0rr0w]

s0rr0w, Вы уверены в этом? Мне так не показалось, что SC проще.

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

Это все равно, что разбираться с xsd или xslt. Трудно первые два дня, потом сидишь и думаешь, вот это я тупой.

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

Туториал вам расскажет только про то, что уже написано. Но не расскажет что нужно еще написать, чтобы это начало работать так, как вам надо, а не так как заложено разработчиками.

[keltanas]

s0rr0w, И сколько уже таких одаренных пользователей SC появилось?

[s0rr0w]

s0rr0w, И сколько уже таких одаренных пользователей SC появилось?

Одаренные пользователи? Это не готовая библиотека, тут надо программировать.