Что лучше: сайт по шаблону или с нуля?

Собрались как-то маркетолог, контент-менеджер, разработчик и владелец веб-студии в одном баре. И завязался у них разговор. Но не о ковиде и выборах, как это модно в 2020. А о Bitrix и готовых CMS. Зачем мы вам это рассказываем? Да ведь это инсайды всех, кто обычно отвечает за работу сайта. Поэтому, если вы сейчас стоите на пороге открытия своего магазина-студии-салона и посматриваете одним глазом на готовую CMS, рекомендуем к прочтению. Так сказать, получите всесторонний взгляд на происходящее.

Именно он чаще всего отвечает за то, каким сайтом вы будете пользоваться. Так получилось, что маркетолог в эту компашку попал самый типичный, и он рассказал, чем руководствовался, когда выбирал Битрикс для своей работы.

— Ну, во-первых, я посмотрел все рейтинги веб-разработчиков, выбрал студий 5 и начал изучать их портфолио.

И вот тут случается главный косяк. Например, в Беларуси почти все студии работают с Битриксом. Тех, кто предлагает разработку с нуля, буквально пара штук. И очень часто среди их компетенций все равно присутствует Битрикс. Это значит, что, если они почуяли запах денег клиента, предложат нормальный сайт. Если что-то пустяковое, даже не будут утруждаться, продадут «коробку», и дело с концом.

— Дальше, я, конечно, написал ТЗ, прикинул бюджет, денег было немного, а Битрикс – это ведь дешево…

Вот тут кроется еще одна загвоздка. Если вам надо будет дорабатывать «коробочное решение”, вносить изменения, затачивать под себя или даже просто докупать какие-то интеграции и лицензии, ваше дешево постепенно превратится в “а чё так дорого?». А любая кастомизация готового решения может обернуться сущим адом, перестать работать, обновляться и пр.

— Ну хорошо, а если бы я заказал сайт с нуля, кто нам потом его бы поддерживал будет? То ли дело, Битрикс, там ведь самому можно все поменять!

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

— Но главное-то, главное, что с 1С Битрикс будет работать как часы!

Уверен? Если коротко, то «не факт», если длинно, то разработчик потом объяснит, почему заветная буква в названии CRM не гарантируют беспроблемного подключения, обмена данными и т.п.

До встречи с Битриксом она уже имел опыт общения с разными админками, но такого дна не видел…У ворда в далеком 98 году и то было больше возможностей для верстки текста. Проблемы с картинками, проблемы с поиском в админке тех мест, где располагался контент на сайте.

А еще ходили легенды, что можно в Битриксе редактировать все. И тут прямо комбо из заблуждений. Во-первых, нельзя. Не получится маркетологу и контент-менеджеру самостоятельно поменять иконки, блоки (только если разработчик не вынесет все это в отдельные компоненты, как и в случае разработки проекта с нуля). А так только текст и картинки, картинки и текст.

А во-вторых, часто случается так, что даже просто внося изменения в шаблонные поля, «специалисты” рождают Франкенштейна. Это пламенный привет любителям «поиграться шрифтами», “выделить жирненьким, красненьким или капсом» и залить самую дурацкую стоковую картинку. Хорошо, когда у контентщика есть хоть какое-то чувство вкуса, и он не будет сильно влезать в шаблон, сможет соблюдать одинаковое количество строк и подбирать симпатичный визуал. Но это большая редкость.

Работал я с Битриксом. Хватило меня на месяцев 10. Но этого времени было достаточно, чтобы «насладиться» сполна.

Во-первых ты никак не развиваешься. Возьмем условно двух backend-разработчиков. Один работал N-ное время с 1С-Битрикс, а другой – столько же с Symfony. За этот период второй освоил php7, выработал глубокое понимание ООП, овладел общепринятыми паттернами проектирования (MVC, DI, Factory, Repository как минимум), научился разрабатывать Unit-тесты, стал использовать шаблонизаторы (минимум, twig), ORM (с Doctrine), composer, git, стандарты PSR, получил опыт работы с консолью и написания консольных приложений, базовые навыки настройки веб-сервера. А разработчик на Битриксе? Он за это время освоил php7, еще html/css + javascript/jquery, возможно git, немного sql и… все?

В случае с Symfony ты постоянно изучаешь что-то новое, можешь предложить не один путь решения вопроса.

Чем это чревато для владельца бизнеса? Да тем, что не развивается разработчик = не развивается ваш сайт. Он будет сделан по стандартам двухлетней давности. Про всякие тренды и фишки можете забыть. Будете наслаждаться заранее морально устаревшим продуктом.

Окей, отбросим личные интересы, но Битрикс от этого лучше не станет. Мне есть с чем сравнивать – 2 года на Laravel.

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

Документация Битрикса отстает от всего, что есть вообще, и ты никогда не узнаешь, если там появится что-то новое. Хоть она и весьма объемная, но какая-то бестолковая, без практических примеров. Плюс для новичков сложная. Если честно, мне кажется, что, даже имея опыт с Laravel, я бы все равно не смог в ней разобраться.

Для бизнеса тут тоже есть свои последствия. Вот взяли вы «коробку», взяли программиста на Битриксе. Он вам что-то там настраивал и делал пару лет. А потом решил пойти своей дорогой. Окей, нашли другого. А он смотрит в код и видит…Ну вы знаете. Конечно, он спустя какое-то время разберется. Ну и потом поверх чужих костылей начнет свои городить. И сколько такой сайт проработает не знает даже Ванга. Может долго продержаться, а может лечь в пиковую нагрузку.

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

В Битриксе надо вносить все изменения в сам шаблон. И один раз «сломав” его, ты больше не сможешь накатывать обновления. Я имею в виду, дописав что-то свое. Поддержка функциональности превращается в ад. Сами “обновы», кстати, тоже достаточно сомнительные. Сырые, с багами, редкие. Битриксу проще напродавать кучу однотипных шаблонов, а потом забыть про них. После чего выпустить новые и так далее.

Почему это должно парить предпринимателя? Потому что «ломать” шаблон точно придется. Либо «ломать» свой бизнес, отказываться от каких-то фишек и штучек. Даже модуль оплаты нельзя будет под себя поменять. Иначе обновления на него уже никакие не встанут. То есть вы по факту заплатите за шаблон, пару интеграций, а к ним еще идет “поддержка от производителя», но, если вы что-то поменяли, сорян, дальше сами.

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

Однажды в пору работы с Битриксом мне надо было написать свой компонент, который будет отвечать за обмен сообщениями между пользователями. Типа чат. Думал, возьмусь за документацию, посмотрю, как там расписано создание своих компонентов и модулей. Ага, щас! Быстрее вышло написать API на Laravel на совершенно отдельном серваке, к которому Битрикс уже самостоятельно подключался.

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

Даже хваленая синхронизация с 1С не проходила так безболезненно, как обычно обещают все продавцы – были обрывы. Да, все те, кто уже юзает 1С, и думает: «вот сейчас сделаю сайт на Битриксе, нажму на волшебную кнопку, и все синхронизируется!», — не верьте! Вам придется еще всю свою 1С подогнать под то, как это удобно Битриксу.

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

Исторически сложилось так, что мы в Веб Секрет делаем проекты только с нуля. И я считаю, что в этом нам очень повезло. Повезло, что просто технически невозможно было их делать с использованием коробочных решений. Тем не менее, я не топлю за то, чтобы совсем отказываться от готовых CMS. Joomla, Drupal, Битрикс – все они имеют место быть, т.к. в бизнесе есть сегмент, которому не нужны самописные уникальные решения.

Конечно, за эти деньги можно и стартап запилить. Но для типового бизнеса, у которого нет специфических задач, ничего «особенного» и не надо.

Однако это на текущий момент. А планируете ли вы масштабироваться? Коробка – это совсем не про рост бизнеса. И хейтите меня сколько угодно, что, мол, сделать можно все, лишь бы руки росли из нужного места. Вопрос в другом – какой ценой? Я уверен, что рано или поздно у каждого наступает такой момент, когда он понимает, что лучше сейчас переписать сайт с нуля, чем продолжать строить «костыли».

Есть очень яркий пример – реселлер бытовой техники в РБ. У них десятки тысяч товаров в каталоге. И вот они захотели сайт на Битриксе. Почему? Просто потому, что Битрикс проникает в умы своим маркетингом. Ну и потому что у них есть магическая буква 1С в названии. Именно она заставляет людей верить, что интеграция пройдет безболезненно. Оно то, конечно, может и так. Но только если вы строите бизнес и сайт параллельно. А если у вас уже полжизни сосредоточено в 1С, а сайт вы просто решили обновить, закупайтесь таблетками от геморроя. Вам в готовую логику придется вклиниться, переписать все, чтобы при этом оно работало, и, как говорил разработчик, забыть навсегда про дальнейшие обновления.

Так вот, реселлер сделал-таки сайт на Битриксе, но не реализовал всех задуманных фич, настрадался и в течение года принял решение, собрать команду разработчиков, которые с нуля напишут сайт. Бэк на Laravel, фронт на Vue – все по красоте.

Какие были мучения, спросите вы? На Битриксе за целые сутки не обрабатывался обмен данными с 1С из-за огромного кол-ва товаров. А там, например, надо обновить цены на 10 000 позиций за 5 минут, потому что курс изменился. Иначе будешь нести убытки.

Была у нас и обратная история – с известной в РБ компанией-застройщиком. Мы сделали крутой дизайн, продумали все до мелочей как для покупателей квартир, так и для отдела продаж. Исходя из их потребностей, стали писать кастомную админку, чтобы им было удобнее. Собрали список болей всех и планировали решить их на новом сайте. Начали делать его на React, бэк – на Laravel. А клиент сказал: «Долго. Давайте вы закончите в 2 раза быстрее, а с заполнением админки я готов страдать, как и раньше…» И ты вот разводишь руками, размышляя, почему, вкладывая деньги, люди не хотят что-то улучшать, а делают для галочки.

Единственное, что вы можете перепроверить – какой стэк для разработки был выбран. Большинству проектов достаточно распространенных языков: PHP, Node.js, Go.

Но есть ряд ситуаций, когда все-таки лучше использовать коробочное решение:

• Когда решаешь типовую задачу (создаешь админку, экспорт в иксель, сортировку по полям, выборки).
• Когда сайт нужен быстро.
• Когда вы боитесь, что без разработчиков что-нибудь сломается и не будет работать.
• Когда вас устраивает готовая панель управления.

И тем не менее, вам придется помнить про минусы «коробок»:

• Они не масштабируются в большие проекты, Если быть точнее, то тяжело и не понятно, какой ценой.
• Сложно кастомизировать свою логику и выстроить необходимый функционал. Например, отвечать за цены и производить/не производить переоценку товаров в то время, когда товар уже лежит у пользователя в корзине. Настраивать поиск (однокоренные, неоднокоренные, синонимы и т.п.) или рекомендации (как будет происходить замена товара).
• Трудно решать вопросы работы с большим объемом инфы и гарантировать высокую скорость работы сайта.
• Коробочные решения отстают в скорости развития от фреймворков. И здесь речь даже о тех, что не Битрикс. Например, OctoberCMS – написана на Laravel и выложена в open source. Но обновления там могут выкатываться с опозданием на полгода, а это значит, что вы отстанете от своих конкурентов, написавших сайт с нуля, ровно на такой период времени.
• Невозможно качественно создавать единую экосистему приложения и сайта. Например, у нас бэкенд на Laravel, и есть API, который задокументирован, в котором прописаны все методы, и они отдают одну и ту же логику. Это значит, что можно использовать их как для сайта, так и для приложения, или для виджета, или для еще одного сайта. То есть бэк один, а на него нанизывай все, что угодно. Коробочные решения такой роскоши не позволяют. Есть бэкенд, который работает с сайтом, и API, который работает с приложением. В итоге, когда меняется какая-то логика, ее надо править и на сайте, и в приложении. При росте проекта это сильно увеличит риск ошибки. Мы же можем API всегда покрыть автотестами, чтобы гарантировать, что логика на сайте и в приложении будет всегда одинаковой.

Какой можно сделать вывод из всего этого разговора?

Например, если у вас 1000 товаров, то даже 3 человека в день будут страдать от тормознутости какого-нибудь Wordpress. Потому что это платформа для блогов и визиток. Это как мясорубкой гвозди забивать. Вроде можно, но лучше же делать это специально предназначенным инструментом. Если речь идет о 10 товарах, то магазин можно реализовать даже на Tilda или Wix. И речь о фреймворках вообще не уместна. Фреймворки используют для высоконагруженных проектов и сложной кастомной логики. Поэтому всегда задавайте себе эти вопросы:

Как это будет работать? Какой ценой вы это сделаете? С какой скоростью это будет работать? Как вы будете это поддерживать? Как потом масштабируете?

Да, если вы считаете свои деньги здесь и сейчас, коробочное решение даже с кастомизацией может выйти дешевле. Но, если вы реально задумываетесь о будущем, то ответ очевиден.