Слишком сложно продвигать JavaScript с помощью Script # и javascript? - PullRequest
2 голосов
/ 12 января 2010

Итак, я играл с домашним проектом, который включает в себя много js. Я использовал Script # для написания своей собственной библиотеки и т. Д. Лично я бы не стал писать много js, если бы у меня не было такого инструмента, как Script # или GWT, который помог бы поддерживать его.

Пока он включает в себя следующие внешние библиотеки: - ASP.NET AJAX - ExtJS - Карты Гугл - Google Visulisations - Моя собственная библиотека, чтобы обернуть вышеупомянутые библиотеки и добавить дополнительную функциональность ...

Так что получается куча js. Он отлично работает на моем компьютере. Однако я мало верю в js / browser и обеспокоен тем, что загрузка слишком большого количества js приведет к тому, что браузер умрет или будет работать плохо.

Это действительная проблема?

Есть ли у кого-нибудь опыт загрузки большого количества js в браузер, что привело к проблемам с производительностью? Я, однако, знаю, что здесь много переменных, например, тип браузера (я полагаю, IE хуже других), ОЗУ клиентских ПК и т. Д., Но было бы хорошо получить опыт других людей. Я бы не хотел тратить много времени на js, только чтобы понять, что я рисую себя в угол.

Чем больше я использую Script #, тем больше клиентских классов у меня появляется, когда я перекладываю больше обработки на клиента. В какой момент это станет проблемой? Я уверен, что браузер мог бы легко обрабатывать 100 MS Ajax-классов, но что было бы слишком далеко для браузера?

ПРИМЕЧАНИЕ. Меня не беспокоит фактический размер файла js, но больше загружается среда выполнения.

Ответы [ 4 ]

2 голосов
/ 12 января 2010

Нет ничего плохого в том, что у меня большое количество js-файлов или больших js-файлов. В настоящее время над проектом работает более 60 базовых библиотек фреймворка, и 30 из каждого модуля получают в среднем от 5 до 6 js-файлов.

Таким образом, единственное беспокойство вызывает то, как вы разрабатываете свой веб-сайт, используя лучшие методы и методы оптимизации JS. как

  1. Сведите к минимуму JS с помощью YUI или любых других библиотек сжатия для решения проблем с размером загрузки.
  2. Включите правильное кэширование на своем веб-сервере, чтобы уменьшить загрузку файлов.
  3. Поместите свой JavaScript внизу страницы или сделайте его отдельным файлом.
  4. Сделайте ваш ответ AJAX кэшируемым.
  5. И, наконец, создайте свою страницу, которая будет обрабатывать загрузку скриптов по требованию.
    - Microsoft DOLOTO является хорошим примером для этого. скачать его здесь

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

1 голос
/ 12 января 2010

с современными браузерами, обычно занимающими 250 МБ ОЗУ или более, кэшированием сценариев и оптимизированными механизмами javascript, сохранение резидентной библиотеки сценариев, вероятно, незначительно увеличит нагрузку в большинстве разумных сценариев.

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

0 голосов
/ 12 января 2010

Я очень сомневаюсь, что браузер когда-нибудь аварийно завершит работу ваших JS-скриптов, но он станет очень медленным и может не работать так, как вы хотите. Большинство людей больше беспокоятся о том, насколько быстро он работает, а не , если он будет работать!

0 голосов
/ 12 января 2010

Я согласен с jspcal, вы должны быть в состоянии загрузить довольно много JavaScript без проблем. Javascript-движки во всех современных браузерах на много быстрее, чем несколько лет назад. Первоначальная загрузка будет самой большой проблемой. Если возможно, я бы предложил ленивые скрипты загрузки, которые не нужны для отображения страницы.

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

http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

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

...