да… дизайн и внешне паршивенько выглядит и юзабельность в минусе. то тут то там вылезет ничем не обоснованный скроллинг, нету instantApply и вообще настройки неудобные.
особенно порадовал «яндексовый футер» который тут прилеплен как телеге пятая нога.
а в коде… было 90кб скриптов, стало больше 600кб
раньше всё живенько применялось налету, ресайзилось и тп, а теперь при ресайзе происходит моргание да ещё и с задержкой. и так все перерисовки.
1. структура файлов хаотичная. логику создания директорий так и не уловил.
2. накладывание трансформация кучи маленьких xml, и склеивание их вместе через промежуточную сериализацию в html — это медленно, не удобно и попросту багоёмко. нормальная практика — сформировать 1 xml, потом его трансформировать за один запуск xslt.
3. именованные шаблоны нельзя перегружать. какой смысл использовать xslt и не использовать его основную фишку — выбор шаблона на основе данных?
4. вместо «справочника» надо использовать ключи. они именно для этого и предназначены и именно для этого оптимизированы.
5. огульное использование disable-output-escaping — потенциальная дырень в безопасности. использовать его нужно там, где без него никак. в данном же случае он нахрен не нужен.
по обсуждению
1. развели флейма как вставить скрипты в html. считайте, что xslt — это перила, которые не дают вам упасть в говнокод.
2. xslt конечно громоздок. и все это понимают. но альтернатив-то особо и нет. если это так уж сильно напрягает — могу выложить доведённую до ума вот эту либу: www.php.ru/forum/viewtopic.php?f=27&t=27236
все языки в чём-то кривоваты. что теперь, не программировать вовсе?) а писать статьи можно лишь об идеальных языках?
дизайн в этом месте и правда крив — вынуждает использовать хаки на ровном месте. ну вот какого лешего this начинает указывать в стратосферу, когда можно «по умолчанию» подставлять объект в контексте которого эта функция была создана?
оверхед — это 100500 хттп запросов и как следствие лишние задержки. а кеширование в ls — ещё один костыль, не добавляющий ни надежности ни поддерживаемости.
тут нужно наследование локалей. и не через какой-то там сервис, а прямо тут, при разработке. и не конфигов, а самих локализованных строк. или строки у тебя в конфигах? для каждого модуля?
для jit функции и сами прогреются когда надо будет. на то он и jit. ускорять работу одной фичи путём торможения работы всего браузера — не самая светлая идея. если все будут считать себя пупами земли и прогревать себя при старте — браузер будет стартовать как старичок нетскейп. ну или тупить первую минуту, как винда.
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.
говоря простым языком: ресурс — это абстракция, которая может быть доступна по разных ссылкам в зависимости от требуемых соглашений приёма и передачи данных.
далее, совершенно не важно в какой стпени в каких спеках описано кэширование. да хоть оно вообще нигде не было бы описано — совершенно не важно. важно то, что введение ограничения «немодифицирующие запросы, надо помечать специальным словом GET или HEAD, если BODY не нужен» введено ИСКЛЮЧИТЕЛЬНО для того, чтобы можно было легко и быстро определять что можно кэшировать, а что не стоит. если бы не эта причина, формулировка была бы куда проще: get — просто получение данных, будь там хоть рандомайзер.
а при чём тут бд? допустим я хочу сделать обновление ресурсов сайта посредством посылки архива с исходниками на определённый ресурс. посылаю на один — изменяются многие другие. в вебе это повсеместное явление. или мисье теоретик?)
не хочу я чтобы рсс читался у меня спрашивала не только ссылку на поток, но и список необходимых заголовков, чтобы получить именно поток, а не хтмл страницу. и не надо говорить про стандартизацию, с ней всё очень плохо в современном вебе.
это ты путаешь курицу и яичницу) семантика GETкак раз и введена для того, чтобы можно было кэшировать ответ сервера, а не ломиться на него каждый раз. а CRUD — это вообще о другом. CRUD — абстракция над реляционной моделью, которая сильно проще сетевой. в частности, не хватает таких методов как HEAD, MOVE, COPY, LINK и других.
это только в сферическом вакууме возможен прямой маппинг ресурсов на модели с указанием отображения в заголовках. но эта абстракция сразу начинает течь, попав в реальный мир:
1. отсылка одной формы должна быть произведена за один запрос к одному ресурсу, а не за десять к десяти, не смотря на то, что фактически она изменяет не один ресурс, а десять.
2. нужно предоставлять пользователю возможность получать данные в разных представлениях. требовать от браузера поддержки всех возможных на всех сайтах видов представлений — наивно и глупо. например, диаграмма может быть представлена в виде разноцветного отрезка (нужно указать ещё и его длину), может ввиде круга (нужно указать диаметр или габариты), а может ввиде цилиндра (тут надо указать углы поворота в 3д, степень удаления и габариты области просмотра). а задачей content negotiation является обеспечение доступности, а не предоставление выбора. в примере с диаграммами — для цилиндра выбор между jpeg растром и vrml моделью. но как ты заметил, современные html технологии плохо для этого предназначены.
1. для получения данных нужно использовать GET, а не POST, но не потому что CRUD, REST или ещё какая аббревиатура, а потому что кэширование. советую почитать про заголовок Cache-Control. При этом урл является ключём кэша.
2. параметр в урле лучше, чем просто http-заголовок. потому что ответы сервера разные. а урл является ключём кэша. как вариант можно в ответе прописать «Vary: X-Rrequested-With», чтобы этот заголовок тоже попал в ключ, но зачем, если есть возможность изменить сам урл? ещё и в логах сервера аяксовые и обычные запросы будут отличаться урлами, и не надо будет шаманить с добавлением заголовка и туда.
3. аякс многие справедливо недолюбливают потому что это велосипед окружённый костылями: для истории, для роботов, для кеширования, для уведомления о прогрессе загрузки, для вывода ошибок загрузки, для повторной отправки пропавшего в дебрях gprs запроса, для отображения загруженной части большого контента. и всё это для того, чтобы криво написанный сайт не так сильно тормозил.
4. добиться высокой скорости можно гораздо более простыми и стандартными способами. освойте http-кеширование и грузите по отдельности те данные, что имеют разную степень актуальности. например, навигацию(если она большая конечно) нужно грузить отдельно от содержимого страницы. и не нужно никаких костылей.
в том-то и дело, что ленивая нужна загрузка не модулей, а пакетов. иначе будет 100500 запросов.
> Пример абстракции над файловой системой
а, пример определения модуля i18n как алиаса на один из конкретных файлов? а что делать в случае, когда в какой-нибудь турецкой локали не хватает нужных строк? тут нужно не просто «всё решать одной абстракцией» — тут надо парсить локали и собирать сборную солянку. либо громко ругаться, что не хватает переводов. но уж точно не просто заменять один файлик на другой.
> Недавно буквально наткнулись на такую проблему (плагины для браузра) без ленивой загрузки и без прогретого JIT он стартует 150 мс (ну очень тяжелый), а с ленивой загрузкой 20мс
я.бар?) ну, вообще говоря, да, специфика плагинов в том, что подгрузка модулей из памяти не даёт такого пенальти, как подгрузка с сервера, зато есть куча левого функционала, который практически не используется. поэтому для мозиллы, например, я написал клёвый ленивый загрузчик (https://github.com/nin-jin/fenix-snippet#%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8F%D1%80%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F) — кстати, хороший пример, ленивой загрузки и изоляции модулей, оставаясь при этом в рамках PMS. правда ценой типовой шапки из нескольких строк: подключение загрузчика и подключение каждого необходимого пакета, модули из которых грузятся уже лениво.
> Консультировал по оптимизации визуальных закладок 2,0.
под какой браузер? и какие выводы?
> особенность архитектуры, часто не мы решаем какая она должна быть (адрес бэкнда другой у дева и продакшена)
и всё же, ошибки в архитектуре тоже надо исправлять, иначе есть риск погрязнуть в костылях.
> Что-то у нас тред разросся :) Понаписали уже больше чем в статье.
автор нас наверно уже проклял, сглазил и навёл порчу х)
> У тебя архитектура предполагает факт того, что логика приложения может динамически расширятся?
сама по себе? нет) вся логика должна быть задекларирована программистом, протестирована тестировщиком и раскатана по cdn-у) это если говорить абстрактно. а конкретно — не должно быть никаких висячих зависимостей. глупо делать так, чтобы фреймворк зависел от опционального плагина. или я что-то не улавливаю?
> хороший тому пример «i18n»: «ru.json» и «i18n»: «en.json»
пример чего? я могу отвечать только раз в сутки, так что переспрашивать не очень удобно
> Это, конечно, копейки, но в некоторых случаях и копейка важна
сферическая копейка в вакууме конечно важна, но на практике бутылочные горлышки находятся в совсем других местах
> спиддиал например
тоже занимался спиддиалом?) пример, кстати, показательный. знаешь что позволяет визуальным закладкам от яндекса открываться быстрее любых других? пререндер вкладки.
> И тут в тред врывается абстракция над файловой системой и наследование конфигов! ;-)
фс — сама по себе уже достаточно неплоха абстракция древовидной структуры и незачем лепить сверху практически то же самое, но со своими праилами блекджека. линух на этом основан. а у меня нет конфигов и нечего не надо наследовать: Р
> Тут минимум dev — один хост бэкэнда, test — другой. Ну и всякие хитрые оптимизации production-сборки.
а что мешает использовать тот хост с которого загружена страница? я бы побоялся выкладывать на продакшен не тестированный код. отличие даже в один небольшой файл может вылиться в серьёзные проблемы.
> должно быть явное разделение того, что входит в сборку и что используется.
почему должно? одно без другого не имеет смысла. включить модуль в сборку, но нигде им не воспользоваться… зачем? обычно это не надо. а когда надо — всегда можно «воспользоваться» им в *.meta.tree. использовать модуль, не подгрузив его… зачем? код же не будет работать, а будет сыпать ошибками. разве что какой-то хитрый вариант типа «нужный модуль будет подгружен потом другим модулем, чтобы этот модуль мог им воспользоваться» необходимость которого я с трудом представляю.
> На крайняк можно заюзать wildcard "*": "*.js" и включить в сборку все модули.
а если не все из них используются? у меня вот есть условно 2 типа пакетов: библиотеки и приложения. когда собирается приложение — его модули грузятся все, а вот из библиотек только те, что реально используются.
> Еще каждый модуль может требовать наличие какого-то плагина, что в случае с «бесконфигной» архитектуры влечет за собой всякое колдовство в коде и хтрый его анализ.
ничего не влечёт. я плохо акцентировал на этом внимание… автоматика сильно упрощает работу, но она не творит чудеса) если требуется плагин, который регистрируется как, например, функция в инстансе jq. то есть факт его использования в общем случае статически определить сложно, то эту зависимость надо будет определить явно. в meta.tree или же в самом jam.js в комментарии (то есть опуститься до уровня cjs ;). другой вариант — добавить алиас, чтобы обращение к нему удовлетворяло принципам jam:
$jd( '.fancybutton' ).$jq_fancybutton()
но тогда, разумеется, появляется некоторая избыточность обращения.
> И еще я считаю, что модули должны быть гибко абстрагируемы от файловой системы.
а я считаю, что не надо плодить абстракции. знать где лежит модуль, который вот тут вот используется — это классно. а лазить по конфигам в поисках исходника — это бяка.
> каждый объект скоупа увеличивает цену вызова функции, лежащей в этом скоупе
ну там же хэш-таблица. разница незначительна.
> спасибо, я уже с browserify наигрался =)
ну это же совсем не то: о второй уровень из 4 по моей шкале х)
> как ты собираешься организовывать локализацию на разные языки, которые могут влеч за собой отключение каких-то фичей?
хороший вопрос) я пока делал только подмену текстов, но там был отдельный формат для локалей, который собирался также как и все остальные, но на выходе получались собранные бандлы типа index.locale=ru.xml из файлов типа ya_search.locale=ru.xml
думаю можно реализовать аналогичную поддержку «плоскостей сборки» для всех форматов. а ковыряться в конфигах, прописывая каждую локализованную версию файла — совсем не хочется.
> Ну и как делать версии для dev/prod/test?
а это зачем? на мой взгляд разница должна быть настолько минимальной, на сколько это возможно. а если нужны какие-то дополнительные инструменты для дебага — грузить их отдельным пакетом.
ну, я там много распинался по поводу того, что именование одной сущности по разному в разных местах — это плохо как для машины, так и для человека. в этом случае любой принцип именования «нас ограничивает», так же как перила ограничивают нас в возможности спрыгнуть с моста и стрелять себе в ноги, чтобы снизить скорость падения)
> тем, что они не должны, по крайней мере, лежать в одном скоупе
а почему бы и нет? изоляция нужна в случае ада вида «два модуля зависят от двух несовместимых версий другого модуля». но мы же не хотим грузить клиенту несколько версий одного модуля, правда? оупенсорс же в конце концов: если что-то не устраивает — почини. и себе жизнь упростишь и остальным.
> кроме времени инициализации, которое нужно замерять в доисторических системах и мобильниках, существуют еще и ресурсы, события, вычисления, которые тянет каждый модуль.
которые вовсе не обязательно выполнять при старте, если в том нет необходимости. хотя да, если либа изначально не ленива, то загрузчик с эвалом в нутрях сделает её ленивой. правда цена — координаты строк будут указывать в стратосферу. и не надо рассказывать про светлое будущее с sourcemap — нам сейчас мучиться)
> Лучше явно чем как-то так автоматически.
автоматически на основе _явной_ декларации использования. $jam.Component — не менее явно, чем require( 'jam/Component' ).
> Максимум документации должно быть в коде — код должен быть самодокументируемым. То, что доки где-то лежат вне файла многим наплевать(не удобно туда-сюда прыгать).
документация должна быть рядом с кодом, но не вперемешку. но это отдельный холивар, который к теме нашего текущего разговора не имеет отношения)
> в require() ленивая загрузка — бонус архитектуры
а у меня бонус фреймворка — модуль $jam.Lazy, который позволяет сделать ленивым не только модуль, но и любую функцию)
> Согласен, просто как вариант. С require() возможно автоматическое применение Code Coverage инструкций без участия бэкэнда.
и всётаки мы скатились до бесполезного спора «а у нас в квартире газ, а нас свой водолаз»). в конце концов всегда можно нагенерировать аннотацию со списком зависимостей, если она всё-таки нужна. у всех разные приоритеты — на том и порешим)
ну, ничто не мешает статически трансформировать JAM модули в AMD и обретать все его плюсы и минусы и переключаться между сборками в зависимости от того, что важнее)
основной-то посыл был всё-таки такой:
1. собирать нужно не только js, но и прочие прилагающиеся ресурсы. авторы CJS, AMD и других стандартов упорно про это забывают.
2. не за чем плодить рутину там, где достаточно простого соглашения и нехитрой автоматики.
ты всё-таки попробуй поиграться с примером — просто создаёшь файл, пишешь там код и обновив страницу получаешь его исполнение. при этом грузится только то, что реально используется. это очень удобно и позволяет сконцентрироваться на реализации не отвлекаясь на зависимости.
а что именно? для динамической загрузки (необходимость которой сильно преувеличена) можно использовать хоть тот же requireJS. статический анализ на самом деле даёт гораздо больше возможностей. можно даже статически превращать модули хоть в LMD, хоть в AMD, хоть в CJS
> возможен overhead по коду
имеется ввиду, что рядом с каждым модулем нужно писать имя пакета? он не большой и, кстати, легко минимизируется статически. у меня даже был минификатор, который находил пары пакет-модуль и заменял их на короткие алиасы во всех файлах (скрипты, стили, шаблоны и даже серверные скрипты), выхлоп от этого был мизерный, а отлаживать минифицированный код — то ещё удовольствие. Ещё у меня была версия с заворачиванием кода в with( $jam ) with( $wc ) { $Component(… ) } то есть, модули используются без указания пакета, но пакеты в которых нужно искать модули перечисляются вначале файла, но из-за этого возникала неоднозначность вида «а это модуль из какого пакета?», что вносило лишь путаницу и проблемы при переносе кода между файлами (а подключён ли нужный пакет? а не используется ли модуль из не того пакета?). В результате я остановился на варианте: вырезаем коментарии и отступы, склеиваем и зипуем. А одинаковые последовательности — очень хорошо зипуются)
> по соглашениям получается какая-то Java
это каким местом? в яве используются развесистые пространства имён, что напрягает. тут же больше похоже на php с его автолоадом.
> модули ничем не ограничены
а чем они должны быть ограничены? там вся и соль, что PMS и JAM в частности не мешают реализовывать приложение так как хочется. Они лишь помогают работать с зависимостями.
> нет ленивой инициализации(все сразу интерпретируется).
ну, время интерпретации — это такой мизер, что его даже измерить толком не получается. вот тут я стенал по этому поводу: nin-jin.ya.ru/replies.xml?item_no=76
так что временем интерпретации можно пренебречь. а вот что модуль будет делать при старте, а что по необходимости — это уже зависит от разработчика этого модуля)
> В require() на самом деле больше плюсов, чем минусов: он явный(документация зависимостей по коду,
если в этом есть необходимость, в PMS несложно сделать вывод списка зависимостей для каждого модуля, также как сейчас это делается для пакетов. так что посмотреть от чего зависит не сложно. а вот захламлять код портянкой require() и заставлять за ними следить вручную — плохо. в результате получается объявление зависимостей в двух местах («по факту использования» и «по факту включения»), которые обязаны быть синхронизированными.
> IDE не ругается на глобалы),
тут стоило бы уточнить что за ide. komodo вот, например, не ругается. видимо потому, что в глобальной области видимости слишком много всего-всего и с каждым релизом браузеров становится всё больше и больше. вести реестр этих свойств — неблагодарное занятие. а та ide, что следит за глобальными перемеными, могла бы для приличия хотябы просканировать файлы проекта на предмет определения глобальных переменных.
> с помощью него возможна ленивая инициализация модуля.
а если нужно не весь модуль инициализировать лениво, а только часть? опять же, нет смысла смешивать зависимости и ленивые вычисления. это перпендикулярные понятия, которые лучше оставить независимыми.
> Это полезный слой абстракции, который может изменить способ загрузки модуля (.coffee -> .js),
MPS как бы из коробки поддерживает различные форматы. научить его ещё и варить кофе — не проблема. другое дело, что этот синтаксический сахар не стоит тех проблем с отладкой, которые он вызывает.
> а так же позволяет собирать статистику без наглых хаков.
1. да как ни обзывай — там этого нет. по стандарту содержимое template не должно рендериться, но текущие браузеры ничего про template не знают и рендерить будут. аналогично со style scoped — стили будут применяться ко всему документу. и тому подобные несоместимости. а раз уж мы делаем несоместимо, то можно сделать и по уму, а не притягивать за уши префикс «x-» или дважды указывать, что x-fancybutton является расширением button и кидать ошибку, если разработчик это недокопипастил.
2. тогда возникает вопрос: чем эта поделка лучше xbl или htc? потому что они обладают всем известным «фатальным недостатком»? ещё опере надо реализовать свои «компоненты» и тогда у каждого движка будет своя их реализация)
3. ну да, и из-за этого приходится городить кучу костылей — сначала рендерим шаблон, а потом скриптом его перефигачиваем.
это попытка XBL (http://www.w3.org/TR/xbl/), который реализован и обкатан в мозилле, но никто не собирается его поддерживать, переложить на html5. получилась хрень, потому как:
1. нет возможности плавной деградации для не поддерживающих эту технологию браузеров, а также нет возможности сделать js-эмуляцию оной (xbl можно транслировать в htc и сделать эмуляцию на js, но с некоторыми ограничениями)
2. описание компонент идёт прямо в html, а не выносится в отдельные подключаемые кэширующиеся ресурсы (в xbl это выносится by design)
3. крайний примитивизм шаблонов (в xbl не сильно лучше)
4. пихание разных языков (js, css, html) в одну кучу без возможности разнести их по отдельным файлам (в xbl даже хуже — необходимо амперсанды в js экранировать).
5. сволочи, они украли у меня название мета-фреймворка)
зато очень в тренде «html5» который стал символом велосипеда. или наоборот о0
пишет консоли и не реагирует на наклон:
Port error: Could not establish connection. Receiving end does not exist.
chromeHidden.Port.dispatchOnDisconnect miscellaneous_bindings:236
Werdas возможно сенсор барахлит и воспринимает как даблклик
1) то, что XSL впервые реализован в IE не отменяет той проблемы, что реализация во всех остальных браузерах от него отличается
в чём? или имеется ввиду javascript api? ну так спрятать различия в обёртку — не великий подвиг.
2) возможно починили в свежих версиях оперы, но проблема точно есть в Opera 9.64, например, приходилось всегда объявлять, иначе самый первый мог не отработать
ну вот, а говорите не развивается) пилят потихоньку. не так активно как модный «html5» к сожалению.
3) например
и что сложного в этом ни на что не матчащемся шаблоне?) для справки:
а) индексация в xpath начинается с единицы, а не с нуля
б) у элемента xsl:attribute нет никакого аттрибута select. поправьте ваш «пример» github.com/pasaran/yate/blob/master/examples/mailbox/mailbox.xsl#L452
4) если в шаблоне есть, то эта картинка загрузится при чтении шаблона, ещё и onload может вызваться, проблема в том, что картинка грузится, а переменные в src не интерполируются, в итоге 404
5) все браузеры просят, а в хроме такой output работает не всегда и для него приходится генерить отделные шаблоны с
в каких это случаях метод html не работает? и что значит не работает?
6) такое мнение может пропасть, если почитать скомпилированный yate-шаблон, там всё достаточно понятно и логично, понятные имена функций, комментарии, у нас проблем с этим не возникало
а где его взять простому смертному? впрочем, я не поленился и заморочился со скачиванием исправлением багов в вашем компиляторе, чтобы он не падал под виндой, исправлением глупых багов в шаблонах. nin-jin.github.com/etc/yate-vs-xslt/template.js — вот это вы называете «понятно и логично»? это типичный нагенеренный трешак с именами функций вида t42 и переменными вида v13.
7) очень спорный момент — это передавать с сервера дату сразу в 20 локалях и в индивидуальном формате для каждой локали, лучше передать timestamp и из него сделать правильный вывод при отрисовке view
а зачем передавать сразу 20 локалей, когда нужна всего одна? и тогда уж не timestamp а в iso, который понятен человеку. но тут ещё ладно, дата — вещь атомарная — её куда угодно можно присунуть. а вот формирование урлов с помощью яваскрипта в шаблонизаторе — это ахтунг. github.com/pasaran/yate/blob/master/examples/mailbox/mailbox.yate#L425
эти урлы должны либо приходить с данными, либо для них должны быть отдельные шаблоны (с матчингом и плейсхолдерами, а не ифами и конкатенацией). в конце концов, на кой чёрт данные для экшенов фигачить в урл? они либо в теле сообщения должны быть, либо в uri ресурса (в данном случае сообщения), который и должен приходить с данными.
8) у E4X не самая богатая документация и синтаксис не самый очевидный, он то «около-xpath», то js + он depricated + он только в SpiderMonkey + да, он медленный
уж кто бы говорил про документацию) ну да, не взлетел. но штука всё же классная.
9) да, yate автоматически экранирует данные, про JSON не совсем понял вопрос, но вроде он тоже экранируется
про json вопрос был в том, чтобы можно было формировать ваш любимый onclick=«return {...}» без необходимости вручную экранировать каждое значение. аналогично с урлами и прочими языками в языке.
10) время трансформации — это время за которое из JSON с помощью скомпилированного шаблона получается строка с HTML, которая затем достаточно быстро вставляется в DOM с помощью innerHTML, script evaluation time для скомпилированного шаблона не учитывается, так как выполняется только один раз при загрузке шаблона и, например, профайлер оперы говорит, что уходит на это 2-3мс
а я вот тут потестил на вашем «примере» и у меня графики получились не такие классные. nin-jin.github.com/etc/yate-vs-xslt/ что я делаю не так?
по моим данным скорость примерно равна с перевесом в сторону xslt во всех браузерах, кроме хрома. yate разворачивает 24кб шаблон в 42кб и плюс требует 24кб рантайма. xslt шаблон занимает 25кб и парсится за те же единицы миллисекунд. при этом если сделать рефакторинг шаблонов и серверной выдачи (упростить структуру и избавиться от сложной логики) — можно ещё сильнее ускорить и ужать в размере. но это не так интересно как изобретать велосипед ;-) кстати, вопреки расхожему мнению, данные в json формате оказались больше по объёму, чем те же данные в xml.
особенно порадовал «яндексовый футер» который тут прилеплен как телеге пятая нога.
а в коде… было 90кб скриптов, стало больше 600кб
раньше всё живенько применялось налету, ресайзилось и тп, а теперь при ресайзе происходит моргание да ещё и с задержкой. и так все перерисовки.
в общем, для тех, кто с дури решил попробовать новую версию — я сохранил последнюю версию старых вз: dl.dropbox.com/u/15534041/vb%40yandex.ru.xpi
var LazyObserver = function( ){
var hashTable= { }
this.add= function( server ){
hashTable.__defineGetter__( server.name, function( ){
return server.ping()
})
return this
}
this.check= function( ){
return hashTable
}
}
1. структура файлов хаотичная. логику создания директорий так и не уловил.
2. накладывание трансформация кучи маленьких xml, и склеивание их вместе через промежуточную сериализацию в html — это медленно, не удобно и попросту багоёмко. нормальная практика — сформировать 1 xml, потом его трансформировать за один запуск xslt.
3. именованные шаблоны нельзя перегружать. какой смысл использовать xslt и не использовать его основную фишку — выбор шаблона на основе данных?
4. вместо «справочника» надо использовать ключи. они именно для этого и предназначены и именно для этого оптимизированы.
5. огульное использование disable-output-escaping — потенциальная дырень в безопасности. использовать его нужно там, где без него никак. в данном же случае он нахрен не нужен.
по обсуждению
1. развели флейма как вставить скрипты в html. считайте, что xslt — это перила, которые не дают вам упасть в говнокод.
2. xslt конечно громоздок. и все это понимают. но альтернатив-то особо и нет. если это так уж сильно напрягает — могу выложить доведённую до ума вот эту либу: www.php.ru/forum/viewtopic.php?f=27&t=27236
дизайн в этом месте и правда крив — вынуждает использовать хаки на ровном месте. ну вот какого лешего this начинает указывать в стратосферу, когда можно «по умолчанию» подставлять объект в контексте которого эта функция была создана?
тут нужно наследование локалей. и не через какой-то там сервис, а прямо тут, при разработке. и не конфигов, а самих локализованных строк. или строки у тебя в конфигах? для каждого модуля?
для jit функции и сами прогреются когда надо будет. на то он и jit. ускорять работу одной фичи путём торможения работы всего браузера — не самая светлая идея. если все будут считать себя пупами земли и прогревать себя при старте — браузер будет стартовать как старичок нетскейп. ну или тупить первую минуту, как винда.
а в каких случаях таких возможностей нет?
www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.
говоря простым языком: ресурс — это абстракция, которая может быть доступна по разных ссылкам в зависимости от требуемых соглашений приёма и передачи данных.
далее, совершенно не важно в какой стпени в каких спеках описано кэширование. да хоть оно вообще нигде не было бы описано — совершенно не важно. важно то, что введение ограничения «немодифицирующие запросы, надо помечать специальным словом GET или HEAD, если BODY не нужен» введено ИСКЛЮЧИТЕЛЬНО для того, чтобы можно было легко и быстро определять что можно кэшировать, а что не стоит. если бы не эта причина, формулировка была бы куда проще: get — просто получение данных, будь там хоть рандомайзер.
а при чём тут бд? допустим я хочу сделать обновление ресурсов сайта посредством посылки архива с исходниками на определённый ресурс. посылаю на один — изменяются многие другие. в вебе это повсеместное явление. или мисье теоретик?)
не хочу я чтобы рсс читался у меня спрашивала не только ссылку на поток, но и список необходимых заголовков, чтобы получить именно поток, а не хтмл страницу. и не надо говорить про стандартизацию, с ней всё очень плохо в современном вебе.
это только в сферическом вакууме возможен прямой маппинг ресурсов на модели с указанием отображения в заголовках. но эта абстракция сразу начинает течь, попав в реальный мир:
1. отсылка одной формы должна быть произведена за один запрос к одному ресурсу, а не за десять к десяти, не смотря на то, что фактически она изменяет не один ресурс, а десять.
2. нужно предоставлять пользователю возможность получать данные в разных представлениях. требовать от браузера поддержки всех возможных на всех сайтах видов представлений — наивно и глупо. например, диаграмма может быть представлена в виде разноцветного отрезка (нужно указать ещё и его длину), может ввиде круга (нужно указать диаметр или габариты), а может ввиде цилиндра (тут надо указать углы поворота в 3д, степень удаления и габариты области просмотра). а задачей content negotiation является обеспечение доступности, а не предоставление выбора. в примере с диаграммами — для цилиндра выбор между jpeg растром и vrml моделью. но как ты заметил, современные html технологии плохо для этого предназначены.
2. параметр в урле лучше, чем просто http-заголовок. потому что ответы сервера разные. а урл является ключём кэша. как вариант можно в ответе прописать «Vary: X-Rrequested-With», чтобы этот заголовок тоже попал в ключ, но зачем, если есть возможность изменить сам урл? ещё и в логах сервера аяксовые и обычные запросы будут отличаться урлами, и не надо будет шаманить с добавлением заголовка и туда.
3. аякс многие справедливо недолюбливают потому что это велосипед окружённый костылями: для истории, для роботов, для кеширования, для уведомления о прогрессе загрузки, для вывода ошибок загрузки, для повторной отправки пропавшего в дебрях gprs запроса, для отображения загруженной части большого контента. и всё это для того, чтобы криво написанный сайт не так сильно тормозил.
4. добиться высокой скорости можно гораздо более простыми и стандартными способами. освойте http-кеширование и грузите по отдельности те данные, что имеют разную степень актуальности. например, навигацию(если она большая конечно) нужно грузить отдельно от содержимого страницы. и не нужно никаких костылей.
в том-то и дело, что ленивая нужна загрузка не модулей, а пакетов. иначе будет 100500 запросов.
> Пример абстракции над файловой системой
а, пример определения модуля i18n как алиаса на один из конкретных файлов? а что делать в случае, когда в какой-нибудь турецкой локали не хватает нужных строк? тут нужно не просто «всё решать одной абстракцией» — тут надо парсить локали и собирать сборную солянку. либо громко ругаться, что не хватает переводов. но уж точно не просто заменять один файлик на другой.
> Недавно буквально наткнулись на такую проблему (плагины для браузра) без ленивой загрузки и без прогретого JIT он стартует 150 мс (ну очень тяжелый), а с ленивой загрузкой 20мс
я.бар?) ну, вообще говоря, да, специфика плагинов в том, что подгрузка модулей из памяти не даёт такого пенальти, как подгрузка с сервера, зато есть куча левого функционала, который практически не используется. поэтому для мозиллы, например, я написал клёвый ленивый загрузчик (https://github.com/nin-jin/fenix-snippet#%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8F%D1%80%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F) — кстати, хороший пример, ленивой загрузки и изоляции модулей, оставаясь при этом в рамках PMS. правда ценой типовой шапки из нескольких строк: подключение загрузчика и подключение каждого необходимого пакета, модули из которых грузятся уже лениво.
> Консультировал по оптимизации визуальных закладок 2,0.
под какой браузер? и какие выводы?
> особенность архитектуры, часто не мы решаем какая она должна быть (адрес бэкнда другой у дева и продакшена)
и всё же, ошибки в архитектуре тоже надо исправлять, иначе есть риск погрязнуть в костылях.
> Что-то у нас тред разросся :) Понаписали уже больше чем в статье.
автор нас наверно уже проклял, сглазил и навёл порчу х)
сама по себе? нет) вся логика должна быть задекларирована программистом, протестирована тестировщиком и раскатана по cdn-у) это если говорить абстрактно. а конкретно — не должно быть никаких висячих зависимостей. глупо делать так, чтобы фреймворк зависел от опционального плагина. или я что-то не улавливаю?
> хороший тому пример «i18n»: «ru.json» и «i18n»: «en.json»
пример чего? я могу отвечать только раз в сутки, так что переспрашивать не очень удобно
> Это, конечно, копейки, но в некоторых случаях и копейка важна
сферическая копейка в вакууме конечно важна, но на практике бутылочные горлышки находятся в совсем других местах
> спиддиал например
тоже занимался спиддиалом?) пример, кстати, показательный. знаешь что позволяет визуальным закладкам от яндекса открываться быстрее любых других? пререндер вкладки.
> И тут в тред врывается абстракция над файловой системой и наследование конфигов! ;-)
фс — сама по себе уже достаточно неплоха абстракция древовидной структуры и незачем лепить сверху практически то же самое, но со своими праилами блекджека. линух на этом основан. а у меня нет конфигов и нечего не надо наследовать: Р
> Тут минимум dev — один хост бэкэнда, test — другой. Ну и всякие хитрые оптимизации production-сборки.
а что мешает использовать тот хост с которого загружена страница? я бы побоялся выкладывать на продакшен не тестированный код. отличие даже в один небольшой файл может вылиться в серьёзные проблемы.
различные xml технологии
отвечаю не чаще раза в день)
почему должно? одно без другого не имеет смысла. включить модуль в сборку, но нигде им не воспользоваться… зачем? обычно это не надо. а когда надо — всегда можно «воспользоваться» им в *.meta.tree. использовать модуль, не подгрузив его… зачем? код же не будет работать, а будет сыпать ошибками. разве что какой-то хитрый вариант типа «нужный модуль будет подгружен потом другим модулем, чтобы этот модуль мог им воспользоваться» необходимость которого я с трудом представляю.
> На крайняк можно заюзать wildcard "*": "*.js" и включить в сборку все модули.
а если не все из них используются? у меня вот есть условно 2 типа пакетов: библиотеки и приложения. когда собирается приложение — его модули грузятся все, а вот из библиотек только те, что реально используются.
> Еще каждый модуль может требовать наличие какого-то плагина, что в случае с «бесконфигной» архитектуры влечет за собой всякое колдовство в коде и хтрый его анализ.
ничего не влечёт. я плохо акцентировал на этом внимание… автоматика сильно упрощает работу, но она не творит чудеса) если требуется плагин, который регистрируется как, например, функция в инстансе jq. то есть факт его использования в общем случае статически определить сложно, то эту зависимость надо будет определить явно. в meta.tree или же в самом jam.js в комментарии (то есть опуститься до уровня cjs ;). другой вариант — добавить алиас, чтобы обращение к нему удовлетворяло принципам jam:
$jd( '.fancybutton' ).$jq_fancybutton()
но тогда, разумеется, появляется некоторая избыточность обращения.
> И еще я считаю, что модули должны быть гибко абстрагируемы от файловой системы.
а я считаю, что не надо плодить абстракции. знать где лежит модуль, который вот тут вот используется — это классно. а лазить по конфигам в поисках исходника — это бяка.
> каждый объект скоупа увеличивает цену вызова функции, лежащей в этом скоупе
ну там же хэш-таблица. разница незначительна.
> спасибо, я уже с browserify наигрался =)
ну это же совсем не то: о второй уровень из 4 по моей шкале х)
> как ты собираешься организовывать локализацию на разные языки, которые могут влеч за собой отключение каких-то фичей?
хороший вопрос) я пока делал только подмену текстов, но там был отдельный формат для локалей, который собирался также как и все остальные, но на выходе получались собранные бандлы типа index.locale=ru.xml из файлов типа ya_search.locale=ru.xml
думаю можно реализовать аналогичную поддержку «плоскостей сборки» для всех форматов. а ковыряться в конфигах, прописывая каждую локализованную версию файла — совсем не хочется.
> Ну и как делать версии для dev/prod/test?
а это зачем? на мой взгляд разница должна быть настолько минимальной, на сколько это возможно. а если нужны какие-то дополнительные инструменты для дебага — грузить их отдельным пакетом.
> r(«pewpew-ololo»);
ну, я там много распинался по поводу того, что именование одной сущности по разному в разных местах — это плохо как для машины, так и для человека. в этом случае любой принцип именования «нас ограничивает», так же как перила ограничивают нас в возможности спрыгнуть с моста и стрелять себе в ноги, чтобы снизить скорость падения)
> тем, что они не должны, по крайней мере, лежать в одном скоупе
а почему бы и нет? изоляция нужна в случае ада вида «два модуля зависят от двух несовместимых версий другого модуля». но мы же не хотим грузить клиенту несколько версий одного модуля, правда? оупенсорс же в конце концов: если что-то не устраивает — почини. и себе жизнь упростишь и остальным.
> кроме времени инициализации, которое нужно замерять в доисторических системах и мобильниках, существуют еще и ресурсы, события, вычисления, которые тянет каждый модуль.
которые вовсе не обязательно выполнять при старте, если в том нет необходимости. хотя да, если либа изначально не ленива, то загрузчик с эвалом в нутрях сделает её ленивой. правда цена — координаты строк будут указывать в стратосферу. и не надо рассказывать про светлое будущее с sourcemap — нам сейчас мучиться)
> Лучше явно чем как-то так автоматически.
автоматически на основе _явной_ декларации использования. $jam.Component — не менее явно, чем require( 'jam/Component' ).
> Максимум документации должно быть в коде — код должен быть самодокументируемым. То, что доки где-то лежат вне файла многим наплевать(не удобно туда-сюда прыгать).
документация должна быть рядом с кодом, но не вперемешку. но это отдельный холивар, который к теме нашего текущего разговора не имеет отношения)
> в require() ленивая загрузка — бонус архитектуры
а у меня бонус фреймворка — модуль $jam.Lazy, который позволяет сделать ленивым не только модуль, но и любую функцию)
> Согласен, просто как вариант. С require() возможно автоматическое применение Code Coverage инструкций без участия бэкэнда.
и всётаки мы скатились до бесполезного спора «а у нас в квартире газ, а нас свой водолаз»). в конце концов всегда можно нагенерировать аннотацию со списком зависимостей, если она всё-таки нужна. у всех разные приоритеты — на том и порешим)
> Статистика подключений — вызовы require(), профилирование времени инициализации модуля, сбор динамической статистики.
ну, ничто не мешает статически трансформировать JAM модули в AMD и обретать все его плюсы и минусы и переключаться между сборками в зависимости от того, что важнее)
основной-то посыл был всё-таки такой:
1. собирать нужно не только js, но и прочие прилагающиеся ресурсы. авторы CJS, AMD и других стандартов упорно про это забывают.
2. не за чем плодить рутину там, где достаточно простого соглашения и нехитрой автоматики.
ты всё-таки попробуй поиграться с примером — просто создаёшь файл, пишешь там код и обновив страницу получаешь его исполнение. при этом грузится только то, что реально используется. это очень удобно и позволяет сконцентрироваться на реализации не отвлекаясь на зависимости.
а что именно? для динамической загрузки (необходимость которой сильно преувеличена) можно использовать хоть тот же requireJS. статический анализ на самом деле даёт гораздо больше возможностей. можно даже статически превращать модули хоть в LMD, хоть в AMD, хоть в CJS
> возможен overhead по коду
имеется ввиду, что рядом с каждым модулем нужно писать имя пакета? он не большой и, кстати, легко минимизируется статически. у меня даже был минификатор, который находил пары пакет-модуль и заменял их на короткие алиасы во всех файлах (скрипты, стили, шаблоны и даже серверные скрипты), выхлоп от этого был мизерный, а отлаживать минифицированный код — то ещё удовольствие. Ещё у меня была версия с заворачиванием кода в with( $jam ) with( $wc ) { $Component(… ) } то есть, модули используются без указания пакета, но пакеты в которых нужно искать модули перечисляются вначале файла, но из-за этого возникала неоднозначность вида «а это модуль из какого пакета?», что вносило лишь путаницу и проблемы при переносе кода между файлами (а подключён ли нужный пакет? а не используется ли модуль из не того пакета?). В результате я остановился на варианте: вырезаем коментарии и отступы, склеиваем и зипуем. А одинаковые последовательности — очень хорошо зипуются)
> по соглашениям получается какая-то Java
это каким местом? в яве используются развесистые пространства имён, что напрягает. тут же больше похоже на php с его автолоадом.
> модули ничем не ограничены
а чем они должны быть ограничены? там вся и соль, что PMS и JAM в частности не мешают реализовывать приложение так как хочется. Они лишь помогают работать с зависимостями.
> нет ленивой инициализации(все сразу интерпретируется).
ну, время интерпретации — это такой мизер, что его даже измерить толком не получается. вот тут я стенал по этому поводу: nin-jin.ya.ru/replies.xml?item_no=76
так что временем интерпретации можно пренебречь. а вот что модуль будет делать при старте, а что по необходимости — это уже зависит от разработчика этого модуля)
> В require() на самом деле больше плюсов, чем минусов: он явный(документация зависимостей по коду,
если в этом есть необходимость, в PMS несложно сделать вывод списка зависимостей для каждого модуля, также как сейчас это делается для пакетов. так что посмотреть от чего зависит не сложно. а вот захламлять код портянкой require() и заставлять за ними следить вручную — плохо. в результате получается объявление зависимостей в двух местах («по факту использования» и «по факту включения»), которые обязаны быть синхронизированными.
> IDE не ругается на глобалы),
тут стоило бы уточнить что за ide. komodo вот, например, не ругается. видимо потому, что в глобальной области видимости слишком много всего-всего и с каждым релизом браузеров становится всё больше и больше. вести реестр этих свойств — неблагодарное занятие. а та ide, что следит за глобальными перемеными, могла бы для приличия хотябы просканировать файлы проекта на предмет определения глобальных переменных.
> с помощью него возможна ленивая инициализация модуля.
а если нужно не весь модуль инициализировать лениво, а только часть? опять же, нет смысла смешивать зависимости и ленивые вычисления. это перпендикулярные понятия, которые лучше оставить независимыми.
> Это полезный слой абстракции, который может изменить способ загрузки модуля (.coffee -> .js),
MPS как бы из коробки поддерживает различные форматы. научить его ещё и варить кофе — не проблема. другое дело, что этот синтаксический сахар не стоит тех проблем с отладкой, которые он вызывает.
> а так же позволяет собирать статистику без наглых хаков.
о какой статистике идёт речь?
nin-jin.github.com/etc/modules/index.xml
пишите тут в коментах плюсы и минусы упомянутых подходов. об ошибках и неточностях тоже. есть ли подходы, которые я не упомянул, а стоило бы?
сахара много, но решает ли этот язык хоть одну проблему, которую не решают другие языки? только из-за синтаксиса язык никто менять не будет.
2. тогда возникает вопрос: чем эта поделка лучше xbl или htc? потому что они обладают всем известным «фатальным недостатком»? ещё опере надо реализовать свои «компоненты» и тогда у каждого движка будет своя их реализация)
3. ну да, и из-за этого приходится городить кучу костылей — сначала рендерим шаблон, а потом скриптом его перефигачиваем.
1. нет возможности плавной деградации для не поддерживающих эту технологию браузеров, а также нет возможности сделать js-эмуляцию оной (xbl можно транслировать в htc и сделать эмуляцию на js, но с некоторыми ограничениями)
2. описание компонент идёт прямо в html, а не выносится в отдельные подключаемые кэширующиеся ресурсы (в xbl это выносится by design)
3. крайний примитивизм шаблонов (в xbl не сильно лучше)
4. пихание разных языков (js, css, html) в одну кучу без возможности разнести их по отдельным файлам (в xbl даже хуже — необходимо амперсанды в js экранировать).
5. сволочи, они украли у меня название мета-фреймворка)
зато очень в тренде «html5» который стал символом велосипеда. или наоборот о0
Port error: Could not establish connection. Receiving end does not exist.
chromeHidden.Port.dispatchOnDisconnect miscellaneous_bindings:236
Werdas возможно сенсор барахлит и воспринимает как даблклик
в чём? или имеется ввиду javascript api? ну так спрятать различия в обёртку — не великий подвиг.
2) возможно починили в свежих версиях оперы, но проблема точно есть в Opera 9.64, например, приходилось всегда объявлять, иначе самый первый мог не отработать
ну вот, а говорите не развивается) пилят потихоньку. не так активно как модный «html5» к сожалению.
3) например
и что сложного в этом ни на что не матчащемся шаблоне?) для справки:
а) индексация в xpath начинается с единицы, а не с нуля
б) у элемента xsl:attribute нет никакого аттрибута select. поправьте ваш «пример» github.com/pasaran/yate/blob/master/examples/mailbox/mailbox.xsl#L452
4) если в шаблоне есть, то эта картинка загрузится при чтении шаблона, ещё и onload может вызваться, проблема в том, что картинка грузится, а переменные в src не интерполируются, в итоге 404
интересный баг, но при чём тут xslt? nin-jin.github.com/etc/opera-img-bug/
5) все браузеры просят, а в хроме такой output работает не всегда и для него приходится генерить отделные шаблоны с
в каких это случаях метод html не работает? и что значит не работает?
6) такое мнение может пропасть, если почитать скомпилированный yate-шаблон, там всё достаточно понятно и логично, понятные имена функций, комментарии, у нас проблем с этим не возникало
а где его взять простому смертному? впрочем, я не поленился и заморочился со скачиванием исправлением багов в вашем компиляторе, чтобы он не падал под виндой, исправлением глупых багов в шаблонах. nin-jin.github.com/etc/yate-vs-xslt/template.js — вот это вы называете «понятно и логично»? это типичный нагенеренный трешак с именами функций вида t42 и переменными вида v13.
7) очень спорный момент — это передавать с сервера дату сразу в 20 локалях и в индивидуальном формате для каждой локали, лучше передать timestamp и из него сделать правильный вывод при отрисовке view
а зачем передавать сразу 20 локалей, когда нужна всего одна? и тогда уж не timestamp а в iso, который понятен человеку. но тут ещё ладно, дата — вещь атомарная — её куда угодно можно присунуть. а вот формирование урлов с помощью яваскрипта в шаблонизаторе — это ахтунг. github.com/pasaran/yate/blob/master/examples/mailbox/mailbox.yate#L425
эти урлы должны либо приходить с данными, либо для них должны быть отдельные шаблоны (с матчингом и плейсхолдерами, а не ифами и конкатенацией). в конце концов, на кой чёрт данные для экшенов фигачить в урл? они либо в теле сообщения должны быть, либо в uri ресурса (в данном случае сообщения), который и должен приходить с данными.
8) у E4X не самая богатая документация и синтаксис не самый очевидный, он то «около-xpath», то js + он depricated + он только в SpiderMonkey + да, он медленный
уж кто бы говорил про документацию) ну да, не взлетел. но штука всё же классная.
9) да, yate автоматически экранирует данные, про JSON не совсем понял вопрос, но вроде он тоже экранируется
про json вопрос был в том, чтобы можно было формировать ваш любимый onclick=«return {...}» без необходимости вручную экранировать каждое значение. аналогично с урлами и прочими языками в языке.
10) время трансформации — это время за которое из JSON с помощью скомпилированного шаблона получается строка с HTML, которая затем достаточно быстро вставляется в DOM с помощью innerHTML, script evaluation time для скомпилированного шаблона не учитывается, так как выполняется только один раз при загрузке шаблона и, например, профайлер оперы говорит, что уходит на это 2-3мс
а я вот тут потестил на вашем «примере» и у меня графики получились не такие классные. nin-jin.github.com/etc/yate-vs-xslt/ что я делаю не так?
по моим данным скорость примерно равна с перевесом в сторону xslt во всех браузерах, кроме хрома. yate разворачивает 24кб шаблон в 42кб и плюс требует 24кб рантайма. xslt шаблон занимает 25кб и парсится за те же единицы миллисекунд. при этом если сделать рефакторинг шаблонов и серверной выдачи (упростить структуру и избавиться от сложной логики) — можно ещё сильнее ускорить и ужать в размере. но это не так интересно как изобретать велосипед ;-) кстати, вопреки расхожему мнению, данные в json формате оказались больше по объёму, чем те же данные в xml.