Comments 52
Огромное спасибо, у меня как раз встала проблема повторной загрузки.
С удовольствием буду использовать!
А вы собираетесь отписать в jQuery о включении этого чуда стандартную поставку?
С удовольствием буду использовать!
А вы собираетесь отписать в jQuery о включении этого чуда стандартную поставку?
Спасибо большущее! вещь очень полезная
Полезная штука, пригодится ;)
сам jQuery настолько «тяжелый», что оптимизировать последующую загрузку странно.
Однако встречаются и случаи, когда jQuery + пара плагинов навернуто на mootools + пара плагинов. Создателей таких сайтов вообще отстреливать надо…
Однако встречаются и случаи, когда jQuery + пара плагинов навернуто на mootools + пара плагинов. Создателей таких сайтов вообще отстреливать надо…
Что странного в том, чтобы подгружать, допустим, 100 Кб какого-нибудь функционала только тогда, когда он действительно понадобится на странице (учитывая, что он может и не понадобится)?
да ничего. Просто если для того, чтобы загрузить 100Кб по требованию, нужно выгрузить на каждую страницу 50Кб jQuery, — это, имхо, перебор.
Обычно, jQuery все-таки нужен не для того чтобы загрузить 100Кб по требованию. Здесь предлагается решение, когда jQuery уже используется на проекте, но есть необходимость в ленивой загрузке части функционала.
Это понятно. Но лично я считаю использование всего jQuery признаком ленивости программистов. Да, это средство для быстрой разработки. Да, это экономит силы. Но если проект по размеру выходит за рамки размера самого jQuery, то его точно нужно рефакторить и выбрасывать лишнее.
Не понял, если js проекта по размеру больше, чем размер jQuery, то его (jQuery) нужно рефакторить и выбрасывать все лишнее? Мне кажется это более чем странно. Как мне думается, чем больше проект, тем наоборот, все больше и больше бонусов начинаешь получать от использования jQuery.
И с выходом новой версии jQuery опять рефакторить и выбрасывать лишнее из него?
И с выходом новой версии jQuery опять рефакторить и выбрасывать лишнее из него?
а зачем нужна новая версия jQuery, если старое хорошо работает?
Я просто к тому, что, например, CSS-селекторы в самом jQuery за счет оберток работают в 3 раза медленнее, чем в Sizzle (про YASS я молчу).
Сам Resig неоднократно писал, что рефакторил и будет рефакторить код на предмет производительности. Но код-то от этого меньше не становится. Вот если бы выложил модульную структуру, чтобы скачать только необходимое — респект ему и хвала.
Просто использование какой-то «чужой» библиотеки в большом проекте обычно приводит к тому, что издержки от ее применения и работы становятся больше, чем выигрыш — приходится писать громоздкие конструкции и опираться на определенную, часто избыточную, логику библиотеки.
Я просто к тому, что, например, CSS-селекторы в самом jQuery за счет оберток работают в 3 раза медленнее, чем в Sizzle (про YASS я молчу).
Сам Resig неоднократно писал, что рефакторил и будет рефакторить код на предмет производительности. Но код-то от этого меньше не становится. Вот если бы выложил модульную структуру, чтобы скачать только необходимое — респект ему и хвала.
Просто использование какой-то «чужой» библиотеки в большом проекте обычно приводит к тому, что издержки от ее применения и работы становятся больше, чем выигрыш — приходится писать громоздкие конструкции и опираться на определенную, часто избыточную, логику библиотеки.
Одна из причин перехода на новые версии, как вы сами заметили, — это увеличение производительности в новых версиях. Другая — то, что там обычно появляется новых функционал (обычно востребованный). А можно увидеть где-нибудь тесты, где Sizzle оказывается быстрее в 3 раза чем он же, обернутый jQuery? Да и вообще мне кажется, что если в вашем приложении критична скорость селекторов, то надо подумать об оптимизации использования селекторов, а не увеличения их производительности.
боюсь, что все мои последующие комментарии так же будут заминусованы офисным планктоном, но
ajaxian.com/archives/sizzle-john-resig-has-a-new-selector-engine
sizzlejs.com/
yass.webo.in/slickspeed/?yass_0-3-8/Peppy_0-1-2/Sizzle_20-05-09/jQuery_1-3-2
P.S. да, обертки jQuery уже не так сильно нагружают Sizzle (или частично переехали в Sizzle?), поэтому разницы в скорости нет.
P.P.S. стоит учитывать, что в Peppy/YASS включено кэширование, поэтому результаты отличаются на порядок. Однако даже с выключенным кэшированием все равно значительный прирост скорости.
ajaxian.com/archives/sizzle-john-resig-has-a-new-selector-engine
sizzlejs.com/
yass.webo.in/slickspeed/?yass_0-3-8/Peppy_0-1-2/Sizzle_20-05-09/jQuery_1-3-2
P.S. да, обертки jQuery уже не так сильно нагружают Sizzle (или частично переехали в Sizzle?), поэтому разницы в скорости нет.
P.P.S. стоит учитывать, что в Peppy/YASS включено кэширование, поэтому результаты отличаются на порядок. Однако даже с выключенным кэшированием все равно значительный прирост скорости.
Хм. Интересно про YASS, не знал о нём ничего до сих пор.
Я насколько знаю jresig свои библиотеки делает что бы они и xml обрабатывали. YASS это не делает?
Я насколько знаю jresig свои библиотеки делает что бы они и xml обрабатывали. YASS это не делает?
YASS работает с DOM-деревом. Без разницы, в каком документе
Почему на странице с тестированием нет cssquery? jresig в книге пишет что когда он начал jquery, то хотел повторить именно функционал cssquery только по-своему.
Ещё два вопроса.
Если yass будет работать несколько секунд, он блокирует интерфейс браузера?
Если yass будет работать несколько секунд, он блокирует интерфейс браузера?
В yass используется общий код который один на все браузеры или есть оптимизированный код под конкретные браузеры?
Так делают программисты под windows mobile, для разных процессоров и инструкций в одной программе пишут несколько функций оптимизированные под разные процессоры.
Так делают программисты под windows mobile, для разных процессоров и инструкций в одной программе пишут несколько функций оптимизированные под разные процессоры.
Ну, ведь вмешательство в фреймворк на некотором этапе — это плохо относительно общей концепции фреймворка.
Проекты бывают разные. jQuery может сильно упростить жизнь в некоторых случаях
19kb это не тяжелый. Это фигня.
А на специальных сайтах бывают и сотни килобайт JS. И их разумно подгружать по необходимости.
А на специальных сайтах бывают и сотни килобайт JS. И их разумно подгружать по необходимости.
:) давайте, мы будем говорить о конкретных цифрах?
Если у вас 19Кб минимизированного и gzip-сжатого JS кода в jQuery, то у вас дополнительного функционала никак не будет «сотни килобайт».
Если имеется в виду несжатого функционала на сотни килобайт, то и про jQuery стоит упомянуть в соответствующем ключе.
Я про относительные размеры библиотек, а не про абсолютные. Сейчас понятие «абсолютной тяжести» скриптов несколько размыто в связи с большим разнообразием каналов связи у конечных пользователей.
Если у вас 19Кб минимизированного и gzip-сжатого JS кода в jQuery, то у вас дополнительного функционала никак не будет «сотни килобайт».
Если имеется в виду несжатого функционала на сотни килобайт, то и про jQuery стоит упомянуть в соответствующем ключе.
Я про относительные размеры библиотек, а не про абсолютные. Сейчас понятие «абсолютной тяжести» скриптов несколько размыто в связи с большим разнообразием каналов связи у конечных пользователей.
При разработке сложных внутренних интерфейсов интранет-систем даже сжатого и минимизированного JS может быть сильно больше 100k.
Не за счет собственного кода, конечно, а просто потому, что легко и эффективно использовать тяжелые внешние библиотеки. Тот же jquery ui и аналоги.
Не за счет собственного кода, конечно, а просто потому, что легко и эффективно использовать тяжелые внешние библиотеки. Тот же jquery ui и аналоги.
Знаю проект, в котором 2 мегабайта несжатого прикладного JS кода. ;-) После yuicompressor остается порядка 400К. Предлагаете загружать его сразу?)
Пожелания:
1)
Лучше бы использовали концепцию $.usescript. Всего лишь смена имени.
2)
Чаще всего нужно выполнить $.usescript(['first-one', 'second-one'], function()
{
//…
});
3)
Хочу задавать $.expand($.usescript.defaults, { prefix: '/js/', suffix: '.js' });
4)
Скрипт может по уму пропарсить DOM, чтобы знать, какие скрипты уже включены в страницу.
1)
Лучше бы использовали концепцию $.usescript. Всего лишь смена имени.
2)
Чаще всего нужно выполнить $.usescript(['first-one', 'second-one'], function()
{
//…
});
3)
Хочу задавать $.expand($.usescript.defaults, { prefix: '/js/', suffix: '.js' });
4)
Скрипт может по уму пропарсить DOM, чтобы знать, какие скрипты уже включены в страницу.
Спасибо, буду думать. Мне кажется только пункт 3 немного лишний. Лучше в своем приложении сделать какой-нибудь
NAMESPACE.useModule(), где уже будет прописано откуда и что брать. А $.loadScript все-таки ф-ия немного более низкого уровня.Это свего лишь умолчания. В обьекте опций можно передать другие переменные.
Кстати, соответственно context должен быть удален, вместо него передавать options, у которых вероятно свойство scope (то есть context, но scope более привычен, такое именование принято, например, в Ext.JS).
Кстати, соответственно context должен быть удален, вместо него передавать options, у которых вероятно свойство scope (то есть context, но scope более привычен, такое именование принято, например, в Ext.JS).
Вообщем, пока только переименовал
$.loadScript в $.useScript и сделал поддержку массива урлов. Остальное под вопросом.$(document).ready(function()
{
$('script[src]').each(function()
{
save its this.src in table of already loaded scripts…
});
});
{
$('script[src]').each(function()
{
save its this.src in table of already loaded scripts…
});
});
вернее, $(this).attr('src'), чтобы пути корректно брать, без приколов браузеров.
Не нравится
Надо еще покопать и подумать в этом направлении.
$('script[src]') — проход по всему дереву. Да и не дает этот метод гарантии — допустим, в подключаемом в head скрипте 1.js стоит вызов $.useScript('2.js') напрямую и после этого в head идет подключение 2.js. В итоге, все равно 2 запроса за одним и тем же уйдет.Надо еще покопать и подумать в этом направлении.
Осталось выложить в plugins.jquery.com/
Существует xLazyLoader, который собираются интегрировать в jQuery Core.
Sign up to leave a comment.
Загрузка по требованию и jQuery