Comments 12
А я вот пользую code.google.com/p/extsrcjs/
Жаль разавитие проекта остановилось.
Жаль разавитие проекта остановилось.
Еще один вариант — это yepnope.js, асинхроная загрузка вообще любого контента, в том числе css и скриптов. Кстати входит в состав Modernizr.
Opera — удобный с точки зрения пользовательского интерфейса и очень быстрый браузер. Когда-то даже команда разработки Opera позиционировала его как самый продвинутый с точки зрения поддержки новых веб-стандартов (возможно, и сейчас так позиционируют). Но, к сожалению, куча таких вот мелочей, когда не поддерживаются маленькие фишки, которые уже поддерживаются и хромом и фаерфоксом, очень расстраивает!
UFO just landed and posted this here
Пятый слайд презентации очень хорош.
> Инженер из компании Google
Как бы его познакомить с разработчиками Google Sites из той же компании… :)
Как бы его познакомить с разработчиками Google Sites из той же компании… :)
Спасибо, о нагрузке на сервер задумывался, а вот про клиент частенько забывал. Пошёл апдейтить скрипты.
Даже если вы сделаете один монолитный файл или он надежно закэшируется, то у вас останется еще одна весомая проблема, которая становится более актуальна сегодня(вес скриптов увеличивается, скорость сети увеличивается) — инициализация скрипта aka Startup Latency. Данная проблема такая же актуальная как и тормоза при старте Java-приложений.
Сравним: 1Мб JavaScript на локалхосте загружается за 32мс и меньше. В iOS Safari 4 он инициализируется за 3500мс!!!, а в Firefox 9 — около 600мс. Даже если мы эти 32мс превратим в 0, то как избавится от 600-3500мс?! Сейчас не существует нативных средств (JavaScript/DOM) устранить эту проблему и это физически невозможно для JavaScript (его классы функции не декларативны — требуют инициализации) дамп памяти(Image) тоже, в принципе, невозможен.
Есть способ уменьшить Startup Latency(да, как всегда, костыли):
1. Загружать и инициализировать модули по необходимости(так работает gmail) — асинхронные модули+кэш
2. Загружать все, а потом инициализировать модули по необходимости(так работает lmd) — синхронный способ как в Node.js
Еще раз повторю — это костыль. Например в Dart такой проблемы нет.
Почитать:
www.nczonline.net/blog/2011/02/14/separating-javascript-download-and-execution/
googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html
calendar.perfplanet.com/2011/lazy-evaluation-of-commonjs-modules/
github.com/azproduction/lmd
Сравним: 1Мб JavaScript на локалхосте загружается за 32мс и меньше. В iOS Safari 4 он инициализируется за 3500мс!!!, а в Firefox 9 — около 600мс. Даже если мы эти 32мс превратим в 0, то как избавится от 600-3500мс?! Сейчас не существует нативных средств (JavaScript/DOM) устранить эту проблему и это физически невозможно для JavaScript (его классы функции не декларативны — требуют инициализации) дамп памяти(Image) тоже, в принципе, невозможен.
Есть способ уменьшить Startup Latency(да, как всегда, костыли):
1. Загружать и инициализировать модули по необходимости(так работает gmail) — асинхронные модули+кэш
2. Загружать все, а потом инициализировать модули по необходимости(так работает lmd) — синхронный способ как в Node.js
Еще раз повторю — это костыль. Например в Dart такой проблемы нет.
Почитать:
www.nczonline.net/blog/2011/02/14/separating-javascript-download-and-execution/
googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html
calendar.perfplanet.com/2011/lazy-evaluation-of-commonjs-modules/
github.com/azproduction/lmd
Еще вариант — это как сделанно в GWT с их code splitting: при разработке отдельные приложение разбивается на «куски», которые подгружаются (включая парсинг) уже по мере необходимости (т.е при необходимости показатьк какой-то виджет) автоматически.
Довольно неплохое решение для быстрого startup приложения, хотя из-за того что анализ зависимостей автоматический, иногда не так хорошо сплитится как хотелось.
Довольно неплохое решение для быстрого startup приложения, хотя из-за того что анализ зависимостей автоматический, иногда не так хорошо сплитится как хотелось.
UFO just landed and posted this here
LMD и AMD — одно лицо, только в LMD нет define, все модули локальны и инициализируются по требованию.
Немного о истории LMD.
Сначала я решил пропатчить require.js, добавив отложенную инициализацию, но покопавшись в кода и поняв, что там много чего лишнего и понял, что лучше начать с нуля (так, собственно, и делаются все велосипеды).
require.js — огромный кусок кода, который чинит косяки многих браузеров по асинхронной загрузке различных ресурсов и предоставляет перегруженный интерфейс — зачем все это, если можно собрать скриптовый пакет и работать с модулями как в Node.js, используя только
Собирать все модули в одну кучу с первого взгляда кажется плохо — зачем мне загружать скрипты для блока «ололо» если пользователь этот блок не увидит — уж лучше я сэкономлю 10кб трафика пользователя, сделаю 50 запросов вместо одного и помучаюсь с асинхронными модулями и неработающими блоками в оффлайн режиме! (тут я не говорю о сборке в пакет сторонних библиотек)
Зачем все это, если все модули можно так или иначе закэшировать, пользователь рано ли и поздно воспользуется блоком «ололо», мы сокращаем количество запросов до минимума и работаем с модулями в привычном и удобном для нас синхронном виде(node.js).
Это плюсы LMD по сравнению с require.js
Немного о истории LMD.
Сначала я решил пропатчить require.js, добавив отложенную инициализацию, но покопавшись в кода и поняв, что там много чего лишнего и понял, что лучше начать с нуля (так, собственно, и делаются все велосипеды).
require.js — огромный кусок кода, который чинит косяки многих браузеров по асинхронной загрузке различных ресурсов и предоставляет перегруженный интерфейс — зачем все это, если можно собрать скриптовый пакет и работать с модулями как в Node.js, используя только
require()? LMD около 300 байт клиентского скрипта.Собирать все модули в одну кучу с первого взгляда кажется плохо — зачем мне загружать скрипты для блока «ололо» если пользователь этот блок не увидит — уж лучше я сэкономлю 10кб трафика пользователя, сделаю 50 запросов вместо одного и помучаюсь с асинхронными модулями и неработающими блоками в оффлайн режиме! (тут я не говорю о сборке в пакет сторонних библиотек)
Зачем все это, если все модули можно так или иначе закэшировать, пользователь рано ли и поздно воспользуется блоком «ололо», мы сокращаем количество запросов до минимума и работаем с модулями в привычном и удобном для нас синхронном виде(node.js).
Это плюсы LMD по сравнению с require.js
Sign up to leave a comment.
Оптимизация JavaScript для ускорения загрузки веб-страниц