> большинство MVC-фрейморков в php было слизано именно с RoR
А можете теперь обосновать это? Ну к примеру, сделать таблицу всех PHP фреймворков с указанием пруф ссылки где говорится что данный фреймворк был «слизан» с ROR.
Раз уж решили сравнивать Drupal c фреймворками, то надо определиться, что именно сравнивать.
Если сравнивать качество кода, то тут беспорно Drupal проигрывает, как и любая другая CMS.
Фреймворки чаще обновляются и имеют более современную архитектуру. У них меньше проблем с производительностью. Они легче адаптируются под разные задачи. И ещё, им не важна совместимость между мажорыми версиями и им не нужно поддерживать устаревшие версии PHP (Drupal 7 — PHP 5.2, Drupal 6 — PHP 4).
Если сравнивать с коммерческой точки зрения, то тут ситуациия координально противоположная.
По соотношению цена/качество Друпал в своём сегменте рвёт конкрурентов на запчасти. «Не объяснимая любовь народа к Друпалу» объяснется вполне объяснимой любовью народа к деньгам. Друпал позволяет вам в одиночку делать сложные проекты, для которых в других случаях требуется целая команда зендистов/питонистов/рубистов.
Заказчику, который умеет считать деньги, очень трудно объяснить что его друпал сайт сделал на «неправильном» коде. Особенно если этот сайт отлично работает.
Статья годичной давности, а перевод баянистый, на хабре он уже был и ещё один перевод можно найти здесь.
Перед тем как критиковать автора (не переводчика), нужно хотя бы примерно представлять кто он такой. Daniel F. Kudwien (sun) один из ключевых работчиков ядра друпала. Кроме этого, он является одним из самых продуктивных контрибьютеров в друпал сообществе. Смотрите список модулей в его профиле.
В статье описываются внутренние проблемы, которые происходили при разработке Drupal 7. В последствии эта статья стала активно использоваться в анти-друпал публикациях, причем в абсолютно перевернутом контексте.
Один важный момент, который нужно учитывать при прочтении статьи. Половина разработчиков ядра работает в одной компании (aquia). Есть мнение, что одна из причин кризиса это то, что aquia перестала уделять достаточно внимания разработки ядра друпала. А в некоторых случаях даже пыталась адаптировать его под свои коммерческие интересы. Как раз в этот период начались попытки привлечь новых контрибьютеров в разработку ядра. Со стороны это выглядело как попытка заменить качество на количество.
Drupal 7.0 вышел в январе 2011 года. И он действительно был очень не стабильным. По факту её можно было называть бетой.
Примечательно, что огромное количество багрепортов уже присутствовало к моменту выхода этой версии, но тем не менее это не остановило релиз. Дрис составил релиз план, согласно которому, Drupal 7 должен был выйти как только не останется ни одного критического бага. Мажорные баги остались на втором плане. Показательный момент, после релиза значительная часть багов была исправлена сообществом, однако, следующая минорная версия вышла только через 5 месяцев. Вероятно, из каких то маркетинговых соображений.
P.S. На данный момент актуальная версия 7.15 — вполне стабильное решение.
Можно сказать, что Drupal 7 сейчас находится в пике своей популярности и бОльшая часть пробем, описанных в статье уже не актуальна.
Сам Dan F. Kudwien iсейчас сейчас активно учавствует в разработке Drupal 8.
Имхо, устанавливать сайты из под root-а всё таки не правильно.
Одна из особенностей друпала это то, что он по умолчанию не «привязывается» к домену и может быть установлен не только в корневую директорию сайта. Поэтому нет никакой необходимости для каждого «песочного» сайта добавлять записи в hosts и sites-available. В общем случае можно обойтись одним доменом:
sandbox/site1
sandbox/site2
sandbox/site3
Для автоматизации установки Друпала удобно пользоваться bash в сочетании с drush командами. И ещё есть очень удобная команда drush make (до 5-ой версии Drush была в отдельном модуле ).
В последнее время значительное количество сайтов имеет одну и ту же проблему связанную с очень большим количеством внешних JS файлов. Я имею ввиду JS cниппеты для контекстной рекламы, различных сервисов Яндекса и Гугла, кнопки социальных сетей, счётчики и т.д. Есть сайты, у которых кол-во внешних http запросов составляет 100 и больше…
Типичная ситуация: Сайт проектируется с учётом требований к производительности. Принимаются специальные меры по уменьшению времени загрузки страницы, устанавливаются различные модули для кэширования, покупается дорогой хостинг. Вроде всё ОК, при запуске сайт «летает». Однако, потом начинается наполнение сайта различной JS хренью в угоду SEO и маркетингу. В результате сайт начинает тормозить. Особенно при медленном интернет соединении.
При этом многие владельцы таких сайтов не понимают почему это происходит. Меняют хостинг, нанимают программистов для того, чтобы разогнать «тормознутый» движок и т.д.
А почему именно underscore? Поясните пожалуйста или дайте ссылку на соответствующий раздел в документации
А можете теперь обосновать это? Ну к примеру, сделать таблицу всех PHP фреймворков с указанием пруф ссылки где говорится что данный фреймворк был «слизан» с ROR.
Если сравнивать качество кода, то тут беспорно Drupal проигрывает, как и любая другая CMS.
Фреймворки чаще обновляются и имеют более современную архитектуру. У них меньше проблем с производительностью. Они легче адаптируются под разные задачи. И ещё, им не важна совместимость между мажорыми версиями и им не нужно поддерживать устаревшие версии PHP (Drupal 7 — PHP 5.2, Drupal 6 — PHP 4).
Если сравнивать с коммерческой точки зрения, то тут ситуациия координально противоположная.
По соотношению цена/качество Друпал в своём сегменте рвёт конкрурентов на запчасти. «Не объяснимая любовь народа к Друпалу» объяснется вполне объяснимой любовью народа к деньгам. Друпал позволяет вам в одиночку делать сложные проекты, для которых в других случаях требуется целая команда зендистов/питонистов/рубистов.
Заказчику, который умеет считать деньги, очень трудно объяснить что его друпал сайт сделал на «неправильном» коде. Особенно если этот сайт отлично работает.
Перед тем как критиковать автора (не переводчика), нужно хотя бы примерно представлять кто он такой.
Daniel F. Kudwien (sun) один из ключевых работчиков ядра друпала. Кроме этого, он является одним из самых продуктивных контрибьютеров в друпал сообществе. Смотрите список модулей в его профиле.
В статье описываются внутренние проблемы, которые происходили при разработке Drupal 7. В последствии эта статья стала активно использоваться в анти-друпал публикациях, причем в абсолютно перевернутом контексте.
Один важный момент, который нужно учитывать при прочтении статьи. Половина разработчиков ядра работает в одной компании (aquia). Есть мнение, что одна из причин кризиса это то, что aquia перестала уделять достаточно внимания разработки ядра друпала. А в некоторых случаях даже пыталась адаптировать его под свои коммерческие интересы. Как раз в этот период начались попытки привлечь новых контрибьютеров в разработку ядра. Со стороны это выглядело как попытка заменить качество на количество.
Drupal 7.0 вышел в январе 2011 года. И он действительно был очень не стабильным. По факту её можно было называть бетой.
Примечательно, что огромное количество багрепортов уже присутствовало к моменту выхода этой версии, но тем не менее это не остановило релиз. Дрис составил релиз план, согласно которому, Drupal 7 должен был выйти как только не останется ни одного критического бага. Мажорные баги остались на втором плане. Показательный момент, после релиза значительная часть багов была исправлена сообществом, однако, следующая минорная версия вышла только через 5 месяцев. Вероятно, из каких то маркетинговых соображений.
P.S. На данный момент актуальная версия 7.15 — вполне стабильное решение.
Можно сказать, что Drupal 7 сейчас находится в пике своей популярности и бОльшая часть пробем, описанных в статье уже не актуальна.
Сам Dan F. Kudwien iсейчас сейчас активно учавствует в разработке Drupal 8.
Одна из особенностей друпала это то, что он по умолчанию не «привязывается» к домену и может быть установлен не только в корневую директорию сайта. Поэтому нет никакой необходимости для каждого «песочного» сайта добавлять записи в hosts и sites-available. В общем случае можно обойтись одним доменом:
Для автоматизации установки Друпала удобно пользоваться bash в сочетании с drush командами. И ещё есть очень удобная команда drush make (до 5-ой версии Drush была в отдельном модуле ).
Типичная ситуация: Сайт проектируется с учётом требований к производительности. Принимаются специальные меры по уменьшению времени загрузки страницы, устанавливаются различные модули для кэширования, покупается дорогой хостинг. Вроде всё ОК, при запуске сайт «летает». Однако, потом начинается наполнение сайта различной JS хренью в угоду SEO и маркетингу. В результате сайт начинает тормозить. Особенно при медленном интернет соединении.
При этом многие владельцы таких сайтов не понимают почему это происходит. Меняют хостинг, нанимают программистов для того, чтобы разогнать «тормознутый» движок и т.д.