Я исходил от другого. У Python и JavaScript немного разное положение:
Python — серверный язык. Как я понял — он возник после PHP, Perl и всего такого — не нужен он дизайнерам и оформителям интерфейсов. Изучать его будут люди, знающие другие языки программирования (начинающие — не в счёт =)
JavaScript — язык браузера… Перед написанием придумал аргумент: «Вот, глянте ка, на компани.яндекс.ру в вакансиях только разработчик интерфейсов есть» (а там ещё аж 2 вакансии — JS и JS-гуру =). Пойду с другой стороны.
Кроме него ничего нет. Даже его нет — есть jQuery и т.п. Всеобщий накопленный багаж знаний о языке позволяет либо делать какие-нибудь поделки, например через onmouseover и onmouseout менять картинку; либо делать простые вещи используя простой фреймвёрк. Это может сделать любой. Непрограммист, желая войти на рынок труда в качестве «разработчика интерфейсов», легко в него войдёт. Программист же не захочет, потому что если не копать глубже — это «не язык, а лажа какая-то» (я так не думаю, — Прим.ред.).
Вобщем, естественный отбор, эволюция и всё такое =)
> не особо важно, что будет завтра-послезатра
>… я буду десять раз грузить одни и те же скрипты.
>… микрооптимизация… гроша выеденого не стоит
Ладно! =)
Рассмотрим пользователя, который в самый первый раз зайдёт на страницу.
Этот пользователь, по-любому, идёт на страницу не за контролами, ни в какое в избранное он добавлять ничего не будет, не будет нажимать на регистрацию, не будет комментировать. Не будет до тех пор, пока не поймёт: стоящая ли страница и весь остальной сайт или нет. Это всё потому, что он идёт на сайт за информацией. Если информация — текст, то он его получит быстро и начнёт читать и соображать. Если информация картинка или видео — то он дождётся загрузки. В это время всё загрузится и контролы будут работать.
Если человек вдруг сделает второй клик, то на следующей странице он должен будет загрузить: (1) html, (2) сгенерённые картинки-превьюшки, (3) баннеры, (4) 3-4 js-файла с компонентами, если страница не будет аналогичной первой (остальное — в кэше). Вторая страница покажется пользователю ещё более быстрой, он будет рад и счастлив. В этом случае задержка в работе контролов на долю секунды будет платой за счастье пользователя.
Рассмотрим постоянного пользователя с кэшем.
У этого чела есть все файлы в кэше. Для каждой новой страницы ему нужно будет догрузить только (1) html, (2) баннеры. Этот чел счастлив от того, что остался на сайте =)
Рассмотрим постоянного пользователя без кэша.
Да, этот пользователь может резко нажать мышкой на «добавить в избранное» в середине страницы. Но этот человек — явно либо псих, либо проверяет реализацию догрузки JS-файлов для компонент. Такие люди явно не считаются (хотя я тут могу ошибаться =) Я всё же думаю, что таких людей — единицы из тысячи — можно пренебречь (тут тоже возможна ошибка)
По поводу «хаотичной функциональности»: я не вижу тут никакой проблемы (я не вруЪ). Это вполне решаемая задача! В представленном мной примере эта задача не решалась (не было такой цели).
По поводу расчётов про «пинг», «объём», «всё такое»: судя по всему расчёт вёлся от момента начала загрузки страницы до надписи «Готово» в левом нижнем углу браузера. Я же твёрдо убеждён в том, что нужно делить этот промежуток времени на два: от начала до отображения контента и от отображения контента до «готово». Фактически у нас разные критерии правильности и разные формулы. Т.е. наши оценки скорости нельзя сравнивать: кто-то из нас неправ и третьего не дано =)
Про ленивую загрузку: вот ссылка dojotoolkit.org/demos/fisheye-demo
Это очень здорово работает, когда я первый раз это увидел, я был поражён возможностями dojo. Но по скорости загрузки — это Жесть, а не страница =)
> объединять js и css — это, конечно, изврат
Тут я почти согласен. У меня это всё автоматом собирается из тучи мелких файлов. Это не напрягает разработчика, делает быстрее загрузку, радует пользователя. Все счастливы, вобщем. А загружать все стили сразу — тоже вроде как нехорошо: не на всех страницах оно может потребоваться…
> слева — несколько текстарий, а справа — панель инструментов, работающая с текущей текстарией.
А, ну это да. Я видимо, не привык к таким интерфейсам )
> 2-3 скрипта по 20кб сидящих в кэше достаточно для комфортного сёрфинга по сайту
По статистике завтра-послезавтра этих скриптов всё равно уже не будет в кэше (Yahoo не даст соврать — я только ссылку на исследование потерял =( Так что кэш — не аргумент.
> дополнительного лага между появлением страницы и активацией компонент
Про лаг согласен, но только от части: этого лага заметно не будет! человек быстро получит страницу, сразу же начнёт интересоваться и читать сайт, а к тому времени как он опомнится — все компоненты будут инициализированны.
> как избежать
Если очень хочется, чтобы непроинициализированный контрол выглядел не так как проинициализиварованный, можно загружать JS и CSS в одном файле. Вот пример: beatle.joos.nnov.ru/jas/Beatle, cHabr, List, Holder.js/ — это компонента-«корневой DIV списка из текста статьи».
> jsx.ru
Это, на самом деле, оригинал идеи (я ссылку на него ставил в пред.статье). У меня другая реализация + оптимизация Client-Side
Кстати, без объединения файлов там загружается аж 17 js-файлов. У меня — 3.
> не работает, ибо вёрстка бывает весьма разная
В этом случае события будут бегать через body, либо верстальщик будет аннигилирован.
Я всё же считаю, что это не нормально: вёрстка должна быть правильной, оформление — функциональным, а работа команды — эффективной. Так должно быть. Или вы считаете, что в общем случае Web-разработчики верстают «не правильно»?
> и действительно, что за херня?
Это гораздо лучше, чем ситуация в которой контент начинает показываться только после загрузки десятка JS файлов с общим весом килобайт в 200, потом после загрузки страницы должны загрузится ещё десять js-файлов.
Если страницу правильно соптимизировать, то недостатки, которые вы указали, совершенно не заметны + к тому описанную вами ситуацию с контролом можно избежать.
Как я понимаю, у меня не Посредник и не Наблюдатель, а Наблюдатель — это тот же посредник, только никто не знает про диспетчера (а он есть (с) =)
Мои Диспетчеры хоть и знают о существовании зарегистрированных у них компонент, но от разработчика это скрыто: есть только функции «зарегистрироваться» и «разрегистрироваться».
С другой стороны — иногда (ну очень редко) действительно нужно вводить лишний бесполезный класс Диспетчера только для диспетчеризации. Но гораздо чаще Диспетчер хранит какие-то данные, распределяет их по требованию или отправляет результат работы дочерних компонент куда-нибудь во вне. + К тому, у меня заложено, что если не указывать класс родительской компоненты, то событие побежит через дефолтный диспетчер — а фактически это и есть Наблюдатель.
> что усложняет замену конкретной реализации компонента системы
Системе пока 3 месяца, пока никого не напрягает, всё работает… но с другой стороны до замены чего-нибудь на другое пока не дошло… Посмотрим что будет. Хотя с третьей стороны — если что-то поменяется, то поменяется и HTML и CSS — а значит, что вероятность замены функционала всё равно очень велика…
Этот смысл многие не видят =( На самом деле тут всё зависит от задачи. У меня задача была — появился механизм, а потом — понеслось…
А в остальном — согласен.
У меня понимание языка и реализация классов шли нога в ногу =)
Я как-то нашёл одну замечательную фразу:
Язык, как средство выражения мыслей, и мышление, как процесс производства мыслей, теснейшим образом взаимосвязаны и взаимообусловлены. Взаимозависимость языка и мышления проявляется, упрощенно говоря, в том, что мысли отливаются в формы, удобные для их выражения средствами языка, а язык устроен таким образом, чтобы наиболее адекватно отражать сформировавшиеся мысли.
Короче говоря, я хочу называть эту надстройку «реализацией классов», потому что мне удобно «думать классами» =)
Это потому, что необходимо иметь несколько Диспетчеров.
Пример: кнопки оформления над textarea — они бросают одно и тоже событие «обрамитьТэгомВыделенныйТекст_вTextarea». На странице может быть несколько textarea (и несколько форм). Посредник позволяет направить событие в нужную textarea, а Наблюдатель потребует передачи ещё каких-нибудь параметров.
Удобно — это «на вкус, на цвет товарища нет» =)
Лично мне удобно иметь функцию «расширения прототипа», удобно иметь функцию, настраивающую «мои виртуальные методы», удобно называть некоторые функции — «Классами», удобно писать вызов функции родительского класса не указывая имя этого класса и не писать при этом конструкции вида parentClassName.prototype.myMethod.call(this, param1)
> var ExcavationRobot = new GenericRobot();
В этой конструкции не хватает как минимум кода инициализации объекта.
А я и использую «прототипное наследование» (в основном).
А использовать «чистое прототипное наследование» мешает отсутствие читаемого и удобного метода повторного использования кода.
А мы не ставим Гугл.Аналитикс только из-за того, что там происходит загрузка JS из чёрти-от-куда (я что-то даже и не подумал, что там доп.картинка загружается).
Теперь есть повод присмотреться к Г.А. повнимательнее, а заодно и Лирушный счётчик переделать =)
Ну ещё можно дописать else document_write.call(document, s_code); (на всякий пожарный =)
Как я понимаю, все эти манипуляции со счётчиками придуманы для (1) отложенной загрузки картинкок-счётчиков, чтобы дать быстрее загрузиться «родной» статике; (2) избавления от дополнительных внешних JS-файлов; (3) избавления от document.write.
Поэтому только подмена document.write может и не помочь оптимизации.
С другой стороны, отложенная загрузка счётчиков сделает статистику менее точной… Вобщем нужен какой-то компромис.
Python — серверный язык. Как я понял — он возник после PHP, Perl и всего такого — не нужен он дизайнерам и оформителям интерфейсов. Изучать его будут люди, знающие другие языки программирования (начинающие — не в счёт =)
JavaScript — язык браузера… Перед написанием придумал аргумент: «Вот, глянте ка, на компани.яндекс.ру в вакансиях только разработчик интерфейсов есть» (а там ещё аж 2 вакансии — JS и JS-гуру =). Пойду с другой стороны.
Кроме него ничего нет. Даже его нет — есть jQuery и т.п. Всеобщий накопленный багаж знаний о языке позволяет либо делать какие-нибудь поделки, например через onmouseover и onmouseout менять картинку; либо делать простые вещи используя простой фреймвёрк. Это может сделать любой. Непрограммист, желая войти на рынок труда в качестве «разработчика интерфейсов», легко в него войдёт. Программист же не захочет, потому что если не копать глубже — это «не язык, а лажа какая-то» (я так не думаю, — Прим.ред.).
Вобщем, естественный отбор, эволюция и всё такое =)
что верно, то верно — вместе с JS придётся передавать и CSS и HTML (иначе ничего работать не будет =(
А что касается второго абзаца: я бы заменил слово «должен знать» на «может знать» — ведь, это просто другой алгоритм реализации того же самого и всё.
>… я буду десять раз грузить одни и те же скрипты.
>… микрооптимизация… гроша выеденого не стоит
Ладно! =)
Рассмотрим пользователя, который в самый первый раз зайдёт на страницу.
Этот пользователь, по-любому, идёт на страницу не за контролами, ни в какое в избранное он добавлять ничего не будет, не будет нажимать на регистрацию, не будет комментировать. Не будет до тех пор, пока не поймёт: стоящая ли страница и весь остальной сайт или нет. Это всё потому, что он идёт на сайт за информацией. Если информация — текст, то он его получит быстро и начнёт читать и соображать. Если информация картинка или видео — то он дождётся загрузки. В это время всё загрузится и контролы будут работать.
Если человек вдруг сделает второй клик, то на следующей странице он должен будет загрузить: (1) html, (2) сгенерённые картинки-превьюшки, (3) баннеры, (4) 3-4 js-файла с компонентами, если страница не будет аналогичной первой (остальное — в кэше). Вторая страница покажется пользователю ещё более быстрой, он будет рад и счастлив. В этом случае задержка в работе контролов на долю секунды будет платой за счастье пользователя.
Рассмотрим постоянного пользователя с кэшем.
У этого чела есть все файлы в кэше. Для каждой новой страницы ему нужно будет догрузить только (1) html, (2) баннеры. Этот чел счастлив от того, что остался на сайте =)
Рассмотрим постоянного пользователя без кэша.
Да, этот пользователь может резко нажать мышкой на «добавить в избранное» в середине страницы. Но этот человек — явно либо псих, либо проверяет реализацию догрузки JS-файлов для компонент. Такие люди явно не считаются (хотя я тут могу ошибаться =) Я всё же думаю, что таких людей — единицы из тысячи — можно пренебречь (тут тоже возможна ошибка)
По поводу «хаотичной функциональности»: я не вижу тут никакой проблемы (я не вруЪ). Это вполне решаемая задача! В представленном мной примере эта задача не решалась (не было такой цели).
По поводу расчётов про «пинг», «объём», «всё такое»: судя по всему расчёт вёлся от момента начала загрузки страницы до надписи «Готово» в левом нижнем углу браузера. Я же твёрдо убеждён в том, что нужно делить этот промежуток времени на два: от начала до отображения контента и от отображения контента до «готово». Фактически у нас разные критерии правильности и разные формулы. Т.е. наши оценки скорости нельзя сравнивать: кто-то из нас неправ и третьего не дано =)
Про ленивую загрузку: вот ссылка dojotoolkit.org/demos/fisheye-demo
Это очень здорово работает, когда я первый раз это увидел, я был поражён возможностями dojo. Но по скорости загрузки — это Жесть, а не страница =)
> объединять js и css — это, конечно, изврат
Тут я почти согласен. У меня это всё автоматом собирается из тучи мелких файлов. Это не напрягает разработчика, делает быстрее загрузку, радует пользователя. Все счастливы, вобщем. А загружать все стили сразу — тоже вроде как нехорошо: не на всех страницах оно может потребоваться…
Вот — правильная ссылка на «Пример»: http://beatle.joos.nnov.ru/jas/Beatle, cHabr, List, Holder.js/
А, ну это да. Я видимо, не привык к таким интерфейсам )
> 2-3 скрипта по 20кб сидящих в кэше достаточно для комфортного сёрфинга по сайту
По статистике завтра-послезавтра этих скриптов всё равно уже не будет в кэше (Yahoo не даст соврать — я только ссылку на исследование потерял =( Так что кэш — не аргумент.
> дополнительного лага между появлением страницы и активацией компонент
Про лаг согласен, но только от части: этого лага заметно не будет! человек быстро получит страницу, сразу же начнёт интересоваться и читать сайт, а к тому времени как он опомнится — все компоненты будут инициализированны.
Про это и про «как соптимизировать» я целый талмуд написал: habrahabr.ru/blogs/client_side_optimization/38299/
> как избежать
Если очень хочется, чтобы непроинициализированный контрол выглядел не так как проинициализиварованный, можно загружать JS и CSS в одном файле. Вот пример: beatle.joos.nnov.ru/jas/Beatle, cHabr, List, Holder.js/ — это компонента-«корневой DIV списка из текста статьи».
> jsx.ru
Это, на самом деле, оригинал идеи (я ссылку на него ставил в пред.статье). У меня другая реализация + оптимизация Client-Side
Кстати, без объединения файлов там загружается аж 17 js-файлов. У меня — 3.
Может быть JS стал бы в языком программистов, не для разработчиков интерфейсов и дизайнеров…
В этом случае события будут бегать через body, либо верстальщик будет аннигилирован.
Я всё же считаю, что это не нормально: вёрстка должна быть правильной, оформление — функциональным, а работа команды — эффективной. Так должно быть. Или вы считаете, что в общем случае Web-разработчики верстают «не правильно»?
> и действительно, что за херня?
Это гораздо лучше, чем ситуация в которой контент начинает показываться только после загрузки десятка JS файлов с общим весом килобайт в 200, потом после загрузки страницы должны загрузится ещё десять js-файлов.
Если страницу правильно соптимизировать, то недостатки, которые вы указали, совершенно не заметны + к тому описанную вами ситуацию с контролом можно избежать.
Мои Диспетчеры хоть и знают о существовании зарегистрированных у них компонент, но от разработчика это скрыто: есть только функции «зарегистрироваться» и «разрегистрироваться».
С другой стороны — иногда (ну очень редко) действительно нужно вводить лишний бесполезный класс Диспетчера только для диспетчеризации. Но гораздо чаще Диспетчер хранит какие-то данные, распределяет их по требованию или отправляет результат работы дочерних компонент куда-нибудь во вне. + К тому, у меня заложено, что если не указывать класс родительской компоненты, то событие побежит через дефолтный диспетчер — а фактически это и есть Наблюдатель.
> что усложняет замену конкретной реализации компонента системы
Системе пока 3 месяца, пока никого не напрягает, всё работает… но с другой стороны до замены чего-нибудь на другое пока не дошло… Посмотрим что будет. Хотя с третьей стороны — если что-то поменяется, то поменяется и HTML и CSS — а значит, что вероятность замены функционала всё равно очень велика…
А в остальном — согласен.
Я как-то нашёл одну замечательную фразу:Короче говоря, я хочу называть эту надстройку «реализацией классов», потому что мне удобно «думать классами» =)
Пример: кнопки оформления над textarea — они бросают одно и тоже событие «обрамитьТэгомВыделенныйТекст_вTextarea». На странице может быть несколько textarea (и несколько форм). Посредник позволяет направить событие в нужную textarea, а Наблюдатель потребует передачи ещё каких-нибудь параметров.
Если честно, я узнал про эти паттерны уже после реализации, когда писал статью (вот тут: www.artlebedev.ru/tools/technogrette/js/observable/ =)
Лично мне удобно иметь функцию «расширения прототипа», удобно иметь функцию, настраивающую «мои виртуальные методы», удобно называть некоторые функции — «Классами», удобно писать вызов функции родительского класса не указывая имя этого класса и не писать при этом конструкции вида parentClassName.prototype.myMethod.call(this, param1)
> var ExcavationRobot = new GenericRobot();
В этой конструкции не хватает как минимум кода инициализации объекта.
А использовать «чистое прототипное наследование» мешает отсутствие читаемого и удобного метода повторного использования кода.
А у вас есть ссылка, чтобы почитать про это?
Теперь есть повод присмотреться к Г.А. повнимательнее, а заодно и Лирушный счётчик переделать =)
else document_write.call(document, s_code);(на всякий пожарный =)Как я понимаю, все эти манипуляции со счётчиками придуманы для (1) отложенной загрузки картинкок-счётчиков, чтобы дать быстрее загрузиться «родной» статике; (2) избавления от дополнительных внешних JS-файлов; (3) избавления от document.write.
Поэтому только подмена document.write может и не помочь оптимизации.
С другой стороны, отложенная загрузка счётчиков сделает статистику менее точной… Вобщем нужен какой-то компромис.