Вообще-то можно, если не лениться и раскинуть мозгами — мы так не один модуль Битрикса переписали под нужды клиентов. Потому что надо. И потому что умеем думать и выходить за рамки. Сегодня поговорим о стандартных и нестандартных решениях и выборе между CMS и фреймворками: что и для какого случая выбрать.

Одна из самых популярных на западе бесплатных CMS — Wordpress, особенно для разработки простых корпоративных сайтов в компаниях средней руки. Популярна, в основном, по историческим причинам: изначально это блоговый движок, который стали использовать для чего только можно и нельзя. В России на коммерческих проектах встречается не часто (чаще ее можно увидеть на школьных сайтах или личных блогах). Хозяин-барин, но считаем нужным предупредить о главных минусах:

Бесплатные CMS подходят для небольших проектов с ОЧЕНЬ стандартным функционалом: без многогородовости, учета остатков по складам, миллиардов пунктов выдачи по стране, хитрых бронирований и всего такого прочего.

Который год в России де-факто монополист и № 1 — Битрикс. Потому что есть вездесущая 1С, потому что большое комьюнити, потому что какая-никакая техподдержка и потому что есть обучающие курсы для контент-менеджеров (и это далеко не полный список преимуществ).

Вокруг этой CMS много мифов и неконструктивного брюзжания, но в программировании всегда так: либо есть те, кто недоволен технологией и брюзжит, либо это мертвая технология. Если вы в их лагере, советуем прочесть эту статью.

Да, эта CMS на многое способна, её особенно любят владельцы e-commerce за богатые маркетинговые возможности и правила работы с корзиной, но всё-таки Битрикс не всесилен — в нашей практике полно случаев, когда интеграции с 1С-кой были болезненными, а готовые модули приходилось переписывать под конкретные нужды заказчика из-за ограничений самой CMS. То, что сделано у нас на проекте «Проаптека» — вообще невозможно воплотить «из коробки», например.

Код Битрикса иногда бывает нелогичным, хотя над ним трудились толпы специалистов, и с обратной связью у этих ребят проблем нет — клиентов тысячи. В одном из проектов мы раскопали очень странную логику импорта: вывод свойств элементов, которые позже будут использоваться при фильтрации, можно указывать только при их создании — а значит, их не получится обновить. Мы удивились, но поправили, ничего не нарушив  :)

Из этих историй можно вывести лишь одно правило: Битрикс продуман под многие сложные задачки, но в какой-то момент вам этого не хватит. Можно ли будет вылезти за рамки стандартной коробки? Да, и дальше мы расскажем, как именно.

Большая часть наших проектов сделана на Битриксе — +100 к удобству клиента и +200 к скорости разработки. Но сложные штуки (множество форм, профили, личные кабинеты или непростая бизнес-логика) он всё-таки не тянет, поэтому почти всегда подключается популярный фреймворк. Данные при этом удобненько управляются из админки Битрикса (чтобы не писать новую с нуля, что удвоит сроки и стоимость).

Логика здесь простая: если нам нужны вещи, которые не умеет Битрикс — значит нам нужно в ЛЮБОМ СЛУЧАЕ писать код. Иногда — много кода. Так пусть уж он будет хорошо-структурированным, стандартизованным, в классическом MVC-стиле, с коллекциями, роутерами и легко читаться профессионалами.

У нас есть опыт «склейки» Bitrix+ZendFramework (Laminas) и Bitrix+Laravel. На текущий момент (2022) мы используем Laravel. Здесь намеренно не упоминаем Bitrix Framework, так как он, мягко говоря, недоделан. Технология «склейки» отработана нами очень давно.

Это предпочтение большинства программистов. А также большинства технических директоров на стороне клиента. Скорость, гибкость, власть над кодом — все это дает нам хороший фреймворк (такой, как Laravel). Однако разрабатывать на чистом фреймворке корпоративный сайтик или простой интернет-магазин — иррациональная по бюджетам затея.

Когда же нужен на самом деле фреймворк? На сайтах-сервисах, стартапах, личных кабинетах, при разработке API для сторонних ресурсов или мобильных приложений. И там, где технический директор на стороне клиента категорически против Битрикса ;)