Elementor PRO или Bricks: почему я перестал выбирать один WordPress-билдер на все проекты

Споры между Elementor и Bricks обычно сводятся к попытке определить победителя: что быстрее, удобнее, чище, функциональнее.

После нескольких лет работы с WordPress мне такой вопрос кажется не совсем правильным.

Я много работаю с Elementor PRO и не собираюсь от него отказываться. При этом для новых проектов всё чаще смотрю в сторону Bricks.

Причина не в том, что один билдер «хороший», а второй «плохой». Они по-разному вписываются в процесс разработки.

Для себя я сейчас разделяю их примерно так:

Это не универсальная таблица. Это мой текущий рабочий подход.

Почему Elementor PRO всё ещё остаётся в моём стеке

Главное преимущество Elementor для меня — скорость решения типовых клиентских задач.

Нужно собрать несколько шаблонов через Theme Builder, вывести данные из ACF, сделать popup, форму, страницу благодарности, WooCommerce-шаблон — значительная часть необходимого инструментария уже находится в одной экосистеме.

Есть и второй фактор: Elementor давно используется на клиентских сайтах.

Это означает, что разработчик работает не только с новыми проектами. Есть поддержка, редизайны, исправления, новые разделы и сайты, которые были собраны несколько лет назад.

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

Если задача решается нормально внутри существующей архитектуры Elementor, я предпочту её решить там.

Где начинаются проблемы

Сложности появляются, когда визуальный билдер постепенно превращается в основу довольно большого приложения.

Например, проект развивается по такой цепочке:

CPT → ACF → шаблоны → архивы → связанные сущности → фильтры → условия → разные варианты карточек → дополнительный JS → кастомная логика.

Сам Elementor всё ещё можно использовать.

Но по мере усложнения проекта я всё чаще добавляю собственные классы, CSS, JS, PHP-хуки, шорткоды или отдельные решения вокруг билдера.

В какой-то момент возникает вопрос: если я всё равно строю собственную систему поверх визуального редактора, насколько хорошо сам редактор помогает мне эту систему поддерживать?

Именно здесь для меня становится интереснее Bricks.

Что мне нравится в подходе Bricks

Bricks по своей логике ближе к тому, как я привык думать о frontend-разработке.

Не:

«Какой виджет сюда поставить?»

а скорее:

«Как должен быть устроен компонент?»

Есть классы, Flexbox/Grid, шаблоны, компоненты, Query Loop, условия, динамические источники данных.

Особенно заметна разница на динамических проектах.

Допустим, есть каталог с собственной структурой данных.

Я обычно мыслю примерно так:

CPT ↓ACF ↓шаблон отдельной записи ↓компонент карточки ↓Query Loop ↓архив ↓фильтрация

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

И вот эта концепция Bricks мне сейчас ближе.

А что с ACF и динамикой

Для моих проектов это один из ключевых моментов.

На небольшом сайте динамические данные могут ограничиваться телефоном компании и несколькими полями.

На другом проекте уже появляются:

• CPT;

• таксономии;

• группы ACF;

• repeater-поля;

• связанные записи;

• разные шаблоны;

• условный вывод;

• динамические карточки;

• каталоги;

• фильтры.

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

Elementor PRO умеет работать с динамическими данными и ACF, и для большого количества сайтов этого достаточно.

Но когда динамика становится основой проекта, подход Bricks для меня выглядит более естественным.

Почему я всё равно не перевожу все проекты на Bricks

Потому что архитектурная красота — не единственный критерий коммерческой разработки.

Представим небольшой сайт услуг.

На нём:

• 10–15 страниц;

• несколько форм;

• popup;

• обычные страницы услуг;

• новости;

• контакты;

• несколько шаблонов.

Заказчик хочет после запуска самостоятельно менять часть информации.

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

Elementor PRO эту задачу закрывает нормально и привычно.

Более того, клиенту зачастую вообще неинтересно, какие классы, компоненты и query loops находятся внутри.

Его интересует результат.

Bricks тоже требует дисциплины

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

Не исправляет.

Можно сделать хаос в Elementor.

Можно сделать такой же хаос в Bricks.

Если бессистемно создавать классы, дублировать стили, плодить контейнеры и не продумывать структуру данных, другой инструмент не спасёт.

Разница для меня в другом: Bricks сильнее подталкивает именно к разработческому способу организации проекта.

Это преимущество только тогда, когда им действительно пользоваться.

Что получается на практике

Сейчас я не рассматриваю Elementor → Bricks как обязательную миграцию стека.

Скорее у меня появились две рабочие ветки.

Elementor PRO

Использую для:

• быстрых клиентских проектов;

• лендингов;

• корпоративных сайтов;

• проектов, где важна простота дальнейшего редактирования;

• поддержки существующих сайтов;

• задач, для которых уже есть нормальное готовое решение в экосистеме Elementor.

Bricks

Рассматриваю в первую очередь для:

• новых динамических проектов;

• каталогов;

• сложных CPT + ACF структур;

• проектов с большим количеством повторяемых компонентов;

• сайтов, которые предполагается долго развивать;

• случаев, где хочется иметь больше контроля над frontend-структурой.

Вместо вывода

Раньше вопрос для меня звучал так:

Elementor или Bricks?

Сейчас:

какая архитектура нужна этому проекту и какой инструмент позволит реализовать её с меньшим количеством компромиссов?

Это небольшое изменение формулировки, но оно сильно меняет выбор.

Elementor PRO я продолжаю использовать как рабочий коммерческий инструмент.

Bricks постепенно становится для меня вариантом для проектов, где хочется работать с WordPress ближе к обычной frontend-разработке.

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

Читайте еще в блоге → https://vladimir-kozlov.ru/blog/