Михаил, я не хочу с тобой спорить, потому что знаю что ты серьезный специалист, и говоришь всегда то что есть на самом деле.
Но при всем моем уважении, — есть случаи, когда рациональнее выбирать Dojo, а не jQuery, хотя он может где-то уступает в удобстве, и уж тем более — в легковесности.
Так же само есть случаи, когда рациональнее выбирать Джанго (при всем моем отличном отношении к Flask, и не буду скрывать, к Вашей Svarga (зря Вы все-таки похоронили хорошую идею)).
Что касается "… когда все копейки собираются во Flask, это уже становится серьезно...", — то могу сказать, только одно, и, думаю, ты со мной согласишься. В подавляющем большинстве проектов, шаблонизатор и обработчик URL влияют на производительность в наименьшей степени. Как правило, в средне-статистическом проекте такое количество пожирателей ресурсов, что хоть на Ассемблер переписывай эту логику, — сайт быстрее работать не станет. И если уж и говорить про вопросы быстродействия и оптимизации, — то заходить надо с другой стороны.
Если уж заниматься производительностью, — то ей нужно заниматься серьезно. Это как раз та область, где уровень квалификации разработчика играет более весомую роль, нежели скоростные показатели фреймверка. А когда не совсем квалифицированные разработчики сводят свою борьбу за производительность к тому, чтобы покритиковать Джангу, то это просто удовлетворение самолюбия, и ничего общего к Джанге не имеет…
В критической ситуации (правда Ваша ситуация совсем не критическая) — всегда можно использовать библиотеки для AOP программирования. На Питоне их несколько, — можно выбрать по вкусу.
Ну если Вам легче сменить фреймверк, нежели использовать штатные средства языка программирования (даже не фреймверка) — то это Ваше личное дело. Причем тут Джанго?
Правда последние Ваши слова немного не согласуются с первыми:
> «В других приложениях мне не подошла Джанговоская авторизация и модель юзера. У нас все было завязано на номер сотового телефона — его приходилось хранить в профиле, что было очень не удобно.»
Как выяснилось, Джанго Вас ни в чем не ограничивало. И вопрос не в ней, а в способности разбираться с вопросом. Иначе инструментов не напасешься…
Лично я когда использую Flask, — то причина не в том, что Django плохая. Я понимаю, что сегодня модно плюнуть в сторону PHP, Django и т.д., и таким образом лишний раз утвердиться. Я с одинаковым комфортом могу работать как в Django так и во Flask. И выбираю их исходя из того, что лучше подходит под задачу.
Если я делаю, например, социальную сеть, и для Джанги я могу найти готового кода на 8 человеко*месяцев, — то я выбираю Джанго. Даже если и будет несколько костылей (но это отнюдь не то, что вы назвали костылями)
> например нам нужно вывести дерево комментариев одним запросом через WITH RECURSIVE ..., level и прочее для комментариев в базе не хранятся, чтобы дерево не пересчитывалось долго (а когда комментариев очень много, то пересчет долгий), level считается на лету, и нам нужно подсчитанный level добавить в инстанс модели.
— Этот вопрос немного из другой области. Тут нужно просто выбрать верный способ хранения дерева. Благо в Джанге вопрос работы с деревьями хорошо решен:
Причем, если выбирать NS, — то можно на каждую ветку делать свое дерево. А больших веток не бывает, — т.е. тормоза NS вы не почувствуете. Ну или MP. Кстати в github.com/HonzaKral/django-threadedcomments как раз MP и используется, если не ошибаюсь (в последней версии).
Причем тут это? Вы, стесняюсь спросить, вообще читаете то что я пишу? Не считывайте шаблон каждый раз, — скорость в разы повышается (ребята даже говорили что в десятки раз). Разница с компилируемым шаблоном становится неощутима (впрочем не буду наговаривать, — сам не мерил)
> как-то все это костыльно, да и паттерны-то отличаются, у алхимии Data mapper.
Почему костыли? Причина? Только в том что используется другой SQLBuilder?
В SQLObject он полностью автономный, не зависит от ORM, легко отделяется от библиотеки, — всего три файла. С точки зрения Архитектуры — никаких костылей (и жаль что вы чистое архитектурное решение назвали костылем, это впрочем, о многом говорит). У Вас просто в проекте 2 SQLBuilder, — один простой, но зато удобный. Второй гибкий, для сложных SQL-запросов.
> да и паттерны-то отличаются, у алхимии Data mapper.
— Дорогой Lestat, не могли бы Вы пояснить, как связаны SQLBuilder и ORM? И какое отношение к SQLBuilder имеет «event между получением данных из базы и созданием model instances»?
Вы либо используете один, и только один ОРМ, независимо от того, чем строите SQL, либо у Вас в проекте два самостоятельных ОРМ, но с общими схемами.
> в итоге этих строчек было очень много
— Можно подробнее? Где именно, на каких таких моделях получилось много строчек? Всего на одной модели User? Какие еще модели?
> Есть множество способов решить этот вопрос. И даже без raw и extra… SQL в строчном виде. А высокоуровневыми средствами. И не обязательно даже SQLAlchemy… можно плз подробнее?
1. habrahabr.ru/blogs/python/128052/
2. Объявлять модели через свою фабрику, как сделано bitbucket.org/deepwalker/amalgam
3. Использовать SQLBuilder от SQLObject, StormORM, SQLAlchemy, py-smart-sql-constructor и т.п. для создания SQL, и затем подставлять его в Manager.raw(). Там нужно будет решить несколько нюансов, но они решаемы. И даже связи у результата запроса (инстанции модели) подхватываются.
> а jinja2 генериться млн. писем будет гораздо быстрее
— А Вам нужно каждый раз читать и парсить шаблон? Редко бывает, что пути поиска шаблонов в процессе работы скрипта меняются. Всего 5 строчек кода, — и шаблон только единожды прочтётся и распарсится, а затем будет просто реднериться. Потом можете и замеры делать…
Надо же, как странно, а мы наоборот, благодаря Джанге сэкономили кучу времени…
90% всех претензий Джанги (а из перечисленных Вами наверное 99%) — это проблема не Джанги, а уровня разработчиков.
Типичные обвинения типа «ОРМ» и «Шаблонизатор» звучат со стороны тех, кто ни разу не открывал исходников Джанги. И почему-то умалчивается тот факт, что 90% синтаксиса Jinja — это синтаксис Django. И почему?
При этом обвинения в сторону производительности шаблонизатора звучат с уст тех, кто ни разу не разрабатывал проекта с посещаемостью более 1000 уник. в сутки… Потому что иначе критерии мышления были бы другими…
Всего 5 строчек кода нужно для того, чтобы в разы поднять производительность шаблонизатора Джанги.
ОРМ Джанги — обычно критикуется зря. Есть костность QuerySet (а не ORM), но эта проблема решаема. Есть множество способов решить этот вопрос. И даже без raw и extra… SQL в строчном виде. А высокоуровневыми средствами. И не обязательно даже SQLAlchemy.
Лично я одинаково отношусь и к Flask, и к Django, и к Svarga (жаль что забросили), и к wep.py (не путать с wep2py), и к Pyramid, и к Plone, и к CherryPy, и к bottle, и к TurboGear…
Но когда проект большой, и «один в поле не воин», тогда Джанго — хороший инструмент. Один только djangopackages.com/ чего стоит… Есть причины, по которым такого «окружения» нет у других фреймверков. Именно причины, а не недостатки. Там где начинается много гибкости, — там обычно заканчивается много унифицированности.
> В других приложениях мне не подошла Джанговоская авторизация и модель юзера. У нас все было завязано на номер сотового телефона — его приходилось хранить в профиле, что было очень не удобно.
— есть масса способов не хранить телефон в профайле, а хранить его в юзере…
> не подошла Джанговоская авторизация
— Авторизация, или аутентификация? Скорее всего аутентификация. Сложно представить ситуацию, когда система аутентификации Джанги может не подойти… по крайней мере, судя по этому github.com/omab/django-social-auth А чтобы интерфейс авторизации не подошел, — еще сложнее верится, опять же, судя по этому djangopackages.com/grids/g/perms/
> Например, авторизация во Фласке позволяет самому задавать класс пользователя.
— setattr(model, 'ClassName', NewUser) тоже позволяет… Но в Вашем случае хватило бы Field.contribute_to_class()
> Получается, что практически все возможности Джанги покрыты, а система гораздо гибче.
— гм… Ну, Flask, вообще-то, хорошая система… мне нравится, по крайней мере… Просто сравнение не совсем корректное…
С самого появления алгоритма шифрования RSA, спецслужбы США тщетно пытались бороться с ее распространением. Против Фила Циммермана (Phil Zimmerman), автора PGP, было возбуждено, а потом закрыто («без комментариев») уголовное дело. Время от времени распространяется слух о том, что в очередную версию PGP вложена «закладка», позволяющая третьим лицам читать сообщения, зашифрованные PGP.
В 2001 году на проходившем в Сан-Франциско семинаре крупнейшей некоммерческой програмистской организации Кремниевой Долины Software Development Forum Филип Циммерман выступил с заявлением в поддержку арестованного в США программиста «Элкомсофта» Дмитрия Склярова.
Большую часть своего выступления Циммерман посвятил рассказу о, по его мнению, грязных методах, применявшихся властями в отношении него самого, и призвал софтверные компании Кремниевой Долины создать фонд защиты (defence fund) для сбора средств на защиту Дмитрия, отметив, что власти могут в любой момент выдвинуть обвинения против любой американской компании, занимающейся криптографическими исследованиями и вопросами информационной безопасности.
— Зато можно всех запугать, и этого может оказаться достаточным, чтобы компенсировать невозможность контроля.
P.S.: Периодически меня посещают мысли, что средства контроля интернета были продуманы еще до самого интернета. Просто позволили людям насладиться «свободой» и под этим соусом втянуть себя в полную зависимость от сети.
А удавалось ли Вам не нарушать правил дорожного движения в центре города, и каждое нарушение покрыть штрафом?
Это так, шутка. Не имею ничего против авторских прав, но против цензуры под этим соусом, и против ограничения Конституционных прав одних граждан в пользу других.
Михаил, Вы написали отличную и полезную библиотеку.
Не стоило так растрачивать себя на малолетние споры о необходимости использования более гибких SQL-конструкторов в Джанго. Это и так очевидно для любого человека с опытом разработки на Джанго.
А для тех кому это не очевидно (по причине опыта), — Ваша библиотека просто не нужна, и не стоит никого убеждать ее использовать.
На Джанго Вы, конечно, зря так наехали. Не без «узких мест» конечно, но зато представляет из себя прекрасную экосистему, объединяющую огромное количество разработчиков. На все случаи жизни найдутся готовые решения. Тут трудно найти более более удачный пример.
Справедливости ради, стоит отметить, что в Джанго можно использовать только лишь sqlalchemy.sql, а не весь sqlalchemy. А результат его работы подставлять в Manager.raw(). Возникнут небольшие траблы в паджинацией, но это легко решаемо.
Ваш путь конечно лучше, и предпочтительней, но не без недостатков.
Во первых, Вы сильно привязываетесь к не задокументированному API, стабильность которого никто не гарантирует (а насколько быстро Вы будете реагировать на его изменения, — не известно). Правда, библиотека не большая, и ее можно сопровождать самому, — но все же вопрос остается.
Во вторых, — если используется в проекте GeoDjango, — нужно дорабатывать Вашу библиотеку, чтобы она распознавала новые типы полей и позволяла работать с www.geoalchemy.org/
В третьих, нужно решать вопрос расшаривания соединения, транзакций и пр., но вы вроде бы эти вопросы решали.
>Ваши претензии никак не относятся к теме
Претензий никаких не было.
Теперь будут.
Похоже, суть Вашей статьи — это оптимизация загрузки страницы для небольших сайтиков (а Вы, вероятно только ими и занимаетесь). Только вот непонятно, неужели у них вообще существует потребность в оптимизации?
>Как все это сделать очень легко найти в гугле
Ага-ага. И про обфускацию и минимизацию тоже.
>опять же легко настраивается, но никак не относится к теме.
Да кому нужна эта тема. Людей интересует скорость загрузки, а не басня про шашечки.
P.S.: Последний Ваш комментарий (не без моей подачи) несет больше пользы для читателей, чем сама статья. Будьте внимательней ))
>В данной статье я опишу как сжимать яваскрипты дла production, объединять их в один файл,
Это решение не всегда является приемлемым. И если для простых сайтов объединение в один файл еще прокатит, то для сложных систем такой подход будет приводить к:
1. К паразитной загрузке ненужных для текущей страницы, но объединенных скриптов. Паразитные скрипты, кроме того, отбирают ресурсы у клиента.
2. Если текущая страница требует своих «особых» скриптов, и если создать разные версии «объединенных» скриптов, — то порождается неоптимальное использование клиентского кеша, и рост траффика, который можно избежать (например ядро jQuery присутствует в нескольких объединенных файлах).
3. Невозможность «параллельной загрузки» (загрузка с разных доменных имен), когда объединение наоборот тормозит загрузку.
В статье не отмечен один из самых важных этапов «згрузочной оптимизации». Это:
1. настройка сервера для сверки etag и отдачи 304. Что позволяет сократить максимально трафик.
2. настройка сервера на использование клиентского кеша ExpiresDefault. Что позволяет вообще избежать обращений к серверу.
3. (про это упоминалось) — настройка gzip сжатия.
При выполнении п.1 и 2, — упаковщик из благодетеля превращается в зло, ибо нивелирует их эффективность.
Тогда возникает вопрос, стоит ли вообще пользоваться упаковщиком. Для маленьких сатов, где вариация невысока, — да, безусловно. Для сложных систем — выгоднее использовать хорошо спроектированную модульную структуру, как сделано, например в Dojo.
Но при всем моем уважении, — есть случаи, когда рациональнее выбирать Dojo, а не jQuery, хотя он может где-то уступает в удобстве, и уж тем более — в легковесности.
Так же само есть случаи, когда рациональнее выбирать Джанго (при всем моем отличном отношении к Flask, и не буду скрывать, к Вашей Svarga (зря Вы все-таки похоронили хорошую идею)).
Что касается "… когда все копейки собираются во Flask, это уже становится серьезно...", — то могу сказать, только одно, и, думаю, ты со мной согласишься. В подавляющем большинстве проектов, шаблонизатор и обработчик URL влияют на производительность в наименьшей степени. Как правило, в средне-статистическом проекте такое количество пожирателей ресурсов, что хоть на Ассемблер переписывай эту логику, — сайт быстрее работать не станет. И если уж и говорить про вопросы быстродействия и оптимизации, — то заходить надо с другой стороны.
Если уж заниматься производительностью, — то ей нужно заниматься серьезно. Это как раз та область, где уровень квалификации разработчика играет более весомую роль, нежели скоростные показатели фреймверка. А когда не совсем квалифицированные разработчики сводят свою борьбу за производительность к тому, чтобы покритиковать Джангу, то это просто удовлетворение самолюбия, и ничего общего к Джанге не имеет…
8. Особые случаи не настолько особые, чтобы нарушать правила.
9. При этом практичность важнее безупречности.
Так что это еще вопрос, что больше противоречит…
Правда последние Ваши слова немного не согласуются с первыми:
> «В других приложениях мне не подошла Джанговоская авторизация и модель юзера. У нас все было завязано на номер сотового телефона — его приходилось хранить в профиле, что было очень не удобно.»
Как выяснилось, Джанго Вас ни в чем не ограничивало. И вопрос не в ней, а в способности разбираться с вопросом. Иначе инструментов не напасешься…
Лично я когда использую Flask, — то причина не в том, что Django плохая. Я понимаю, что сегодня модно плюнуть в сторону PHP, Django и т.д., и таким образом лишний раз утвердиться. Я с одинаковым комфортом могу работать как в Django так и во Flask. И выбираю их исходя из того, что лучше подходит под задачу.
Если я делаю, например, социальную сеть, и для Джанги я могу найти готового кода на 8 человеко*месяцев, — то я выбираю Джанго. Даже если и будет несколько костылей (но это отнюдь не то, что вы назвали костылями)
— Этот вопрос немного из другой области. Тут нужно просто выбрать верный способ хранения дерева. Благо в Джанге вопрос работы с деревьями хорошо решен:
— github.com/django-mptt/django-mptt
— bitbucket.org/tabo/django-treebeard
— bitbucket.org/fivethreeo/django-easytree
Причем, если выбирать NS, — то можно на каждую ветку делать свое дерево. А больших веток не бывает, — т.е. тормоза NS вы не почувствуете. Ну или MP. Кстати в github.com/HonzaKral/django-threadedcomments как раз MP и используется, если не ошибаюсь (в последней версии).
Почему костыли? Причина? Только в том что используется другой SQLBuilder?
В SQLObject он полностью автономный, не зависит от ORM, легко отделяется от библиотеки, — всего три файла. С точки зрения Архитектуры — никаких костылей (и жаль что вы чистое архитектурное решение назвали костылем, это впрочем, о многом говорит). У Вас просто в проекте 2 SQLBuilder, — один простой, но зато удобный. Второй гибкий, для сложных SQL-запросов.
> да и паттерны-то отличаются, у алхимии Data mapper.
— Дорогой Lestat, не могли бы Вы пояснить, как связаны SQLBuilder и ORM? И какое отношение к SQLBuilder имеет «event между получением данных из базы и созданием model instances»?
Вы либо используете один, и только один ОРМ, независимо от того, чем строите SQL, либо у Вас в проекте два самостоятельных ОРМ, но с общими схемами.
> в итоге этих строчек было очень много
— Можно подробнее? Где именно, на каких таких моделях получилось много строчек? Всего на одной модели User? Какие еще модели?
Не нравится Field.contribute_to_class(), используйте setattr(), чтобы код был чистым. Или вообще, — весь файл перепишите по своему, и укажите где модуль должен его искать docs.python.org/tutorial/modules.html#packages-in-multiple-directories
Абсолютно не вижу проблем в таком языке программирования как Питон, если в нем конечно хоть немного разбираться…
— цифры?
— уже сказал, setattr(model, 'ClassName', NewUser) или Field.contribute_to_class() (или Model.add_to_class())
Пример как перебить объект в модуле — bitbucket.org/carljm/django-localeurl/src/48e3391e3197/localeurl/models.py только там функция вместо объекта.
> Есть множество способов решить этот вопрос. И даже без raw и extra… SQL в строчном виде. А высокоуровневыми средствами. И не обязательно даже SQLAlchemy… можно плз подробнее?
1. habrahabr.ru/blogs/python/128052/
2. Объявлять модели через свою фабрику, как сделано bitbucket.org/deepwalker/amalgam
3. Использовать SQLBuilder от SQLObject, StormORM, SQLAlchemy, py-smart-sql-constructor и т.п. для создания SQL, и затем подставлять его в Manager.raw(). Там нужно будет решить несколько нюансов, но они решаемы. И даже связи у результата запроса (инстанции модели) подхватываются.
> а jinja2 генериться млн. писем будет гораздо быстрее
— А Вам нужно каждый раз читать и парсить шаблон? Редко бывает, что пути поиска шаблонов в процессе работы скрипта меняются. Всего 5 строчек кода, — и шаблон только единожды прочтётся и распарсится, а затем будет просто реднериться. Потом можете и замеры делать…
90% всех претензий Джанги (а из перечисленных Вами наверное 99%) — это проблема не Джанги, а уровня разработчиков.
Типичные обвинения типа «ОРМ» и «Шаблонизатор» звучат со стороны тех, кто ни разу не открывал исходников Джанги. И почему-то умалчивается тот факт, что 90% синтаксиса Jinja — это синтаксис Django. И почему?
При этом обвинения в сторону производительности шаблонизатора звучат с уст тех, кто ни разу не разрабатывал проекта с посещаемостью более 1000 уник. в сутки… Потому что иначе критерии мышления были бы другими…
Всего 5 строчек кода нужно для того, чтобы в разы поднять производительность шаблонизатора Джанги.
ОРМ Джанги — обычно критикуется зря. Есть костность QuerySet (а не ORM), но эта проблема решаема. Есть множество способов решить этот вопрос. И даже без raw и extra… SQL в строчном виде. А высокоуровневыми средствами. И не обязательно даже SQLAlchemy.
Лично я одинаково отношусь и к Flask, и к Django, и к Svarga (жаль что забросили), и к wep.py (не путать с wep2py), и к Pyramid, и к Plone, и к CherryPy, и к bottle, и к TurboGear…
Но когда проект большой, и «один в поле не воин», тогда Джанго — хороший инструмент. Один только djangopackages.com/ чего стоит… Есть причины, по которым такого «окружения» нет у других фреймверков. Именно причины, а не недостатки. Там где начинается много гибкости, — там обычно заканчивается много унифицированности.
> В других приложениях мне не подошла Джанговоская авторизация и модель юзера. У нас все было завязано на номер сотового телефона — его приходилось хранить в профиле, что было очень не удобно.
— есть масса способов не хранить телефон в профайле, а хранить его в юзере…
> не подошла Джанговоская авторизация
— Авторизация, или аутентификация? Скорее всего аутентификация. Сложно представить ситуацию, когда система аутентификации Джанги может не подойти… по крайней мере, судя по этому github.com/omab/django-social-auth А чтобы интерфейс авторизации не подошел, — еще сложнее верится, опять же, судя по этому djangopackages.com/grids/g/perms/
> Например, авторизация во Фласке позволяет самому задавать класс пользователя.
— setattr(model, 'ClassName', NewUser) тоже позволяет… Но в Вашем случае хватило бы Field.contribute_to_class()
> Получается, что практически все возможности Джанги покрыты, а система гораздо гибче.
— гм… Ну, Flask, вообще-то, хорошая система… мне нравится, по крайней мере… Просто сравнение не совсем корректное…
В 2001 году на проходившем в Сан-Франциско семинаре крупнейшей некоммерческой програмистской организации Кремниевой Долины Software Development Forum Филип Циммерман выступил с заявлением в поддержку арестованного в США программиста «Элкомсофта» Дмитрия Склярова.
Большую часть своего выступления Циммерман посвятил рассказу о, по его мнению, грязных методах, применявшихся властями в отношении него самого, и призвал софтверные компании Кремниевой Долины создать фонд защиты (defence fund) для сбора средств на защиту Дмитрия, отметив, что власти могут в любой момент выдвинуть обвинения против любой американской компании, занимающейся криптографическими исследованиями и вопросами информационной безопасности.
(Из википедии и других источников)
Не «что в Джанго можно использовать только лишь sqlalchemy.sql», а «что в Джанго можно ограничится использованием только sqlalchemy.sql»
— Зато можно всех запугать, и этого может оказаться достаточным, чтобы компенсировать невозможность контроля.
P.S.: Периодически меня посещают мысли, что средства контроля интернета были продуманы еще до самого интернета. Просто позволили людям насладиться «свободой» и под этим соусом втянуть себя в полную зависимость от сети.
Это так, шутка. Не имею ничего против авторских прав, но против цензуры под этим соусом, и против ограничения Конституционных прав одних граждан в пользу других.
Не стоило так растрачивать себя на малолетние споры о необходимости использования более гибких SQL-конструкторов в Джанго. Это и так очевидно для любого человека с опытом разработки на Джанго.
А для тех кому это не очевидно (по причине опыта), — Ваша библиотека просто не нужна, и не стоит никого убеждать ее использовать.
На Джанго Вы, конечно, зря так наехали. Не без «узких мест» конечно, но зато представляет из себя прекрасную экосистему, объединяющую огромное количество разработчиков. На все случаи жизни найдутся готовые решения. Тут трудно найти более более удачный пример.
Справедливости ради, стоит отметить, что в Джанго можно использовать только лишь sqlalchemy.sql, а не весь sqlalchemy. А результат его работы подставлять в Manager.raw(). Возникнут небольшие траблы в паджинацией, но это легко решаемо.
Ваш путь конечно лучше, и предпочтительней, но не без недостатков.
Во первых, Вы сильно привязываетесь к не задокументированному API, стабильность которого никто не гарантирует (а насколько быстро Вы будете реагировать на его изменения, — не известно). Правда, библиотека не большая, и ее можно сопровождать самому, — но все же вопрос остается.
Во вторых, — если используется в проекте GeoDjango, — нужно дорабатывать Вашу библиотеку, чтобы она распознавала новые типы полей и позволяла работать с www.geoalchemy.org/
В третьих, нужно решать вопрос расшаривания соединения, транзакций и пр., но вы вроде бы эти вопросы решали.
Претензий никаких не было.
Теперь будут.
Похоже, суть Вашей статьи — это оптимизация загрузки страницы для небольших сайтиков (а Вы, вероятно только ими и занимаетесь). Только вот непонятно, неужели у них вообще существует потребность в оптимизации?
>Как все это сделать очень легко найти в гугле
Ага-ага. И про обфускацию и минимизацию тоже.
>опять же легко настраивается, но никак не относится к теме.
Да кому нужна эта тема. Людей интересует скорость загрузки, а не басня про шашечки.
P.S.: Последний Ваш комментарий (не без моей подачи) несет больше пользы для читателей, чем сама статья. Будьте внимательней ))
Это решение не всегда является приемлемым. И если для простых сайтов объединение в один файл еще прокатит, то для сложных систем такой подход будет приводить к:
1. К паразитной загрузке ненужных для текущей страницы, но объединенных скриптов. Паразитные скрипты, кроме того, отбирают ресурсы у клиента.
2. Если текущая страница требует своих «особых» скриптов, и если создать разные версии «объединенных» скриптов, — то порождается неоптимальное использование клиентского кеша, и рост траффика, который можно избежать (например ядро jQuery присутствует в нескольких объединенных файлах).
3. Невозможность «параллельной загрузки» (загрузка с разных доменных имен), когда объединение наоборот тормозит загрузку.
В статье не отмечен один из самых важных этапов «згрузочной оптимизации». Это:
1. настройка сервера для сверки etag и отдачи 304. Что позволяет сократить максимально трафик.
2. настройка сервера на использование клиентского кеша ExpiresDefault. Что позволяет вообще избежать обращений к серверу.
3. (про это упоминалось) — настройка gzip сжатия.
При выполнении п.1 и 2, — упаковщик из благодетеля превращается в зло, ибо нивелирует их эффективность.
Тогда возникает вопрос, стоит ли вообще пользоваться упаковщиком. Для маленьких сатов, где вариация невысока, — да, безусловно. Для сложных систем — выгоднее использовать хорошо спроектированную модульную структуру, как сделано, например в Dojo.