Пользователь
40,1
рейтинг
20 ноября 2015 в 14:14

Разработка → Вышел Drupal 8 — критический взгляд


После четырёх лет разработки наконец вышла стабильная версия Drupal 8. При этом реакция сообщества оказалась довольно разделенной, одни считают, что этот релиз имеет все шансы полностью свергнуть и заменить Wordpress, другие, что после стольких лет Drupal растерял большинство пользовательской базы и вряд ли соберет ее обратно. Вся причина в иной идеологии чем в других CMS, Drupal 8 делает упор на расширяемость и удобство разработки вместо просто редактирования контента. Как результат по-настоящему оценить его можно будет только года через два, когда уже наполнится база модулей. Но раз он уже вышел, то попробуем посмотреть на ту функциональность, какая есть с точки зрения разработки уже сегодня.

Symfony 2
Еще с самого начала самая нашумевшая новость была о переходе на компоненты Symfony 2. Это сильно упрощает порог входа для тех разработчиков которые уже с ними знакомы, но может отпугнуть многих привыкших к функциональному программированию на Wordpress. А ведь ассортимент плагинов зависит от размера сообщества и является важным фактором при выборе CMS. Кстати стоит заметить что Symfony2 не самый быстрый фреймворк, что приводит к следующему пункту.

Скорость работы
Бенчмарки беты показывали упадок в скорости в 3-4 раза в сравнении с Drupal 7, который сам был намного медленнее Wordpress.

image

Но infanty убедил меня попробовать сделать отдельный бенчмарк, я создал DigitalOcean дроплет за 5$/месяц и вот его результаты:

Кэш включен

#siege -b -c20 -t60S http://xxxxxxxx/drupal7/taxonomy/term/1

Transactions:		       11892 hits
Availability:		      100.00 %
Elapsed time:		       59.10 secs
Data transferred:	       36.69 MB
Response time:		        0.10 secs
Transaction rate:	      201.22 trans/sec
Throughput:		        0.62 MB/sec
Concurrency:		       19.93
Successful transactions:       11892
Failed transactions:	           0
Longest transaction:	        1.31
Shortest transaction:	        0.03


#siege -b -c20 -t60S http://xxxxxxxx/drupal8/taxonomy/term/1

Transactions:		        5843 hits
Availability:		      100.00 %
Elapsed time:		       59.84 secs
Data transferred:	       20.48 MB
Response time:		        0.20 secs
Transaction rate:	       97.64 trans/sec
Throughput:		        0.34 MB/sec
Concurrency:		       19.96
Successful transactions:        5843
Failed transactions:	           0
Longest transaction:	        1.36
Shortest transaction:	        0.07


Больше чем в два раза медленнее в сравнении с предыдущей версией!
Еще один бенчмарк родившейся благодаря chilic из сегодняшнего холивора: devhell.ru/drupal-7-vs-drupal-8-performance

Встроенный CKEditor
Найти красивый WYSIWYG редактор для Drupal 7 всегда было проблемой. Стандартный редактор имел очень сильно урезанный функционал и выглядел как дитя 90-х, особенно на фоне встроенного редактора Wordpress. Сегодняшний CKEditor выглядит уже намного лучше.

image

Все дальше нет менеджера рисунков
Загрузить рисунок в статью можно, но функционал существенно урезан. В Wordpress есть менеджер загрузок, автоматический ресайз под несколько размеров, даже банальное удаление. В Drupal 8 можно просто загрузить и вставить. Конечно, со временем кто-то сделает модуль с нужным функционалом, но пока ничего нет.

Quickedit
Это новая возможность редактировать текст прямо на странице, что очень удобно для быстрых правок, красиво смотрится и легко продается клиентам.

image

Views из коробки
Самый популярный плагин из Drupal 7 позволяющий строить произвольные списки контента, виджеты и прочее теперь доступен из коробки. Фактически он являлся киллер фичей, так что его включение в Core не может не радовать.

Twig
Drupal 8 теперь использует тот же шаблонизатор что и Symfony2. Хорошее решение, думаю, многим понравится.

Встроенная мультиязычность
Выглядит очень хорошо и вполне может стать точкой выбора Drupal 8 для многих сайтов.

Под капотом



REST API
Очень интересная фича, открывающая много возможностей по связке сайта, например, с мобильными приложениями.

Свой стиль кода
Я очень надеялся, что если они уж решили взять Symfony2 за основу, то будут использовать и их стандарт кода, но нет. Вместо привычного PSR-2 нас ждет свой стиль кода основан на старом PEAR стандарте.

Не совсем ООП
Если вас раздражали всяческие хуки, массивы и магические строки в Drupal 7, которые надо было знать наизусть и вы ожидали красивого ООП подхода, то тут тоже немного разочарование. По коду все равно бегают массивы, магические строки перекочевали из хуков в .yml файлы конфигурации. Но зато есть DI контейнер.

Свой ORM
Идея построить Drupal 8 на Doctrine прошла только частично, из нее используется только парсер для аннотаций. Как минимум можно было взять еще и DBAL. В любом случае, как раз ORM самая часто использованная часть после может темплейтинга, было бы хорошо не изобретать новый велосипед.

Мои мысли


Не думаю, что он пошатнет Wordpress. Скорость работы и разработки являются критическими факторами для множества компаний, делающих сайты под заказ. Скорее всего, он займет нишу фреймворка для более сложных сайтов, может, даже чуть-чуть заменив на рынке саму Symfony2.

Попробовать Drupal 8 можно тут (нужна регистрация, но не надо подтверждать email).
@jigpuzzled
карма
20,7
рейтинг 40,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (51)

  • +1
    Сразу видно, автор не знаком с Drupal.

    Стандартный редактор имел очень сильно урезанный функционал и выглядел как дитя 90-х, особенно на фоне встроенного редактора Wordpress.

    Стандартного редактора в друпале не было вообще. Он появился только с 8 версией. В тоже время для семерки есть сторонние модули CKEditor и Wysiwyg, которые позволяют подключать 11 различных редакторов.
    • 0
      Да, правда, вспомнил. Я давно уже не работал с Drupal 7 и всегда мой первый шаг был установкой www.drupal.org/project/wysiwyg, его практически все и использовали вот я его стандартным и обозвал.

      Обилие едиторов поддерживаемых Wysiwyg было скорее проблемой чем фишкой. Лучше бы сделали один но красиво ( как теперь в 8-ке )
      • 0
        Это CKEditor красивый?
        • 0
          C Wordpress не сравнится конечно, но лучше чем было =)
    • 0
      Но сделать подобное Wordpress-у ОЧЕНЬ нетривиально. Как минимум у меня путем только конфигурирования готовых модулей не вышло.
      Сам являюсь бэкенд разработчиком под Друпал, но для своих контент проектов выбрал Wordpress, только ради редактора, в котором людям легче работать. (Хотя бэкенд часть ВП приводит меня несколько в ужас конечно и расширять функционал на него сильно сложнее\неудобнее)
      В идеале конечно было бы лучше допилить все на друпал, но просто нет времени и сил на это :\.
  • +2
    Мда… если производительность восьмерки действительно в три раза хуже семерки, то это полная *опа. Из моей практики, значительная часть времени при разработке Друпал-проекта уходила не на реализацию фич, а на то, чтобы продумать стратегию того как-бы похитрее закешировать данные, а потом вовремя инвалидировать кеш. С восьмеркой, видимо, это время только возрастет.
    • +2
      Должно быть намного лучше, т.к. на графике не показаны версии php на которых оно сравнивалось, к тому же сравнивается beta11 а не stable релиз. Вроде как в каждом релизе 8ки что-то делалось для производительности.
  • +5
    функциональному программированию на Wordpress
    не путайте функциональное и процедурное программирование. Функциональным программированием в Wordpress и не пахнет.
    • –1
      Спасибо, я имел ввиду не саму функцыональную парадигму, а сам процесс создания плагина где все завязано на хуках и функциях. Но да, лучше поправлю, а то звучит неправильно
  • 0
    Про реализацию мультиязычности бы поподробнее
  • –2
    попробуем посмотреть на тот функционал


    Вы хотели сказать «на ту функциональность». Функционал — это из математики.
    • +1
      Спасибо, туплю
  • +4
    11 бета восьмёрки против 34 минора семёрки, вы это серьёзно или критически?
    • 0
      Просто та статья уже готова была. Я пробовал вчерашнею версию у себя на сервере, ничем не лучше.
  • +5
    Я не призываю минусовать автора, но в текущем варианте статья просто вброс. Автор не компетентен по производительности, в каждом RC drupal производилась доработка производительности и RC2 от VS beta отличаетсяя по производительности в десятки раз.

    Уже в RC1 Drupal 8 alexrayu.com/blog/should-we-be-very-concerned-drupal-8-performance-drop производительность D7 vs D8 была ещё печальной, но уже видно насколько она быстрее вордпресса без покупных плагинов кэширования.

    А в RC2 Drupal 8 www.redy.host/blog/drupal-741-vs-drupal-8-rc2-benchmarking-analysis производительность D7 vs D8 всего на 30% отличается. При этом в D8 имеется Views размером с сам D7, т.е. если в D7 поставить модули, чтоб он по функционалу был как D8 то разница производительности будет ещё меньше.

    При этом D8 оптимизирован под PHP7 и на нём в разы быстрее — www.redy.host/blog/php-7rc5-released-heating-drupal-8-performance-concerns а вот PHP7 + D7 всё по печальнее — www.drupal.org/node/2454439 при этом есть модули сообщества для D7 которые нужны и годами для D7 не обновлялись (какая уж совместимость), а в D8 их аналог уже в коробке.
    • +1
      Я вот выше комментом написал что буквально вчера пробовал у себя на сервере и получил почти те же результаты.

      Apache2 + PHP-FPM ( PHP 7 RC 7 ) + MariaDB
      Intel Xeon CPU X5650 @ 2.67GHz

      Может я какой-то кеш не включил или что. Пробовал голый 8 против голого 7.
      • 0
        Тут нужно смотреть, возможно что то просто мешает хорошим тестам. Я бы порекомендовал попробовать NGINX + PHP-FPM 5.6 c opcache и MySQL или аналог версии > 5.6. И при тестах мониторить I/O. Бывает проблема с тем что Apache2.2, а не Apache2.4 стоит и он притормаживает. Бывает база начинает тормозить при большой нагрузке. В таком случае может показаться, что виноват Drupal, а тормоза из-за оборудования, при повторении тестов на другом оборудовании показатели могут быть лучше.

        В одной из версий RC D8 было внедрено и включено по умолчанию динамичное кэширование страниц которое довольно хорошо добавили скорости. Подробнее об этом — wimleers.com/blog/drupal-8-page-caching-enabled-by-default. Возможно Вы обновили файлы не обновляя базу данных и при тестировании не включили кэширование?
        • 0
          Ну у меня на этой связке куча сайтов крутится ( порядка 30-ти), так что не думаю что проблема в апаче или базе. Потом на DigitalOcean закину демку для всех если время будет. Там и попробуем =)
          • 0
            Я Вас понимаю, но это не значит что настройки оптимальные и тормозит именно Drupal. В поддержке находится инстанс с PHP 4, на нём Drupal 5 работает а Drupal 7 нет — это не значит, что Drupal 7 плохой. Нужны сравнения как минимум на NGINX + PHP-FPM 5.6 c opcache и MySQL или аналог версии > 5.5. Apache может давать неплохую погрешность (особенно версии 2.2), HDD вместо SSD могут очень тормозить базу данных и поэтому нужно мониторить I/O. И в таком случае тесты превращаются в сферического коня в вакууме. А сферический конь в вакууме это плохо — обижает сообщество, особенно если Вы не являетесь его частью.
            • +1
              Так я же написал что у меня ПХП 7 (под какую вы говорите он уже оптимизирован ) опкеш включен, Апач 2.4, SSD тоже есть (глупо было бы ставить Ксеон и не запускать на SSD )

              Но если честно тестировать надо как раз таки на стандартном shared хостинге на которых куча сайтов крутиться и Wordpress на ура работает.
              • 0
                Чуть ниже написал. Используем digitalocean и vscale, тестами с них могу дополнить новую статью, если вы решите написать расширенные тесты.
            • 0
              У Вас хорошие статьи по PHPixie, если у Вас будет желание написать статью про собственное тестирование Drupal8, то напишите в личные сообщения и я с технической стороны помогу как тестами на своём оборудовании, так и могу помочь рекомендациями по статье, если это Вам поможет.
              • 0
                Пасяб =) У меня еще лишних 20$ на DigitalOcean есть, так что можно попробовать в нескольких кофигах. Сейчас что-то попробую запустить =)

                Если результат кривой будет скину код и попробуем у вас =)
                • 0
                  Хорошо.
                  • 0
                    Запустил, щас обновлю статью
                    • 0
                      Показатели уже лучше )), нужно будет самому более расширенное тестирвоание провести и написать статью на эту тему.
                  • 0
                    Вот теперь точно готово, все кешы включены
                    • 0
                      стоит еще оптимизировать автолоад, инклудов там очень много и это существенно сказывалось в rc-1, в консоли:
                      composer dump-autoload -o
                      

                      • 0
                        Там opcache жестко настроен, так сто разница только при первом запросе
                        • 0
                          нет, опкеш не помогает с функцией file_exists которую вызывает автолоадер без дампа, либо нужно включать enable_file_override в opcache
                          • 0
                            так он ее ведь вызывает только если class_exists не прошел
    • +1
      К нашей общей переписке с jigpuzzled подключился chilic (точнее ребята подключили меня), ссылку на его тесты (chilic-a) добавили в статью. Не совсем однозначно получается с производительностью, хорошая тема для статьи — исследования в drupal блог на Хабрахабр. Ребят, спасибо, что такие отзывчивые, приятно когда авторы вступают в диалог и вместе помогают найти истину.
  • 0
    после стольких лет Drupal растерял большинство пользовательской базы и вряд ли соберет ее обратно


    Русских разработчиков тоже заметно поубавилось в Drupal-сфере.

    Посмотрите на Хабре старые анонсы, да и вообще статьи по Drupal, минимум по 40 комментариев, а проявленного интереса много.
  • 0
    после стольких лет Drupal растерял большинство пользовательской базы и вряд ли соберет ее обратно

    а есть цифры?
  • +3
    Несколько моментов по поводу производительности Drupal 8 vs Drupal 7:

    1. Само сравнение не корректно. Так как в Drupal 7 отсутствует большая куча модулей которые в Drupal 8 присутствуют в ядре. Тоже самое когда то говорили про сравнение Drupal 7 vs Drupal 6.
    2. Drupal 8 (теоретически) должен лучше масштабироваться в следствии новой архитектуры (сервисы, ленивая загрузка кода, отсутствие module файлов, на порядок меньшее кол-во хуков) и т.д. Было бы интересно увидеть бенчмарки какого нибудь интерпрайз проекта (200+ включенных модулей) до и после миграции.
    3. В Drupal 8 количество включенных модулей на стреднестатистическом сайте будет меньше (теоретически). В первую очередь из-за новой системы конфигурации, котороая позволяет избавится от необходимости держать включенными features модули (на некоторых проектах их десятки).
    4. Новоя структура файлов (PSR4) также позволяет уменьшить количество модулей. Если на крупном Drupal 7 проекте поместить весь самодельный код в один модуль, то получится огромный module файл-портянка, который трудно поддерживать. По этой же причине крупные contributed модули реализованны ввиде кучи под модулей (например OG).
    5. Новое cache API. По словам разработчиков Drupal 8 может отдавать страницы для авторизованных пользователей почти с такой же скоростью как для анонимных пользователей. Так как такое кэширование требует индивидуальной настройки для каждого конкретного сайта и не работает из коробки в приведенных бенчмарках это абсолютно не учтено. Нужно отметить что новая система кэширования очень сложная (cache tags, cache contexts, cache placeholders и т.д.) и наверно многие разработчики даже не станут с ней разбиратся...


    • +3
      Drupal 8 is the fastest Drupal ever.
      Fabian Franz — Drupal core maintainer

      DrupalCon Barcelona 2015: Making Drupal fly — The fastest Drupal ever is here! (слайды)
    • 0
      в Drupal 7 отсутствует большая куча модулей которые в Drupal 8 присутствуют в ядре


      от того что они в ядре, меньше ресурсов они потреблять не стали

      отсутствие module файлов, на порядок меньшее кол-во хуков


      module файлы не месте, уменьшение числа хуков с лихвой перекрывает увеличение числа классов и интерфейсов

      Так как такое кэширование требует индивидуальной настройки для каждого конкретного сайта и не работает из коробки в приведенных бенчмарках это абсолютно не учтено


      это кэширование не требует индивидуальной настройки и работает из коробки, оно даже включено по умолчанию. см модуль Internal Dynamic Page Cache — wimleers.com/blog/drupal-8-page-caching-enabled-by-default
      • 0
        Модули в ядре D8 может и не стали потреблять меньше ресурсов, но в D7 их все равно скорее всего пришлось бы ставить на рабочий сайт (хотя бы Views), а в сравнении D7 голый, т.е. получает фору.
  • +1
    Сравнивать Wordpress и Drupal 8 как минимум некорректно, это тоже самое что сравнивать автобус и легковой автомобиль. Drupal целенаправленно двигается в сторону фреймворков и энтерпрайз разработки.
    • +1
      Вообще да, было бы весьма забавно посмотреть как решались бы Drupal задачи на Wordpress сайте :)
  • 0
    от того что они в ядре, меньше ресурсов они потреблять не стали

    Да, но в бенчмарках голая 7-ка без этих модулей.

    уменьшение числа хуков с лихвой перекрывает увеличение числа классов и интерфейсов

    Это спорно.

    это кэширование не требует индивидуальной настройки и работает из коробки

    Потребует на реальном проекте. Только разработчик может точно знать бизнес логику и соотетственно решить как и для кого должны кэшироваться страницы, блоки, вьюхи и т.д., а так же определить в какие моменты должна происходить инвалидация кэша.

    • 0
      Да, но в бенчмарках голая 7-ка без этих модулей.

      установка views мало что изменит

      Это спорно.

      всё крайне однозначно — www.drupal.ru/comment/652502#comment-652502
      • 0
        Хорошие скриншоты в комментарии у Gor-а который Вы привели. Функций стало больше, вызовов больше, больше тиков процессора на обработку требуется. Всё это отставание можно наверстать только кэшированием всего и вся и ещё поэлементно со сбором из частей другого кэша (как Varnish + ESI из коробки), что из коробки и было встроено в D8. Если бы такое кэширование из коробки перенести на D7 или в Backdrop CMS, то была бы хорошая замена Varnish + ESI который стоит не на всех хостингах и не все его умеют настраивать.
  • +2
    К вопросу о популярности: по-моему, Drupal потерял позиции из-за кастомизируемости и стремления быть Content Manage Framework, следовательно, более высокого порога входа, чем у других CMS. Я базируюсь на своём скудном опыте, но, IMHO, моя история показательна.
    Как-то лет пять назад я схватил Drupal и два модуля к нему — Views и CCK, большую часть остальных выкинул за ненадобностью. Для меня, не имевшего дела с вебом, это был очень позитивный опыт: я почувствовал, что действительно управляю контентом, строю сайт под себя. Views и CCK стали для меня краеугольным камнем.
    Но, изучив веб-фреймворки я понял, что переизобретаю модели. Встал вопрос: зачем мне Drupal, если всё, что мне надо, дают фрейворки, при этом я получаю сходный уровень абстракции при лучшей управляемости и понимании, как оно работает. Я для себя на этот вопрос ответил, увы, не в пользу Drupal.
    • 0
      А можете поподробнее описать — на какие фреймворки перешли после Drupal? Мне не нравится, что в друпал слишком много лишнего, хотелось бы перейти в некоторых задачах на что-то более легковесное, но с удобным веб-конструктором моделей, сущностей, представлений, чтобы не в коде ковыряться-описывать все, а как в друпал — прямо в админке создал entity, поля, связи, представления страницы. Ну а результаты уже превратяться в код, который я уже причешу под себя.

      Или фреймворки это как раз когда все ручками пишешь в коде, без удобного интерфейса админки?
      • 0
        А можете поподробнее описать — на какие фреймворки перешли после Drupal?

        Остановился, в итоге на Django и Flask, поэтому простите, за PHP-аналоги не поясню.
        с удобным веб-конструктором моделей, сущностей, представлений, чтобы не в коде ковыряться-описывать все,

        Из того, что я видел — да, всё код.
        а как в друпал — прямо в админке создал entity, поля, связи, представления страницы. Ну а результаты уже превратяться в код, который я уже причешу под себя.

        Из того что видел — обратное, изменения в коде отражаются на админке.

        Но, опять же, повторюсь, разработка для меня хобби, мой опыт скуден. Но я посмею дать совет — возьмите фреймворк на языке, который знаете, возьмите руководство (практически ко всех фреймворкам руководства хороши) и, если у Вас уже есть проект — попытайтесь переписать его на этом фрейморке; если нет — ну, обычно к фреймворку есть учебный проект.
        Удачи!
  • 0
    Популярность потерял, потому что работает на «инженеров», а не на контент-менеджеров. Впрочем это написано в посте

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.