Давайте попробуем понять чем отличаются эти 3 достаточно популярных решения для разработки веб-продуктов на PHP. Что лучше? Symfony, Laravel или WordPress?
С одной стороны, все 3 платформы позволяют решать любые задачи из мира веб-разработки и они очень похожи. Вы можете сделать сайт, блог, магазин, маркетплейс, CRM, трекер задач или все что угодно. Ограничение только в головах и наличии знаний в команде разработки.
С другой стороны у каждой платформы есть свои фишки и некое назначение.
WordPress — это про модульную сборку и типовые решения
Есть такие дома из модулей типа контейнеров. Вот это похоже на WordPress.
Вы можете взять готовые блоки и собрать что нужно. Подход типа NoCode.
Да иногда надо уметь их соединять — но это все минимум кода — LowCode.
Вот только разработка таких модулей — не самая простая задача. Особенно в контексте MVC & DDD архитектур, которые в моде последние лет 10-20.
У WP архитектура на основе модулей и сообщений. А она крайне не привычна для большинства продвинутых разработчиков воспитанных на MVC & DDD идеях.
Плюс там не хватает разных модулей для highload. Их не проблема поставить или разработать, если знать как это делать. Но в мире WP не так много прогеров, которые умеют такое делать. По этой причине highload продукты на WP встречаются редко, но бывают.
Есть такая штука что вы можете допилить все что вам нужно и поменять любую часть системы создав 1 php файл и 3 строчки кода. Если хочется писать минимум кода то это круто.
Полная свобода, пиши что хочешь и как хочешь. В любом стиле.
Но это круто когда ты 1, или в команде 3-4 спецназовца с высоким уровнем знаний.
А вот если у тебя в команде 5-7 человек, с разными уровнем знаний? Вот тут бывают проблемы, потому что свобода ведет к конфликтам. Очень сложно выстроить правила и ограничения, которые создадут ожидаемое поведение кода. Другими словами ты не всегда сможешь угадать кто куда какой файл запилил и где именно находится механизм который начал глючить. Особенно если в команде есть джуны и они там могут творить абсолютно непредсказуемые маневры 🙂
Потому в индустриальной разработке такое обычно не применяется. Там все пересрутся и подерутся.
Картинка выше это ожидания. Но реальность часто бывает другой 🙂 Зачастую низкой квалификации разработчиков хватает только на то чтобы собрать бытовку.
Laravel — это про уникальные решения
Если у вас более менее уникальный функционал, далекий от типовых решений. То Laravel может быть хорошим решением. Он ближе к понятиям MVC архитектуры.
С одной стороны он уже лучше заточен под команду, там есть больше соглашений и ограничений. Тяжелее прострелить себе или коллеге ногу.
С другой стороны если пытаться на нем делать типовые решения, то оно будет заметно дороже чем на WordPress.
Что чего то дописать — не достаточно сделать 1 файл и 3 строчки. Надо уже соблюдать соглашения. Делать классы и файлы согласно архитектуре. В соответствующих папочках.
Это заметно увеличивает количество кода. Но зато дает предсказуемость. Которая важна в команде.
Если 1 разработчик что то поменял, то другие более менее смогут угадать где именно эти изменения.
Переиспользование кода не так круто как в WordPress. По этой причине на Ларе не так много типовых решений и плагинов с бизнес логикой.
Но если система не очень большая, то можно сделать более элегантную архитектуру. Опять же если уметь.
Картинка выше это про ожидания.
В реальности чаще получается что то такое:
Symfony — это про индустриальную разработку
Если сравнивать количество кода которое надо написать для создания условного магазина, то в Laravel его придется писать сильно больше чем в WordPress. Но это детский сад в сравнении с тем что придется писать в Symfony )
В симфе на каждую историю надо писать еще больше кода. Там сильно больше слоев абстракции. И все это обычно имеет смысл в индустриальной разработке каких то больших систем и микросервисов.
Обычно разработка на Symfony очень близка к идеям DDD. Из коробки вам дается просто обработчик HTTP запросов. Нет ни БД, ни кешей, ни пользователей. Ничего.
Но далее включаются соглашения и практики из индустриальных команд. Надо чтобы сущности были отделимы от БД. Потому пишутся дополнительные слои абстракции. Тут нет модели как в Ларе которая умеет все. Тут на каждую таблицу надо написать сущность, для нее DTO, репозитории чтобы это все можно было как то хранить и передавать в разные БД и каналы обмена. Например хранить это в PostgreSQL, в Redis, в ElasticSearch, передавать в RabbitMQ …
Это все частые атрибуты в индустриальной разработке и системах с highload.
Но тут также бывают факапы.
Edge кейсы и выводы
В общем на любой из этих платформ можно сделать что угодно. Вопрос лишь в том что у каждой из них есть особенности, которые чуть лучше или чуть хуже подходят под те или иные контексты.
Рассклад примерно такой:
- Симфа лучше заточена под сложные большие индустриальные системы. С очень большими бюджетами.
- Лара лучше заточена под работу команды и не очень большие системы. Средние бюджеты.
- ВордПресс лучше заточен под быструю сборку типовых решений из готовых модулей. Минимальные бюджеты.
На Ларе или ВордПресс тоже можно делать очень большие и нагруженные системы. Но во первых это надо уметь делать, а во вторых там бюджеты будут такими же. Сложные системы стоят дорого. И не важно на какой платформе.
А бывают такие кейсы, когда на Симфе пытаются сделать переиспользование бандлов с бизнес логикой. И это сложно. Тут Симфонистам не помешал бы опыт ВордПресс. Но его там обычно нет. И там при росте проекта до 50-100 человек и 10-20 команд, при переиспользовании большого объема кода между командами начинает ад блокировок.
В Laravel есть кейсы где это смогли порешать, например FreeScout. Но они как раз почти целиком слизали модульную архитектуру с обменом сообщений и диспетчером хуков из WordPress 🙂
Потому не все всегда и везде, а кое что иногда и местами.
По большей части успех зависит от ценности продукта, от адекватности руководства и уровня развития команды.
А фреймворк — играют очень малую роль.
Все споры среди программистов от низкой квалификации. И потому что каждый кулик хвалит свое болото )
Наставничество и сопровождение проектов
Если интересно снизить риски и повысить продуктивность разработки, то могу предложить вам услугу сопровождения и наставничества https://wpcraft.ru/wordpress-woocommerce-mentoring/
Стоит сделать уникальные плюсики, а то заплюсую до немагу. Разница что фреймворк — это стройматериалы, а CMS — уже построенный дом и сравнивать их как минимум не корректно. А так фотки норм. Сколько проектов вы сделали на Symfony и Laravel, чтобы делать сравнение и подобные выводы? Всегда было интересно почему Laravel — это для стартапов, а Symfony — энтерпрайз, ведь сложность и масштабы проектов и там и там могут быть примерно одинаковыми по величине
Сложность и масштаб проектов — не так чтобы зависят от фреймворка.
Я видел крупные проекты на WP, и видел глупости и мелочь на Symfony. С Laravel тоже самое.
Что есть фреймворк? Тоже спорный вопрос и ответ зависит от точки зрения. WordPress также может быть фреймворком если уметь на нем кодить https://www.amazon.com/Building-Web-Apps-WordPress-Application/dp/1491990082
У меня небольшой опыт работы c Symfony и Laravel, но мне повезло в жизни понять, что такое WordPress и как с ним работать) При правильной организации команды разработчиков за счет событийной архитектуры WoprdPress и его модульной системы разработку web приложения можно сделать намного быстрее и бюджетнее чем на Symfony и Laravel. Также считаю, что при грамотной разработки на WordPress можно сделать проект любой сложности. Согласен, что бюджеты такой разработки будут другими, но все равно меньше чем при разработке на Symfony или Laravel. То что на WordPress можно делать только небольшие проекты — это неправда)
Сложность и масштаб проектов — не так чтобы зависят от фреймворка.
Но ведь было сказано для каких проектов больше подходит Laravel (не больше проекты), а для каких Symfony (большие)
Что есть фреймворк? Тоже спорный вопрос и ответ зависит от точки зрения.
Под каким углом не смотри — разницы нет. Например, у фреймворка нет уже готовой админки, но может быть CRUD генерация, нет уже готовой схемы БД, её нужно проектировать самому, все фрейморки, после установки фреймворка у тебя не создаётся какой-то контент или настройки в БД и т. д., это список можно продолжать, ну а можно провести аналогию, как делал автор в статье. Нельзя же назвать October CMS фреймворком, хоть она и создана на его основе. Не вижу смысла особого здесь спорить. Фреймворк — это удочка, а рыба — уже CMS. У любой CMS по любому есть похожие парадигмы и подходы, как же иначе, тем более что некоторые могут быть построенные на базе фреймворков или их компонентов (Pagekit, Drupal, Magento и т. д.).
В любом случае CMS — это уже готовый продукт, которым могут пользоваться обычные люди, а фреймворк — это заготовка, которая используется программистами. И то что у них могут быть похожие признаки, не делает из одного другого. Можно сравнить CMS c Ubuntu Desktop, а фреймворк с Ubuntu Server, в первом случае ось можно использовать и не программистам, а во втором только программистам и системным администраторам.
Книгу смотрел, но там в основном описывают различные API WordPress на примере создания мультисайта с возможностью создания школ с платным членством, при этом используется достаточно многого плагинов. В частности там говорится что у WordPress есть те же функции, что и любого фреймворка и что на нём можно делать не только простые сайты, но и веб-приложения и с этим я спорить не буду — можно сделать и CRM, биржу по поиску работы или биржу фриланса и т. д., можно сказать что CMS — это и есть веб-приложение, можно об этом поспорить, но так оно и есть. Можно же на WordPress не написать ни строчки кода и создать веб-приложение, благо есть плагины вроде ACF, Elementor и т. д., но ты берёшь готовые продукты, которые имеют UI и лишают тебя необходимости писать код, так что книга так себе и то что там указано Web Application не говорит о том что мы будем использовать в этой книге WordPress как фреймворк и напишем какое-то толковое веб-приложение с нуля (SPA или что-то в этом духе) с нуля без использования каких-либо плагинов. А то что там фактически нет никакой графики — это вообще трэш, как вообще знать что ты получишь на выходе, если на протяжении всей книги вы будете создавать какой-то продукт. Мне кажется больше узнаешь из Brad Williams — Professional WordPress Design and Development, хоть она уже очень давно переиздавалась. Короче не самая удачная книга.
Из последнего что мне попалось по WordPress REST API эти две мини-книги от WP Engine (доступны бесплатно на их сайте после подписки) вроде ничего:
Можно вообще не использовать админку WordPress, лишь его схему БД, логику создания юзеров, различных типов контента, кастомных полей и т. д. и работать с WordPress REST API, но насколько это будет удобно, мне сложно сказать — я таких проектов не делал и в книге об этом также ни слова (по крайней мере в первом издании), но знакомые делали бэк для мобильного приложения на базе WordPress, так что почему-бы и нет, если клиент просит. Тот же человек для своего личного проекта, где нужно было получать данные из другого сервиса, сохранять их базу и затем в удобочитаемом виде, выбрал Laravel, вместо WordPress, хотя и больше с ним (WordPress) работал, и там как раз таки он уткнулся в то, что схема БД WordPress ему не подходила. В общем тут всё сложно, кто как хочет так и дро…ет. Хоть в WordPress и много legacy и многие его хейтят, ну а нам то что, будем дальше работать с тем что нравится и на что есть спрос, может со временем его перепишут так чтобы хейтеров становилось по-меньше.
В любом случае фреймворк или CMS — это всего лишь инструменты, которые нужно выбирать в зависимости от задач к проекту, личных предпочтений и бюджета проекта. Совсем не плохо, если человек кроме какой-то CMS или фреймворка, хорошо знает базу, чтобы быть способным написать свой собственный велосипед в виде собственного фреймворка или CMS по ходу попрактиковавшись на различных подходах, паттернах или фичах, которые используются как в фреймворках так и в CMS, я думаю для такого человека разобраться любой другой CMS или фреймворком будет проще и быстрее. Ну а если их сравнивать — то это просто холивара ради по моему. Ну а там как знать, автору виднее 😉
Я лично не фанатею от WordPress или какого-либо фрейморка — это всего лишь инструменты, которые ты можешь использовать или нет. Всегда в выборе технологии стоит исходить из потребностей на рынке, иначе сложно будет семью прокормить, а у WordPress с этим пока что всё хорошо, пока что…
Ха-ха, вот и получился у меня коммент, практически статья.
Стоить спросить у разработчика этих комментариев, почему плагин для WordPress, а его сайт с личным кабинетом на фрейморке Yii. Пример того что это всего лишь инструменты по заработку денег и спорить что лучше молоток или кувалда — нет смысла, так как они предназначены для разных целей, хотя могут вести себя похожим образом.
да, большой коммент )
и точка зрения понятна, она очень популярная. так мыслят многие и тут много заряженных мнений.
важно понимать что бывают люди с другой точкой зрения. и это нормально )
также нет смысла спорить о том что есть что и как оно называется — это всего лишь слова и ярлыки.
важно лишь уметь делать правильный выбор и принимать адекватные решения в конкретных кейсах и контекстах.
как верно было сказано — это всего лишь инструменты. надо уметь их выбирать и использовать.
делать что то полезное людям. это важно )