Главной причиной написания этой статьи является то что этот вопрос мне задают практически регулярно и было бы хорошо просто иметь под рукой ссылку. Сразу же скажу что холивора в силе Emacs против Vi тут не будет, как и любой попытки сильно упрекнуть Laravel. Уже никто не сомневаются что он работает, на нем крутятся сайты и ничего плохого с ними не происходит, так что глупо утверждать что он чем-то плох. Я же хочу показать какую нишу старается занять PHPixie и Laravel тут просто как пример, так что я надеюсь что читатель воспримет статью как обзор в стиле HTC против Samsung, призванную показать преимущества и разницу в парадигме, но никак не постулировать кто лучше.
Система версий
Стоит заметить что оба фреймворка прошли долгий путь, и если вы были знакомы с ними 2 года назад, то скорее всего совсем не узнаете их сегодня. В этом они оба отличаются от Symfony, который меняется намного медленнее, и даже разница между версиями 2.7 и 3.0 не очень большая. Впрочем если сравнивать с дистрибутивами линукса, то Symfony похож на Debian, Laravel на Ubuntu а PHPixie на Arch. PHPixie использует rolling-release подход, и все новые фичи и багфиксы сразу попадают в мастер и получают тег версии, что делает их доступными максимально быстро. Но «composer update» придется делать более аккуратно, и следить за изменениями. Тут сразу напомню что если вы используете «composer install» то устанавливаете всегда одну и ту же версию, и никаких сюрпризов ждать не приходится. Такой подход заставляет разработчика фреймворка думать о обратной совместимости, и не ломать существующее API. Как результат вы апгрейдите свой код по чуть-чуть вместе с фреймворком, и вам не надо потом думать о прыжках в стиле Laravel 4 к Laravel 5, где в один момент поменялось все, а код на Laravel 4 теперь считается legacy.
Скорость работы
Со скоростью в PHPixie все осталось по старому, она дальше столь же быстра, так как код роутинга и самого ядра практически не изменялся, она лишь обросла новыми библиотеками, которые влияют на скорость только тогда когда вы их используете. Бенчмарки от Techempower показывают что Laravel даже на HHVM не может догнать PHPixie на PHP. В принципе я редко слышу чтобы Laravel хвалили за скорость работы, её больше хвалят за скорость разработки, так что скорее всего производительность просто никогда не была в ней приоритетом.
Порог входа
Тут несомненно выигрывает Laravel, ларакасты, фасады, всяческие сниппеты с туториалов и готовые бандлы позволяют даже новичкам сделать сайт за минимальное количество времени, да и задеполить его теперь тоже можно прямо с artisan. Все это благодаря монолитности самого фреймворка, который хоть он состоит из компонентов, но сам Laravel сливает их в одно целое. PHPixie же строго модульный, поэтому даже нет единого DI контейнера, а все зависимости строятся через отдельные фабрики, и как результат надо больше понимать что происходит за кулисами. Но вот со временем, я бы сказал так за пол года, кривая обучения меняется. PHPixie построен с нуля, и все компоненты созданы по единой парадигме, что делает отладку кода намного проще, поняв одну часть фреймоврка легче понять другую. В то время с Laravel вы проведете много времени в коде разных разработчиков с разными подходами и разного качества. Впрочем если фасады и все такое для вас действительно важно, то опциональний DI компонент позволит вам получить тот-же результат.
Работа с БД
Компоненты Database и ORM развивались наиболее сильно и являются одними из лучших частей фреймворка. Только несколько месяцев назад ORM начал поддерживать Nested Sets, при этом применяя техники оптимизации. Модели четко распределены на репозитории, запросы и сами сущности. Вместо наследования какого-то базового класса модели расширение осуществляется путем паттерна Декоратор что делает ваш код совсем независимым от самой логики работы с базой и элементарно тестируемым. Даже для построения запросов можно использовать несколько вариантов синтаксиса. Ну и конечно киллер фича что все это работает как с SQL базами данных, так и с Mongo, включая связи между сущностями в разных базах. Тут Laravel сильно проигрывает, так как Eloquent не ушел далеко от Kohana ORM и PHP ActiveRecord. Большинство опытных разработчиков при работе с Laravel используют либо Doctrine, либо Propel. Опять же это все зависит от ваших задач, для большинства CRUD приложений Eloquent работает весьма хорошо.
Сообщество
Laravel разработчиков несомненно намного больше, как и митапов и фриланс заказов для них. Единственное чем может крыть PHPixie это наш чат, в котором меня можно найти каждый день и большинство проблем решается прям там на месте. Кстати если пользователей в чате после написания этой статьи прибудет, то я буду очень рад. Даже если вы не используете PHPixie, все равно заходите к нам, даже с Laravel сумеем помочь если что.
Тесты
PHPixie известна своим 100% покрытием тестами. Это число недавно чуть уменьшилось для фреймворка в целом так как вышли 3 новых компонента, к которым пока еще и документации нет, и тесты там только в процессе, но через короткое время вновь будет 100%. Тут кстати важно не только само покрытие кода, но и его тестируемость. Отсутствие магии и фасадов как раз и позволяет писать короткие и быстрые юнит тесты к отдельным классам без необходимости поднимать кучу зависимостей на каждый тест. В Laravel тесты конечно тоже есть, но гораздо меньше, и кстати на гитхаб странице проекта нет бейджа с процентом покрытия, и даже нагуглить этот процент мне не удалось, так что его явно не афишируют. Я не поленился, и сам запустил тесты и сгенерил статистику, вот результат:
Кстати при попытке запустить тест на свежем PHPUnit при включении генерации покрытия просто выкидывает ошибку.
Роутинг
Тут у нас вновь разница парадигм. Laravel как более монолитный фреймворк предоставляет возможности байндинга к моделям, позволяя полностью пропустить код контроллера, например:
$router->bind('user', function ($value) {
return App\User::where('name', $value)->first();
});Также большинство роутов имеют имя а динамический роутинг полностью отсутствует (но его можно симулировать). Компонент роутинга PHPixie более автономный, и даже понятия контролера в нем самом нет, все что он делает это парсит запрос в набор параметров и передает их пользователю. В свою очередь это позволяет более гибкую настройку с вложенными правилами и префиксами. Еще одно отличие в том что в PHPixie роуты хранятся в файле конфигурации массивом а в Laravel задаются программно что более удобно если есть IDE с подсказками.
Шаблонизатор
PHPixie использует ПХП как шаблонизатор, а это означает что все привычные функции например ucwords, substr, trim итд. уже доступны и новый язык учить не придется. PHPixie сумела получить все преимущества популярных шаблонизаторов не прибегая к компиляции, так что с ней вам тоже будут доступны как и наследование шаблонов так и поддержка блоков. В добавок у вас будет полная подсветка синтаксиса в любом IDE и отладка с Xdebug. Кстати как я показывал в предидущих статьях, этот шаблонизатор позволяет прикрутить любой синтаксис, например HAML, в считанные минуты. Laravel Blade же сам по себе ничем особо не отличается от Twig, только синтакс чуть отличается, но ничего нового он не приносит.
HTTP
PHPixie построен на PSR-7, он расширяет его функционал добавляя свои врапперы, но вы всегда можете получить доступ к чистому PSR-7 запросу. Также он может принимать запросы из вне, что позволяет запустить фреймворк например на ReactPHP безо всяких усилий. Это также стало возможно благодаря stateless архитектуре, вместе с ReactPHP это означает что после выполнения запроса фреймворк остается таким как был до него и может сразу обрабатывать следующий без перезапуска. Laravel построен на HTTP компоненте Symfony, который строит свои запросы, и превратить их в PSR-7 можно только используя symfony/psr-http-message-bridge, что как минимум добавит оверхеда на каждом запросе. Хотя скорее всего в следующей версии Laravel перейдет на PSR-7 полностью.
Аутентификация
Добавить аутентификацию в Laravel очень просто, конфигурация доступна фактически из-коробки, но вот имплементация до сих пор оставляет желать лучшего. Уже была статья о том как Laravel просто проверяла зашифрованную айдишку пользователя в кукисах, и как это удалось эксплуатирвать. Проблема была не так в шифровании а в нестрогой проверке результата используя '=='. Дыру починили, но теперь сделали другую. В документации по «remember_me» вы увидите что токен авторизации хранится один для всей учетной записи, то есть если его украсть можно логинится с ним до тех пор пока он валиден. В PHPixie имплементация «remember_me» построена на лучших практиках, когда у каждого девайса для одной учетной записи хранится свой токен, и при этом он еще и обновляется при каждом использовании. Красть такой токен смысла нет как раз ввиду его одноразовости. Если вам интересна полная процедура, то она описана в известно ответе на Stacokverflow. Также настройка авторизации в PHPixie намного гибче, вы можете создавать несколько токенов, использовать сессию или только кукисы и теперь так же социальную авторизацию, все в одном конфиге.
Компоненты
Laravel как и PHPixie состоит из компонентов, и использовать например Eloquent без самого фреймворка очень просто. Но вот другие компоненты, например той же аутентификации завязаны на сам фреймворк гораздо больше, и использовать их с другим фреймворком так легко не получится. PHPixie же изначально задумывалась как независимые компоненты, показательно что на гитхабе каждый компонент PHPixie в отдельном репозитории, в то время как Laravel хранит все в одном проекте и предоставляет read-only репозитории для компонент.
На этом я наверное закончу, а то и так уже слишком длинно получается. На конец только замечу что ни в коем случае не считаю Laravel плохим или даже хуже. Я хотел лишь показать нишу PHPixie как более cutting-edge фреймворка, как и в сравнении с дистрибутивами Линукса в начале статьи. PHPixie это компоненты которые стараются быть на шаг впереди и нацелены больше на опытных разработчиков чем на новичков и скорость разработки.
Чуть ближе познакомится с фреймворком можно с моим вступительным видео в котором я показываю настройку проекта и работу с главными компонентами:
Комментарии (98)
dusterio
05.09.2016 16:56-91) Во владении русским языком Вы уступаете даже Вите АК. Вы могли, хотя бы, авто-корректором каким-то пройтись?
2) «Это число недавно чуть уменьшилось для фреймворка в целом так как вышли 3 новых компонента, к которым пока еще и документации нет, и тесты там только в процессе, но через короткое время вновь будет 100%»
Тесты пишутся перед написанием кода, документация тут не причем.
3) «PHPixie использует ПХП как шаблонизатор, а это означает что все привычные функции например ucwords, substr, trim итд. уже доступны и новый язык учить не придется»
Не совсем уместное сравнение — Вы можете вставлять чистый PHP (не ПХП) код в шаблоны Blade.
4) «Тут у нас вновь разница парадигм. Laravel как более монолитный фреймворк предоставляет возможности байндинга к моделям, позволяя полностью пропустить код контроллера»
Это семантическая бессмыслица. Laravel позволяет вместо имени контроллера передать closure, и это не имеет никакого отношения ни к байндингу, ни к монолитной архитектуре (которой у него нет).
jigpuzzled
05.09.2016 17:35+4Во владении русским языком Вы уступаете даже Вите АК. Вы могли, хотя бы, авто-корректором каким-то пройтись?
Уже по ходу прошелся, щас еще попробую =)
Тесты пишутся перед написанием кода, документация тут не причем.
Не все. Я например сначала делаю функциональные тесты высокого уровня, которые просто запускают все и проверяют результат. Это позволяет мне дальше думать над архитектурой. Когда архитектура уже готова можно углубляться в юнит тесты. Глупо писать юнит тест для класса, который я завтра удалю совсем и разобью на три. Конечно тесты в стиле сохранится ли что-то в БД вообще хороши всегда. Если взглянете на тесты к ОРМ, там отдельно есть функциональные которые пишут и читают с БД и отдельно юнит, которые тестируют сами классы.
Не совсем уместное сравнение — Вы можете вставлять чистый PHP (не ПХП) код в шаблоны Blade.
Это не считается хорошей практикой. И для поддержки блоков и наследования придется использовать блейд все равно
Это семантическая бессмыслица. Laravel позволяет вместо имени контроллера передать closure, и это не имеет никакого отношения ни к байндингу, ни к монолитной архитектуре (которой у него нет).
Нет, если вы все таки прочитаете мануал, там четко пишет что при такой конфигурации роутер сам догадается найти пользователя по айдишке и потом передает его в метод. То о чем вы говорите совсем другое.
oxidmod
05.09.2016 17:37юнит тесты как раз позволят вам продумать правильную архитектуру до того, как вы напишите хоть строчку рабочего кода. как? очень просто, плохое решение будет тяжело тестировать и вы заметите что ваши тесты становятся слишком сложными
jigpuzzled
05.09.2016 17:53+3Может у нас с вами разное понятие юнита. Для меня оно классическое, это один класс. Когда вы пишете например ОРМкку, глупо начинать писать тесты для какого-то маленького класса который например хендлит джойны. Вы сначала напишете один spike-тест, например который получает юзера по айдишке и будуте понемногу рефакторить код пока вам не понравится архитектура. Когда все такие хай-левел тесты пройдут и архитектура вас устроит, вы сможете спустится на уровень ниже и начать тестировать и твикать классы в стиле парсера.
Как раз такими маленькими тестами классов и получается вытянуть покрытие к 100%. А вот эти хай-левел тесты которые проходят через всю систему я держу только для рефакторинга и кавередж ними не считаюoxidmod
05.09.2016 18:04почему же глупо? если у вас каждый маленький кусочек работает правильно, то и состоящий из них механизм будет работать правильно
jigpuzzled
05.09.2016 18:14+2Потому-что на следующий день сутра ты поймешь что надо было сделать совсем по другому. Я ОРМ этот раз наверно 20 переписывал. С первого раза придумать нормальную архитектуру и протестировать можно разве-что CRUD всякий. А когда пишешь темплейтинг тебе свежие идеи лезут одна за другой. И тут важно каждую попробовать и отобрать лучшую, тут и помогают тесты высокого уровня, так как они всегда остаются. А вот если я сегодня начал делать подгрузку связей джойном, и напишу тесты для правильных джойн запросов, а завтра решу что лучше было сделать без джойнов совсем а по айдишкам, то тесты запросов уже тоже можно выбросить, так как этого класса даже не останется. А вот если тест выского уровня и просто проверяет все ли подгрузилось, то ему все равно как я имплементировал.
И вот когда уже я точно знаю какой подход выбрать я напишу юнит тесты.oxidmod
05.09.2016 18:19-5так может стоит сначала подумать, а потом делать?
JonNiBravo
05.09.2016 17:13+6Отличное сравнение, вы сэкономили мне уйму времени.
Вот бы еще SamDark добавил сюда инфу по Yii2
SamDark
05.09.2016 18:46+7Система версий
Yii меняется не быстро. Старое поддерживаем. За новшествами не гонимся сломя голову, старые версии не бросаем потому что есть на них много проектов и мы понимаем, что сейчас выпустить, например, 3.0 — это наплевать на сообщество.
Совместимость если и ломаем, то очень осторожно. Обновляться обычно можно даже ничего не перепроверяя.
Скорость работы
Медленнее PHPixie, быстрее Laravel и Symfony.
Порог входа
Довольно низкий.
Работа с БД
Свой query builder на основе PDO, мощный Active Record. Поддержка noSQL, кросс-базные отношения аля MySQL-Sphinx-Redis.
При сильном желании можно использовать тот же Doctrine.
Сообщество
Прекрасное, дружное, большое. Но не в США. Там слабовато.
Тесты
Больше половины кода покрыто. Не покрыт JavaScript, некоторые виджеты. Тесты постоянно дописываются.
Роутинг
Хорошо настраивается, мощный. Но завязан на контроллеры.
Шаблонизатор
Нативный, twig, smarty на выбор из коробки. Всякие blade расширениями.
HTTP
Свой аналог PSR-7. Попроще. Начинали когда его ещё не было.
Аутентификация
Из коробки, безопасная с HMAC и всем таким.
Компоненты
Чужие использовать — запросто. Из Yii выдирать — пока никак. Но в планах.
Akdmeh
05.09.2016 19:02Как у разработчика, хотелось узнать ваше мнение: почему Yii намного популярнее именно в СНГ?
SamDark
05.09.2016 19:12+9- Потому что русскоязычное сообщество сильное.
- Потому что у него всегда была нормальная документация на русском.
- Потому что я и другие члены сообщества хорошо ездят по конференциям.
- Потому что у нас технари копают сильнее, ценят стабильность и меньше ведутся на маркетинг.
jigpuzzled
05.09.2016 19:08Намного лаконичнее получилось, мне бы так писать =)
Davert
05.09.2016 22:09+2Не надо, у тебя тоже вполне годно получилось. Я впервые услышал реальную критику Laravel (в плане безопасности), вполне себе годный аргумент.
greabock
06.09.2016 01:29Роутинг. Хорошо настраивается, мощный.
Завязывайте… Я чуть чай на монитор не выплюнул =)
Роутинг в yii — это одна из худших частей фреймворка. Он просто никакой.
В остальном — всё верно.
goodnickoff
06.09.2016 12:40+3Тоже хотелось бы увидеть аргументированный ответ. И о какой версии идет речь?
С роутингом в Yii и Yii2 ни разу не сталкивался с вопросами и проблемами, действительно гибкий и мощный.
С чем мне пришлось помучатся во второй версии, так это с механизмом публикации Assets. На мой взгляд перемудрили немного.
Zhuravljov
06.09.2016 14:19+1А что не так с роутингом в Yii2 на ваш взгляд?
Возможность одним правилом описать целый набор однотипных роутов — считаю преимуществом.
Не хотите — конфигурируйте менеджер используя явные правила как в Laravel.
Фича с обработкой роута через колбэк — не аргумент, потому что нужна она чуть меньше чем никогда.
SerafimArts
06.09.2016 14:25+1Фича с обработкой роута через колбэк — не аргумент, потому что нужна она чуть меньше чем никогда.
Фича с группировкой роутов (
$router->group) нужна более чем всегда. А там коллбек. ;)
P.S. Второй аргумент декларации роутера принимает callable, внутри ларки синтаксис
Class@methodявляется расширенным вариантом callable псевдотипа. Всё пролетает сквозь контейнер и отсюда магия с дабл диспатчингом любой возможной функции, хоть коллбека, хоть метода контроллера.SamDark
06.09.2016 15:13+2Группировка в Yii тоже есть:
new GroupUrlRule([ 'prefix' => 'admin', 'rules' => [ 'login' => 'user/login', 'logout' => 'user/logout', 'dashboard' => 'default/dashboard', ], ])
kucheriavij
06.09.2016 09:19Совместимость если и ломаем, то очень осторожно. Обновляться обычно можно даже ничего не перепроверяя.
Нужно было через композер поставить расширение, обновился весь проект, все сломалось, пришлось откатывать. Так что не всегда это работает.
При сильном желании можно использовать тот же Doctrine.
Можно, сейчас так и работаю, но не нравится. Миграции у ларавел больше понравились, на yii мало с миграциями работал
В целом хочу сказать что фреймворк хороший, но мне ларавел больше понравился, видимо потому что лично мне проще было его изучать
ErickSkrauch
06.09.2016 12:17+1В случае с Yii, как и Yii2 всё же лучше хранить версию самого фреймворка жёстко и обновлять по мере необходимости. С Yii2 проблем с тотальной несовместимостью не встречал. В целом же, если в проекте есть тесты, то всё решается.
Zhuravljov
06.09.2016 14:46+1Нужно было через композер поставить расширение, обновился весь проект, все сломалось, пришлось откатывать. Так что не всегда это работает.
Со времён выхода первого стабильного релиза, максимум приходилось рефакторить проект внедряя новые возможности в старый код. А чтобы что-то ломалось — не помню.
С какой и на какую версию вы обновлялись, и что именно сломалось после обновления у вас в проекте?kucheriavij
06.09.2016 15:47Сейчас стоит 2.0.7-dev, обновлялась скорей всего до текущей, какую ошибку выдавало к сожалению уже не помню. Не исключено что это могло быть связано с несовместимостью расширений. Разбираться не было времени, поэтому по времени дешевле оказалось откатиться, и найти способ обойтись без того расширения
Zhuravljov
06.09.2016 16:30+1Да, похоже самая большая беда в нехватке времени, или в нежелании инвестировать его в изучение инструмента, которым пользуешься. Если потратить это самое время и разобраться, как правило, все становится понятно, а инструмент начинает приносить дивиденды в виде стабильно работающих проектов и легко масштабируемого кода.
И, опять таки, не стоит использовать dev-сборки в своих проектах. Для этого нужно держать руку на пульсе: хорошо знать фреймворк, и следить за тем, что в этот момент происходит на гитхабе.
kucheriavij
06.09.2016 16:34Да, похоже самая большая беда в нехватке времени, или в нежелании инвестировать его в изучение инструмента, которым пользуешься. Если потратить это самое время и разобраться, как правило, все становится понятно, а инструмент начинает приносить дивиденды в виде стабильно работающих проектов и легко масштабируемого кода.
Согласен, но лично мне проще учить инструменты на реальных задачах, сколько не пробовал изучать ради изучения — ничего не получалось.
И, опять таки, не стоит использовать dev-сборки в своих проектах. Для этого нужно держать руку на пульсе: хорошо знать фреймворк, и следить за тем, что в этот момент происходит на гитхабе.
Ну тут мне уже не приходилось выбирать, проект достался от другого разработчика, предполагалось что он им будет заниматься, но что-то пошло не так и «волчок» указал на меняZhuravljov
06.09.2016 16:53+1Согласен, но лично мне проще учить инструменты на реальных задачах, сколько не пробовал изучать ради изучения — ничего не получалось.
Разумеется, только на реальных задачах в процессе разработки.
Но вы же и не на хостинге пишете код? И обновляете расширения тоже локально, чтобы убедиться в стабильности, перед тем, как делать это на боевых серверах?
SamDark
06.09.2016 15:18+1Бывает, конечно, что какие-то недокументированные части признаются багом и фиксятся. Смену поведения, даже неофициального, мы описываем в
UPGRADE.md. Вообще вся команда стала за последний год гораздо серьёзней относиться к обратной совместимости.
Миграции, если вы работали с ними на старте 2.0, были другими совсем. Сейчас они намного более приятны:
$this->createTable('news', [ 'id' => $this->primaryKey(), 'title' => $this->string()->notNull(), 'content' => $this->text(), ]);kucheriavij
06.09.2016 15:49+1Я не против миграций, они мне и в прошлом виде вполне симпатизировали. Просто на текущем проекте предыдущий разработчик адаптировал доктриновские аннотации (ему так было удобней), поначалу и мне казалось удобным, но современем начало жутко раздражать
Akdmeh
07.09.2016 13:05+1Да, сейчас все работает, как вы и говорите, да и файл UPGRADE помогает, а если нет — есть система логгирования ошибок.
На моей памяти единственный раз что-то ломалось при обновлении на бете где-то за полгода до релиза (что-то там менялось с csrf-метатегами в layout), но на то она бета — это был домашний проект для обучения, хотя искать ошибку пришлось немало.
symbix
05.09.2016 19:24+1Blade и Twig — это две большие разницы. Twig это классический компилирующий template engine, blade — это макропроцессор (фактически сахарок для php-шаблонов), и в нем php-функции как раз-таки можно использовать.
Я, правда, считаю это недостатком: из шаблона не должно быть вообще возможно получить php-ошибку.Davert
05.09.2016 22:10+1Вот-вот, смысла в blade имхо нет никакого.
restyler
05.09.2016 23:21+1Смысл — в автоэскейпинге переменных. Это важная вещь, которой лично мне только и не хватает в yii2 с pure php шаблонами — безопасность страдает, если разраб торопился.
jigpuzzled
05.09.2016 23:28Ну уже заставить себя написать в стиле
<?=$_($var)?>
вместо просто
<?=$var?>
не так уж трудно. На самом деле если не доверять разработчикам что они вывод нормально сделают, то к базе запросы их пускать писать уж тоже нельзя. Еще сделают Delete запрос без условий и продакшн потрутrestyler
06.09.2016 00:05Если есть возможность сделать написание безопасного кода легче чем опасного — это надо делать) Html::encode иногда писать долго и скучно, особенно сто раз подряд…
v-derckach
06.09.2016 14:32Кстати, относительно недавно (что ли в анонсе последнего обновления Yii, что ли где-то около) кто-то в комментах жаловался, что AR оказался небезопасным и позволил сделать Delete без проверки того, что в результате потрётся всё. И в результате у жалующегося на продакшене всё и потёрлось.
Это так, вспомнилось по ассоциации.Zhuravljov
06.09.2016 14:50Там сам программер накосячил. Проверять свой код нужно, и документацией пользоваться.
v-derckach
06.09.2016 15:00Я ж не спорю. Просто автор упомянул
На самом деле если не доверять разработчикам что они вывод нормально сделают, то к базе запросы их пускать писать уж тоже нельзя. Еще сделают Delete запрос без условий и продакшн потрут
в саркастическом ключе, а мне и вспомнилось, что вполне реально такое бывает, без всякого сарказма.
SerafimArts
06.09.2016 00:36Это не совсем оно. Смысл в том, чтобы взять найтив пых и добавить в него плюшки, нужные для шаблонизатора — экстенд вьюшек, секции, экранирование, как верно выразились и кучу всяких синтаксических плюшек, вроде forelse. Т.е. тупо пых, но тюнингованный под задачу.
Вот и вся цель.
jigpuzzled
06.09.2016 12:20Так имхо тогда в пиксе лучше нет? Все то же, только без дополнительного языка и компиляции, да еще и дебажить легче
SerafimArts
06.09.2016 13:30Нет, отсутсвуют плюшки, предназначенные для шаблнизации (или есть?).
Ну что-то вроде такого. Правда я не понимаю как понимать что тут происходит без чтения доков по блейду, а если бы доки читались бы, то и вопросов "что лучше" не возникало.
@extends('layout.desktop') @section('nav') @forelse($nav as $link => $title) <a href="{{ $link }}">{{ $title }}</a> @empty <span>Главная</span> @endforelse @stop @section('content') <h1>Hell or World?</h1> @stopjigpuzzled
06.09.2016 14:12+1<?php $this->layout('layout.desktop'); ?> <? $this->startBlock('nav'); ?> <? if(isset($nav)): ?> <? foreach($nav as $link => $title): ?> <a href="<?=$link ?>"><?=$_($title) ?></a> <? endforeach; ?> <? else: ?> <span>Главная</span> <? endif; ?> <? $this->endBlock(); ?> <h1>Hell or World?</h1>symbix
06.09.2016 21:25-1Без short tags, которые deprecated уже, страшненько будет. Ну и наверняка это не очень эффективно работает, всякие там вложенные output buffers… Но так-то неплохо, только $_($link), наверное.
Но это еще простой случай. А вот так могете?
http://twig.sensiolabs.org/doc/tags/use.htmlG-M-A-X
06.09.2016 21:40+1Без short tags, которые deprecated уже
Где Вы такое вычитали?
Тут об этому не в курсе:
http://php.net/manual/en/ini.core.php#ini.short-open-tag
Как же мы это переживем?
short_open_tag — няшка :)symbix
06.09.2016 22:25-1Ошибся, да. Пока discouraged, верно. Но обсуждение такое было, точно помню, ну и discouraged часто плавно перетекает в deprecated. Видимо, пока не решились. Но избавление от ини-настроек, влияющих на язык — штука правильная и нужная.
Короткие теги только для нативных php-шаблонов и нужны, если ими не пользоваться — то и не заметишь.jigpuzzled
06.09.2016 22:31С чего это они discouraged? Вы сами придумываете проблемы.
А насчет скорости работы, бенчмарки посмотрите =) И кстати и ларавел и симфони используют output buffering для рендеринга как и пикси. Так что выдумки все этоsymbix
06.09.2016 23:28PHP also allows for short open tag <? (which is discouraged since it is only available if enabled using the short_open_tag php.ini configuration file directive, or if PHP was configured with the --enable-short-tags option).
http://php.net/manual/en/language.basic-syntax.phptags.php
Я себе проблемы не придумываю, у меня их нет — единственное использование тега (в начале файла) проставляется автоматически PHPStorm-ом.jigpuzzled
06.09.2016 23:35+1Вот так прочитайте это предложение еще раз. Он discouraged потому что у кого-то он модет быть выключен. Тоесть если вы делаете плагин для вордпреса который должен на каждом хостинге заработать то конечно же лучше полный тег писать. Но если это ваш сервер то вы сами его настраиваете.
Это то же что сказать что все фичи PHP7 discouraged так как не у всех он есть.symbix
06.09.2016 23:58Проблемой является сама настройка, меняющая поведение языка: неважно, удобная или нет, важно, что настройка. register_globals и magic_quotes, к счастью, выпилили. Потом на очереди отвратительный mbstring overload (очень на это надеюсь), а там и до short_tags дело дойдет. Просто потому, что настроек, меняющих язык, быть не должно. По register_globals тоже плакали, а сейчас вспоминают только как о недоразумении.
jigpuzzled
07.09.2016 00:03register_globals и magic_quotes выпилили суто по причинам безопасности а не потому что они меняют язык. При чем здесь короткий тег?
В любом случае, вы всегда можете просто использовать длинный, в чем проблема собственно? Кстати тег "<?=$bla?>" теперь доступен всегда вне зависимости от ini настроек.
Так что даже если использовать доинный тег то тол ко в ифах и форичах придетсяsymbix
07.09.2016 00:06magic_quotes выпилили, потому что он портит входные данные и вообще глупость несусветная.
SerafimArts
07.09.2016 00:14Короткий тег конфликтует с xml и некоторыми другими шняжками. Теги
<?=и<?phpне имеют такой привычки. Отсюда отключение по-умолчанию и рекомендация отключения оных в самых популярных стандартах, взять хотя бы PSR.
Лично я воспринимаю современный код без PSR как код, написанный ньюфагом, которому не стоит доверять. Естественно это чисто психологическое и вполне возможны иные ситуации, но почти уверен, что у большинства тех, кто читал и использует код популярных open-source решений (Zend, Laravel, Symfony, etc) примерно такие же ассоциации.
jigpuzzled
07.09.2016 00:20Ну во первых как я уже писал раза 3 можно просто писать <?= и <?php. Но на самом деле распространять PSR на файлы темплейта как то уж очень притянутотак как они писаны для кода а не для шаблонов. Это то же самое что с endif, в коде класса он совсем ни к чему и руки за такое ломать, но для шаблона самое оно.
SerafimArts
07.09.2016 00:23Предлагаю показать тогда как должен выглядеть шаблон для sitemap.xml, ну примерно ;)
jigpuzzled
07.09.2016 00:30Кто генерит XML темплейтингом? гораздо проще ведь использовать 300 библиотек для работы с ним. Зачем вам в XML лейауты и блоки??
SerafimArts
07.09.2016 00:40А почему бы тогда html так не генерировать? Он (html), как бы совместим с этими 300 xml библиотеками. И шаблон обязан быть с лайаутом и блоками?
Я просто попросил привести пример sitemap.xml, т.к. разделение логики и представления (где сайтмап — это очевидно шаблон представления) — это хорошо. Или я ошибаюсь?
jigpuzzled
07.09.2016 00:46Так в хтмле есть лейауты и блоки. ХТМЛ это язык разметки, а XML это формат данных. Но все же длинный тег нормально будет работать в XML:
<?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <?php foreach($urls as $url): ?> <url> <loc><?=$_($url)?></loc> </url> <? endforeach; ?> </urlset>SerafimArts
07.09.2016 00:59Получилось вполне читаемо и красиво. А теперь предлагаю запустить приведённый код и наслаждаться фатал эррорами.
После этого можно ещё раз пересмотреть моё предложение по поводу того, что не стоит себе самому палки в колёса ставить.
Мне просто хотелось свою мысль на практике как-нибудь донести, раз объективная аргументация почему это плохо (против вашей "а почему бы и нет" и "это же короче на 3 символа и красивее, несмотря на то, что эти три символа пишутся раз в неделю") не прокатила. =)
P.S. Под html подразумевалось семейство языков, определяемых доктайпом, при этом xhtml полностью совместим (как прямо, так и обратно) с xml.
jigpuzzled
07.09.2016 01:10<?php $urls = array('bla'); ?> <?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <?php foreach($urls as $url): ?> <url> <loc><?=$url?></loc> </url> <?php endforeach; ?> </urlset>
При отключенных коротких тегах запустилось без проблем (Вы же и так писали что их и надо отключать).
Ну а если при включенных надо тоже чтобы работало, то вот:
<?='<?xml version="1.0" encoding="UTF-8"?>'?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <? foreach($urls as $url): ?> <url> <loc><?=$url?></loc> </url> <? endforeach; ?> </urlset>
Кстати Блейдовский и Твиговский темлейты скомпилируються в точно такие-же PHP файлы
G-M-A-X
08.09.2016 09:59Кстати, использовать
<?xml version="1.0" encoding="UTF-8"?>
в шаблонах PHP тоже не стоит. :) А вдруг у нас включены короткие теги :)
И длиннее минимум на 4 символа, так как еще нужен пробел.
symbix
07.09.2016 01:03Будет нормально работать при отключенных коротких тегах.
SerafimArts
07.09.2016 01:08Не будет, т.к. см.предпоследнюю строчку приведённого кода. ;)
jigpuzzled
07.09.2016 01:11Запускал обе версии, работает. Хватит чушь толкать.
SerafimArts
07.09.2016 10:45Хм, я куда-то не туда посмотрел, но мне казалось там был только один исходник. Прошу прощения — не выспался, не заметил.
symbix
06.09.2016 05:04Для новых проектов — никакого, твиг лучше (чем армяне).
А вот легаси портировать проще на blade.
Radik_Wind
06.09.2016 01:45+3Внесу свои пять копеек и скорее всего совершу суицид. Сразу хочу отметить, что ни чего не имею против какого либо фремворка и это хорошо, что их много конкуренция полезная штука, да и это всего лишь инструмент. Не так давно выбирал фреймворк для enterprise смотрел много фреймворков в том числе и PHPixie, ниже не большое заключение:
CodeIgniter — слишком прост, много писать кода на каждый чих и на то время не понятная судьба с развитием и поддержкой
Kohana — чуть чуть дальше ушел от CodeIgniter но проблемы все те же.
PHPixie — нет документации в коде, нет документации по компонентам, маленькое сообщество и на тот момент очень мало функционала, возможно это результат недостатка документации.
Yii — подкупает всех простотой и заявленной высокой производительностью, но на самом деле при его использовании enterprise у всех разработчиков только боль, страдания и кровь из глаз от обилия написанного кода и html внутри PHP классов.
Laravel — не стабильность интерфейсов, переписывать проект с каждым релизом не самая лучшая идея.
Symfony — высоковатый порог вхождения, но это решается отличной документацией и большим сообществом. Большое количество поддерживаемых дополнительных компонентов. Собственно его и выбрал и используем уже достаточно давно и довольны как слоны.
Меня всегда удивляет, что большинство разработчиков фремворков оперируют скоростью работы, но вот скорость разработки ни кто не учитывает и как показывает практика серверов доставить всегда дешевле, чем оплачивать кучу часов разработки проекта, особенно кода важно запуститься «вчера». Так же по личному опыту могу сказать, что 98% случаев медленной работы приложений связанны с не продуманной архитектурой, не умением готовить те инструменты которые используются и ну куда же без этого — кривыми руками разработчиков.SerafimArts
06.09.2016 03:48+1Всё верно описано. Но потерялся Zend, который давеча релизнулся в третью версию и стал почти удобоваримым.
P.S. Из перечисленных я бы выбирал между последним и предпоследним:
- Лара на порядок удобнее симфони, но и постоянно апается (это и плюс и минус), последнее время они перестали сильно ломать обратную совместимость, так что с 5.1 можно запросто перелезть на 5.3.
- С точки зрения симфони — очень надёжная штука, код, написанный под 2.4 вполне можно завести (с пинками конечно же, но не такими как в ларке) под 2.8. В этом плане (совместимости) проделана огромная работа.
neuotq
06.09.2016 08:46На самом деле в Symfony совсем не высокий порог вхождения, а уж если по изучения Laravel (только именно изучения, в том числе почему и как устроен) то вообще расплюнуть.
Конечно Laravel подкупает своими фишками, на нем просто клево что-то делать. А так наверное что-то большое близкое к корпоративным приложениям все же Симфони, средние, стартаперские и большие любительские проекты можно смело на Laravel делать.
А еще мне очень нравится Slim Framework(в связке с Eloquent), быстро, клево, без лишних правил давящих сверху(ну кроме правил кодинга, хотя опять таки частично ).
restyler
06.09.2016 09:39+4Я вот не понимаю чего там такого enterprise в симфони, честно. Десяток файлов конфигурации чтобы связать ACL и userbundle с JmsSerializer и умереть? Программирование через аннотации, которые намертво кешируются и быстро подебажить — целая история? Раздувание бюджетов и количества строчек кода в два раза? ORM и DQL, на котором мало-мальски сложный SQL отчет (с кастомными mysql/pg функциями, например) запаришься писать? или FormBuilder который неприятно использовать в реальных формах, зато приятно тестировать, если конечно кто-то из разработчиков до тестирования доберется из-за дедлайнов? :) по факту получается что основная ценность — это Symfony Components, DI и живое англоязычное community. На мой взгляд любой, даже нормальный, фреймворк (sf2/laravel/yii2, про CI и Kohana не будем, это устарело) это боль, но основная боль идет от некомпетентности разработчиков. Некоторые упарываются по модульности и DI, думая что оно сильно им облегчит жизнь в enterprise, и поэтому ругают «монолитный» yii, например — но в реальном enteprise часто модульность не решает всех проблем с архитектурой и сложность все так же накапливается — и оказывается, например, что проблемы проще решить правильным дизайном более высокого уровня — читай, разделением систем. И три системы на yii, простые как сапог внутри и вполне монолитные, справляются с задачей разделения сложности намного лучше чем один монстр на sf2 с тысячей бандлов.
dizzy7
06.09.2016 11:48Чего там enterprise я тоже не знаю. Модульность зачастую не нужна, факт, но возможность отключить всё лишнее — иногда полезно. В остальном она очень и очень гибкая. Доработать роутинг — пожалуйста, пишешь свой или декорируешь встроенный. Обработчики сессий, кэширование, почти всё можно заменить своим. Кода получается не так много. ORM для сложных sql запросов и не предназначен, он облегчает рутинные действия. Нужен мозголомный запрос — sql всегда лучше, результат по желанию можно привязать к entity и получить сразу объекты. Формы там шикарные — особенно когда нужна вложенность на несколько уровней и коллекции.
От enterprise там пожалуй обратная совместимость. Крупный проект без проблем переезжал c 2.3 на 2.7 и 2.8. Всё работает.
G-M-A-X
06.09.2016 13:11+1>На мой взгляд любой, даже нормальный, фреймворк — это боль.
+100500.
А можете более подробно описать, с какими проблемами Вы столкнулись на фреймворках?
Pinsky
06.09.2016 15:20Не могу с Вами согласиться.
Как минимум, можно использовать минималистичные фреймворки, которые не будут реализовывать тот функционал, что Вам не нужен.
В любом случае, вопросы роутинга, шаблонизации и работы с БД всегда открыты и зачастую достаточно стандартны.
SamDark
06.09.2016 15:23+1Yii — подкупает всех простотой и заявленной высокой производительностью, но на самом деле при его использовании enterprise у всех разработчиков только боль, страдания и кровь из глаз от обилия написанного кода и html внутри PHP классов.
У нас как-то нет боли в том же Stay.com от обилия кода… что-то мы делаем не так. И HTML внутри PHP классов у нас тоже нет.
symbix
06.09.2016 21:31+1Дык боль обычно не от фреймворка, а от бездумного написания кода по примитивным примерам из документации без понимания — с таким подходом и с Laravel, и с Symfony будет боль. Это явно не ваш случай ;)
annenkov
07.09.2016 10:09+1Yii — подкупает всех простотой и заявленной высокой производительностью, но на самом деле при его использовании enterprise у всех разработчиков только боль, страдания и кровь из глаз от обилия написанного кода и html внутри PHP классов.
НЕ любите кошек? Да просто не умеете их готовить!
Если изначально писать проект на YII как описано в элементарных примерах, не смотря на то, что знаешь чтобы будет нечто большое и сложное — да будет много проблем, если все таки немного сразу подумать над архитектурой и следить по ходу дела — можно и на YII писать большое и сложное.
neuotq
06.09.2016 08:51+1PHPixie наверное клевый, много раз о нем слышал, но так в деле не пробовал. Нов се же одним из ключевых плюсов в сторону Laravel будет то что он на порядок(а в гугле так на несколько порядков) популярнее. Это существенный перекос, который для меня один из ключевых. PHPixie уже достаточно существует чтобы стать полноценной звездой, но пока не стал, значит не повезло? Или есть другие причины?
restyler
06.09.2016 11:05Laravel это приятный фреймворк с англоязычным ярким (тейлора одни ненавидят, а другие любят за его деспотичность) хедлайнером, понимающим толк в маркетинге и красивом дизайне. Это большое дело, «русскоязычным» фреймворкам за Laravel не угнаться в ближайшее время, будь ты хоть в два раза лучше :) молодежь, навязанные западные ценности, вот это все… *закуриваю трубку сидя в своем кресле-качалке*
neuotq
06.09.2016 13:59Ну я больше не из-за западных ценностей(вернее вовсе не из-за них), чисто из практических соображений. Вот тот же nginx взлетел, считается нашим продуктом, удобный, авторитетный, проверенный.
А фреймворк, или что другое, не должен быть русскоязычным или американским или еще каким, он должен быть удобный, популярным(а значит извините, но придется развивать прежде всего английскую версию) и интересным.
Ну и повторюсь, PHPixie с виду интересный, просто нет времени да и желания пока что его использовать, впрочем если вы СИЛЬНО советуете, то задумаюсь, но статья меня слабо убедила.
rixaman
06.09.2016 11:15-1Технически PHPixie лучше сравнивать с Lumen.
Laravel же это немного другая весовая категория.jigpuzzled
06.09.2016 11:55+2Почему? Пикся давно уже не микрофреймворк, в ней куча всего из коробки
SerafimArts
07.09.2016 00:17+1Тогда предлагаю начать думать хотя бы над докблок декларациями ;)
jigpuzzled
07.09.2016 00:21https://github.com/PHPixie/Framework/blob/master/src/PHPixie/Framework/Components.php
уже есть, не везде, но в самых востребованых местах точно
raidhon
06.09.2016 15:51+2PHPixie один из моих любимых фреймворков, несколько сайтов на нем построил.
Только на второй версии, никак руки не дойдут перейти на третью.
К нему бы ещё модуль Websocket на основе Ratchet (раз ReactPHP можно прикрутить почему бы и нет ) вообще была бы конфетка.
sayber
13.09.2016 14:25Не вижу смыслов в данных статьях.
Ну сравним мы скорость, удобство и т.д.
Но это даст нам только картину для старта а полной версии конечного продукта нет.
Что взять для крупного проекта, что для среднего а что для финансовой архитектуры и т.д.
Как по мне, любой фреймворк выбирается прежде всего из-за своей архитектуры и возможностей. Т.е. сначала надо подумать что у вас будет на перспективе.
Несколько раз встречал проекты, где люди выбирали тот или иной фреймворк основываясь на базовых данных.
Спустя год, упирались в какие то стены, т.к. изначально не продумали.
P.S.
Я вообще люблю создавать приложение из кирпичиков, которые как можно меньше друг от друга зависят.
А так как я фуллстак, то мне удобнее работать с шаблонизаторами типа twig
G-M-A-X
14.09.2016 10:26Несколько раз встречал проекты, где люди выбирали тот или иной фреймворк основываясь на базовых данных.
Спустя год, упирались в какие то стены, т.к. изначально не продумали.
Ну так как бы фреймворк и предназначен, чтобы быстро из стандартных (не самых оптимальных под проект) кирпичиков сложить домик.
Что-то серьезное пишется на самописи (не, конечно можно и бороться с ограничениями фреймворка, докупать сервера).Pinsky
14.09.2016 15:20RLY?
А считается ли самописью фреймворк созданный в недрах крупной компании(или не крупной) для решения своих задач?
А считается ли самописью доработанный до нужд проекта фреймворк?
В какой момент самопись становится фреймворком, а фреймворк самописью?G-M-A-X
14.09.2016 21:53Кстати, правильное замечание.
Но сторонники мейнстримовых публичных фреймворков считают, что стоит использовать только их и никакой альтернативы не видят.
Также они думают, что невозможно изпользование самописного кода, что для реализации каждой следующей задачи будет писаться все с нуля.
Также они упускают, что эти фреймворки тоже появились, как чья-то самопись.
П.С.
Говоря фреймворк, я подразумеваю публичный мейнстримовый фреймворк.
Malezha
Собственно, почему не взять лучшее из обоих фреймворков? Laravel дает простой и удобный скелет для приложения и у него действительно не лучший AR, почему не сделать бридж? Тоже самое с компонентом Auth — он легко расширяем. В итоге оба сообщества получат плюсы: качественные и более функциональные компоненты для ларавел и приток новых людей в сообщество феи.
С ReactPHP все очень сложно: текущая «стабильная» ветка не умеет в загрузку файлов, а в разрабатываемой планируется реализовать хранение в потоке (памяти). Учитывая, что сейчас все реализации загрузки так или иначе используют работу именно с файловой системой (проксируя move_uploaded_file, is_uploaded_file и т.п.) ждет секс для обеспечения совместимости, либо блокирующий процесс сохранения файла на диск.
iGusev
Blumfontein
Загрузку файлов в отдельный микросервис со своим API и блэкджеком желательно убирать.