Комментарии 98
С ReactPHP все очень сложно: текущая «стабильная» ветка не умеет в загрузку файлов, а в разрабатываемой планируется реализовать хранение в потоке (памяти). Учитывая, что сейчас все реализации загрузки так или иначе используют работу именно с файловой системой (проксируя move_uploaded_file, is_uploaded_file и т.п.) ждет секс для обеспечения совместимости, либо блокирующий процесс сохранения файла на диск.
2) «Это число недавно чуть уменьшилось для фреймворка в целом так как вышли 3 новых компонента, к которым пока еще и документации нет, и тесты там только в процессе, но через короткое время вновь будет 100%»
Тесты пишутся перед написанием кода, документация тут не причем.
3) «PHPixie использует ПХП как шаблонизатор, а это означает что все привычные функции например ucwords, substr, trim итд. уже доступны и новый язык учить не придется»
Не совсем уместное сравнение — Вы можете вставлять чистый PHP (не ПХП) код в шаблоны Blade.
4) «Тут у нас вновь разница парадигм. Laravel как более монолитный фреймворк предоставляет возможности байндинга к моделям, позволяя полностью пропустить код контроллера»
Это семантическая бессмыслица. Laravel позволяет вместо имени контроллера передать closure, и это не имеет никакого отношения ни к байндингу, ни к монолитной архитектуре (которой у него нет).
Во владении русским языком Вы уступаете даже Вите АК. Вы могли, хотя бы, авто-корректором каким-то пройтись?
Уже по ходу прошелся, щас еще попробую =)
Тесты пишутся перед написанием кода, документация тут не причем.
Не все. Я например сначала делаю функциональные тесты высокого уровня, которые просто запускают все и проверяют результат. Это позволяет мне дальше думать над архитектурой. Когда архитектура уже готова можно углубляться в юнит тесты. Глупо писать юнит тест для класса, который я завтра удалю совсем и разобью на три. Конечно тесты в стиле сохранится ли что-то в БД вообще хороши всегда. Если взглянете на тесты к ОРМ, там отдельно есть функциональные которые пишут и читают с БД и отдельно юнит, которые тестируют сами классы.
Не совсем уместное сравнение — Вы можете вставлять чистый PHP (не ПХП) код в шаблоны Blade.
Это не считается хорошей практикой. И для поддержки блоков и наследования придется использовать блейд все равно
Это семантическая бессмыслица. Laravel позволяет вместо имени контроллера передать closure, и это не имеет никакого отношения ни к байндингу, ни к монолитной архитектуре (которой у него нет).
Нет, если вы все таки прочитаете мануал, там четко пишет что при такой конфигурации роутер сам догадается найти пользователя по айдишке и потом передает его в метод. То о чем вы говорите совсем другое.
Как раз такими маленькими тестами классов и получается вытянуть покрытие к 100%. А вот эти хай-левел тесты которые проходят через всю систему я держу только для рефакторинга и кавередж ними не считаю
И вот когда уже я точно знаю какой подход выбрать я напишу юнит тесты.
Вот бы еще SamDark добавил сюда инфу по Yii2
Система версий
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 выдирать — пока никак. Но в планах.
Роутинг. Хорошо настраивается, мощный.
Завязывайте… Я чуть чай на монитор не выплюнул =)
Роутинг в yii — это одна из худших частей фреймворка. Он просто никакой.
В остальном — всё верно.
Тоже хотелось бы увидеть аргументированный ответ. И о какой версии идет речь?
С роутингом в Yii и Yii2 ни разу не сталкивался с вопросами и проблемами, действительно гибкий и мощный.
С чем мне пришлось помучатся во второй версии, так это с механизмом публикации Assets. На мой взгляд перемудрили немного.
А что не так с роутингом в Yii2 на ваш взгляд?
Возможность одним правилом описать целый набор однотипных роутов — считаю преимуществом.
Не хотите — конфигурируйте менеджер используя явные правила как в Laravel.
Фича с обработкой роута через колбэк — не аргумент, потому что нужна она чуть меньше чем никогда.
Фича с обработкой роута через колбэк — не аргумент, потому что нужна она чуть меньше чем никогда.
Фича с группировкой роутов ($router->group
) нужна более чем всегда. А там коллбек. ;)
P.S. Второй аргумент декларации роутера принимает callable, внутри ларки синтаксис Class@method
является расширенным вариантом callable псевдотипа. Всё пролетает сквозь контейнер и отсюда магия с дабл диспатчингом любой возможной функции, хоть коллбека, хоть метода контроллера.
Совместимость если и ломаем, то очень осторожно. Обновляться обычно можно даже ничего не перепроверяя.
Нужно было через композер поставить расширение, обновился весь проект, все сломалось, пришлось откатывать. Так что не всегда это работает.
При сильном желании можно использовать тот же Doctrine.
Можно, сейчас так и работаю, но не нравится. Миграции у ларавел больше понравились, на yii мало с миграциями работал
В целом хочу сказать что фреймворк хороший, но мне ларавел больше понравился, видимо потому что лично мне проще было его изучать
Нужно было через композер поставить расширение, обновился весь проект, все сломалось, пришлось откатывать. Так что не всегда это работает.
Со времён выхода первого стабильного релиза, максимум приходилось рефакторить проект внедряя новые возможности в старый код. А чтобы что-то ломалось — не помню.
С какой и на какую версию вы обновлялись, и что именно сломалось после обновления у вас в проекте?
Да, похоже самая большая беда в нехватке времени, или в нежелании инвестировать его в изучение инструмента, которым пользуешься. Если потратить это самое время и разобраться, как правило, все становится понятно, а инструмент начинает приносить дивиденды в виде стабильно работающих проектов и легко масштабируемого кода.
И, опять таки, не стоит использовать dev-сборки в своих проектах. Для этого нужно держать руку на пульсе: хорошо знать фреймворк, и следить за тем, что в этот момент происходит на гитхабе.
Да, похоже самая большая беда в нехватке времени, или в нежелании инвестировать его в изучение инструмента, которым пользуешься. Если потратить это самое время и разобраться, как правило, все становится понятно, а инструмент начинает приносить дивиденды в виде стабильно работающих проектов и легко масштабируемого кода.
Согласен, но лично мне проще учить инструменты на реальных задачах, сколько не пробовал изучать ради изучения — ничего не получалось.
И, опять таки, не стоит использовать dev-сборки в своих проектах. Для этого нужно держать руку на пульсе: хорошо знать фреймворк, и следить за тем, что в этот момент происходит на гитхабе.
Ну тут мне уже не приходилось выбирать, проект достался от другого разработчика, предполагалось что он им будет заниматься, но что-то пошло не так и «волчок» указал на меня
Согласен, но лично мне проще учить инструменты на реальных задачах, сколько не пробовал изучать ради изучения — ничего не получалось.
Разумеется, только на реальных задачах в процессе разработки.
Но вы же и не на хостинге пишете код? И обновляете расширения тоже локально, чтобы убедиться в стабильности, перед тем, как делать это на боевых серверах?
Бывает, конечно, что какие-то недокументированные части признаются багом и фиксятся. Смену поведения, даже неофициального, мы описываем в UPGRADE.md
. Вообще вся команда стала за последний год гораздо серьёзней относиться к обратной совместимости.
Миграции, если вы работали с ними на старте 2.0, были другими совсем. Сейчас они намного более приятны:
$this->createTable('news', [
'id' => $this->primaryKey(),
'title' => $this->string()->notNull(),
'content' => $this->text(),
]);
На моей памяти единственный раз что-то ломалось при обновлении на бете где-то за полгода до релиза (что-то там менялось с csrf-метатегами в layout), но на то она бета — это был домашний проект для обучения, хотя искать ошибку пришлось немало.
Я, правда, считаю это недостатком: из шаблона не должно быть вообще возможно получить php-ошибку.
Вот-вот, смысла в blade имхо нет никакого.
<?=$_($var)?>
вместо просто
<?=$var?>
не так уж трудно. На самом деле если не доверять разработчикам что они вывод нормально сделают, то к базе запросы их пускать писать уж тоже нельзя. Еще сделают Delete запрос без условий и продакшн потрут
Это так, вспомнилось по ассоциации.
Там сам программер накосячил. Проверять свой код нужно, и документацией пользоваться.
На самом деле если не доверять разработчикам что они вывод нормально сделают, то к базе запросы их пускать писать уж тоже нельзя. Еще сделают Delete запрос без условий и продакшн потрут
в саркастическом ключе, а мне и вспомнилось, что вполне реально такое бывает, без всякого сарказма.
Да, было дело. Но это вина разработчика.
Это не совсем оно. Смысл в том, чтобы взять найтив пых и добавить в него плюшки, нужные для шаблонизатора — экстенд вьюшек, секции, экранирование, как верно выразились и кучу всяких синтаксических плюшек, вроде forelse. Т.е. тупо пых, но тюнингованный под задачу.
Вот и вся цель.
Нет, отсутсвуют плюшки, предназначенные для шаблнизации (или есть?).
Ну что-то вроде такого. Правда я не понимаю как понимать что тут происходит без чтения доков по блейду, а если бы доки читались бы, то и вопросов "что лучше" не возникало.
@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>
@stop
<?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>
Но это еще простой случай. А вот так могете?
http://twig.sensiolabs.org/doc/tags/use.html
Без short tags, которые deprecated уже
Где Вы такое вычитали?
Тут об этому не в курсе:
http://php.net/manual/en/ini.core.php#ini.short-open-tag
Как же мы это переживем?
short_open_tag — няшка :)
Короткие теги только для нативных php-шаблонов и нужны, если ими не пользоваться — то и не заметишь.
А насчет скорости работы, бенчмарки посмотрите =) И кстати и ларавел и симфони используют output buffering для рендеринга как и пикси. Так что выдумки все это
http://php.net/manual/en/language.basic-syntax.phptags.php
Я себе проблемы не придумываю, у меня их нет — единственное использование тега (в начале файла) проставляется автоматически PHPStorm-ом.
Это то же что сказать что все фичи PHP7 discouraged так как не у всех он есть.
В любом случае, вы всегда можете просто использовать длинный, в чем проблема собственно? Кстати тег "<?=$bla?>" теперь доступен всегда вне зависимости от ini настроек.
Так что даже если использовать доинный тег то тол ко в ифах и форичах придется
Короткий тег конфликтует с xml и некоторыми другими шняжками. Теги <?=
и <?php
не имеют такой привычки. Отсюда отключение по-умолчанию и рекомендация отключения оных в самых популярных стандартах, взять хотя бы PSR.
Лично я воспринимаю современный код без PSR как код, написанный ньюфагом, которому не стоит доверять. Естественно это чисто психологическое и вполне возможны иные ситуации, но почти уверен, что у большинства тех, кто читал и использует код популярных open-source решений (Zend, Laravel, Symfony, etc) примерно такие же ассоциации.
Предлагаю показать тогда как должен выглядеть шаблон для sitemap.xml, ну примерно ;)
А почему бы тогда html так не генерировать? Он (html), как бы совместим с этими 300 xml библиотеками. И шаблон обязан быть с лайаутом и блоками?
Я просто попросил привести пример sitemap.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>
Получилось вполне читаемо и красиво. А теперь предлагаю запустить приведённый код и наслаждаться фатал эррорами.
После этого можно ещё раз пересмотреть моё предложение по поводу того, что не стоит себе самому палки в колёса ставить.
Мне просто хотелось свою мысль на практике как-нибудь донести, раз объективная аргументация почему это плохо (против вашей "а почему бы и нет" и "это же короче на 3 символа и красивее, несмотря на то, что эти три символа пишутся раз в неделю") не прокатила. =)
P.S. Под html подразумевалось семейство языков, определяемых доктайпом, при этом xhtml полностью совместим (как прямо, так и обратно) с xml.
<?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 файлы
<?xml version="1.0" encoding="UTF-8"?>
в шаблонах PHP тоже не стоит. :) А вдруг у нас включены короткие теги :)
И длиннее минимум на 4 символа, так как еще нужен пробел.
А вот легаси портировать проще на blade.
CodeIgniter — слишком прост, много писать кода на каждый чих и на то время не понятная судьба с развитием и поддержкой
Kohana — чуть чуть дальше ушел от CodeIgniter но проблемы все те же.
PHPixie — нет документации в коде, нет документации по компонентам, маленькое сообщество и на тот момент очень мало функционала, возможно это результат недостатка документации.
Yii — подкупает всех простотой и заявленной высокой производительностью, но на самом деле при его использовании enterprise у всех разработчиков только боль, страдания и кровь из глаз от обилия написанного кода и html внутри PHP классов.
Laravel — не стабильность интерфейсов, переписывать проект с каждым релизом не самая лучшая идея.
Symfony — высоковатый порог вхождения, но это решается отличной документацией и большим сообществом. Большое количество поддерживаемых дополнительных компонентов. Собственно его и выбрал и используем уже достаточно давно и довольны как слоны.
Меня всегда удивляет, что большинство разработчиков фремворков оперируют скоростью работы, но вот скорость разработки ни кто не учитывает и как показывает практика серверов доставить всегда дешевле, чем оплачивать кучу часов разработки проекта, особенно кода важно запуститься «вчера». Так же по личному опыту могу сказать, что 98% случаев медленной работы приложений связанны с не продуманной архитектурой, не умением готовить те инструменты которые используются и ну куда же без этого — кривыми руками разработчиков.
Всё верно описано. Но потерялся Zend, который давеча релизнулся в третью версию и стал почти удобоваримым.
P.S. Из перечисленных я бы выбирал между последним и предпоследним:
- Лара на порядок удобнее симфони, но и постоянно апается (это и плюс и минус), последнее время они перестали сильно ломать обратную совместимость, так что с 5.1 можно запросто перелезть на 5.3.
- С точки зрения симфони — очень надёжная штука, код, написанный под 2.4 вполне можно завести (с пинками конечно же, но не такими как в ларке) под 2.8. В этом плане (совместимости) проделана огромная работа.
Конечно Laravel подкупает своими фишками, на нем просто клево что-то делать. А так наверное что-то большое близкое к корпоративным приложениям все же Симфони, средние, стартаперские и большие любительские проекты можно смело на Laravel делать.
А еще мне очень нравится Slim Framework(в связке с Eloquent), быстро, клево, без лишних правил давящих сверху(ну кроме правил кодинга, хотя опять таки частично ).
От enterprise там пожалуй обратная совместимость. Крупный проект без проблем переезжал c 2.3 на 2.7 и 2.8. Всё работает.
+100500.
А можете более подробно описать, с какими проблемами Вы столкнулись на фреймворках?
Yii — подкупает всех простотой и заявленной высокой производительностью, но на самом деле при его использовании enterprise у всех разработчиков только боль, страдания и кровь из глаз от обилия написанного кода и html внутри PHP классов.
У нас как-то нет боли в том же Stay.com от обилия кода… что-то мы делаем не так. И HTML внутри PHP классов у нас тоже нет.
Yii — подкупает всех простотой и заявленной высокой производительностью, но на самом деле при его использовании enterprise у всех разработчиков только боль, страдания и кровь из глаз от обилия написанного кода и html внутри PHP классов.
НЕ любите кошек? Да просто не умеете их готовить!
Если изначально писать проект на YII как описано в элементарных примерах, не смотря на то, что знаешь чтобы будет нечто большое и сложное — да будет много проблем, если все таки немного сразу подумать над архитектурой и следить по ходу дела — можно и на YII писать большое и сложное.
А фреймворк, или что другое, не должен быть русскоязычным или американским или еще каким, он должен быть удобный, популярным(а значит извините, но придется развивать прежде всего английскую версию) и интересным.
Ну и повторюсь, PHPixie с виду интересный, просто нет времени да и желания пока что его использовать, впрочем если вы СИЛЬНО советуете, то задумаюсь, но статья меня слабо убедила.
Laravel же это немного другая весовая категория.
Ну сравним мы скорость, удобство и т.д.
Но это даст нам только картину для старта а полной версии конечного продукта нет.
Что взять для крупного проекта, что для среднего а что для финансовой архитектуры и т.д.
Как по мне, любой фреймворк выбирается прежде всего из-за своей архитектуры и возможностей. Т.е. сначала надо подумать что у вас будет на перспективе.
Несколько раз встречал проекты, где люди выбирали тот или иной фреймворк основываясь на базовых данных.
Спустя год, упирались в какие то стены, т.к. изначально не продумали.
P.S.
Я вообще люблю создавать приложение из кирпичиков, которые как можно меньше друг от друга зависят.
А так как я фуллстак, то мне удобнее работать с шаблонизаторами типа twig
Несколько раз встречал проекты, где люди выбирали тот или иной фреймворк основываясь на базовых данных.
Спустя год, упирались в какие то стены, т.к. изначально не продумали.
Ну так как бы фреймворк и предназначен, чтобы быстро из стандартных (не самых оптимальных под проект) кирпичиков сложить домик.
Что-то серьезное пишется на самописи (не, конечно можно и бороться с ограничениями фреймворка, докупать сервера).
А считается ли самописью фреймворк созданный в недрах крупной компании(или не крупной) для решения своих задач?
А считается ли самописью доработанный до нужд проекта фреймворк?
В какой момент самопись становится фреймворком, а фреймворк самописью?
Но сторонники мейнстримовых публичных фреймворков считают, что стоит использовать только их и никакой альтернативы не видят.
Также они думают, что невозможно изпользование самописного кода, что для реализации каждой следующей задачи будет писаться все с нуля.
Также они упускают, что эти фреймворки тоже появились, как чья-то самопись.
П.С.
Говоря фреймворк, я подразумеваю публичный мейнстримовый фреймворк.
PHPixie против Laravel