zikla.ru: фреймворк против CMS

Тема этой заметки может показаться довольно спорной, но меня давно посещают мысли о принципиальной разнице между разработкой сайтов на CMS и фреймворках.

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

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

Проилюстрирую свои мысли на недавнем примере. Все совпадения неслучайны, персонажи не выдуманы.

Пару месяцев назад ко мне обратился старый друг, назовём его Костя, с просьбой перенести его сайт, сделанный на Битриксе, на мою систему Vesp. На первый взгляд сайт был не очень сложным - просто календарь бронирования циклорамы, а заодно и аренда оборудования из их каталога: фотокамер, объективов, штативов, света и т.д. Можно прийти в студию без ничего, только с моделью, и всё отфотать.

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

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

Так как я давно работаю в Pixmill полный день, и сторонние заказы не беру, он ко мне не обращался до последнего, но тут уже всё - пациенту срочно требовалась операция. Да и работа выглядела ерундовой, на пару недель в свободное время по вечерам, не больше.

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

Что сделала студия

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

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

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

Админки я не видел, возможно это вообще какая-то мультиконтекстная система, где один движок обслуживает сразу несколько разных сайтов, но Костя об этом ничего не знал, и, конечно же, ничего подобного не заказывал. То есть не было разговоров, мол, это один сайт на троих со скидкой.

Сайт производил впечатление не особо быстрого, вёрстка с ошибками. Например, десктопная и мобильная версия не переключались нормально без перезагрузки страницы, видимо что-то завязано на определение ширины окна в JS и работает это только при загрузке.

Самописный календарь на VueJS рисовал в коде сайта сразу 365 дней и потом их проматывал как слайдер.

Казалось бы - вы уже используете Vue, неужели нельзя сделать как-то более эффективно? Но нет, там внутри еще и вызовы на jQuery.

На момент моего знакомства с сайтом заказы вообще не работали, в консоли this.user is null.

А еще у заказчика была целая пачка изменений в дизайне (они рисуют его сами как креативное агентство), которые не были внедрены. Я так понял, что разработчики их внедрять совсем не торопились.

В итоговый код из старого сайта попали только секретные ключи для подключения к оплате, код виджета онлайн-чата и стили заголовков с высотой шапки. Это всё, что я смог использовать. Но, тем не менее, я много смотрел как работает оригинал - спасибо ребятам за прототип!

Что сделал я

Понятное дело, использовал для работы Vesp и заверстал всё сразу адаптивно на BootstrapVue.

Спроектировал новую структуру БД, безо всяких инфоблоков и прочего ненужного от CMS. На данный момент она весит 528 килобайт (а было 300 мегабайт).

Написал новый календарь, используя Vue-Cal. Я люблю писать велосипеды, но календари не в их числе - работа с датами и временем бывает очень сложной, лучше использовать проверенное (другими разработчиками) решение. Доработал оформление и написал логику обработку кликов по месяцам. В мобильном режиме этот же самый календарь просто переключает вид с недели на месяц, без перезагрузки компонента.

Согласовал и переделал мобильный вид каталога. Раньше товары в нём выводились всплывающими окнами при клике, очень неудобно. Теперь прокручиваются пальцем, без окошек.

Самое главное - персональная админка, созданная для этого конкретного проекта. У Vesp есть всё нужное для написания подобных админок, включая специальные собственные компоненты.

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

Почему я считаю, что это проблема CMS?

Да потому, что проект оказался совсем нестандартным и Битрикс для него никак не подходит. Это вроде как интернет магазин, но совершенно не обычный.

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

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

И оба вида товаров прикручиваются к одному заказу. Как вы это сделаете без костылей на CMS? Честно говоря, я вообще удивлён, что студия это как-то реализовала и оно даже иногда работало.

А на Vesp я за пару часов продумал и написал себе нужные модели со связями:

• Light: вид освещения с ценой
• Interval: временные интервалы
• Product: обычные товары каталога с картинкой и ценой

Далее создаются

• Order: заказ, к которому присоединяются заказанные модели
• OrderInterval: ссылки на выбранные интервалы, с датой и видом освещения
• OrderProduct: ссылки на выбранные товары

И дальше уже с этим работает логика интернет-магазина. Причём, опять же, логика совсем непривычная - здесь только 1 вариант онлайн оплаты через Тинькофф и нет статусов заказа. Он или оплачен, или нет. И если нет, то удаляется через сутки, чтобы не занимать место в календаре.

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

Кстати, так как все модели связаны между собой, то для админки я получаю заказ в таком виде:

{
    "id": 83,
    "uuid": "8d919798-32f3-4973-9b36-7655462642cb",
    "total_intervals": 650,
    "total_products": 0,
    "discount": null,
    "total": 650,
    "name": "Добронь",
    "phone": "+7xxxxxxxxx",
    "payment": "cash",
    "confirmed": true,
    "paid": false,
    "promo_id": null,
    "remote_id": null,
    "created_at": "2022-05-23T08:45:23.000000Z",
    "updated_at": "2022-05-23T08:45:32.000000Z",
    "order_intervals": [
        {
            "order_id": 83,
            "interval_id": 4,
            "light_id": 2,
            "date": "2022-05-28",
            "price": 650,
            "interval": {
                "id": 4,
                "start": "11:30:00",
                "end": "12:00:00"
            },
            "light": {
                "id": 2,
                "title": "Циклорама",
                "price": 650
            }
        }
    ],
    "order_products": [],
    "promo": null
}

Остаётся только оформить данные на VueJS фронтенде.

А теперь сравнение

Я потратил на работу в свободное время примерно месяц. Крупная студия делала сайт 2 месяца (и вряд ли по вечерам и выходным), а потом дорабатывала еще примерно полгода, после чего Костя уже обратился ко мне.

Сайт стал гораздо быстрее. Ему не нужно грузить ничего лишнего. Например в MODX перед выдачей страницы система грузит настройки сайта, контекста, лексиконы, запускает всякие плагины (которые не факт что нужны), проверяет\обновляет кэш страницы и делает еще много разных вещей. Система, написанная на фреймворке будет делать только то, что нужно - ничего другого в ней просто нет.

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

Рабочие данные чётко отделены от системы. Никаких настроек в БД не хранится, только товары, заказы и подобное. Через это исходный код на 100% версионируется и к нему можно подключить автоматический деплой на хостинг. Кстати говоря, Костя использует modhost.pro, который отлично работает с Vesp.

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

Изменения на новом сайте вносятся очень быстро - не нужно бороться с системой, инфоблоками, ТВ полями, кэшированием и прочим. У вас есть только то, что вы написали, вам ничего не может мешать. Отправил коммит, через 5 минут он уже крутится на сервере.

Как правило фреймворки используют гораздо более свежую кодовую базу. Более новые версии PHP, MySQL и библиотек под капотом - просто потому, что им не нужно поддерживать какое-то легаси. А вот новые версии CMS как правило должны обновлять все старые сайты без ошибок. И вот мы имеем ExtJS 3.4 от 2012 года в новеньком MODX 3, выпущенном в 2022 году.

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

Когда меня на работе просят посмотреть какой-нибудь старый сайт на MODX, то там может несколько часов уйти просто на поиск места для изменений, пока разберёшься в структуре MIGX или ContentBlocks.

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

Выводы

А выводы у меня такие: CMS нужны для лёгкой продажи проекта клиенту, чтобы называть заказчику известный бренд: Битрикс, Wordpress, MODX и т.д. Объяснить преимущества индивидуальной разработки со своей админкой может быть сложнее.

Работа с фреймворком требует больше знаний и навыков, но как ни странно, со временем (и проектами) работать становится гораздо легче. Лично я сейчас на Vesp пишу в несколько раз быстрее, чем на MODX, просто потому, что накопился опыт решения распространённых проблем и я могу эти решения сам у себя копировать.

Сделал один проект с навигацией на картах MapBox, разобрался с этим сервисом (а не установил чужое дополнение) - следующий проект с этими картами идёт в разы быстрее.

Когда приходится что-то делать на MODX ощущения как будто руки за спиной связаны: ни миграций, ни нормальной работы в IDE, ни вёрстки на VueJS - кошмар!

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

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

Единственная реальная проблема самописных фреймворков - у них зачастую нет нормальной документации и тут Vesp, увы, не исключение. Рассказать как пользоваться своим творением может быть сложнее, чем его создать - и я переодически думаю, как можно это решить.

В любом случае, надеюсь, вам было интересно почитать мои мысли, спасибо за внимание!