Комментарии 40
В своей жизни сталкивался с разным стеком. В том числе битрикс, Yii2, opencart и тому подобные решения - комьюнити которых не особо готово делиться чем-то полезным. Либо в силу отсутствия понимания чего-то, за пределами коробки, либо из корыстных соображений (условный кейс постигли ограниченное количество людей - и за его решением в частном порядке к ним же и обращаются). После таких "закидонов" - сообщество Лары - особенно теплое, ламповое, няшное, дружелюбное.
Если проект крупный, не нужен Фреймворк. Нативный код всегда быстрее и более гибкий. Но если это прям проект, лучше рассмотреть node.js + если есть математика то её рассчитывать на питоне, си или расте
Спорное утверждение. Иметь каркас, подходящий под основные задачи, на наш взгляд, все-таки лучше, чем не иметь ничего и тратить огромное количество времени на создание велосипедов. А дальше уже обкладывать микросервисами с интересующими нюансами. Хоть на Rust, хоть на Python. Либо это должен быть настолько крупный и уникальный проект, для которого вообще нет решений. Что маловероятно, но возможно (но процент крайне мал).
В большинстве веб-проектов тормоза не в языке, а в базе данных. Умудриться делать сотни неоптимизированных запросов без кеша, чтобы показать главную страницу, одинаково легко как на PHP, так и на Rust.
Хотелось бы посмотреть на бенчмарки полноценного кейса на этих фреймворках в сравнении.. очень любопытно как временной отклик на страницу с кешированием и без него, так и требуемые ресурсы в виде количества подгружаемых классов и памяти на отклик.
В свое время сам делал подобное сравнение (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 не юзал .. года три как уже в Го..
Очень странная затея делать подобные бенчмарки. Само собой, что самописный код всегда будет работать быстрее, потому что в нём ничего нет. Не "ничего лишнего", а именно просто "ничего". Возьмём простой пример, список из 5 статей с заголовком и текстом. Вот напишете вы запрос в базу данных, который это выберет. Ну ок. А теперь представьте себе, что одна из статей неопубликованная и показывать её можно только админу или автору. Есть ли среди ваших шести подгруженных классов тот, который отвечает за сессию и роль пользователя? Далее, что там ещё в тексте можно сделать? XSS-фильтрация? Добавить target=_blank и rel=nofollow к внешним ссылкам. Сделать ресайз картинок в тексте. Всё ещё думаете, что шесть классов достаточно? А давайте добавим в хэдер и футер менюшку, которую можно редактировать из админки!
честные бенчи
Честный бенч будет только тогда, когда сравниваться будет одинаковый функционал. Для этого надо взять внятное ТЗ простейшего сайта, и сделать этот сайт несколько раз с использованием разных технологий, причём так, чтобы во всех случаях внешний вид и функционал был полностью одинаковым. Кроме того, чтобы функционал на 100% соответствовал не только ТЗ, но и всем общепринятым практикам, начиная с защиты от SQL-инъекций, заканчивая всякими SEO-штуками вроде генерации внятных заголовков страниц и метатегов.
Но и этого на самом деле недостаточно. Скорее всего самописное решение по-прежнему будет выигрывать по производительности. Но вот только какой ценой будет даваться внесение изменений и дополнений в самописный функционал? Вряд ли кто-то захочет намертво привязывать себя к одному разработчику ради того, чтобы главная страница отдавалась не за 200мс, а за 100.
Тут ещё стоит добавить возможность расширения функционала. В случае самописного его придется писать самому, а если используется фреймворк, то есть большая вероятность что есть уже готовый под ваши хотелки.
Используйте CMS. Там в хэдер и футер менюшку, которую можно редактировать из админки уже добавили.
Не рекламы ради, а информации для. :)
Находятся отдельные ещё разработчики, которые даже на PHP 5 продолжают
развитие проектов/инструментария от линии CMS Fusion не переходя например на версию 9 и более новые версии PHP языка.
https://vk.com/phpfusion (Бесплатная CMS PHP-Fusion 7 Bogatyr)
https://rusfusion.ru/forum/viewthread.php?thread_id=2923 (объясняя почему)
Всё описанное вами решается достаточно простыми средствами и да, конечно же по большей части было в тестовом "сайте".
Как раз была задача "что выбрать" для скоростной отдачи страниц .. условный хайлоад на ПХП, если он вообще на нем возможен, и насколько возможен.. сравнивался один и тот же функционал по ТЗ.
Предподготовка и нгинх выиграли "на порядок" .. ;)
А я и не говорю, что это сложно решается. Я говорю, что в условном Laravel или Drupal это всё уже решено, но за это приходится платить "подгрузкой 150 классов".
PS: хайлоад на пхп вполне возможен и существует
Мне хватило шести:
Класс с рекурсивной диспетчеризацией (роутинг), в т.ч. отдача "быстрых" страниц без предподготовки (роутинг по хеш-мапе), предподготовка параметров запроса гет, пост, куки, формы .. всё что есть "оптом", подгрузка сессии в нем же. Позволял за собой вызывать далее 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 на таком "нано-фреймворке".. закрыл, ибо не увидел смысла платить за хостинг. В этом виде и тестился.. ;)
Вот здесь можно посмотреть — https://kinsta.com/blog/php-benchmarks/. И вот здесь — https://www.techempower.com/benchmarks/#hw=ph&test=fortune§ion=data-r22&l=zik073-cn3, но тут не уверены за их неангажированность.
Какой интересный график. Люди стали забывать для чего были нужны проценты и нормировка. Если убрать лидера то оставшиеся будут составлять 98%. Это значит что все используют какой-то фреймворк и половина из них еще и laravel используют. Либо им не хватает laravel и они используют запасной фреймворк или они используют основной и тыкают палкой laravel ибо модно.
Это надо ну прям сильно любить пхп чтобы писать на нем энтерпрайз.
Жаль нет про spiral - на одной из прошлых работ рассматривали его как основной фреймворк для php приложений и тогда мне он очень понравился, особенно в связке с roadrunner
Laravel хорошо себя показывает в связке с swoole, сейчас пишу проект, разбираясь с подводными кампням swoole самого
в целом всё чаще вижу когда обычный фреймворк прикручивают к roadrunner или swoole, аналоги
Было бы неплохо, если бы вы потом поделились знанием о подводных камнях с сообществом, если это не тое, что на поверхности.
в целом всё чаще вижу когда обычный фреймворк прикручивают к roadrunner или swoole, аналоги
Да, PHP сообщество уже активно двигается в этом направлении, не то что пару лет назад. Натягивают умирающие архитектуры на стержень лонгливинга. Появились Laravel Octane, Symfony Runtime, кастомные приблуды для слима и прочее.
Spiral сразу проектировался в связке с RoadRunner под распределёнщину и высокую нагрузку. И, отвечая на вопрос автора, сейчас для энтерпрайза я бы брал именно его.
А Joomla? Она не только и не столько CMS. Начиная с 4й версии они слили фреймворк с CMS и это теперь один продукт.
Slim отлично скейлится до больших приложений, особенно если прикрутить к нему хороший DI (например PHP-DI)
При выборе фреймворка для долгоиграющего коммерческого проекта надо смотреть не только на скорость этого самого фреймворка, но и на стратегию развития. Как я вижу, в настоящее время она отлично прописана и исполняется в Laravel, Symfony, CakePHP. У них ясный релиз-цикл, которому они следуют. Плюс смотреть насколько развито и активно коммунити.
А насчет чистого PHP. Работать он будет быстрее конечно. Только вот поддерживать и расширять такое решение еще то удовольствие. И, как показывает практика, все равно скатываются в написание собственного фрейморка. А это чревато большими проблемами в долгосрочной перспективе.
Подтверждаю. Больше 20 лет писал на PHP. Первому моему сайту уже 21 год стукнуло. И всё время был на нативном PHP. Постепенно из проектов пришлось вытаскивать куски и делать своё подобие фреймворка. С каждой новой версией постоянно что-то ломал, переделывал. Приходилось попутно менять и свои сайты на нём. В конце концов задумался, что надо с этим что-то делать. Решил копнуть Symfony. Со скрипом попробовал запустить некоторые страницы своего первого сайта. Показалось очень медленно. Но потом, покопавшись в документации, нашёл как собирать проект под prod. И оказалось, Symfony быстрее того, что я за все эти годы нагородил :-D Да, не совсем честно, потому что в моём коде нужно только оптимизировать автозагрузку и никакого файлового кэша... Но кого это сейчас волнует! Кэш соберётся при деплое. К тому же теперь есть относительно чёткая структура проекта (к которой надо постепенно привыкать, а не городить что попало). Единственное, что стало заметно хуже - взаимодействие с БД. Я постоянно пользовался PostgreSQL. В Doctrine это конечно всё работает. Но если по всем правилам создавать сущности для каждой таблицы, то задолбаешься их настраивать. При создании миграции Doctrine делает какую-то дичь, например, удаляет хорошо названные индексы, которую создал сам PostgreSQL и делает свой такой же с названием, не говорящим человеку ничего. Все миграции надо руками переписывать. Но я только в начале пути, как-нибудь разберусь. И да. если кто хочет сравнить какой код работает быстрее, нативный или Symfony, то tavda.info написан на symfony, а old.tavda.info написан на чистом PHP. Только сильно сервер не бомбите :-D Там слабая машина, на наплыв пользователей не рассчитана.
Выглядит как очередная статья "Топ N PHP Фреймворков 20XX года", которая переписывается из года в год с незначительными изменениями. Только на этот раз, похоже, нагенеренная через LLM.
Особенно вот это зашло:
Написание повторяющихся кодов полностью исключено, так как Yii следует правилу DRY — Don’t Repeat Yourself — и позволяет структурировать кодовую базу.
Не хочу показаться банальным но под капотом ларки ядро симфони. И для меня многие вещи которые элементарно реализуются на симфони из-за его концепта со скрипом можно сделать в ларавеле. Например сборку зависимостей в зависимости от реквеста.
laravel и symfony, остальное я бы не использовал. Поддержка и развитие одно из самых главных. Yii мертва, остальное изредка мелькает в подобных статьях
Наша компания использует Фреймворк nette, у которого почти нет комьюнити и это очень больно. Призодится ковырять код фрейма, для решения некоторых задач. Такая же проблема с yii2, на котором написан CraftCMS. Тут комьюнити больше. Но всё равно, не такое как на wp. На мой взгляд, комьюнити имеет большое значение, для большинства проектов.
Yii вообще терпеть не могу, на нëм такой говнокод пишут, и представление и логика вам в одном файле, ужас.
У CodeIgniter в 2019 сменилось ядро и он стал более Лара-подобным.
"и рассчитан на маленькие проекты" можете чем-то обосновать?
"вот статистика лучших PHP-фреймворков от Cloudways." в этой статье меняется только год. Например, описании CakePHP говорится о релизе 3.7 который был в 2018 году.
Так что ссылаться на это... ну такое себе.
По производительности без асинхронности, вроде RR и Swoole, Laravel прилично отстает от других перечисленных фреймворков (мы же не считаем CMS). Но, в статье почему то не указано, что Symfony поддерживает всё тоже самое, тоже может в асинхронность, да и Yii3 (в статье не указана версия), может похвастаться тем-же. В итоге - пробуем их всех через RoadRunner и Laravel опять в хвосте. Но примерно вот так работает его маркетинг.
Slim - пушка
Хочу сравнить Yii и Laravel. В Yii функционал разработан так, что думаешь попадание не в бровь, а в глаз. С одной стороны просто, а с другой стороны максимально удобно для разработки. Не хочу сказать, что Laravel плох, но как-то есть в нём недоработки. FormRequest - вообще неудобный, я полностью от него отказался в пользу своих классов. В миграциях не те настройки по умолчанию, которых хотелось бы иметь. Раньше нельзя было создать несколько миграций с одними теми же параметрами, например так: php artisan make:migration update_users_table . Как-то всё очень сложно. Много избыточных классов приходиться создавать. В Yii очень многое сделано для разработки MVC приложений. Очень удобно делать веб формы, табличные данные - в Laravel это делать нужно "ручками" или с помощью сторонних расширений. Когда пишу на Laravel , гораздо чаще думаю: вот бы сейчас функционал из Yii, а вот обратная ситуация бывает, но значительно реже. В Yii например не удобно проверять сложно структурированные данные. Есть внешний пакет, но он не совсем удобен.
Bitrix - это тихий ужас. Вместо MVC или web-api и использует метод "плюх". Вместо pdo myqsli, что небезопасно. Код жуткий, который с 90х, наверное ни разу не переписывался. И вообще такое ощущение, что Bitrix писали робинзоны, которые жили на не обитаемом острове в изоляции от другого мира.
WordPress, Drupal - ерунда, не годиться для разработки нормальных сайтов.
Выбираем подходящий PHP-фреймворк для проекта