Я — Валерий Комягин, руководитель одной из ведущих российских компаний по заказной веб-разработке. Мы часто доказываем клиенту, что выбор распространенной в России системы 1С-Битрикс — плохая идея для больших и нестандартных проектов. Но есть задачи, которые Битрикс решает хорошо. Я решил изложить свою позицию в одной статье.
Чаще всего нам поручают создание проектов с нестандартной логикой, стартапов, интегрированных решений и сайтов с высокой посещаемостью. Поэтому наша основная платформа для разработки — это связка из Vue.js на фронтенде и PHP-фреймворка Laravel на бэкенде. Наше «поэтому» часто оказывается неочевидным для заказчика. Значит, нужны пояснения.
Моё мнение
1С-Битрикс (и CMS-концепция в целом) хорошо подходит для небольших проектов с типичной механикой и алгоритмами, которые более, чем на 75%, совпадают с возможностями 1С-Битрикс «из коробки».
Laravel (и концепция фреймворков в целом) хорошо подходит для амбициозных проектов с высокой скоростью масштабирования, большим числом интеграции и сложными нетипичными механиками.
Таблица сравнения 1С-Битрикс и Laravel
Эту таблицу мы собирали всей командой для своих заказчиков, но решили поделиться со всеми. В статье под таблицей я всё поясню подробно.
Фундаментальные знания
Сразу признаюсь: я затеял сложное сравнение, «тёплого с мягким».
Два продукта — яркие представители двух совершенно разных классов, двух концепций.
1С-Битрикс — это CMS.
Laravel — фреймворк.
Разберемся с фундаментальными определениями, они важны для понимания.
1. CMS
CMS — это сокращение от Content Management System (Система управления контентом).
Удачное определение подсказывает Википедия:
CMS — это компьютерная программа, которая используется для обеспечения и организации совместного процесса создания, редактирования и управления содержимым.
В этом определении заключена главная концепция:
CMS — это цельный продукт, главная задача которого заключается в облегчении работы с контентом.
В том, что касается методов представления контента, CMS ограничивает свободу пользователя в угоду главной функции — удобству работы с контентом.
Я люблю использовать сравнение CMS с наборами детского конструктора. Да, из них можно собрать какое-то количество замков и крепостей. Но если вам потребуется деталь, которой нет в конструкторе, — задуманный замок вы не построите.
2. Framework
И снова соглашусь с Википедией:
Фреймворк — это программная платформа, которая определяет структуру программной системы; иначе — программное обеспечение, которое облегчает разработку и объединение разных компонентов большого программного проекта.
Обратите внимание, здесь уже нет ни слова об удобстве работы с контентом. Основное внимание во фреймворке уделено «структуре» и «архитектуре». А понятие «большого программного проекта» акцентировано даже в самом определении.
По моей аналогии, фреймворк — это станок по производству любых деталей для детских конструкторов. Это умный станок, он сам следит за тем, чтобы детали были совместимыми, надежными и безопасными (разумеется, при соблюдении правил эксплуатации).
3. Иерархическое представление
В основе практически любого фреймворка лежит тот или иной язык программирования.
В основе практически любой CMS-системы лежит тот или иной фреймворк.
Фреймворки предоставляют больше свободы для разработчика, при этом с их помощью можно разработать интерфейсы, вполне комфортные для редактора контента.
CMS-системы, в свою очередь, предоставляют максимум удобств для контент-редактора и в такой же максимальной степени ограничивают возможности разработчика.
Преимущества каждой концепции с точки зрения пользователя
Мы разобрались с базовым пониманием каждой концепции. Теперь зафиксируем преимущества каждой из них с точки зрения конечного пользователя — то есть заказчика, будущего владельца разработанного сайта.
1 — Скорость разработки
Здесь CMS одерживает безоговорочную победу.
Из «кубиков LEGO» внутри 1С-Битрикс можно собрать за считанные дни (иногда и за один день) даже такой сложный сайт, как интернет-магазин.
При одной важной оговорке — если ничего не менять в бизнес-логике такого интернет-магазина и полностью согласиться с тем, как видит правильный интернет-магазин 1С-Битрикс.
Сборка такого же несложного e-commerce-решения с помощью фреймворка потребует значительно больше времени.
Да, для фреймворков существует огромное количество готовых библиотек, а опытный разработчик уже располагает достаточным числом «заготовок». Но при прочих равных фреймворк-разработка всё-таки займет больше времени.
2 — Независимость от конкретного разработчика
Вспоминаем этот рекламный лозунг 1С-Битрикс :)
В каком-то смысле — это правда. С этой CMS работают тысячи компаний по всей стране.
Но всё же полная независимость — это миф и лукавство.
Во-первых, с фреймворком Laravel точно так же работают тысячи компаний, но уже не только в России, а по всему миру!
Приложив эквивалентные усилия, вы сможете найти преемника по разработке и в случае 1С-Битрикс, и в случае Laravel.
Во-вторых, основной рекламный довод 1С-Битрикс верен лишь частично.
Да, это «единая система», с которой знакомы все разработчики. Но это единство работает только в том случае, если сайт полностью собран на стандартных «инфоблоках» (так называются готовые модули в 1С-Битрикс), а заказчик не просил разработчика перестроить бизнес-логику под себя. Но такая ситуация — скорее исключение, чем правило.
Если же разработчик внес изменения в стандартные конструкции компонентов 1С-Битрикс, разобраться с таким измененным продуктом преемнику будет весьма непросто.
С моей точки зрения, использование фреймворка не вызывает никаких серьезных проблем с передачей проекта от одной команды другой.
Фреймворк предоставляет единый набор правил разработки, хотя и требует как значительно более высокой квалификации разработчика по сравнению с Битрикс, так и четкого соблюдения всех принципов и правил кодирования и документирования проекта.
Важный момент: в случае отсутствия квалифицированного IT-персонала, заказчику будет непросто контролировать качество кода и документации в таких фреймворк-проектах.
3 — Панель администратора
Панель управления («админка») — еще одно серьезное конкурентное преимущество 1С-Битрикс.
Админка у 1С-Битрикс продуманная и удобная. В своё время за её интерфейс отвечала одна из лучших дизайн-команд страны (AIC). Но здесь ограничения для разработчика еще жёстче — изменять логику админки в 1С-Битрикс практически невозможно. Если вам будет неудобно, придется… привыкать.
Для Laravel админку придётся разработать.
У опытных команд уже есть наработки, и чаще всего их админки выглядят ненамного хуже 1С-Битрикс (а некоторые и гораздо лучше). При выборе команды попросите показать вам административные панели ранее выполненных проектов — поймете, что вы получите по итогам проекта.
Но разработка своей панели управления — однозначное преимущество Laravel!
Разработчики построят такую панель управления, которая нужна именно вам.
Иногда это критично. Например, в случае ведения текстовой онлайн-трансляции спортивного матча, когда скорость ввода данных (использования админки) чрезвычайно важна.
4 — Скорость работы
Скорость обработки данных и загрузки страниц является очень важным параметром сразу по нескольким причинам.
- Это влияет на SEO: чем выше скорость загрузки сайта, тем выше он будет в результатах поисковой выдачи.
- Это влияет на конверсию: чем дольше посетитель ждет загрузки страницы, тем ниже вероятность, что он что-то купит.
И вот здесь сильнейшая сторона 1С-Битрикс — универсальность и множество функций, доступных «из коробки», становится его же ахиллесовой пятой.
При загрузке каждой страницы 1С-Битрикс опрашивает множество своих модулей, пытаясь понять, задействованы ли они в данном проекте или нет. Это многократно увеличивает время, нужное для обработки каждой страницы.
1С-Битрикс — медленная платформа.
Кроме этого, из-за своеобразной архитектуры хранения данных, 1С-Битрикс очень тяжело справляется с большой номенклатурой. Если в ваших каталогах десятки и сотни тысяч товаров, сайт будет работать очень медленно. Проблема частично решается только через специальные манипуляции.
При прочих равных, фреймворк Laravel по этому параметру безоговорочно выигрывает у 1С-Битрикс и по скорости обработки больших данных, и по скорости загрузки страниц.
5 — Техническая поддержка
Laravel — это бесплатный фреймворк с открытым исходным кодом, который можно использовать по Лицензии MIT. Официальной службы поддержки нет. Но зато к услугам разработчика — огромное комьюнити, форумы и актуальная документация. Как правило, этого достаточно для решения большинства вопросов.
1С-Битрикс — это коммерческий продукт, стоимость которого, в зависимости от редакции, составляет от 5,4 тысяч рублей до 1,5 миллионов рублей. У компании есть служба поддержки, но оперативность и качество ответов является «притчей во языцех».
Да, поддержка способна достаточно грамотно ответить на большинство вопросов пользователей, касающихся интерфейса системы, но разработчик чаще всего остается один на один со своей проблемой и вынужден скитаться по форумам и коммьюнити других разработчиков. То есть точно так же, как и в случае с Laravel.
6 — Требуемая квалификация разработчика
1С-Битрикс предъявляет «минимальные системные требования» к разработчикам.
Но работать на этом продукте талантливые специалисты не хотят.
Для разработки на Laravel нужны инженеры с высокой квалификацией. Но наиболее одаренные программисты предпочитают работать именно с фреймворками.
7 — Доступное число разработчиков и уровень зарплат
По данным hh.ru на май 2021 года, в России в поиске работы находились 4500 1С-Битрикс-программистов и 500 Laravel-специалистов. Средний оклад первых оценивался в 120-150 тысяч рублей, вторых — в 150-300 тысяч рублей.
Таким образом, по ситуации на рынке труда, 1С-Битрикс-программистов значительно больше, и они гораздо дешевле Laravel-программистов.
Но по факту часто оказывается так: качество подавляющего числа найденных 1С-Битрикс-программистов окажется низким, а опыт — недостаточным.
Если для проекта нужны по-настоящему качественные инженеры, вы быстрее их найдете, если будете искать для работы с фреймворком, а не с CMS.
8 — Требования к хостингу
1С-Битрикс, как я уже отметил, — медленная и неповоротливая система. Чтобы она работала приемлемо, при прочих равных ей нужно гораздо больше «аппаратных ресурсов», чем для проектов, реализованных на базе фреймворка.
Проще говоря, проекты на 1С-Битрикс прожорливы и требовательны к ресурсам. Поэтому на хостинг вы будете тратить больше. Гораздо больше.
Преимущества каждой концепции с точки зрения разработчика
1 — Единая концепция разработки
1С-Битрикс поддерживает MVC-модель разработки.
MVC (Model-View-Controller) — это схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо.
Простыми словами, это когда данные, логика и шаблоны отображения аккуратно разложены по полочкам, отдельно друг от друга.
При использовании такой модели код получается аккуратным и чистым, проект работает быстрее, его легче масштабировать.
Но это заявление 1С-Битрикс очень формально.
На деле, разработчик 1С-Битрикс очень часто сталкивается с ситуацией, когда файлы проекта представляют собой свалку из HTML, JS- и PHP-кода. Разобраться в такой «вермишели» очень непросто. Работать с таким кодом неприятно и неудобно.
Laravel декларирует принципы «красивой разработки». Лучшие практики создания кода описаны как в самой документации по фреймворку, так и в сообществе разработчиков.
Безусловно, написать «свалку» можно и при помощи Laravel. Но если у Laravel-программиста есть выбор, у 1С-Битрикс-программиста такого выбора нет.
2 — Качество кода и соблюдение принципов ООП
Фреймворк, на котором построен 1С-Битрикс, часто подвергается критике из-за устаревшей концепции использования массивов, в то время как все современные инструменты разработки уже давно перешли на модель ООП.
ООП (Объектно-ориентированное программирование) — методология программирования, которая основана на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования.
Формально, новое ядро 1С-Битрикс использует основные принципы ООП, но делает это скорее «для галочки», не предоставляя реальных преимуществ разработчику.
Laravel предоставляет все необходимые возможности для написания качественного структурированного кода (например, для внедрения зависимостей, то есть использования Dependency Injection).
Dependency injection (DI) — процесс предоставления внешней зависимости программному компоненту, когда объект отдаёт заботу о построении требуемых ему зависимостей внешнему, специально предназначенному для этого общему механизму.
Такой код легче тестировать и гораздо легче масштабировать.
В первую очередь, благодаря использованию статических анализаторов кода, применять которые на 1С-Битрикс невозможно.
3 — Шаблонизатор
Шаблонизатор помогает отделить «шаблоны оформления» данных от исполняемого кода.
В чём практическая польза? — Это помогает ускорить разработку проекта, делая возможной параллельную работу фронтенд- и бэкенд-разработчика.
У 1С-Битрикс нет встроенного шаблонизатора. Разработчику необходимо самостоятельно его подключить. Чаще всего используют распространенные шаблонизаторы Twig или Smarty.
В экосистему Laravel уже встроен производительный шаблонизатор Blade.
4 — Кастомизация готовых компонентов
Чаще всего бывает так, что готовый компонент 1C-Битрикс не соответствует бизнес-процессам заказчика и нужно изменить его стандартную логику.
У Laravel с этим нет проблем — он изначально создан для разработки проектов «с нуля», поэтому предоставляет максимальную свободу разработчику.
1С-Битрикс официально заявляет о такой возможности. На деле же, кастомизация типовых компонентов очень часто затруднена из-за избыточного кода и чрезмерной связности компонентов между собой. Всё это вынуждает разработчика писать «костыли», которые помогают обходить ограничения платформы.
Самое печальное: нередко совет написать такой «костыль» можно услышать даже из уст специалистов официальной техподдержки 1С-Битрикс.
5 — Возможность построения микросервисной архитектуры
Микросервисная архитектура — относительно молодая и набирающая популярность концепция создания программных продуктов.
Цельный продукт («монолит») делится на множество независимых частей («микросервисов»), которые взаимодействуют между собой через API.
При таком подходе при изменении нужного процесса нужно изменить только отдельные микросервисы, а не переписывать огромный кусок кода, который затрагивает десятки соседних процессов.
Теоретически, 1С-Битрикс не препятствует реализации микросервисной архитектуры. На деле же, большая часть его компонентов представляет собой «микро-монолиты». Чрезмерная зависимость компонентов друг от друга усложняет «распиливание» монолита на микросервисы.
В Laravel «из коробки» есть консольные команды для создания и выполнения тестов. Но самое главное, что с помощью DI-контейнера можно писать тестируемый код, делая заглушки на внешние сервисы.
Например, есть сервис отправки СМС, но при тестировании мы не хотим отправлять реальные смски. Тогда для интерфейса СМС-провайдера мы создаём класс-заглушку, которая делает вид, что отправляет СМС. Тем самым мы можем автономно проверить факт отправки СМС и её содержание без реальной отправки сообщения — протестировать всю логику, завязанную на сервисе, и внести изменения.
6 — Возможность использования unit-тестов
Почти все разработчики больших проектов сталкивались с ситуацией, когда «одно чиним, другое — ломаем». Это происходит, когда проект разрастается, и становится сложно уследить за тем, как поведёт себя вся конструкция при внесении изменений в какую-то часть.
Проблема частично решается внедрением юнит-тестов — небольших автоматических проверок, которые выполняются после каждого изменения компонента.
Если написать юнит-тест для Laravel по силам любому хорошему разработчику, то покрыть тестами код компонентов 1С-Битрикс (а особенно код, использующий API 1C-Битрикса) — может стать нетривиальной задачей.
7 — Возможность реализации концепции CI/CD
CI/CD (Continuous Integration, Continuous Delivery, то есть непрерывная интеграция и доставка) — это технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам (разработчики, аналитики, инженеры качества, конечные пользователи).
Значимая часть концепции CI/CD — это автоматическое тестирование до выкладки кода и после нее. Про написание тестов с 1C-Битрикс приходится помучаться, а тесты обычно получаются не сильно качественными.На главное в CI/CD — это автоматическая публикация изменений.
Во фреймворки «из коробки» заложены миграции для базы данных, возможность писать удобные консольные команды и публиковать все изменения без ручного вмешательства.
В 1С-Битрикс приходится часто работать «мышкой», наращивая массив информации в базе данных: поля инфоблоков, соответствие шаблонов конкретным страницам, почтовые шаблоны и многое другое.
В «коробке» 1С-Битрикс нет инструментов для миграций изменений на все площадки. Разработчику приходится регулярно брать чужие решения или писать свои.
Прочие параметры
1 — Популярность в своей категории
Я нашел несколько рейтингов CMS-систем. Данные в них разнятся, но в большинстве источников картина такая:
CMS: 1С-Битрикс уверенно занимает 2-е место в России, уступая только WordPress.
По данным исследований iTrack и builtwith.com, 1С-Битрикс отстаёт от нынешнего лидера, как минимум, в два раза.
Рейтинга исключительно backend-фреймворков я найти не сумел (если нашли, поделитесь, пожалуйста), но удалось обнаружить общие рейтинги популярности фреймворков (совокупно по фронтенду и бэкенду).
В них (раз и два) предсказуемо лидируют такие популярные фронтенд-фреймворки, как React и Vue. Если же очистить эти списки, то Laravel займет четвертую-пятую строчку по популярности, уступив ASP.NET, Ruby on Rails и Django.
PHP как язык программирования занимает лидирующую строчку в чартах популярности платформ для создания сайтов. Но… такое сравнение было бы некорректным, мы проводим сравнение внутри одной категории.
2 — Популярность среди наиболее посещаемых проектов
С исследованием этого вопроса оказалось ещё сложнее, т.к. объективных источников информации ещё меньше. Здесь я опирался на статью 2017-го года и сайт builtwith.com.
«Как мы видим, всего 13 сайтов из 100 работают на коробочной CMS, т.е. всего 13% высоконагруженных проектов в рейтинге используют CMS. Кроме этого, 3 проекта используют студийные разработки, которые могут быть собраны специально под их потребности и, скорее всего, сильно отличаются от обычной коробочной CMS. В сухом остатке мы видим, что на коробочной CMS работают всего несколько проектов.» (Источник: статья Никиты Семёнова из SECL Group).
По сведениям builtwith.com, на 1С-Битрикс созданы такие сайты, как:
На Laravel разработаны такие сайты, как:
Обратите внимание: сайт ФК «Зенит» встречается в обоих списках.
Это пример подхода, при котором многие проекты используют «гибридную» схему организации: часть проекта реализована на коробочной CMS (в нашем случае — это 1С-Битрикс), а наиболее нагрузочная или нестандартная часть реализована на фреймворке (у нас — это Laravel).
3 — Использование за рубежом
Laravel очень популярен в США. Этим объясняется его активное использование в крупнейших мировых проектах, например:
1C-Битрикс отдают предпочтение крупные международные компании с российскими корнями (например, www.kaspersky.com). В остальных случаях на этой CMS разрабатывается только локальный российский поддомен транснациональных корпораций (например, https://ru.levi.com и https://ru.benetton.com).
Долгое время компания «1С-Битрикс» отказывалась от международной экспансии, не уделяя внимания созданию англоязычного административного интерфейса и службы поддержки. Очевидно, неудачи компании за рубежом связаны, в первую очередь, именно с этой многолетней политикой. Сейчас, по моим данным, «Битрикс» прикладывает усилия для популяризации своего продукта вне рынка России и стран СНГ.
Заключение
Эта статья — структурирование опыта нашей команды и частное мнение по данной теме, которое может не совпадать не только с мнением редакции, но и с мнением других экспертов :-)
Лично я считаю, что обе платформы работают хорошо при правильном выборе под конкретный проект и профессиональном использовании.
1С-Битрикс больше подходит для небольших проектов.
Если вы только проверяете свою бизнес-гипотезу, и вам нужно быстро развернуть типичный по своим возможностям сайт, 1С-Битрикс будет прекрасным решением.
Правильное использование 1С-Битрикс — это максимальное использование существующих инфоблоков без их кастомизации (от слова «совсем»). Вам должно хватать функциональности «из коробки», которой у 1С-Битрикс предостаточно.
Фреймворк подойдет для амбициозного проекта с уникальными механиками и чудовищной посещаемостью.
А также для проекта с огромной базой данных (и не важно, что это за данные — текстовые статьи или товары каталога) и для интеграции с десятком других информационных систем.
Для всех этих задач правильнее будет с самого начала использовать фреймворк. Переписывать позже «с нуля» будет гораздо сложнее, болезненнее и дороже.
Поделитесь в комментариях, что выбираете вы, Битрикс или Laravel?
Комментарий недоступен
Особенно всё прекрасно в Битрикс: обратная совместимость и куча старого легаси кода. Который никуда не едет. Особенно мне нравится, когда сравнивают фреймворк и cms (мокрое и мягкое).
Комментарий недоступен
Фреймворк умирает, когда перестает реагировать на вызовы. На сколько я знаю Лара идет в ногу со временем, так что скорая смерть уж точно не грозит ей.
Касательно CodeIgniter, если я не ошибаюсь, он был побочным инструментом коммерческой разработки, но на него забили на второй версии, в следствии чего и появился Laravel.
После передачи фреймворка в BCIT появилась 4я версия, которая пытается зацепиться за последний вагон мимикрируя под Лару, но не без своих тараканов.
Думаю, что популярность фреймворка зависит от региона. И если брать первую тройку в РФ то это Laravel, Symfony и Yii. За пределами РФ Yii меняется на CodeIgniter.
Спасибо за комментарий.
"С битрой всё стандартно" - вот об этом мифе, как раз, наверное моя статья. В том-то и дело, что если действительно с битрой всё стандартно, иными словами заказчик не костылил, а принимал функциональные возможности CMS такими, какими видит их разработчик CMS, а не говорил "а вот здесь нам нужно немного по-другому", тогда Битрикс - прекрасен, и я обеими руками за него.
В противном же случае, его а) становится очень дорого и сложно обновлять; б) передать другой команде становится даже сложнее и дороже, чем проект на фреймворке, если он написан квалифицированными разработчиками и хорошо документирован.
С другими CMS у меня меньше опыта. Насколько я знаю, Magento написана на базе фреймворка Zend, поэтому там, возможно, все немного лучше обстоит. Тут, наверное, нужно дождаться комментариев тех, кто много работает с этими CMS.
Вывод в наше время один: и то и другое помойное решение для ретроградов, которые ничего не хотят слышать о современных языках разработки (Go, Ruby и прочее). Не видел ни одного быстрого вебсервиса на PHP.
Плохо смотрел.
При чем тут современные языки? Суть в архитектуре, ее адекватности, которая является прямым следствием адекватности знаний разработчика. Можно на самом суперсовременном накодить такого помойла, что целый отдел сеньоров потом не разберется. Как и на старом сделать удобно и лаконично.
Вы хотите сказать, что PHP медленнее, чем Ruby?
vk, badoo, википедия и так далее — написаны на пхп.
Комментарий недоступен
Привет. Не знал про эту статью - почитаю )))
Ну, статьи все субъективны. Я скорее транслирую мнения заказчиков. Если сравнивать админку Битрикса и админки большинства самописных проектов - Битрикс (на мой вкус) посимпатичнее все-таки выглядит. Хотя бы потому, что отдельное время уделили вопросам ее проектирования и дизайна.
Впрочем, вполне допускаю, что Андрей видел что-то, чего не видел я. Почитаю его статью обязательно, спасибо.
Битрикс или Vendor lock-in что же выбрать мне как заказчику? )
Понятную cms, где я за день могу найти разраба и ввести в курс дела или петлю на шею за оверпрайс )
Для каждой задачи свой инструмент, в 95% случаев битрикс будет лучшим вариантом, если это не что-то монструозное, где он превратится в *бный скворешник. Но в таком случае выбор должен быть опредёлен еще на этапе проектирования.
Так что сто раз подумайте, когда вам навязывают какой-то новомодный фреймворк - считайте вы женитесь на этих разработчиках, будьте готовы плясать под их дудку, оплачивать работы как элитной проститутке, а развод выльется в копейку.
Почти все что указано в таблице сравнения - откровенный бред человека который видимо не очень разбирается в Битрикс и в программировании в целом. Нужна уникальная логика компонентов без лишнего - пиши свои компоненты, свои модули, свои правила корзины, и тд и тп. Можно всё. Даже то же оформление заказа которое якобы сложно кастомизируется - там есть много событий, слушая которые, можно влиять на результат работы без написание собственного чекаута. Про composer - кто мешает использовать композер и тянуть любые пакеты на битрикс проектах? Про производительность - плохо написать можно на чём угодно.
По бизнес задачам - автору конечно выгоднее продавать проекты на ларавел, тк там будет заложено куда больше человекочасов, которые как пишет автор ещё и и стоят дороже из за якобы "тру" программистов с более высокой зп. Только клиенту будет выгода от этого? Кто потом будет поддерживать и за какие деньги эти проекты если вы пропадёте с разработчиками? Схема не для решения задач клиента, а для высасывания из него денег.
У меня было такое мнение как у автора, когда я поработал с битрикс пару лет, и оценивая себя и свое мнение в те времена я могу сказать лишь что я мало понимал, знал и умел. Только вот автор указал, что занимается веб разработкой уже более 20 лет, и выходит либо он в битрикс не разобрался либо... додумайте сами.
За свой многолетний опыт php разработчика (более 10 лет), видел плохо написанные проекты и на битрикс и на "настоящих" фреймворках типо симфони и ларавел. Как и программистов, которые о себе и своих знаниях громко заявляют а неделе ни о чем.
В общем статья не объективна и основа лишь на знаниях автора, опираться на которые я бы не стал.
Валера, отличный разбор, спасибо! Согласен с аргументами, только в нашем случае вместо Laravel — Symfony.
Вопрос: у вас был опыт разработки на 1С-Битрикс в виде бекенд-фреймворка, который отдаёт данные через API в single-page application на фронтенд-фреймворке типа react или vue?
Максим, привет.
Я несколько раз перечитал твой вопрос. И это тот самый редкий случай, когда я вопросом на вопрос отвечу: ЗАЧЕМ?! )))
Ну, то есть, если у меня есть SPA на современных инструментах, в который мне нужно через API передавать те или иные данные - зачем мне Битрикс в качестве backend'а использовать?! )))
Единственным разумным ответом мне кажется: потому, что заказчик так просит. И вот с этой практикой накостыливания, когда в угоду хотелкам заказчика громоздятся костыльные решения, я предлагаю не соглашаться.
Но если все-таки попытаться ответить на твой вопрос: чисто технически - проблем не должно возникнуть. Получается, нужно будет построить что-то вроде шины данных, которая будет получать данные из различных источников, заботливо хранить и выдавать по запросу тем, кто будет обращаться. Проще говоря, я бы отдельную компоненту для решения этой задачи написал, а не лез бы грязными руками внутрь Битрикса. Битрикс пусть остается в макисмально первозданном виде.
У меня был опыт. Нет проблем. Для клиентов удобная админка, для разработчиков чистый код.
Валера, хороший материал. Думаю для понятности и наглядности стоило бы раскрыть термин "для небольших проектов". Поясни, что вы вкладываете в это понятие?
Привет. Каверзный вопрос, конечно ))
На мой взгляд "небольшой проект" должен отвечать следующим критериям:
1. Уровень функционала покрывается возможностями типовой CMS более на 75% или больше (то есть уровень кастомизации - низкий).
2. Объем хранимых данных не превышает 50 тысяч наименований (проще говоря - каталог не выходит за пределы 50 тысяч SKU).
3. Уровень связанности с внешними ИС низкий, связанность типичная (например, сайт связан только с 1С и получает из нее стандартный набор данных - цену и наличие).
4. Сайт не будет испытывать высоких нагрузок со стороны пользователей (ну, скажем, ежедневные посетители не более 15 000 уников и нагрузка в моменте не более 1 000 одновременных сессий).
При выходе за любой из этих параметров 1С-Битрикс в частности может стать неоптимальным выбором по моему мнению.
А тот факт, что битрикс строит денег, а фреймворки бесплатны? Или что разработчиков на битрикс найти очень сложно.
Это сайт про бизнес, поэтому нужно рассуждать с позиции бизнеса. А именно: следует помнить, что для получения готового решения что на Битриксе, что на фреймворке, потребуются определённые трудо- и денежные затраты. Это дизайн, вёрстка, программирование, администрирование, заполнение контентом и сео-оптимизация. И с этой стороны типовое решение на Битриксе (или любой другой популярной CMS) будет дешевле, чем реализация на фреймворке. Вдобавок, и время запуска решения для клиентов (time to market) будет существенно меньше.
Однако в случае нетипичного проекта, который слабо укладывается в концепцию, решаемую готовой CMS, решение на Битриксе потребует значительно больше времени (сходное или даже большее, чем для фреймворка), а качество получившегося решения (включая качество кода, скорость работы, потенциал поддержки и расширения) будет ниже.
Ну, вообще в статье об этом прямо или косвенно говорится.
Мой опыт тоже говорит о том, что найти программиста под фреймворк гораздо проще, чем программиста под 1С-Битрикс. Тупо не хотят программисты с этим продуктом работать. Но цифры HH вещь упрямая и говорит об обратном, поэтому я вынужден был написать то, что написал - я старался быть объективным.
Что касается стоимости ... Стоимость Битрикс все-таки очень символическая. И, если его использовать по назначению (то есть разворачивать на нем быстрые типовые проекты), стоимость его лицензии быстро нивелирует разницу со стоимостью затрат на программистов, который не фреймворк вынуждены будут типичный функционал "с нуля" возводить.
Так что фактически - да, Вы правы: Битрикс "дороже" фреймворка. На практике же, с учетом стоимости лицензии - это точно не решающий фактор по моему опыту.
Классный материал! Частенько не хватает аргументов ЗА.
Битрикс за их легаси ненавижу, но советую любой компании, у которой нет собственной группы веб-разработчиков. Дешевле и быстрее. А когда заработаете, сделаете отдел разработчиков, и пусть дальше прораб изобретает собственный кирпич )
На мой взгляд в статье есть ряд неточностей и работа с Битриксом на самом деле значительно проще. Приведу некоторые примеры.
1. Эльдорадо и Зенит на Битриксе
2. Кастомизация готовых компонент как правило не представляет каких то сложностей. Достаточно изменить стандартный шаблон или сделать полностью свой.
3. Если выполнять разработку проекта с учетом рекомендаций вендора, то не возникнет проблема как с обновлениями, так и с работой собственного кода меняющего стандартные поведение и представление системы.
4. В случае если какие то интерфейсы админки не подходят и не хватает стандартных возможностей кастомизации, всегда можно написать для нее свое "дополнение". Которое закроет потребности в нестандартном функционале.
5. Микросервисы при необходимости реализовать возможно. И скорее всего для этого не надо использовать компоненты. Есть множество других системных инструментов для этого. Остается только вопрос целесообразности.
6. Так же не согласен с утверждением, что система не производительна и очень требовательна к хостингу. Все зависит от качества разработки конечных решений и знания платформы. К тому же продукт обладает достаточно большим перечнем инструментов для обеспечения быстрой и стабильной работы проектов.
Все зависит от конкретного проекта. Как ни крути, но при повышении нагрузки вы рано или поздно упретесь в то, что все элементы всех инфоблоков хранятся в одной таблице. А если разработчики не особо расчитывали на высокие нагрузки, то к этому добавится так же то, что все пользовательские свойства всех элементов хранятся еще в одной таблице (или двух? не помню точно).
В результате выборки из базы станут медленнее просто в силу количества данных.
Комментарий недоступен
Спасибо. Запишу в темник - классная идея ;-)
У меня несколько комментариев по сравнительной таблице:
Шаблонизация. В битриксе действительно не используется ни паттерн MVC, ни какой-либо шаблонизатор. Но у битрикса есть своя система построения страницы, которая предполагает как общий шаблон сайта, так и шаблон каждого компонента. Так что, шаблонизация как таковая в битриксе есть, а вот шаблонизаторы да, не используются.
Кастомизация готовых компонентов. То, что указано в таблице, полностью и безоговорочно относится только к КОМПЛЕКСНЫМ компонентам. Простые компоненты кастомизируются так же довольно просто. Особенно если шаблоны и фронтенд писать самостоятельно с нуля. Более того, механизм result_modifier.php позволяет манипулировать результатом работы компонента до передачи его шаблону, а component_epilog.php, соответственно, после отработки шаблона.
Независимость от разработчика. Я счиатю, тут с Laravel все одинаково. При условии документации и соблюдения соглашений (да, у битрикса тоже есть соглашения по стилю кода) все будет независимо от разработчика.
Документация. Неполная - так и есть. Особенно плохо документирован внутренняя JS-библиотека. Устаревшая - не совсем так. Но абсолютное большинство компонентов и классов, требующихся для повседневной работы документированы в достаточной степени. У Laravel документация более подробна. У битрикса более ориентирована на русскоязычного пользователя.
Простота использования для редактора. Про жесткие ограничения - чушь. Админка битрикса предоставляет множество механизмов кастомизации. Кроме того, собственные модули могут содержать любую бизнес-логику и любой интерфейс.
Требуемая квалификация разработчика. Тут мне, конечно, сложно судить. Но я знаю такое название как Интерволга. Рекомендую посмотреть их сайт. Требования к разработчикам, решенные кейсы в блоге и статьях. Если это программисты максимум среднего уровня и не талантливые, то я впаду в депрессию из-за синдрома самозванца.
Единая концепция разработки. Как ни крути, но битрикс - это MVC. Модель (модули), Контроллер (компонент) и Вид (шаблон компонента) - присутствуют.
Если у вас файлы представляют свалку HTML, JS, CSS, то Laravel вас не спасет. Вы и там свалку разведете. К тому же, проблема "толстого контроллера" в Laravel распространена не меньше. То, что в битриксе нет единой точки входа - правда. Но ведь она и не требуется этим паттерном. Зато не нужен роутинг на каждом хите.
Микросервисная архитектура. Мне сейчас кажется, что я прочитал какую-то чушь про битрикс. Во-первых, микромонолит. Это что за зверь такой? Я его не представляю. Во-вторых, о реализации микросервисной архитектуры на битриксе я хотел бы узнать больше. Буду благодарен автору за описание его опыта на эту тему в отдельной статье. Потому что в моей картине мира микросервсная архитектура на битриксе - это извращение сродни написанию сайта на ассемблере: вроде и можно, но для данной задачи существуют и лучшие решения.
Соблюдение принципов ООП. D7 вполне себе соблюдает ООП. В остальном же с Laravel все одинаково: качество кода зависит от квалификации разработчиков. Никто не мешает вам использовать объекты в битриксе. Как самописные, так и те, что сможете найти в composer.
Возможность организации итерационной разработки. Хотелось бы получить более развернутую информацию, что же мешает организовать ее на битриксе?
Производительность. Структура БД и вправду неоптимальна. Более того, в битриксе в качестве БД можно использовать только mysql. Так что если вы целитесь в highload, где важна каждая микросекунда, то я не назвал бы битрикс оптимальным решением. Сайт моей компании держит 2500 запросов/сек. Без кластеризации (сейчас в планах) и микросервисов. У Интерволги тоже есть кейсы с хайлоадом на битриксе. Но, по моему мнению, это уже попытка натянуть сову на глобус.
Популярные альтернативы. А вот тут я не понял. Почему в альтернативах Laravel фреймфорки на других языках? Где yii(хоть его и ругают, кажется, не меньше битрикса)? От себя так же добавлю, что порог входа в Symfony выше, чем в Laravel, хотя Laravel под капотом и использует довольно много компонентов Symfony.
В целом со статьей скорее согласен. но :)
Есть некоторые не логичные пункты сравнения. Например Кастомизация компонентов. Противопостваляется "у лары нет компонентов и нет проблем" у "битрикс сложно". Соответственно тут вообще нельзя по этому критерию сравнивать. В то же время ни кто вообще не мешает написать свой компонент с ноля. Причем, при желании, вполне можно использовать хоть лару хооть симфони (главное что б в этом был действительно практический смысл). Лучше пожалуй сифони, т.к. некоторые ее сущности есть в битриксе (но это так, незначительный плюс в торону выбора сифони против лары в рамках проекта битрикс :)
По БД тоже такое себе сравнение. Для узких мест ни кто не мешает создать свою архитектуру в бд. и работать с ней через АПИ битрикс (позволит использовать, например, событийную модель, ну и прочие "плюшки") В т.ч. будет работа именно с объектами, а не с массивами. (включая данные)
Вопрос про то что если модуль кастомизирован и его потом сложно... Тут скорее вопрос как раз в том, что "требования к специалисту ниже". Если вменяемый человек кастомизировал - все ок.
В общем очень много проблем именно из-за квалификации.
Тут многие пункты относятся больше к сравнению классов инструментов универсальна CMS vs Framwork.
Если оставить сравнение исключительно только Битрикс vs лара. что статья получилась бы меньше.
По этому гораздо правильнее сначала клиенту дать сравнение решения на CMS и на Framework
После того как выбран класс инструмента. Уже вторым этапом сравнивать решения на разных CMS (или на разных фреймворках). Но это, как правило, уже сводится к тому, какой инструмент лучше знает данная команда веб разработчиков. :)
Ну битрикс в общем-то у всех на слуху
Потому что ЗАКАЗЧИКА интересует магазин как можно быстрее. И чтобы с 1с его можно было связать как можно проще. А уж на чем его делать - его не волнует.
Ну а дальше мое предположение: там, где на битриксе нужно слегка подправить напильником всякие экспорты/импорты с 1с или яндекс.маркетом, на других системах нужно придумывать другой путь.
Отличная статья, спасибо! А вы Мегапланом не пользовались? Мы сейчас выбираем себе црмку, Битрикс кажется слишком сложным, а Мегаплан вроде полегче. Если есть опыт, поделитесь, пожалуйста
Привет. Спасибо за "спасибо" ))
Нет, Мегапланом мы не пользовались. Одно время пробовали пользоваться Б24 - у нас не очень прижилось. Попробовали amoCRM - тоже не зашло, но было ближе к тому, что нам нужно. В итоге остановились на Pipedrive. Пока почти всем довольны. Почти - потому, что не смогли связаться Pipedrive с мессенджерами (а у нас много клиентской переписки в мессенджерах происходит) и не смогли привязать синхронизацию задач Pipedrive с Todoist, которым пользуются наши продажники.
Но тут важно понимать еще цели CRM. Для нас - это исключительно ведение сделок от входящего обращения до заключения контракта.
Валерий, правильно писать «руководитель одной из компаний, ведущих бизнес в России по заказной веб-разработке».
Вот тут очень авторитетные ребята сравнивают другую готовую реализацию для электронной коммерции с фреймворками и прочими продуктами, тем кто хочет строить ИМ обязательно к прочтению, студии как всегда многого не договаривают https://www.yireo.com/blog/2021-08-26-magento-for-haters
Лично я с опытом e-commerce с 2013 года, из двух этих вариантов выбрал бы Битрикс(хоть и ненавижу его), неокрепший ум коммерсанта в вебе выбрав любой фреймворк вместо готового решения будет волосики на попке вырывать от того на какие бабки он попал. Фреймворк только для крупнобюджетных проектов
А почему не рассматриваете Framework на Node js, GO или даже Java?
Комментарий удален модератором
респект, первая статья в России об эффективных менеджерах вендоров, хотя везде в мире схема одинаковая, мы преувеличиваем значение тех прогресса
У Битры есть проблемы с объемом ядра (гигабайты), с миграциями и обновлениями (связанность), сложностью ci/cd и доставке обнов, есть непонятки с d7/ORM и документацией, urlrewrite, множество точек входа, prolog...
Но при этом — всё решаемо. Вся бизнес логика выносится за проект, composer, phpunit, миграции все подключается к проекту в 2 строчки.
С main версии 21.400.0. уже можно переключить роутинг — будут и замыкания и контроллеры и экшены.
С main версии 20. уже DI\ServiceLocator
Работал с системами с разветвленной бизнес логикой. Встречались и бэк - битра + graphql, фронт - vue / react, вполне себе норм.
мнение с другой стороны https://wrp.ru/uslugi/perenos-laravel-bitrix/
Можно выбрать что то нормальное на Node js, GO и даже Java) А не древние штуки на PHP
Java - выпущена в 1990г.
PHP -выпущен в 1994г.
JavaScript - Выпущен в 1996г.
О, да. Стильные, модные молодежные вещи на JAVA и JS - это вам не то же самое, что древний и замшелый PHP:)
Но самое интересное, что интерпритаторы всего перечисленного (кроме, возможно Go и Java) написаны на свежих и вечно молодых C(1972) или C++(1983). Как и большинство веб-серверов и операционных систем.