Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
Полезно, но вряд ли пригодится rails-разработчикам из-за assets pipeline и опции :cache хелпера javascript_include_tag в третьей ветке фреймворка.
А вот тем, кто еще на 2.3.* — очень даже пригодится.
А вот тем, кто еще на 2.3.* — очень даже пригодится.
Круто, если что-то подобное предусмотрено в rails, значит я копаю в нужном направлении =)
Расспрошу поподробнее у своих коллег, которые спецы в rails.
Расспрошу поподробнее у своих коллег, которые спецы в rails.
api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper/JavascriptTagHelpers.html#method-i-javascript_include_tag
Там чуть пониже есть пункт «Caching multiple JavaScripts into one». Но это только часть всех фишек.
Там чуть пониже есть пункт «Caching multiple JavaScripts into one». Но это только часть всех фишек.
Тем кто на rails 2.3.* пригодится плагин github.com/customink/sprockets-rails2
Или http://pivotallabs.com/users/dwfrank/blog/articles/1972-giving-rails-2-the-asset-pipeline- более подробно о том как вкручивать asset pipeline в rails 2.3.
Или http://pivotallabs.com/users/dwfrank/blog/articles/1972-giving-rails-2-the-asset-pipeline- более подробно о том как вкручивать asset pipeline в rails 2.3.
Я так понял каждый файл сжимается по отдельности и не идёт сборка в единый js/css?
Нет. Пользователь сам распределяет JS-файлы по спискам, каждый из которых сжимается в MIN.JS-файл.
Это бывает полезно, если сайт состоит из нескольких страниц. Тогда есть какие-то общие JS-файлы, которые подключаются ко всем страницам — включим их в один список «common». Еще у каждой отдельной страницы есть собственные JS-файлы — включим их в отдельные списки, например «a», «b» и «c». После релизной компиляции получим 4 файла: common.min.js, a.min.js, b.min.js и c.min.js.
Теперь, когда пользователь зайдет на страницу «a», у него загрузятся 2 файла: common.min.js и a.min.js. Далее, когда он зайдет на страницу «b», будет загружаться только файл b.min.js, а файл common.min.js будет взят из браузерного кэша.
Это одно из преимуществ перед Sencha SDK, которое все JS-файлы сжимает в общий «app-all.js»
Это бывает полезно, если сайт состоит из нескольких страниц. Тогда есть какие-то общие JS-файлы, которые подключаются ко всем страницам — включим их в один список «common». Еще у каждой отдельной страницы есть собственные JS-файлы — включим их в отдельные списки, например «a», «b» и «c». После релизной компиляции получим 4 файла: common.min.js, a.min.js, b.min.js и c.min.js.
Теперь, когда пользователь зайдет на страницу «a», у него загрузятся 2 файла: common.min.js и a.min.js. Далее, когда он зайдет на страницу «b», будет загружаться только файл b.min.js, а файл common.min.js будет взят из браузерного кэша.
Это одно из преимуществ перед Sencha SDK, которое все JS-файлы сжимает в общий «app-all.js»
Ну да, а составить a_common.min.js и b_common.min.js что мешает?
Место на ЖД?
Особенно если учесть селективную перекомпиляцию.
Место на ЖД?
Особенно если учесть селективную перекомпиляцию.
В этом случае содержимое common.min.js по сути будет перекачиваться для каждой страницы с отличающимся набором скриптов.
Есть ли возможность включить один файл в два или более списков?
Справедливости ради хочу заметить, что у Sencha SDK другая идеология: страница загружается всего одна и работает в режиме приложения, а все необходимые дополнительные компоненты подгружаются с помощью require.
Так что для Sencha это не недостаток, а просто особенность архитектуры фреймворка.
За работу спасибо, для меня будет очень полезна в проектах на jQuery.
Так что для Sencha это не недостаток, а просто особенность архитектуры фреймворка.
За работу спасибо, для меня будет очень полезна в проектах на jQuery.
Не вижу ничего страшного в PHP: здесь он используется как кроссплатформенный интерпретатор скрипта для запуска из командной строки, который с тем же успехом можно было написать на Java, Python, NodeJS или <подставьте свое>, просто вот мне захотелось на PHP.
Единственный момент, который связывает его с Apache — это файл .htaccess, который производит следующий реврайт:
/<url_без_расширения> => /pages/<url>.html
Это очень удобно для проектов с архитектурой JS + AJAX + веб-сервис. Если вас это не устраивает — можете выкинуть файл .htaccess: написать свой или воспользоваться другим веб-сервером для раздачи статики.
Отказа от динамики нет: читайте раздел Совмещение jWidget SDK с PHP и пр. серверными генераторами HTML. Но тогда вы лишаетесь преимущества браузерного кэширования HTML-содержимого страниц, или вынуждены обеспечивать его вручную.
>>Ускорение у вас от YUICompressor, «программирование интерфейсов на JS» от extjs и его аналогов
А как, интересно, вы будете совмещать их между собой? Напишете индивидуальные sh-скрипты? Сколько времени вы на это угробите, чтобы обеспечить кроссплатформенность и два режима компиляции? Сколько добавочного времени вы будете тратить при добавлении новых файлов в проект? С jWidget SDK времени уйдет на порядок меньше.
Документация для других веб-серверов под Linux и Mac — дело времени.
Единственный момент, который связывает его с Apache — это файл .htaccess, который производит следующий реврайт:
/<url_без_расширения> => /pages/<url>.html
Это очень удобно для проектов с архитектурой JS + AJAX + веб-сервис. Если вас это не устраивает — можете выкинуть файл .htaccess: написать свой или воспользоваться другим веб-сервером для раздачи статики.
Отказа от динамики нет: читайте раздел Совмещение jWidget SDK с PHP и пр. серверными генераторами HTML. Но тогда вы лишаетесь преимущества браузерного кэширования HTML-содержимого страниц, или вынуждены обеспечивать его вручную.
>>Ускорение у вас от YUICompressor, «программирование интерфейсов на JS» от extjs и его аналогов
А как, интересно, вы будете совмещать их между собой? Напишете индивидуальные sh-скрипты? Сколько времени вы на это угробите, чтобы обеспечить кроссплатформенность и два режима компиляции? Сколько добавочного времени вы будете тратить при добавлении новых файлов в проект? С jWidget SDK времени уйдет на порядок меньше.
Документация для других веб-серверов под Linux и Mac — дело времени.
Да, когда-то я так и делал: вбивал HTML для подключения JS и CSS простых легких сайтов и сжимал их вручную. Но действительно надоедало напоминать заказчику «почистить кэш» — timestamp'ы для JS и CSS-файлов не станешь ведь проставлять вручную? Поэтому сейчас я использую jWidget SDK всегда и везде. Вещь небольшая, но действительно удобная.
Я не обижаюсь. Вы дали хорошую наводку на minify, спасибо.
Я не обижаюсь. Вы дали хорошую наводку на minify, спасибо.
Наилучшее решение проблемы с данными из БД — воспользоваться AJAX для загрузки данных и отрендерить все содержимое с помощью JS. Преимущество: весь HTML/JS/CSS без исключения кэшируется в браузере, пропадает нагрузка на сервер, связанная с лишними запусками PHP-интерпретатора, перезагружаются только данные. Данные (в том же формате JSON), как правило, весят гораздо меньше, чем HTML для их показа на странице. Следовательно, страница грузится очень (!) быстро. Недостаток: беда с поисковыми роботами. Но на любом крупном сайте маркетинговая часть разрабатывается с помощью CMS, ей и оставим возню с поисковыми роботами, а вот прикладную часть (та, что после логина) можем спокойно рендерить через JavaScript.
Если на странице надо будет что-то обновить, все шаблоны править не надо. Если вы следуете инструкции, которую я привел, то единственное упоминание JS/CSS в коде — это строчка:
Зачем ее менять?
Что касается minify, действительно, я не указал его в списке конкурентов и его следует изучить поподробнее. Сейчас же просто посмотрим страницу How it works. Первое, что смущает — это использование Cache-Control, которое вообще уничтожает всякую попытку перезагрузки содержимого при его изменении, если только пользователь не подождет с пол-часа или не очистит браузерный кэш (я правильно понял, что там используется max-age?). Второе: каждый раз при загрузке дергается index.php. Хоть он и возвращает код 304, но это лишняя нагрузка на сервер и необходимость установки PHP-адаптера для веб-сервера. Третье: сжатие осуществляется при первом обращении, т.е. мы приносим в жертву время первого посетителя нашего сайта, вместо того, чтобы одной командой сжать все-все-все скрипты на нашем сайте.
Возможно, я ошибаюсь — мне нужно время для подробного изучения minify.
Если на странице надо будет что-то обновить, все шаблоны править не надо. Если вы следуете инструкции, которую я привел, то единственное упоминание JS/CSS в коде — это строчка:
include APPLICATION_PATH . '/html/mypage.html'Зачем ее менять?
Что касается minify, действительно, я не указал его в списке конкурентов и его следует изучить поподробнее. Сейчас же просто посмотрим страницу How it works. Первое, что смущает — это использование Cache-Control, которое вообще уничтожает всякую попытку перезагрузки содержимого при его изменении, если только пользователь не подождет с пол-часа или не очистит браузерный кэш (я правильно понял, что там используется max-age?). Второе: каждый раз при загрузке дергается index.php. Хоть он и возвращает код 304, но это лишняя нагрузка на сервер и необходимость установки PHP-адаптера для веб-сервера. Третье: сжатие осуществляется при первом обращении, т.е. мы приносим в жертву время первого посетителя нашего сайта, вместо того, чтобы одной командой сжать все-все-все скрипты на нашем сайте.
Возможно, я ошибаюсь — мне нужно время для подробного изучения minify.
Когда вместо настройки коробочных CMS вы начнете делать ajax-приложения на каком-нибудь knockout — сразу всё поймёте.
а вы случаем с Денисом Поповым не знакомы?
Нет
Подозрительные плюсики у вашего комментария. Я что-то не знаю? =)
был такой гражданин с очень смелыми заявлениями :)
deflate зипнет ваши исходные JS-файлы, не объединив их между собой, не удалив пробельные символы, не сократив имена локальных переменных и не проведя иных известных оптимизаций. Если у вас было 100 исходных JS-файлов размером по 5 Кб, то с deflate вы получите 100 GZIP-файлов по 1 Кб. А с jWidget SDK вы получите 1 файл (или больше, в зависимости от структуры страниц сайта) размером 200 Кб. Что быстрее: выполнить 100 запросов по 1 Кб или 1 запрос в 200 Кб? Трудно сказать. По крайней мере, разница невелика. Хотя deflate можно использовать как дополнение к jWidget SDK, чтобы сжать сайт еще сильнее (получите не 200 Кб, а ~50 Кб). Еще, кстати, минусы deflate: работает только в новых браузерах, зипует налету (дополнительное время и нагрузка на сервер).
Не понял тезисов про phing, phpundercontrol и сборку проекта. Сейчас, чтобы собрать проект, все что от вас требуется — запустить один-единственный sh или bat-файл, включенный в состав SDK. Неужели это так сложно? Если ваш проект полностью собирается Ant'ом, можете добавить соответствующую команду в свой build.xml. А другой чей-то проект собирается sh-скриптом, тогда строчку запуска оптимизатора можно поместить туда.
Не понял тезисов про phing, phpundercontrol и сборку проекта. Сейчас, чтобы собрать проект, все что от вас требуется — запустить один-единственный sh или bat-файл, включенный в состав SDK. Неужели это так сложно? Если ваш проект полностью собирается Ant'ом, можете добавить соответствующую команду в свой build.xml. А другой чей-то проект собирается sh-скриптом, тогда строчку запуска оптимизатора можно поместить туда.
>> сборка проекта sh-скриптом — это велосипед
>> до вас это сделали уже десятки разработчиков
Вы имеете неправильное представление о велосипедах. Если вы мне укажете на бесплатное, полностью задокументированное и столь же удобное решение обозначенной проблемы — вот это и будет критерий велосипедности. Пока что вы даете какие-то разрозненные наводки на сторонние средства, которые не имеют никакой связи с поставленной задачей, а еще даете ссылку на какой-то репозиторий, в котором лежит несколько PHP файлов и никаких признаков инструкции. Инструкция, в частности, необходима для того, чтобы объяснить пользователю, что Splitfiles — это не «разделить файлы», а «объединить файлы» (ноу, ви а рашн!).
Насколько я понял, вы требуете от пользователя вручную вбивать длинную Ant-совместимую последовательность команд для сборки проекта. Это занимает гораздо больше времени, чем конфигурация JS-списков и страниц в jWidget SDK.
Если вы будете минусовать каждый мой коммент, спор будет не на равных: я пока не накопил достаточно кармы, чтобы минусовать ваши. Вы можете воздержаться?
>> до вас это сделали уже десятки разработчиков
Вы имеете неправильное представление о велосипедах. Если вы мне укажете на бесплатное, полностью задокументированное и столь же удобное решение обозначенной проблемы — вот это и будет критерий велосипедности. Пока что вы даете какие-то разрозненные наводки на сторонние средства, которые не имеют никакой связи с поставленной задачей, а еще даете ссылку на какой-то репозиторий, в котором лежит несколько PHP файлов и никаких признаков инструкции. Инструкция, в частности, необходима для того, чтобы объяснить пользователю, что Splitfiles — это не «разделить файлы», а «объединить файлы» (ноу, ви а рашн!).
Насколько я понял, вы требуете от пользователя вручную вбивать длинную Ant-совместимую последовательность команд для сборки проекта. Это занимает гораздо больше времени, чем конфигурация JS-списков и страниц в jWidget SDK.
Если вы будете минусовать каждый мой коммент, спор будет не на равных: я пока не накопил достаточно кармы, чтобы минусовать ваши. Вы можете воздержаться?
YUICompressor тоже пока сбоев с UTF-8 не давал. Я говорю о JSON-файлах конфигурации, которые сейчас парсятся функцией json_decode, которая, похоже, не совместима с UTF-8.
Да, пафос присутствует в вики проекта. Что в этом плохого? А вам приятнее читать сухую статью в формате ВАК?
Да, пафос присутствует в вики проекта. Что в этом плохого? А вам приятнее читать сухую статью в формате ВАК?
Что вы скажите о github.com/B-Vladi/Site-builder?
Не требует PHP.
Не требует PHP.
Вот, другое дело! Здесь уже вроде все понятно.
Вы уже где-нибудь публиковали ссылку на свой инструмент?
Расскажите, пожалуйста, как вы строите фрагмент HTML-кода для подключения файлов (теги script и link)? Если это делается автоматически, есть ли поддержка двух режимов компиляции (отладочный, релизный)? Проставляются ли timestamp'ы в ссылках на файлы для защиты от непреднамеренного кэширования?
Вы уже где-нибудь публиковали ссылку на свой инструмент?
Расскажите, пожалуйста, как вы строите фрагмент HTML-кода для подключения файлов (теги script и link)? Если это делается автоматически, есть ли поддержка двух режимов компиляции (отладочный, релизный)? Проставляются ли timestamp'ы в ссылках на файлы для защиты от непреднамеренного кэширования?
Вы уже где-нибудь публиковали ссылку на свой инструмент?
Публиковал тут: javascript.ru/forum/project/25248-site-builder.html
Но в тот момент это была глубокая альфа, так что там первый пост уже не актуален.
Расскажите, пожалуйста, как вы строите фрагмент HTML-кода для подключения файлов (теги script и link)?
Если это делается автоматически, есть ли поддержка двух режимов компиляции (отладочный, релизный)?
Пока никак, через шаблонизатор. Эта функциональность у меня уже в TODO-листе, но пока не до конца представляю какие использовать метки.
Проставляются ли timestamp'ы в ссылках на файлы для защиты от непреднамеренного кэширования?
Сейчас нет, так же в TODO-листе.
Вообще я думал поделиться с хабрасообществом, но пока рано. Когда запилю сборку спрайтов — тогда уже можно будет :)
Публиковал тут: javascript.ru/forum/project/25248-site-builder.html
Но в тот момент это была глубокая альфа, так что там первый пост уже не актуален.
Расскажите, пожалуйста, как вы строите фрагмент HTML-кода для подключения файлов (теги script и link)?
Если это делается автоматически, есть ли поддержка двух режимов компиляции (отладочный, релизный)?
Пока никак, через шаблонизатор. Эта функциональность у меня уже в TODO-листе, но пока не до конца представляю какие использовать метки.
Проставляются ли timestamp'ы в ссылках на файлы для защиты от непреднамеренного кэширования?
Сейчас нет, так же в TODO-листе.
Вообще я думал поделиться с хабрасообществом, но пока рано. Когда запилю сборку спрайтов — тогда уже можно будет :)
Сделали бы такой компрессор, который работает, как Simpless для less-css файлов. Отметил источники, отметил куда сохранять итог, и на выходе готовый(-ые) сжатые файлы после каждого изменения без всяких привязок к IDE и Java…
а есть еще Require.js, который эту задачу с помощью своего оптимизатора вполне добротно решает, хотя и не без нюансов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизатор загрузки JavaScript