Загрузка и инициализация JavaScript

[vasachi]

Про AppCache не знал, спасибо. А статистика при его использовании какая?

[SergeiStartsev]

AppCache — это здорово, главное — не увлекаться=) Как веб-приложение может скачать в кэш 2 ГБ, а вы не заметите

[azproduction]

Это уже проблема реализации в конкретном браузере — можно же гибко модерировать квоту, спрашивая пользователя.

[1ex]

Впечатляет, спасибо. У нас проблема не стоит пока, но в будущем очень возможна )

Один момент, поправьте пожалуйста значек на значок

[serf]

Еще вариант интеллектуальной загрузки (predictive loading) или фоновой. Загрузка начинается не по требованию, а сразу после загрузки страницы. Пока модуль не загружен все возможные обращения к нему собираются в очередь. После загрузки модуля очередь исполняется и далее вызовы проходят напрямую.

[kuzemchik]

До конца не понял про LMD и require.js. Re.js генерит minified либы для проекта, LMD делает это на лету? Или что?

[azproduction]

Сборка
LMD собирает, сжимает, валидирует, stringify-ет все модули, входящие в проект(прописанные в конфиге) и создает из них 1 пакет/файл в который включает и свой оптимизированный по конфигу код. Все эти упаковки и сжатия гибко настраиваются для каждого модуля. Пакет получается таким, что наружу не видны никакие части приложения (не засоряются глобалы). Также возможны и off-package модули, которые загружаются по требованию.

Сборка на лету
При любом изменении файлов, входящих в пакет LMD его необходимо пересобрать. Это можно сделать либо руками/сервером по требованию, либо запустить LMD в режиме watch, что удобнее для разработки.

[kuzemchik]

То есть кроме как сборкой на лету от от require.js + r.js не отличается?

[azproduction]

Если бы не отличался, то в нем бы не было смысла.
1. Ленивая инициализация модулей
2. Можно не писать лишние обертки define() и тп — модули 1-в-1 Node.js
3. Максимально гибкая настройка объема lmd.js — десяток(пока) флагов в конфиге, которые включают/выключают определенные возможности — гибко меняют объем кода.
4. Кэширование модулей в localStorage, которое включается 2-3 опциями.

{   
    "cache": true
    "cache_async": true,
    "version": "1.6.7-2"
}

+index.html c кэшированием
5. Globalless
6. «Умный сборщик»

Тут я подробно описал его особенности github.com/azproduction/lmd

[kuzemchik]

ясно, спасибо, буду копать

[pxx]

AppCache это интересно, недавно изучал его. НО, заметил весьма интересный факт: ни один из сайтов, пишущих про AppCache, его не использует. Более того, я не нашел ни одного его реального использования на просторах интернетов.

[azproduction]

Mobile Twitter www.stevesouders.com/blog/2011/09/26/app-cache-localstorage-survey/ (инфа не очень свежая)

[yeremeiev]

Я встречаю периодически запрос на сохранение данных.
Но у AppCache довольно много других проблем: www.alistapart.com/articles/application-cache-is-a-douchebag/

[sunnybear]

одна из основных: в AppCache нужно перечислять все ресурсы страницы, иначе при повторном заходе неперечисленные ресурсы (например, картинки) не будут показаны. Таким образом AppCache больше подходит для веб-приложений, но никак не подходит для обычных сайтов / интернет-магазинов и т.д.

[azproduction]

NETWORK:
*

[sunnybear]

да, спасибо. Только после некоторого переосмысления у меня возник основной вопрос: а зачем нужен AppCache с усложненной логикой кэширования, если есть обычный кэш (и два механизма к нему: условное и безусловное кэширование)?

[azproduction]

Обычный — общий и поэтому может быть вытеснен любым сайтом: Expires +300years на 20Мб файл — бб кэш.

[sunnybear]

а AppCache не общий? Какие у него ограничения?

[azproduction]

В стандарте не написано, сколько должно быть и как распределяться. Есть данные за 2011 год от 5мб-Unlimited grinninggecko.com/developing-cross-platform-html5-offline-app-1/

[z6Dabrata]

В Chrome можно посмотреть все сайты, которые сохранили что-то в браузере:
chrome://appcache-internals/

[pxx]

У этого подхода, безусловно, есть один существенный минус — пользователю по клику на элемент ростера приходится ждать 4 секунды (чтобы загрузились остальные скрипты), что, конечно, не очень хорошо.

Это тоже можно оптимизировать: когда основной минимум ресурсов загрузился, можно начать асинхронно подгружать и, соответственно, кешировать скрипты, которые с большой вероятностью понадобятся в дальнейшем. Т. е. пока юзер смотрит в ростер и листает его, догружаются недостающие модули, когда он кликнет, с большой вероятностью всё уже будет готово.

[sunnybear]

288 байтов — это очень странный результат. Advanced оптимизация Google Compiler, которая ломает все обращения к зарезервированным переменным. Проверьте это, плиз.

[Quadratoff]

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

[azproduction]

А вы пользовались как пользователь и писали как писатель прежде чем советовать?
Синхронна она при инициализации in-package модулей. Для всех остальных же способов загрузки — как и все другие лоадеры асинхронно(я не псих делать синхронный XHR) Пример такого

[azproduction]

Уберу (and synchronous) из ридми, а то это сбивает с толку.

[Mithgol]

Сочинение модулей в стиле Node.js одобряю.

[ivnC]

Не хотелось бы, чтобы у читателей сложилось мнение, что $LAB не помогает в оптимизации страниц. Очевидно, для данного примера это решение бесполезно. Но в случае «обычных» сайтов бывает полезным. Понятно, что AMD более продвинутый способ для загрузки, но он требует системного подхода к созданию рабочих файлов. Для веб-приложения системный подход оправдан, для прочих сайтов — нет, имхо.

[jandosul]

Чрезвычайно полезный пост

[1ac3124]

А если использовать localStorage для серелизаии и хранения объектов, никто не пробовал?

[azproduction]

В LMD, который описан в конце этой статьи, кэширование модулей в localStorage прозрачно и включается 2-3 опциями в конфиге

{   
    "cache": true,       // включаем кэширование индексного файла
    "cache_async": true, // кэширование асинхронных модулей (с сервера)
    "version": "1.6.7-2" // версия для проверки состояния кэша
}

+кэш-лоадер вместо индексного файла

[manny]

[manny]

черт возьми. вкладкой ошибся.

[Imbolc]

А как в lmd отлаживать скомпилированный модуль?
Например, в require.js можно на локалке подключать модуль без компиляции. В browserify есть ключ --debug (сломался в 2.0, правда).
Я про то, чтобы в консоли браузера видеть реальные файл / строку.

[azproduction]

Можно собрать с SourceMap. Я дебажу без Source Map. LMD генерит предельно debugable код.

[Imbolc]

О, большое спасибо, разобрался. Немного не очевидна логика работы sourcemap + sourcemap_www + www_root. Ожидал что-то типа sourcemap_url.

[azproduction]

Дело в том, что LMD не знает ничего о вашей файловой системе, ни о wwwPath. Поэтому столько писанины, зато отличная переносимость ;-)

[asheee]

Интересно, нет ли чего-то типа Yeoman Generators для генерации базового проекта на LMD? Или чего-то типа `express .`.

[azproduction]

Нет, но можно в качестве основы взять github.com/2layer/2layer.github.io проект на Backbone+LMD с хорошим скелетом.

[asheee]

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

[azproduction]

Да, подходит. LMD использует CommonJS модули.