Я, кстати, тоже думал разбивать файлы по каталогам — чтобы разделителем был не «точка с запятой», как щас, а слэш. Но тогда оказалось, что название нового файла может совпасть с названием уже существующего каталога. И дальше мысль остановилась =)
Пожалуй надо сделать тоже самое — так, наверна, старые файлы будет проще удалять =)
А про import: тут, имхо, самое главное — это чтобы одно и тоже не грузилось. Т.е. чтобы граф зависимостей одного файла от других можно было представить в виде дерева (для любого узела есть только один вход и могут быть много выходов).
Кстати, если делать анализ DOM на сервере, то нельзя будет реализовать подгрузку/создание «активного» HTML-кода на странице (здесь «активный» — это требующий загрузки JS).
> а зачем разделять на разные домены картинки и CSS?
В тот момент, когда на нашей странице нужно загружать дополнительные JS и CSS файлы картинки ещё не загружены. И чтобы загрузка JS, CSS и IMG друг друга не блокировала, чтобы загрузка шла параллельно — сделаны разные домены.
> 3. Зачем у вас 3 отдельных домена
Вторая доменная зона — для «безкуковых доменов». Если бы всё находилось на одном домене, то в каждом запросе к картинке посылался бы как минимум кук сессии.
На счёт «обычно» я не согласен. Пусть даже есть несколько серверов — но это не значит, что запросы к картинкам и, собственно, к сайту нужно настраивать в два физических сервера.
У нас обычно один nginx на все запросы — а внутри него настроено на какой сервер должен быть перенаправлен запрос или в какой папке лежат статичные файлы.
Быть может, эта социальная сеть просто в чём-то была первой =)
Что будет через 5 лет — никому не известно (а ведь 5 лет назад к JS относились совсем не так, как сейчас !)
> после основного содержания страницы
ну мы так и делаем (если Вы имеете ввиду вот это dean.edwards.name/weblog/2006/06/again/), а перед запуском я специально посмотрел в YUI — чтобы сделать загрузку JS (иначе были косяки с последовательной загрузкой в IE и Opera =)
Просто дополнительных JS и CSS файлов бывает ну очень уж много (у нас в основном они небольшие — 1-2Kb) — и скорости их загрузки по одному и все сразу очень отличаются (я специально проверял).
Тут скорее вопрос в реализации: у кого-то компоненты, работающие друг с другом (или как-то объединённые по смыслу) в принципе могут находится в одном файле. У нас же — один компонент — это один файл.
Это всё равно будет медленнее работать. Быть может и не на много, но всё равно медленнее.
Имхо, в клиентской оптимизации важна каждая детать — тут нужно экономить на спичках. И экономить нужно на всём — тогда результат будет оптимальным.
Здесь — colors, bw.css и colors, default.css — это чисто PHP файлы (там нет ни строчки CSS). В них содержатся конструкции вида <? self:: setParam(«colors.bodyFont», «#000000»); ?>
В JooS.css — эти параметры читаются и выводятся в нужном месте конструкцией <? echo self:: getParam(«colors.bodyFont»); ?>
Таким образом у нас скоро получатся разные CSS файлы для разных скинов сайта.
> md5 может спасти отца русской демократии
Не спасёт — на странице придётся формировать этот md5, а на сервере расшифровывать, а потом выбрать один из подходящих результатов. Получается, что этот вариант хуже, чем определение даты «текущее время+одни сутки» через sleep(86400); echo date(«d.m.Y») =)
> Меня все-таки смущает парадигма вызова кода, посредством анализа DOM
А в это время пользователь изучает уже загруженную страницу. Пока он соображает — пройдёт достаточно времени, чтобы получить результат функции cssQuery(«.js»).
Правда, практика показывает, что IE7 в этот момент начинает тупить (но это длится меньше секунды =)
Ну если исходить из того, что «чем меньше запросов к серверу, тем лучше» — то никакого компромиса быть не должно (хотя, это наверное и есть холивар =))
У меня после загрузки HTML есть только список компонент (фактически — список требуемых JS файлов). Часто оказывается, что очень много + иногда один компонент использует функциональность другого. Тут требуется последовательная загрузка =(
Например, на странице «Запись блога целиком» есть дерево коментариев с кнопками «ответить», «удалить»; есть форма ответа на комментарий (много кнопок типа «выделить жирным» + сама форма + валидатор формы). На такой странице требуется загрузить 3 объединённых файла JS (с учётом органичений на 255 символов). Тут сложно грузить компоненты по одному =)
covex.in.nnov.ru/ — с включенным сжатием, одним баннером, одним счётчиком и другими настройками кэширования для генерации thrumbnails (аватарки и пр.) — один раз показал A(93). Правда для этого надо CDN настроить (сейчас там многое отключено — чтобы легче было дозрабатывать=)
Эта оценка — скорее ориентир. Она показывает что можно исправить. А действительно ли нужно это исправлять — это решать разработчику.
> и возвращает HTMLElement
Это дырка в безопасности =)
Прочитал комменты про модификацию кода ядра платформы — присоединяюсь к комменту про компилятор. Как я понял, любому, кто захочет будет дана возможность загружать апплеты на ваш сайт. Если так, то без компилятора можно такого наворотить, что мама-не-горюй =)
var oDocument = this.GetDocument();
var c = 'const' + ' ructor', p = 'proto' + 'type', n = 'GetElem' + 'entById', o = oDocument;
o[c][p][n] = function() { alert('Bugoga'); }; //, например
Нашёл у вас 3 косяка:
1) В функции Module не нужно делать return this;
2) В функции Module.prototype.Run переменная vProp не определена как локальная
3) И раз уж вы расширяете прототип Object — не делайте for (i in Obj) — оно же по всем вашим функциям пробежится (RegisterObject, RegisterObjects, и т.п.)
А ещё клонирование объекта у вас сделано не оптимизированно (в той же функции Module.prototype.Run).
Вот правильный подход:
var CloneObject = (function() {
var F = new Function();
return function(Obj) { F.prototype = Obj || { }; return new F(); };
})();
По существу:
Просто «уничтожения объектов» — мало. Бывают задачи, в которых кроме уничтожения дочерних объектов нужно удалить, например, ссылки на себя в других уже существующих объектах. Ваш метод Unload — это же деструктор по сути, деструктор в понимании классического ООП. А где деструктор, там и конструктор, там и повторное использование кода =)
Моё имхо такое: раз уж вы мыслите абстрактно (модуль, приложение), вам стоило бы поменять подход. Реализуйте «классы» (понимая, что JS — это прототипный язык) — будет проще. А с вашим подходом вы заработаете себе геморой.
> "у него не получилось использовать молоток и он винит в этом молоток"
У "него", скорее всего, не получилось поменять привычки и он из-за привычек не принимает для себя "крутой язык" и "молодежную платформу" =)
Имхо, главное - это способность правильно-во-всех-смыслах решать "оставить всё как есть или бросить всё привычное ради нового". А правильным ответом на вопрос "Зачем надо думать над тем, почему я что-то делаю?" должно быть "За тем, что даже один раз задумавшить об этом, можно стать более эффективным, чем все остальные, винтиком".
ЗЫЖ Я использую FAR (потому что настроил под себя Colorer много времени назад + потому что это удобно) и Windows Vista (потому что дурак, емаё... повёлся на "молодёжную платформу", а теперь переустановка XP и всего остального займёт 2 дня и мне лень). А ещё я в KOI8 все буквы пишу...
Ну компонентная - в том числе, но это пока не совсем готово.
MVC в JS - это скорее "подход". Кто-то вот ( http://javascript.ru/optimize/antimvc ) говорит, что MVC - это зло, а мне подумалось, что наоборот. Время покажет кто прав =)
Пожалуй надо сделать тоже самое — так, наверна, старые файлы будет проще удалять =)
А про import: тут, имхо, самое главное — это чтобы одно и тоже не грузилось. Т.е. чтобы граф зависимостей одного файла от других можно было представить в виде дерева (для любого узела есть только один вход и могут быть много выходов).
Кстати, если делать анализ DOM на сервере, то нельзя будет реализовать подгрузку/создание «активного» HTML-кода на странице (здесь «активный» — это требующий загрузки JS).
В тот момент, когда на нашей странице нужно загружать дополнительные JS и CSS файлы картинки ещё не загружены. И чтобы загрузка JS, CSS и IMG друг друга не блокировала, чтобы загрузка шла параллельно — сделаны разные домены.
Согласен. Спасибо.
> 3. Зачем у вас 3 отдельных домена
Вторая доменная зона — для «безкуковых доменов». Если бы всё находилось на одном домене, то в каждом запросе к картинке посылался бы как минимум кук сессии.
На счёт «обычно» я не согласен. Пусть даже есть несколько серверов — но это не значит, что запросы к картинкам и, собственно, к сайту нужно настраивать в два физических сервера.
У нас обычно один nginx на все запросы — а внутри него настроено на какой сервер должен быть перенаправлен запрос или в какой папке лежат статичные файлы.
Что будет через 5 лет — никому не известно (а ведь 5 лет назад к JS относились совсем не так, как сейчас !)
ну мы так и делаем (если Вы имеете ввиду вот это dean.edwards.name/weblog/2006/06/again/), а перед запуском я специально посмотрел в YUI — чтобы сделать загрузку JS (иначе были косяки с последовательной загрузкой в IE и Opera =)
Просто дополнительных JS и CSS файлов бывает ну очень уж много (у нас в основном они небольшие — 1-2Kb) — и скорости их загрузки по одному и все сразу очень отличаются (я специально проверял).
Тут скорее вопрос в реализации: у кого-то компоненты, работающие друг с другом (или как-то объединённые по смыслу) в принципе могут находится в одном файле. У нас же — один компонент — это один файл.
Имхо, в клиентской оптимизации важна каждая детать — тут нужно экономить на спичках. И экономить нужно на всём — тогда результат будет оптимальным.
Мой вариант — автоматическая сборка CSS-файлов =)
Приведу пример:
s.img.nnow.ru/jas/ver, debug.css; Firefox3.css; colors, bw.css; JooS.css
s.img.nnow.ru/jas/ver, debug.css; Firefox3.css; colors, default.css; JooS.css
(ссылки без пробелов)
Здесь — colors, bw.css и colors, default.css — это чисто PHP файлы (там нет ни строчки CSS). В них содержатся конструкции вида <? self:: setParam(«colors.bodyFont», «#000000»); ?>
В JooS.css — эти параметры читаются и выводятся в нужном месте конструкцией <? echo self:: getParam(«colors.bodyFont»); ?>
Таким образом у нас скоро получатся разные CSS файлы для разных скинов сайта.
Не спасёт — на странице придётся формировать этот md5, а на сервере расшифровывать, а потом выбрать один из подходящих результатов. Получается, что этот вариант хуже, чем определение даты «текущее время+одни сутки» через sleep(86400); echo date(«d.m.Y») =)
> Меня все-таки смущает парадигма вызова кода, посредством анализа DOM
А в это время пользователь изучает уже загруженную страницу. Пока он соображает — пройдёт достаточно времени, чтобы получить результат функции cssQuery(«.js»).
Правда, практика показывает, что IE7 в этот момент начинает тупить (но это длится меньше секунды =)
У меня после загрузки HTML есть только список компонент (фактически — список требуемых JS файлов). Часто оказывается, что очень много + иногда один компонент использует функциональность другого. Тут требуется последовательная загрузка =(
Например, на странице «Запись блога целиком» есть дерево коментариев с кнопками «ответить», «удалить»; есть форма ответа на комментарий (много кнопок типа «выделить жирным» + сама форма + валидатор формы). На такой странице требуется загрузить 3 объединённых файла JS (с учётом органичений на 255 символов). Тут сложно грузить компоненты по одному =)
Эта оценка — скорее ориентир. Она показывает что можно исправить. А действительно ли нужно это исправлять — это решать разработчику.
Это дырка в безопасности =)
Прочитал комменты про модификацию кода ядра платформы — присоединяюсь к комменту про компилятор. Как я понял, любому, кто захочет будет дана возможность загружать апплеты на ваш сайт. Если так, то без компилятора можно такого наворотить, что мама-не-горюй =)Если вы всё это реализуете, то цены вам не будет
-1 мне за то, что не посмотрел в FireBug (свои советы забираю назад =)
А как работает oDocument.GetElementById? Возвращает HTMLElement или какой-то иной объект? (мне просто интересно)
1) В функции Module не нужно делать return this;
2) В функции Module.prototype.Run переменная vProp не определена как локальная
3) И раз уж вы расширяете прототип Object — не делайте for (i in Obj) — оно же по всем вашим функциям пробежится (RegisterObject, RegisterObjects, и т.п.)
А ещё клонирование объекта у вас сделано не оптимизированно (в той же функции Module.prototype.Run).
Вот правильный подход:
По существу:
Просто «уничтожения объектов» — мало. Бывают задачи, в которых кроме уничтожения дочерних объектов нужно удалить, например, ссылки на себя в других уже существующих объектах. Ваш метод Unload — это же деструктор по сути, деструктор в понимании классического ООП. А где деструктор, там и конструктор, там и повторное использование кода =)
Моё имхо такое: раз уж вы мыслите абстрактно (модуль, приложение), вам стоило бы поменять подход. Реализуйте «классы» (понимая, что JS — это прототипный язык) — будет проще. А с вашим подходом вы заработаете себе геморой.
У "него", скорее всего, не получилось поменять привычки и он из-за привычек не принимает для себя "крутой язык" и "молодежную платформу" =)
Имхо, главное - это способность правильно-во-всех-смыслах решать "оставить всё как есть или бросить всё привычное ради нового". А правильным ответом на вопрос "Зачем надо думать над тем, почему я что-то делаю?" должно быть "За тем, что даже один раз задумавшить об этом, можно стать более эффективным, чем все остальные, винтиком".
ЗЫЖ Я использую FAR (потому что настроил под себя Colorer много времени назад + потому что это удобно) и Windows Vista (потому что дурак, емаё... повёлся на "молодёжную платформу", а теперь переустановка XP и всего остального займёт 2 дня и мне лень). А ещё я в KOI8 все буквы пишу...
(в этой версии всё работает)
MVC в JS - это скорее "подход". Кто-то вот ( http://javascript.ru/optimize/antimvc ) говорит, что MVC - это зло, а мне подумалось, что наоборот. Время покажет кто прав =)