Привет, Хабр. Меня зовут Денис, я backend-разработчик в Пиробайте. Поговорим о самых распространенных PHP-фреймворках и о том, для каких проектов целесообразнее выбрать тот или иной вариант.
Статистику распространения бэкенд-фреймворков на PHP я брал с портала JetBrains, она 2021-2022 года, но ситуация к концу 2023 практически не изменилась — вот статистика лучших PHP-фреймворков от Cloudways.
Самыми популярными были и остаются Laravel и Symfony. После них идет WordPress, но в статье его рассматривать не будем (потому что CMS).
Следующий за ним CodeIgniter пропущу намеренно. Я удивился, но разработчики в интернете до сих пор спорят о том, что лучше — Laravel или CodeIgniter. По сути, это full-stack MVC фреймворк, коих много. Он делает то же, что Laravel или Symfony, только отличается архитектурой и рассчитан на маленькие проекты. Он стар (существует с 2006 года) и тот же Laravel был создан как его альтератива.
Вместо этих 2-х ребят я предлагаю рассмотреть следующие — Laminas (Mezzio) и Slim. Эти фреймворки/микрофреймворки, на мой взгляд, более технологичны на фоне предыдущих и хорошо подходят для решения нетипичных задач.
Сразу оговорюсь, что статья носит субъективный характер (но это не мешает подискутировать в комментариях). Автор статьи, как и студия, имеет большой, исчерпывающий опыт разработки именно на Laravel, а знания об остальных фреймворках основаны на небольшом личном опыте, данных из общего доступа и мнениях многочисленных коллег.
Итак.
Laravel
Фаворит PHP-сообщества. Золотая середина между сложностью и функциональностью. С 2011 года постоянно улучшается. У него достаточно низкий порог входа, из-за того он так популярен.
У фреймворка много решений из коробки, что дает спокойно подумать над архитектурой, а не изобретать велосипед. Например, в нем предусмотрены готовые решения для авторизации пользователя, тестирования отдельных модулей продукта, системы защиты от всевозможных атак и прочее, и прочее. У него отличные системы миграции баз данных, эффективный API для быстрой отправки электронной почты.
Использование Laravel облегчает кучу рутинных вещей — маршрутизацию, кеширование, авторизацию, аутентификацию. Упрощает такие задачи, как проверка электронных адресов пользователей, хеширование и сброс паролей.
Одна из особенностей Laravel — валидация форм в любом месте и в любой момент времени, так как он предоставляет отдельный класс валидатора. С этим парнем можно не беспокоиться о кодировании моделей, представлений и контроллеров по отдельности. А самое, наверное, крутое — это его многочисленное комьюнити. Он удобен для новых разработчиков и имеет большую поддержку на различных сайтах, таких как Stack Overflow. В общем, преимуществ у него хватает и распространен он не просто так.
Для каких проектов используется Laravel
В основном, для разработки B2B-решений. Для создания проектов с большой нагрузкой и сложной бизнес-логикой, для которых нецелесообразно использовать CMS вроде Битрикса. Идеален для разработки безопасного и надежного веб-проекта, при этом он всегда останется на пике технологий. Laravel хоть и не предлагает встроенных средств контроля безопасности, но они доступны с помощью расширений.
На фреймворке можно запустить крупный проект со сложной архитектурой. А поскольку он пригоден для быстрой обработки больших объемов данных, на его базе получится запустить хорошо оптимизированный онлайн-сервис: социальную сеть, сервис по аренде яхт, онлайн-аукцион, корпоративное приложение для сотрудников — все, что душе угодно. Фреймворк решает необходимые задачи, которые возникают у всех проектов. Конечно, что-то на нем сделать нельзя, но на это есть открытое сообщество.
Laravel может работать и в связке в Flutter, если мы говорим о мобильных приложениях: у него есть готовый функционал для реализации аутентификации и работы с данными, функционал для отправки пуш-уведомлений и электронных писем.
Отдельно упомянем технологию Laravel Octane.
Laravel Octane
Не так давно появилась технология Laravel Octane, которая позиционируется как полноценная замена Lumen. Octane, по заявлениям Тейлора, суперскоростной и работает на демоническом PHP. При этом поддерживается разработчиком Laravel из коробки.
У Laravel Octane свои сервера, не Apache или Nginx, а Swoole и RoadRunner. Они, во-первых, в разы быстрее. А во-вторых, позволяют постоянно держать в памяти PHP. Вот оригинальная статья, в которой говорится, от чего зависит скорость работы.
Суть Laravel Octane в том, чтобы разработчики, не умеющие работать с асинхронным PHP, могли с ним работать. Без головной боли о том, как же все устроено под капотом.
Для каких проектов используется Laravel Octane
Для прироста производительности уже существующих приложений, разработанных на Laravel. Технология позволяет запускать параллельные задачи, а также пользоваться таймерами, интервалами, особо быстрым кэшем и Swoole tables — структурами данных для общения между корутинами Swoole (если в качестве сервера был выбран именно Swoole, у Roadrunner такого нет):
Октан загружает приложение один раз, сохраняет его в памяти, а после отправляет ему запросы на сверхзвуковой скорости.
Symfony
У Symfony процветающее сообщество разработчиков, с количеством более 300к человек. Гибкий фреймворк, конфигурируемый под любую ситуацию, из-за чего используется в крупных проектах. У него богатая экосистема, сам он сложнее, чем Laravel, и порог входа у него выше. Есть решения для оперативного написания API и есть библиотеки, которые упрощают такие задачи, как создание форм, аутентификация маршрутизации, настройка объектов и создание шаблонов. В общем, Symfony — монстр с решениями на все случаи, но на его изучение может уйти пару жизней.
Ходит мнение, что каждый уважающий себя PHP-разработчик должен попробовать Symfony — он действительно интересно устроен, работа с ним прокачивает понимание многих вещей. Например, придется понять, как именно работает внедрение зависимостей, рефлексия классов, событийная архитектура (у Symfony, в отличие, например, от Laravel, обработка запроса реализуется не через Middleware, а через обработку событий для каждого этапа жизненного цикла).
Для каких проектов используется Symfony
Для проектов уровня энтерпрайз. В крупных компаниях-корпорациях. Для примера: на Symfony разработаны такие веб-ресурсы, как Spotify, и Yahoo! Также многие CMS под капотом используют компоненты Symfony. Это Drupal, Magento, eZ Publish и phpBB.
У Symfony есть расширения для настройки того или иного функционала. Например, компоненты для подключения онлайн-оплаты, мессенджера, настройки мультиязычных страниц веб-приложения.Также разработчики на Symfony часто используют свои самописные компоненты в других проектах, чтобы ускорить процесс. Но из-за высокого порога вхождения отладить Symfony сложнее, и зачастую проекты на нем будут работать медленнее, чем на других фреймворках.
Yii
Yii — это объектно-ориентированный и MVC PHP-фреймворк. Одной из лучших его особенностей является генерация CRUD.
Yii использует специальный инструмент генерации кода под названием Gii – веб-интерфейс, а также интерфейс командной строки для генерации часто используемых фрагментов кода. Что способствует быстрой разработке и повышению производительности приложений.
Написание повторяющихся кодов полностью исключено, так как Yii следует правилу DRY — Don’t Repeat Yourself — и позволяет структурировать кодовую базу. Содержит множество Ajax-виджетов для проверки данных. Обеспечивает расширяемость платформы путем внесения незначительных изменений в код, а также совместимость с интерфейсами сторонних разработчиков, ускоряет время загрузки страниц, тем самым повышая производительность сайта.
Для каких проектов используется Yii
Используется для разработки приложений любой сложности — от сайтов-визиток до крупных сервисов. Но в 2023 разрабатывать новые проекты на Yii, на мой взгляд, целесообразнее, если штат разработчиков хорошо разбирается в Yii, но не разбирается в других технологиях. Тенденция такова, что фреймворк теряет позиции, и новые проекты на нем пишутся редко.
Гораздо больше разработчиков на Laravel, их легче найти, коммьюнити намного активнее. Да и разнообразных пакетов навскидку для Laravel больше. Популярность Yii, наверное, можно объяснить тем, что существовал он до широкого распространения публичных Git-репозиториев и практики коллективной open-source разработки, и какое-то время у него не было серьезных конкурентов.
Slim
Это микрофреймворк, который помогает писать простые, но мощные веб-приложения и API. По сути, Slim — диспетчер, который получает HTTP-запрос, вызывает соответствующую процедуру обратного вызова и возвращает HTTP-ответ.
Большой плюс в том, что Slim очень быстрый и имеет мало кода.
Из-за того, что это микрофреймворк, можно использовать только нужные функции, не перегружая проект лишним кодом — Slim супер легковесный.
Для каких проектов используется Slim
Для решения небольших задач, в ситуациях, когда Symfony и Laravel для них будут избыточными. Основное веб-приложение можно разработать на Laravel, а отдельные, слабо связанные и атомарные сервисы — на Slim. Фреймворк используется для небольших api, для микросервисов, для отдельных сервисов в рамках монолита.
Laminas (Mezzio)
По сути Mezzio — это ответвление от Zend Framework. Он собран из кусков Zend Framework, который сейчас называется Laminas, и поддерживает все модули Laminas. Получается, что непосредственно Mezzio не популярен, в то время как Laminas (Zend) довольно таки распространен.
Микрофреймворк позволяет строить модульные приложения (почти как в NestJs). Также он позволяет использовать только те элементы, которые необходимы для выполнения задач конкретного проекта: MVC, аутентификацию, кэширование и многое другое.
У Laminas хорошая поддержка, он постоянно обрастает новыми функциями и обновляется.
Поддерживает запуск через Swoole. Отлично подходит для микросервисной архитектуры. Богат библиотеками, включающими компоненты для синхронизации с внешними сервисами — например, YouTube. Поддерживает большинство популярных СУБД, включая MySQL, Microsoft SQL Server, SQLite, PostgreSQL.
Для каких проектов используется Laminas (Mezzio)?
Однозначного ответа нет. Можно использовать для разных целей, но главным образом для API. Хорошо подойдет для микросервисов. По умолчанию доступен скелетон модульного приложения. Если его использовать и придерживаться модульной архитектуры, то на выходе получится код, который легко поддерживать и масштабировать.
То есть, если у бизнеса появится необходимость масштабироваться, то Mezzio позволит сделать это относительно недорого. В этом он похож на Symfony. Если надо будет разбить приложение на микросервисы, с Laravel это будет сделать сложнее, так как его архитектура немного о другом.
На что обратить внимание при выборе фреймворка?
С точки зрения бизнеса — это всегда будет доступность. Никто никогда не выберет никому неизвестную технологию, к которой потом не найдешь разработчиков.
С точки зрения разработчиков — однозначно ответить на этот вопрос нельзя. Все зависит от конкретной задачи. Если нужно реалтайм-взаимодействие (что PHP не поддерживает), ты будешь искать решение не в PHP. А, на Node.js, например. А если все-таки нужно оставаться в рамках PHP, можно найти асинхронные решения вроде RoadRunner или Swoole.
Если нужен сервис, который раз в неделю будет проверять сайт на битые ссылки, можно взять какой-нибудь микрофеймворк вроде Slim и поднять его отдельно.
Если нужен бэк для чат-ботов Telegram — аналогично. Можно обойтись микрофреймворком. Главное, чтобы для него были удобные библиотеки для работы с API Telegram.
Для решения малых задач не обязательно использовать full-stack решения, а любую крупную задачу можно разбить на множество малых. У каждого фреймворка свои преимущества, но самым важным фактором при выборе всегда будет способность фреймворка закрывать поставленные вами задачи.
По сему у меня возникает вопрос — что используете для разработки B2B-проектов вы? И насколько хорошо это решает задачи? Напишите в комментах.
Комментарии (28)
antonstovpets
14.12.2023 06:08Если проект крупный, не нужен Фреймворк. Нативный код всегда быстрее и более гибкий. Но если это прям проект, лучше рассмотреть node.js + если есть математика то её рассчитывать на питоне, си или расте
pyrobyte
14.12.2023 06:08Спорное утверждение. Иметь каркас, подходящий под основные задачи, на наш взгляд, все-таки лучше, чем не иметь ничего и тратить огромное количество времени на создание велосипедов. А дальше уже обкладывать микросервисами с интересующими нюансами. Хоть на Rust, хоть на Python. Либо это должен быть настолько крупный и уникальный проект, для которого вообще нет решений. Что маловероятно, но возможно (но процент крайне мал).
how
14.12.2023 06:08В большинстве веб-проектов тормоза не в языке, а в базе данных. Умудриться делать сотни неоптимизированных запросов без кеша, чтобы показать главную страницу, одинаково легко как на PHP, так и на Rust.
VladimirFarshatov
14.12.2023 06:08Хотелось бы посмотреть на бенчмарки полноценного кейса на этих фреймворках в сравнении.. очень любопытно как временной отклик на страницу с кешированием и без него, так и требуемые ресурсы в виде количества подгружаемых классов и памяти на отклик.
В свое время сам делал подобное сравнение (2019г), на один поток сервера с 1Гб ОЗУ и Core2Duo 2Ггц (ну вот такой тестовый сервер) для связки nginx + php-fpm7.4 + mariaDB 10.2 получал около 250 подгружаемых классов для Laravell на страничку, читающую ответ из БД тупо по primary key. Ну и около 170 ответов в секунду, не более.
Yii2 для такой же странички был чутка (двое? не помню) легковеснее и отдавал около 190 ответов в секунду.
Чистый код на PHP7.4 в стиле MVC с прямой работой через PDO отдавал уже 1500-2500 ответов в секунду. Но я там обошелся подгрузкой всего 6 классов, включая диспетчера.. не совсем корректное сравнение все же.
Чистый nginx отдавал страничку из предподготовленного файла около 8000 в сек. а может и поболее..
Есть какие-то честные бенчи без разных подгонов? Просто любопытно, давно PHP не юзал .. года три как уже в Го..
gun_dose
14.12.2023 06:08Очень странная затея делать подобные бенчмарки. Само собой, что самописный код всегда будет работать быстрее, потому что в нём ничего нет. Не "ничего лишнего", а именно просто "ничего". Возьмём простой пример, список из 5 статей с заголовком и текстом. Вот напишете вы запрос в базу данных, который это выберет. Ну ок. А теперь представьте себе, что одна из статей неопубликованная и показывать её можно только админу или автору. Есть ли среди ваших шести подгруженных классов тот, который отвечает за сессию и роль пользователя? Далее, что там ещё в тексте можно сделать? XSS-фильтрация? Добавить target=_blank и rel=nofollow к внешним ссылкам. Сделать ресайз картинок в тексте. Всё ещё думаете, что шесть классов достаточно? А давайте добавим в хэдер и футер менюшку, которую можно редактировать из админки!
честные бенчи
Честный бенч будет только тогда, когда сравниваться будет одинаковый функционал. Для этого надо взять внятное ТЗ простейшего сайта, и сделать этот сайт несколько раз с использованием разных технологий, причём так, чтобы во всех случаях внешний вид и функционал был полностью одинаковым. Кроме того, чтобы функционал на 100% соответствовал не только ТЗ, но и всем общепринятым практикам, начиная с защиты от SQL-инъекций, заканчивая всякими SEO-штуками вроде генерации внятных заголовков страниц и метатегов.
Но и этого на самом деле недостаточно. Скорее всего самописное решение по-прежнему будет выигрывать по производительности. Но вот только какой ценой будет даваться внесение изменений и дополнений в самописный функционал? Вряд ли кто-то захочет намертво привязывать себя к одному разработчику ради того, чтобы главная страница отдавалась не за 200мс, а за 100.
shasoftX
14.12.2023 06:08Тут ещё стоит добавить возможность расширения функционала. В случае самописного его придется писать самому, а если используется фреймворк, то есть большая вероятность что есть уже готовый под ваши хотелки.
RichardBlanck
14.12.2023 06:08Используйте CMS. Там в хэдер и футер менюшку, которую можно редактировать из админки уже добавили.
gun_dose
14.12.2023 06:08Так я и использую. Это же не я задаюсь вопросом, почему там 150 классов грузится. Я прекрасно понимаю, зачем они туда грузятся
forthuse
14.12.2023 06:08Не рекламы ради, а информации для. :)
Находятся отдельные ещё разработчики, которые даже на PHP 5 продолжают
развитие проектов/инструментария от линии CMS Fusion не переходя например на версию 9 и более новые версии PHP языка.https://vk.com/phpfusion (Бесплатная CMS PHP-Fusion 7 Bogatyr)
https://rusfusion.ru/forum/viewthread.php?thread_id=2923 (объясняя почему)
VladimirFarshatov
14.12.2023 06:08Всё описанное вами решается достаточно простыми средствами и да, конечно же по большей части было в тестовом "сайте".
Как раз была задача "что выбрать" для скоростной отдачи страниц .. условный хайлоад на ПХП, если он вообще на нем возможен, и насколько возможен.. сравнивался один и тот же функционал по ТЗ.
Предподготовка и нгинх выиграли "на порядок" .. ;)
gun_dose
14.12.2023 06:08А я и не говорю, что это сложно решается. Я говорю, что в условном Laravel или Drupal это всё уже решено, но за это приходится платить "подгрузкой 150 классов".
PS: хайлоад на пхп вполне возможен и существует
VladimirFarshatov
14.12.2023 06:08Мне хватило шести:
Класс с рекурсивной диспетчеризацией (роутинг), в т.ч. отдача "быстрых" страниц без предподготовки (роутинг по хеш-мапе), предподготовка параметров запроса гет, пост, куки, формы .. всё что есть "оптом", подгрузка сессии в нем же. Позволял за собой вызывать далее Zend,Yii, Laravel и что угодно (для этого и писался в свое время);
Класс "базовый контроллер" с готовыми типовыми валидаторами, можно наследовать. Может иметь "хелперы" доподготовки параметров, роли могут быть тут же как хелпер (вот этого в тесте не было, но и на фреймворках не задавалось);
Класс ассертов, подбирающий к выдаче css, js, .. Layouts в нем же.
Класс SQL-builder на базе PDO, никаких Active Record, ORM .. на базе prepare and execute. Исключаем иньекции здесь же (prepare). Да, не "объектная модель БД" (нахрена она нужна, когда прямой скуль запрос пишется в два раза шустрее, если умеешь? Не надо прописывать "модели", методы, связи.. всё это есть в БД, "студент(маппер) не нужен" (с) Кин-дза-дза. Позволял множественные execute с предподготовленным запросом;
Класс сборки и отрисовки view (представлений). FormBuilder как хелпер (виджет), сериализация, валидация эскейпинг исходящего.. Также "базовый", можно наращивать, в т.ч. и трейтами по необходимости;
Класс мониторинга и отладки. Вставлял скрытый div в выдачу с пошаговым исполнением запроса при уровне debug. Логирование - здесь же. Уровни логирования, потребленный объем ЗУ, время исполнения по шагам;
.. вроде бы ничего не забыл. А, ну да, как же. Стартовый скрипт, с автолоадером классов как по таблице классов, так и по текущим путям с настройкой.. ;)
Прямое применение YAGNI, KISS, DRY, SOLID и именно в этом порядке...
Всё это было выложено на хостинг NIC.RU на доменное имя ussr.monster в виде исходного кода и пошаговой инструкции как пишется MVC на таком "нано-фреймворке".. закрыл, ибо не увидел смысла платить за хостинг. В этом виде и тестился.. ;)
pyrobyte
14.12.2023 06:08Вот здесь можно посмотреть — https://kinsta.com/blog/php-benchmarks/. И вот здесь — https://www.techempower.com/benchmarks/#hw=ph&test=fortune§ion=data-r22&l=zik073-cn3, но тут не уверены за их неангажированность.
kovserg
14.12.2023 06:08Какой интересный график. Люди стали забывать для чего были нужны проценты и нормировка. Если убрать лидера то оставшиеся будут составлять 98%. Это значит что все используют какой-то фреймворк и половина из них еще и laravel используют. Либо им не хватает laravel и они используют запасной фреймворк или они используют основной и тыкают палкой laravel ибо модно.
SerJook
14.12.2023 06:08Это надо ну прям сильно любить пхп чтобы писать на нем энтерпрайз.
antonstovpets
14.12.2023 06:08Лет 15 писал на php. Язык для своих задач до сих пор актуален. Но его функционал ограничен сейчас потребностями. Его пытаются использовать там, где он ну совсем не подходит. И обижаются на любую критику.
Фреймворки вообще зло
shasoftX
14.12.2023 06:08Фреймворки это по сути функции/классы более высокого порядка. Даже если писать с нуля, то начнешь сам такие фреймворки писать. Так и разбираться проще, и стартовать другой аналогичный проект быстрее.
Tony-Sol
14.12.2023 06:08Жаль нет про spiral - на одной из прошлых работ рассматривали его как основной фреймворк для php приложений и тогда мне он очень понравился, особенно в связке с roadrunner
AleksandrTm
14.12.2023 06:08Laravel хорошо себя показывает в связке с swoole, сейчас пишу проект, разбираясь с подводными кампням swoole самого
в целом всё чаще вижу когда обычный фреймворк прикручивают к roadrunner или swoole, аналоги
roxblnfk
14.12.2023 06:08Было бы неплохо, если бы вы потом поделились знанием о подводных камнях с сообществом, если это не тое, что на поверхности.
в целом всё чаще вижу когда обычный фреймворк прикручивают к roadrunner или swoole, аналоги
Да, PHP сообщество уже активно двигается в этом направлении, не то что пару лет назад. Натягивают умирающие архитектуры на стержень лонгливинга. Появились Laravel Octane, Symfony Runtime, кастомные приблуды для слима и прочее.
Spiral сразу проектировался в связке с RoadRunner под распределёнщину и высокую нагрузку. И, отвечая на вопрос автора, сейчас для энтерпрайза я бы брал именно его.
sergeytolkachyov
14.12.2023 06:08А Joomla? Она не только и не столько CMS. Начиная с 4й версии они слили фреймворк с CMS и это теперь один продукт.
arokettu
14.12.2023 06:08Slim отлично скейлится до больших приложений, особенно если прикрутить к нему хороший DI (например PHP-DI)
smarthomeblog
14.12.2023 06:08При выборе фреймворка для долгоиграющего коммерческого проекта надо смотреть не только на скорость этого самого фреймворка, но и на стратегию развития. Как я вижу, в настоящее время она отлично прописана и исполняется в Laravel, Symfony, CakePHP. У них ясный релиз-цикл, которому они следуют. Плюс смотреть насколько развито и активно коммунити.
А насчет чистого PHP. Работать он будет быстрее конечно. Только вот поддерживать и расширять такое решение еще то удовольствие. И, как показывает практика, все равно скатываются в написание собственного фрейморка. А это чревато большими проблемами в долгосрочной перспективе.
FSA
14.12.2023 06:08Подтверждаю. Больше 20 лет писал на PHP. Первому моему сайту уже 21 год стукнуло. И всё время был на нативном PHP. Постепенно из проектов пришлось вытаскивать куски и делать своё подобие фреймворка. С каждой новой версией постоянно что-то ломал, переделывал. Приходилось попутно менять и свои сайты на нём. В конце концов задумался, что надо с этим что-то делать. Решил копнуть Symfony. Со скрипом попробовал запустить некоторые страницы своего первого сайта. Показалось очень медленно. Но потом, покопавшись в документации, нашёл как собирать проект под prod. И оказалось, Symfony быстрее того, что я за все эти годы нагородил :-D Да, не совсем честно, потому что в моём коде нужно только оптимизировать автозагрузку и никакого файлового кэша... Но кого это сейчас волнует! Кэш соберётся при деплое. К тому же теперь есть относительно чёткая структура проекта (к которой надо постепенно привыкать, а не городить что попало). Единственное, что стало заметно хуже - взаимодействие с БД. Я постоянно пользовался PostgreSQL. В Doctrine это конечно всё работает. Но если по всем правилам создавать сущности для каждой таблицы, то задолбаешься их настраивать. При создании миграции Doctrine делает какую-то дичь, например, удаляет хорошо названные индексы, которую создал сам PostgreSQL и делает свой такой же с названием, не говорящим человеку ничего. Все миграции надо руками переписывать. Но я только в начале пути, как-нибудь разберусь. И да. если кто хочет сравнить какой код работает быстрее, нативный или Symfony, то tavda.info написан на symfony, а old.tavda.info написан на чистом PHP. Только сильно сервер не бомбите :-D Там слабая машина, на наплыв пользователей не рассчитана.
roxblnfk
14.12.2023 06:08Выглядит как очередная статья "Топ N PHP Фреймворков 20XX года", которая переписывается из года в год с незначительными изменениями. Только на этот раз, похоже, нагенеренная через LLM.
Особенно вот это зашло:
Написание повторяющихся кодов полностью исключено, так как Yii следует правилу DRY — Don’t Repeat Yourself — и позволяет структурировать кодовую базу.
Uzzzer2pac
В своей жизни сталкивался с разным стеком. В том числе битрикс, Yii2, opencart и тому подобные решения - комьюнити которых не особо готово делиться чем-то полезным. Либо в силу отсутствия понимания чего-то, за пределами коробки, либо из корыстных соображений (условный кейс постигли ограниченное количество людей - и за его решением в частном порядке к ним же и обращаются). После таких "закидонов" - сообщество Лары - особенно теплое, ламповое, няшное, дружелюбное.