Про «art аллею» претензия снимается. Пусть с точки зрения русского языка это и не правильно, но в случае исправления пользователи повалят на другой сайт :(

Вам бы вычиткой заняться: «зарегестрироваться», «фото альбом», «art аллея» и т.п. Первые же два абзаца текста на главной содержат ошибки. Ну и мелочи типа того, что не указана валюта в ценах, оставлены компьютерные термины («категории», «теги»), в то время как аудитория сайта — обыватели. А в остальном вполне качественный и приятный сайт, удачи вам.

А нас много, недовольных. Я думаю, что в той или иной мере недовольно все поколение, начавшее программировать в 2003-2007 годах. Просто я когда-то прочитал статью Спольски «Огонь и движение» и примерил ее на себя, и теперь не считаю себя неправым только на том основании, что я в меньшинстве.

Аналогично, только года на два попозже вас :) Не думаю, что найдется много стоящих веб-программистов, у которых хотя бы идеи такой не возникало.

Вообще, сейчас странные вещи в мире вебдева творятся — почему-то теперь даже для самых примитивных библиотек авторы считают нужным выделить отдельный сайт, создать фан-клуб и наладить выпуск футболок с символикой. Да и с кодом какая-то чертовщина — там, где можно обойтись одним файлом, они делают DI и десяток классов по два метода (и еще дюжину пустых классов, с именами, заканчивающимися на Exception) в отдельных файлах. Раньше тоже высокомерно относился к старикам, а теперь вот сам стал ужас как консервативен.

Ах да, иллюстрация. Адов ужас, я считаю:

class HeaderSetter
{
    public function statusCode($protocol, $code, $message)
    {
        header("{$protocol} {$code} {$message}");
        return $this;
    }

    public function headerField($field, $value)
    {
        header("{$field}: {$value}");
        return $this;
    }
}

Сама идея этой библиотеки порочна: вместо того, чтобы сохранять ассеты в доступной по вебу папке, она требует на каждое подключение ассетов дергать её php-файл (+0.5мб расхода памяти на запрос МИНИМУМ). Этим она берет на себя функции веб-сервера, и выполняет их из рук вон плохо: не поддерживает докачку при обрыве, делает совершенно невозможным снижение числа запросов способом, предложенным мною выше, не дают серверу использовать кэширование файлов в памяти. Да ещё и gzip делает исключительно на лету :)

А программистов я считаю просто восторженной пионерией — они напихали в код модные молодёжные паттерны, написав в три раза больше кода, чем нужно, сделали наитупейшие архитектурные ошибки типа двухфазной инициализации, и при этом у них не предусмотрен элементарнейший вариант, что обрабатываемый скрипт/картинка/etc не лежит в готовом виде в файловой системе. Не завидую их работодателю.

Добавить просто к собранным ассетам хэши от исходного содержимого и Большую Красную Кнопку «очистить кэш», которая также будет автоматически нажиматься при включении/выключении плагинов. От инвалидации кэша на лету вы потеряете весь выигрыш в производительности.

Когда кэш включен, ФС вы дергать не сможете ни под каким видом — браузер будет брать уже собранные файлы. А когда он только собирается, торопиться особо некуда, и возможные проблемы от оптимизаций не стоят ускорения.

Они не профессионалы, и использовать эту библиотеку не надо.

Не улавливаю нить разговора. Что должно было получиться в итоге — возможность разнести дополнительные поля по разным местам шаблона?

У меня, прямо скажу, в очереди доработок для Alto конкретно эта даже не в первой десятке, т.к. лично мне она не особо нужна — у меня сейчас вообще нет своих сайтов, а разгрузка gzip нужна только для высоконагруженных проектов. Да и в систему asset-ов я еще толком не вникал, не мне ее улучшать. Почему бы этим не заняться вам? :)

Да, понадобится что-то типа такого в .htaccess:

<FilesMatch "\.(css|js|html)$">
Header set Content-Encoding gzip
</FilesMatch>

Сделал архив с простым примером. У меня на хостинге он, правда, не завелся — для распаковки gzip браузерам (по крайней мере, chrome) требуется правильный Content-Length, а там фронтэндом стоит nginx, который его не указывает :( Так что по умолчанию эту оптимизацию включать нельзя.

Еще возможное улучшение — заранее архивировать asset-ы в gzip, чтобы это не приходилось каждый раз делать веб-серверу.

Применительно к вебдеву это обычно называется ресурсами.

Кстати, если я изменю какой-либо файл, изменится ли путь к asset-у, в котором он состоит? Если да, то можно заставить браузер всегда брать файлы по этому пути из кэша — это сэкономит десятки запросов при каждом переходе по страницам:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 3 months"
</IfModule>
<IfModule mod_headers.c>
Header set Cache-Control "max-age=7257600"
</IfModule>

Присоединяюсь к вопросу. Идея была интересная, почему от нее отказались?

Я не заметил название темы :) В общем-то, отсутствие стандартного шаблона — это регрессия, и её надо исправить.