Заинтересовал меня намедни такой вопрос: какой PHP фреймворк вы выберете для создания среднего или крупного проекта (корпоративный портал, магазин и т.п.) в 2016 году?
Уточню, что это не холивар, какой фреймворк лучше, речь идет именно о вашем личном выборе, причины которого, могут быть любыми.
И да, Bitrix это не совсем фреймворк, но тем не менее.
UPD: Подразумевается, что стадия сравнения, споров и выбора уже прошла, и тимлид или команда или бизнес решили: по факту будем писать на этом. Хочется узнать фактический мейнстрим на 2016 год, то есть, что будет на самом деле, а ни этот хороший, а тот плохой.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (249)
UncleJey
01.04.2016 14:42-2А где же CodeIgniter?
bardex
01.04.2016 14:44Я специально выбрал фреймворки, которые сегодня, чаще других упоминаются на habrahabr.ru или hh.ru. В голосовании есть вариант "Другой" в комментариях можно написать какой именно.
maximw
01.04.2016 21:45Почему тогда Symfony 3 нет?увидел ниже, что об этом уже спросили несколько раз
NeoCode
01.04.2016 15:16+2Уважаемые профессионалы, а можете развернуто сравнить Laravel 5 vs. Yii 2 vs. Symfony 2? (для личных проектов, которые могут быть как маленькими так и достаточно большими)
SamDark
01.04.2016 17:40Чтобы развёрнуто сравнивать, надо знать, что у вас за проект и какие части фреймворков для него особенно важны.
Big_Shark
01.04.2016 18:09+4А вам что больше нравится, bmw, mercedes или audi? Тут все зависит от предпочтений, и знаний, не более, не менее.
sparksounds
01.04.2016 15:28Silex
SerDIDG
02.04.2016 01:58+2Который превращается в ходе разработки в тот же symphony 2 но на костылях? ) Спрашиваю ради интереса, потому что когда делал на нём проект, пришлось чуть ли не половину компонентов symphony перетащить, ещё и настроить верно, чтобы не конфликтовали с друг-другом. Были проблемы с последовательностью инициализации последних.
Fesor
02.04.2016 02:20С выходом Symfony 2.8 сайлекс не нужен вовсе.
akubintsev
02.04.2016 14:58Почему? Он стал более легковесным и конфигурируемым на этапе установки? Где об этом почитать можно?
Fesor
02.04.2016 16:35akubintsev
02.04.2016 20:01Спасибо выглядит неплохо, но не совсем то, что мне нужно. Иногда микрофреймворк нужен не для микроприложений, а для слабой связности компонентов и низкого оверхеда, чтобы интегрировать в имеющийся код.
Мне надо что-то вроде 50% функционала стандартного Symfony 2. То есть с yaml-роутингом и конфигурационными файлами, symfony-translate, twig и DI хоть в каком-нибудь виде. Мне показалось проще допилить Silex до этой комплектации, чем урезать Symfony. По крайней мере в случае с Silex накоплена обширная база знаний.
P.S. я вспомнил еще один нюанс с компонентами 2.8 — негарантированная поддержка php 5.3, что опять же существенно для меня в настоящий момент, увы.Fesor
03.04.2016 01:10а для слабой связности компонентов и низкого оверхеда, чтобы интегрировать в имеющийся код.
Ну тут да, тут проще брать отдельные компоненты даже, а не микрофреймворки. Хотя если надо быстро накидать апишку — то почему бы и нет.
Мне показалось проще допилить Silex до этой комплектации
Мне тоже так казалось пока не попробовал, в итоге теложвижений было много больше, а урезать симфони — без проблем. Правда у меня на этих проектах небыло сильно требований по быстродействию и т.д. потому чуть оверхэда добавляло. Но опять же в режиме микроядра все должно быть ок.
негарантированная поддержка php 5.3, что опять же существенно для меня в настоящий момент, увы.
Чтож, могу лишь посочувствовать. У меня подавляющее большинство проектов на 5.6 и все за последние месяца 4 на php7.
dmitryvashkevich
02.04.2016 02:20silex — деревяшка, к которой легко приделывается термоядерный реактор, который умеет печь блины и делать конфетки. для меня, как любителя, делает еще и офигенный кофе :)
kanstantsin
01.04.2016 15:31+1Кмк, принятие PSR в последние годы направляет PHP в сторону модулей/компонентов, а не фреймворков. Сейчас легко можно собрать фреймворк под свои задачи, без мук выбора.
SerafimArts
01.04.2016 15:39Так современные фреймворки как раз и компонентные. С таким же успехом можно взять симфони или ларавельку и разобрать на составляющие. Будет почти тоже самое, но в обратную сторону.
kanstantsin
01.04.2016 15:41+2Если разобрать ларавельку, то получится симфони :)
Я про то и говорю, что понятие фреймворк теперь это набор компонентов и нет особой разницы, кто эти компоненты воедино собрал и назвал новым именем.
Кроме того, чтобы привязываться к фреймворку и вникать в его абстракции, нужно хорошо подумать, что будет с ним через несколько лет. Для работы на аутсорс это важнее, свой проект во фреймворке, скорее всего, не нуждается.
wordwild
01.04.2016 16:21+1Phalcon на PHP7
kanstantsin
01.04.2016 21:00Мне кажется, что фалькон умер еще до выхода PHP7. А теперь и подавно. Не успевают писать зефир и баги в фальконе править, слишком мало контрибьюторов.
Да многим после выхода PHP7 он не нужен, т.к. разница в скорости уже не такая значительная, а ограничений получается много.wordwild
01.04.2016 23:49Это всё из-за кризиса. Из разряда, как нам на одном сервере запустить три-четыре «фейсбука»? А флакон, всё-таки, несмотря на все свои недостатки, наименее требовательный к ресурсам среди вышеперечисленных вариантов.
Fesor
02.04.2016 02:21Ну я как бы могу на go свои проекты писать и выйдет ни чуть не медленнее, какой мне смысл брать фреймворк на Си или на компилируемом в Си языке?
wordwild
02.04.2016 02:53Очень правильное решение — писать на go. Как только создадут опрос «На каком фреймворке вы будете писать Go приложение в 2016 году», я обязательно выскажусь по-этому поводу. Но, поскольку, мы обсуждаем PHP, я вынужден воздержаться от комментария о смысле использования Go вместо Phalcon.
Fesor
02.04.2016 16:38+1Да поймите, если у меня внезапно будут задачи где нужны прилиные RPS, и, мжет у нас уже есть существующее приложение на PHP, устраняем сайдэффекты меджу запросами и впиливаем поверх всего php-pm. В итоге время бутстраппинга фреймворка невилировано, а скорость PHP7 позволяет сравнивать время работы зефрики и просто PHP. Одно но — пых теперь не умирает, а это требует чуть более адекватного уровня. Как никак средне-статистический похапэшник понятия не имеет что такое сайд эффекты и какие из них есть в его коде.
wordwild
02.04.2016 21:22Меня больше ресурсы интересуют, а не скорость. Заведётся ли Laravel на VPS 0.25GHz/128Mb или не очень… И тут я понял, что недостаточно изучил вопрос. Пойду гуглить.
Fesor
03.04.2016 01:11Заведётся ли Laravel на VPS 0.25GHz/128Mb или не очень…
А зачем вообще такой VPS брать? Это ж бесполезная игрушка.wordwild
03.04.2016 11:12Это я больше для примера. Хотя такие бесполезные игрушки у нас вполне предлагают хостеры. И глядя на то, как развивается кризис, терзают смутные сомнения, что скоро мы всерьёз будем рассматривать даже такие игрушки.
Aeliot
01.04.2016 17:50+5Тут важно с какой целью задавался вопрос. Если с позиции «взять какой-то новый фреймворк на изучение или продвинуться в текущем»? То можно посмотреть по вакансиям. «Самый-самый» тренд может и не словите, но в качестве прогноза на ближайшие пару лет сойдёт. Без хлеба точно не останешься.
Итак.
Посмотрел сейчас на jobs.tut.by (тот же hh.ru, только для Беларуси)
Из 221-й вакансии, где требуется (упоминается) PHP
[ Фреймфорки ]
В 46-и вакансиях в требованиях упоминается Symfony
В 25-и Yii
В 29-и Zend Framework (возможно немного меньше, если в одном объявлении использованы обе формы: 20 Zend + 9 ZF)
В 19-и Laravel
В 5-и CakePHP
В 4-х CodeIgniter
[ CMS ]
В 33-и Bitrix
В 24-х Magento
В 21-и Drupal
В 17-и Joomls
В 17-и WordPress
Из подсчёта выкинуты Маркетологи, SEO-специалисты и пр. В одном и том же объявлении может быть упомянуто несколько фреймворков/CMS. Но общее представление можно составить.
Ещё можно воспользоваться wordstat.yandex.ru и посмотреть количество запросов (уровень проявленного интереса) и, возможно, динамику его изменения.
morozovsk
04.04.2016 14:11В России немного иначе. Неделю назад делал срезы по вакансиям на hh.ru, к сожалению данные остались только по последнему, но пропорции приблизительно те же, что и по всем php-программистам без учёта зп (постараюсь вечером найти эти результаты).
Итак, отфильтровал все все php-вакансии с зп >= 140к, получилось их — 90, а потом по ним искал упоминания в описании:
ниже результаты (поисковая фраза — количество вакансий, в которых присутствовала)
yii — 47
yii2 — 29
symfony — 19
symfony2 — 19
zend — 11
mysql — 70
redis — 33
mongodb — 23
postgresql — 16
memcache — 11
linux — 20
docker — 17
composer — 15
git — 58
svn — 9bardex
04.04.2016 14:42Laravel? Zend еще часто пишут просто как ZF.
morozovsk
04.04.2016 15:02laravel — было меньше 10, у zf было где-то 5, в общем ни как особо не влияло на итоги
bardex
04.04.2016 15:10спасибо большое за цифры
morozovsk
04.04.2016 15:17+1Посчитал сейчас текущие данные:
поисковый запрос на hh — количество вакансий
NAME:php — 1039
NAME:php AND (yii or yii2) — 292
NAME:php AND (symfony or symfony2 or symfony3) — 194
NAME:php AND (zend OR zf) — 137
NAME:php AND (laravel or laravel4 or laravel5) — 95
adubovskoy
01.04.2016 17:50Drupal добавьте тогда уж)
afi13
01.04.2016 18:15Непонятно за что минусуют. Если уж решили добавить Bitrix, то надо было и Drupal, и MODX добавлять. А так какой-то странный опрос получается.
Ну и в целом список скудный, Silex, Slim, Phalcon, CakePHP имеют право участвовать в статистике, даже если по каким-то причинам кому-то не нравятся.bardex
01.04.2016 19:59Список составлялся из самых популярных фреймворков, Битрикс потому, что он отвоевал заметную долю рынка, даже не смотря на платность.
SerafimArts
01.04.2016 23:02+5Простите, я пропустил тот момент когда это "чудо" начало зваться фреймворком. Ну хоть близко.
LeonidZ
01.04.2016 18:34На Symfony 3, естественно
LeonidZ
01.04.2016 23:47На всякий случай, когда будете считать статистику: я нажал на другое, т.к. все же между sf2 и sf3 приличное количество отличий.
youmad
02.04.2016 02:22+1Нет там больших отличий. Ломает обратную совместимость? Да. Сложно обновиться с 2.8 до 3? Нет. Различий в версиях минимум.
Fesor
02.04.2016 02:23Можете назвать "приличное количество различий" между sf2.8 и sf3.0 кроме удаления помеченного депрекейтед функционала? Я вот как-то не могу. Новая структура директорий? Я ее с версии 2.6 юзаю.
LeonidZ
02.04.2016 02:38Скорее всего вы просто не используете огромное количество возможностей Symfony.
Вот листинг того, что надо менять при переходе с 2.x на 3.0: https://github.com/symfony/symfony/blob/master/UPGRADE-3.0.md.
Но как минимум хотя бы с конструкторами форм вы должны были столкнуться (теперь там не экземпляры FormType, а FormType::class), измененными валидаторами объектов и измененными Yaml конфигами (например, вызов колбеков после конструктора, описание роутов).
Так же есть незначительные, но все же изменения в ContainerBuilder-е, bundle compiler-е, dependecy injection, если вы делаете свои бандлы кастомно прекомпилируемыми.
Понятно, что это не кардинальные изменения по сравнению с 1.x -> 2.x, но если проект серьезный, то несколько дней правок обеспечены.youmad
02.04.2016 09:24+1теперь там не экземпляры FormType, а FormType::class
Нет, теперь там FQCN вместо alias.
измененными валидаторами объектов
Уточните, пожалуйста. Мои правила в sf3 такие же, как и в sf2.
измененными Yaml конфигами
Это правится один раз.LeonidZ
03.04.2016 00:34По поводу FQCN согласен, но цитирую UPGRADE-3.0.md от Symfony:
...the FormFactory::create*() methods is not supported anymore. Pass the fully-qualified class name of the type instead.
Before: $form = $this->createForm(new MyType());
After: $form = $this->createForm(MyType::class);
Поэтому не совсем понятно, где именно вы нашли то, к чему относилось «Нет».
LeonidZ
03.04.2016 00:47В любом проекте при переходе с чего-то одного на что-то другое все правится 1 раз, поэтому это странный аргумент. По факту после апдейта на 3.0 даже с 2.8 значительная часть не «hello world» проектов не работает корректно, и да, необходимо, пробежаться везде и по одному разу в каждом моменте подправить. Т.е. нет 100% совместимости. Но, еще раз, естественно, это не переезд на другой фреймворк (включая sf1.4).
По валидаторам:
The PHP7-incompatible constraints (Null, True, False) and their related validators (NullValidator, TrueValidator, FalseValidator) have been removed in favor of their Is-prefixed equivalent.
The class Symfony\Component\Validator\Mapping\Cache\ApcCache has been removed in favor of Symfony\Component\Validator\Mapping\Cache\DoctrineCache.
The constraints Optional and Required were moved to the Symfony\Component\Validator\Constraints\ namespace. You should adapt the path wherever you used them.
The option «methods» of the Callback constraint was removed. You should use the option «callback» instead. If you have multiple callbacks, add multiple callback constraints instead.
The interface ValidatorInterface was replaced by the more powerful interface Validator\ValidatorInterface. The signature of the validate() method is slightly different in that interface and accepts a value, zero or more constraints and validation group. It replaces both validate() and validateValue() in the previous interface.
The interface ValidationVisitorInterface and its implementation ValidationVisitor were removed. The implementation of the visitor pattern was flawed. Fixing that implementation would have drastically slowed down the validator execution, so the visitor was removed completely instead.
Along with the visitor, the method accept() was removed from MetadataInterface.
The interface MetadataInterface was moved to the Mapping namespace.
The interface PropertyMetadataInterface was moved to the Mapping namespace.
The interface PropertyMetadataContainerInterface was moved to the Mapping namespace and renamed to ClassMetadataInterface.
The interface ClassBasedInterface was removed. You should use Mapping\ClassMetadataInterface instead:
The class ElementMetadata was renamed to GenericMetadata.
The interface ExecutionContextInterface and its implementation ExecutionContext were moved to the Context namespace.
The method addViolationAt() was removed. You should use buildViolation() instead.
The methods validate() and validateValue() were removed. You should use getValidator() together with inContext() instead.
The parameters $invalidValue, $plural and $code were removed from addViolation(). You should use buildViolation() instead. See above for an example.
The method getMetadataFactory() was removed. You can use getValidator() instead and use the methods getMetadataFor() or hasMetadataFor() on the validator instance.
The interface GlobalExecutionContextInterface was removed. Most of the information provided by that interface can be queried from Context\ExecutionContextInterface instead.
The interface MetadataFactoryInterface was moved to the Mapping\Factory namespace along with its implementations BlackholeMetadataFactory and ClassMetadataFactory. These classes were furthermore renamed to BlackHoleMetadataFactory and LazyLoadingMetadataFactory.
The option $deep was removed from the constraint Valid. When traversing arrays, nested arrays are always traversed (same behavior as before). When traversing nested objects, their traversal strategy is used.
The method ValidatorBuilder::setPropertyAccessor() was removed. The validator now functions without a property accessor.
The methods getMessageParameters() and getMessagePluralization() in ConstraintViolation were renamed to getParameters() and getPlural().
The class Symfony\Component\Validator\DefaultTranslator was removed. You should use Symfony\Component\Translation\IdentityTranslator instead.
Это все изменения в именовании классов, их методов и параметров методов в неймспейсе Symfony\Component\Validator. Странно, что вы не столкнулись с тем, что даже те же Optional и Required валидаторов уже нет на прошлом месте.
Fesor
02.04.2016 16:40Алгоритм простой — апаемся на sf 2.8, все те вещи в списке начинают писать в логах о том что что-то депрекейтед юзается, планомерно выпиливаем старое и пользуемся всеми плюшками sf3 сохраняя обратную совместимость. И как только мы подчистили все — апаемся на тройку.
То есть если не пропускать обновление на 2.8 то менять придется не много.LeonidZ
02.04.2016 17:37Вот здесь соглашусь полностью.
Просто Symfony 2 не есть именно Symfony 2.8. Т.к. 2.8 — это вообще спец. версия для подготовки к переходу на 3.0. В голосовании же идет речь просто про 2.х, т.е. в том числе 2.0. А 2.0 от 3.0 отличается серьезно, и список изменений очень не маленький.
Мне недавно довелось переводить 2.4 на 3.0 один очень серьезный проект. Так вот, только зачистка на 2.8 заняла 3 дня.
shoomyst
02.04.2016 17:57+1Похоже топикстартер просто не в теме версионирования симфони.
Вообще как на выступлении говорил Fabien есть symfony1 и есть Symfony (никаких 2, 2.х)
ivorobioff
01.04.2016 22:19-3Как я рад что на первом месте пока-что Yii2 а не Laravel 5 :)
Fesor
02.04.2016 02:23+2Отрекись от своего бога.
ivorobioff
02.04.2016 17:53-1У меня нет бога, просто Laravel это дьявол который пудрит всем мозги. И самое страшное что не все осознают это.
SerafimArts
02.04.2016 21:35+1Вот мне, лично для себя интересно — чего плохого в Laravel, чего нет в Yii2?
Fesor
03.04.2016 01:12У человека нет бога, зато есть дьявол. Сатанист же.
ivorobioff
03.04.2016 10:01Если был бы сатанист значит Laravel мне бы устраивал. Так что низнаю кто тут сатанист
Naymen
01.04.2016 22:19+1Я сейчас пишу на Yii2 Advanced. Мое мнение, что Yii2 вырос после обновления из Yii1.
Fesor
02.04.2016 02:24+1Интересно что вы скажите если для разнообразия попишите на других фреймворках. Вот просто ради расширения кругозора. Возможно ваши проекты на Yii так же станут лучше за счет нового опыта.
Wave
02.04.2016 22:34+1Очень заметно вырос. Делал проекты на Yii1, было ощущение какой-то инопланетной логики. Недавно закончил проект на Yii2 — всё очень просто и понятно. Не исключаю, что это моя квалификация поднялась, но всё-таки по ощущениям гораздо удобней стало работать.
Fesor
03.04.2016 01:15А с какими фреймворками у вас еще опыт есть? ибо… ваше описание не говорит ровным счетом ничего на самом деле. Скажем, есть люди которые довольны своей производительностью труда используя какие-то инструменты. Из них половине повезло с задачами, а вторая половина просто не знает что можно эффективнее расходовать время. Ну то есть… для меня Yii слишком сильно сковывает в том как делать дела. И мне интересно какие дела делают те, что у них все хорошо.
michael_vostrikov
03.04.2016 07:04+1Раз уж зашел разговор про сравнение фреймворков. Я пару раз начинал изучать laravel, но как говорится "ниасилил" (может потом как-нибудь еще поразбираюсь). То что не понравилось по сравнению с Yii:
Генератор HTML для форм надо ставить отдельно. На это есть свои причины, но неудобно.
Для работы с ассетами надо использовать elixir, для elixir надо ставить node.js, нода грузит кучу модулей, которые занимают много места, и к тому же делает слишком большую вложенность папок node_modules, на что Windows ругается при удалении.
Статические обращения через фасады. Например, в обучающем примере есть вызовRedirect::route().
Захочешь посмотреть, как этот класс Redirect устроен, какие функции в нем еще есть, или может в документации что-то не понял, ищешь по исходникам и находишь:
class Redirect extends Facade { protected static function getFacadeAccessor() { return 'redirect'; } }
А класс на самом деле называется Redirector.
Из-за этого автокомплит в IDE не работает. Для автокомплита можно поставить отдельный пакет, но там просто заглушки, поэтому к месту реального объявления все равно не перейти.
Генератор модели по таблице и генератор CRUD в Yii тоже удобная штука, позволяет быстро создать минимальный рабочий код. Особенно если сделать свой генератор, который генерирует в верстке выпадающие списки на основе foreign keys. Для laravel вроде тоже есть какие-то пакеты, которые можно поставить отдельно, но я с ними не работал, поэтому ничего сказать не могу.
На мой взгляд, Yii хорошо подходит для разработки в одиночку небольших и средних проектов, у него неплохая документация и более-менее понятная архитектура, в которой можно разобраться просто по исходникам.Big_Shark
04.04.2016 07:07+1Сейчас все больше проектов уходят в сторону SPA, где класс форм больше не нужен, а тот самый elixir приходится к месту, так как есть возможность подключить такие штуки как babel.
Facade в Laravel это просто доступ к классу в контейнере по имени, в данном случае имя в контейнере 'redirect'.
CRUD меняется от проекта к проекту, и как правило занимает время только на начальном этапе, поэтому нет смысла выносить это в функционал, да и как правило для таких проектов подойдут обычные CMS или CMF.
Использовать что Laravel, что Symfony в PHPStorm без плагинов почти не возможно, так что не вижу в этом ничего особенного.
michael_vostrikov
03.04.2016 07:04+1А в каких задачах Yii вас сковывает?
Fesor
04.04.2016 10:06+1Все что связано с бизнес логикой сложнее CRUD и соблюдением принципа protected variations (когда требования меняются — это важная штука).
bardex
01.04.2016 22:25Если подвести промежуточный итог, то понравился ответ kanstantsin https://habrahabr.ru/post/280694/#comment_8834966, сегодня используя composer можно собрать нужный функционал из отдельных, хорошо зарекомендовавших себя, библиотек, например на базе микрофреймворка.
kovalevsky
01.04.2016 22:49Всё на микрофреймворках писать неудобно, но ради исключения оверхеда, для небольших проектов, вариант с композером отлично подходит. Сам успешно применяю :)
aktuba
02.04.2016 00:58+1Не понимаю… Для чего в 2016-м использовать фреймворки? Composer + Github помогут для проекта любого размера.
Delphinum
02.04.2016 01:04Часто нет лишней недели на создание архитектуры из кусочков, проще использовать:
php composer.phar create-project --stability="dev" zendframework/skeleton-application path/to/installFesor
02.04.2016 02:26Да там как бы за пару часов можно сделать… PHP-DI + PSR-7 + какой FastRoute + PSR-3 + Doctrine2 и готов полноценный фреймворк.
Delphinum
02.04.2016 02:34+2Не думаю что за пару часов можно перечисленное вами сделать, если ранее вы этого еще не делали (если делали, то это уже ваш личный фреймворк и "не считается"), а ведь все что вы наделаете нужно еще "протестировать временем", а потом не раз переписать, перекостылись, перепере. Я обожаю "сборные" фреймворки (даже есть собственное решение в этой области), но очень часто хватает какого нить ZF2, что наводит на мысли.
Fesor
02.04.2016 16:44-1протестировать временем
Вы ничего не пишите, вы только берете готовые компоненты и связываете их вместе через тот же php-di. Все то что я перечислил это либо рекомендованные стандарты (PSR) либо популярные реализации (FastRoute юзают в половине микрофреймворков). Да и потом, заварачиваем все в свои адаптеры и заменяем по необходимости отдельные компоненты.
То есть реально сделать простенький фреймворк за пару часов, просто под задачу. Конечно у вас уже должен быть опыт работы с отдельными компонентами, которые будут составлять его, иначе смысла в этом нет как бы.
В целом же я лично ленивый и потому просто для мелких проектов беру sf3.0 в режиме микроядра а для проектов побольше — просто свою сборку sf3.Delphinum
02.04.2016 20:58Вы ничего не пишите, вы только берете готовые компоненты и связываете их вместе через тот же php-di.
А давно инстанциация всего набора необходимых в приложении классов == созданию архитектуры приложения? Про конфигурирование, взаимодействие, системное тестирование и подобную муть вы решили не упоминать? А какую модель роутинга вы выбирите? А ваше приложение будет поддерживать RESTful API, или только классические GET/POST HTTP запросы с возвратом HTML? А как вы будете решать проблему дублирования кода представления? А если в приложении планируется рендеринг ответа в виде HTML кода, но будет много JS на странице, как вы это решите? А (подставьте любой другой архитектурный вопрос)?
То есть реально сделать простенький фреймворк за пару часов, просто под задачу
Composer + Github помогут для проекта любого размера
Мы о проектах любого размера.
В целом же я лично ленивый и потому просто для мелких проектов беру sf3.0 в режиме микроядра а для проектов побольше — просто свою сборку sf3
Замечательно что у вас есть готовые решения )Fesor
03.04.2016 01:22созданию архитектуры приложения?
А давно архитектура приложения = фреймворк? Это ж совершенно разные вещи.
Про конфигурирование, взаимодействие, системное тестирование и подобную муть вы решили не упоминать?
- конфигурирование — PHP-DI, .env
- взаимодействие — PHP-DI, FastRoute, может какой Event Dispatcher еще
- системное/модульное тестирование — HttpKernel/PSR7 + phpspec + codeception/phpunit/peridot/etc
А какую модель роутинга вы выбирите?
Я же написал — FastRoute, в плане "модели роутинга" вариантов как бы не сильно много. Это все в любом случае вешается как мидлвэр какой.
А ваше приложение будет поддерживать RESTful API, или только классические GET/POST HTTP запросы с возвратом HTML?
А ваше? Есть например symfony/serializer для простеньких штук, и fractal для вещей посложнее. А так — повторю еще раз — PSR-7, HttpKernel.
А как вы будете решать проблему дублирования кода представления?
Twig — у него пока серьезных конкурентов как бы нет.
А если в приложении планируется рендеринг ответа в виде HTML кода, но будет много JS на странице, как вы это решите?
Я последние три года перешел на схему http api + spa на ангуляре и в большинстве случаев решают этот вопрос так. Ну и да, javascript-а в html-е у меня нет в любом случае. И это вообще к теме фреймворка не привязано.
подставьте любой другой архитектурный вопрос
То что вы описали это не архитектура — а инфраструктура. Архитектура — это то как вы например организуете работу с платежками, или систему скидок прикрутили и т.д. То есть это болше влияет на уровне бизнес логики, а там у меня старый добрый PHP (спасибо доктрине за persistence ignorance)Delphinum
03.04.2016 12:13А давно архитектура приложения = фреймворк? Это ж совершенно разные вещи.
Тогда надо прежде определится, что есть фреймворк. Для меня это не набор инстанциированных классов с разрешенными зависимостями, а для вас?
Архитектура — это то как вы например организуете работу с платежками, или систему скидок прикрутили и т.д. То есть это болше влияет на уровне бизнес логики
Лихо вы архитектуру приложения и бизнес логику "сэквивалентили" ))
По остальным ответам — видите, если есть опыт в сборке фреймворка из кусочков то дело идет быстрее, но это, как я уже говорил ранее, "жульничество", ибо вы уже создали свой фреймворк и его пользуете. Собрать такое (работающее) быстро с первого раза не получится.Fesor
03.04.2016 13:12Архитектура — это то что дорого менять. Хорошая архитектура — позволяет нам безболезненно менять принятые ранее решения. А фреймворк — это просто куча абстракций и базовая реализация типичных юзкейсов.
По остальным ответам — видите, если есть опыт в сборке фреймворка из кусочков то дело идет быстрее
Да нет, просто у меня много опыта работы с этими компонентами в контексте Symfony. Ну то есть понятно что человек который первый год пишет на Laravel собрать адекватно свой фреймворк практически невозможно. Но ему еще и не нужно, три стадии обучения и все такое, а он еще напервой.Delphinum
03.04.2016 22:41Архитектура — это то что дорого менять
Тобишь если мой кусок кода написан наспех и крайне каменно, а его вдруг стало необходимо поменять, да как то очень дорого, то этот кусок стал архитектурой?
Но ему еще и не нужно
А вам нужно? )Fesor
03.04.2016 22:45то этот кусок стал архитектурой?
Совокупность таких кусочков. Это то как вы построили свое приложение, как здание. если на аналогии переходить. А фреймворк — это каркас, то есть без него никак, но это второтепенная часть приложения.Delphinum
04.04.2016 01:53Тобишь выявление рисков есть архитектура?
Fesor
04.04.2016 10:08Тобишь архитектура это то как вы построили приложение. Плохая архитектура — высокий уровень технического долга. А уже технический долг влияет на риски. Потому стараются выстраивать архитектуру так, что бы уровень технического долга был на приемлимом уровне. А для этого надо выявлять риски, что может поменяться и т.д. Естественно не стоит забывать про yagni но и про protected variations помнить надо.
Delphinum
04.04.2016 19:54Тобишь архитектура это то как вы построили приложение
Вот так бы сразу, а то про риски да про "дорого менять" ))
Тобишь архитектура это то как вы построили приложение
А что тогда структура? )) Мы сейчас уедем не в ту степь с вами. Может таки не будем уходить в размышления на тему — инфраструктура, структура и архитектура — и объединим все это в одно понятие?
Если да, то фреймворк (в отличии от библиотеки) дает готовую архитектуру.
ПримерВозьмем ZF2. Этот монстр скроен из кучи пакетов, но в нем так же есть задел на архитектуру будущего приложения через Zend\MVC и Application. Пользоваться этим или превратить ZF2 в библиотеку, решаете вы как разработчик, но фреймворк предлагает архитектуру.
aktuba
03.04.2016 02:53Я не Fesor, поэтому отвечу за себя.
>Про конфигурирование, взаимодействие, системное тестирование и подобную муть вы решили не упоминать?
Можно упомянуть, но плюс будет не на стороне фреймворков. В них тестируется код, но не архитектура или взаимодействие с другим кодом.
>А ваше приложение будет поддерживать RESTful API, или только классические GET/POST HTTP запросы с возвратом HTML?
В моем — без разницы. Или тот-же FastRoute мешает написать поддержку RESTful API? Ну а если мне надо будет именно RESTful API — я возьму либу именно для этого, а не сторонний фреймворк.
>А как вы будете решать проблему дублирования кода представления?
А что это за проблема?
>А если в приложении планируется рендеринг ответа в виде HTML кода, но будет много JS на странице, как вы это решите?
Использованием отдельных вьюх/рендера? В чем проблема-то?Delphinum
03.04.2016 12:21В них тестируется код, но не архитектура или взаимодействие с другим кодом
Архитектура и взаимодействия в них уже протестированы временем, о чем я писал выше.
Или тот-же FastRoute мешает написать поддержку RESTful API?
Скорее мешает вопрос — а что для этого лучше использовать? Когда вы собираете свой первый фреймворк, этот вопрос часто не дает покоя.
А что это за проблема?
Ну вот предположим вам нужна простая админка для управления данными мобильного приложения. Ничего особенного, десяток сущностей, метр JS оберток для удобного GUI, реляционная база и немного кеша. Все ваши экраны будут делится на 3 основных: таблица сущностей, экран добавления, экран редактирования — и десяток виджетов: список выбора, группа checkbox, группа radio, мультивыбор и т.д. По хорошему, в хорошей архитектуре все это должно быть реализовано ровно 1 раз для всех сущностей, и, если необходимо, переопределено, если для конкретной сущности нужно что то особенное.
Использованием отдельных вьюх/рендера? В чем проблема-то?
Что за отдельная вьюха и рендер позволит легко прикручивать JS к странице? Объясню по другому. У вас есть коллекция элементов, которые отдаются с сервера в виде HTML списка. Этот список уже готов к изучению пользователем, но к нему нужно прикрутить кнопки с JS логикой, позволяющие удалять компоненты из этого списка, добавлять их и сохранять результат (список в form). Нужно как то восстановить JS модель прямо из этого HTML списка средствами самого JS, навешать на нее события и при изменении модели перерендерить список. Естественно при инициализации список не должен перерендерится. На деле я уже объяснил как это сделать, но когда речь о новом фреймворке, опять таки встает вопрос — а как лучше? Что и отнимает уйму времени. О чем я и говорю сейчас )Fesor
04.04.2016 10:10Когда вы собираете свой первый фреймворк, этот вопрос часто не дает покоя.
Мы тут обсуждали фреймворк на компонентах. Я уже говорил что таким надо заниматься только когда уже есть опыт с одним-двумя фреймворками и отдельно компонентами. Ну то есть это уже уровень чуть повыше должен быть у разработчика.Delphinum
04.04.2016 20:01Думаю можно обобщить мое высказывание до:
Когда вы собираете свой фреймворк, этот вопрос часто не дает покоя
ivorobioff
02.04.2016 18:03Тут я соглашусь, в Интернете можно найти кучу уже готовых программных блоков (ака библиотек/пакетов) из которых можно за день с легкостью создать свой собственный фреймворк. Я даже статью в своем блоге про это написал http://blog.igorvorobiov.com/2016/03/28/build-your-own-php-framework-with-ease/
LAV45
02.04.2016 02:24-1Давным давно выбрал Yii2 из эстетических соображений и ни разу об этом не пожалел.
Если найду в нем баг, с работью пришлю им pull request и заработаю ещё +1 в карму ))
popcorn2d
02.04.2016 02:24А как насчет Lumen?
green_tree
02.04.2016 21:06+1использую Laravel постоянно, а вот Lumen совсем не пошел, какой-то недоделанный он (сравнивая с другими микрофреймворками). Поэтому, имхо, насчет Lumen никак…
sayber
02.04.2016 02:51Почему указан Symfony 2 когда как актуальная версия 3?
Надо тогда уж просто писать — Symfony.
Ну и конечно, почему нет выбора нескольких позиций?
Symfony 3 / Laravel 5+
Очевидно что для крупных проектов и средних, лучшие решения.
Правда Symfony мало кому по зубам, поэтому выбирают yii.bardex
02.04.2016 13:07у Symfony 3.0 поддержка 8 месяцев — это не серьезно, а 3.3 еще не вышел. Можете отметить Symfony 2, поменять голосование уже не могу.
shoomyst
02.04.2016 14:51Обновление между минорными версиями во 2-ой ветке было в целом беспроблемным. В любом случае тесты вас спасут.
Вообще я считаю, что обновляться на минорные версии даже полезно: показывает насколько ваш код способен эволюционировать :)
caballero
02.04.2016 12:47Ого!.. Столько минусавания за собственные решения что лучше промолчу. Хорошо что создатели сомфоней и прочих лаваралей в свое время не участвовали в дискусиях на хабре — огребли бы по полной програме сколько в их будущем фреймворке будет костылей, что это будут велосипеды с квадратными колесами и в том же духе.
DenQ
02.04.2016 13:15+3Понимаете, создать свой фреймворк это нормально. Но только если у вас опыт за плечами в +10 лет.
Fesor
02.04.2016 16:46+1Полностью поддерживаю. Свой фреймворк это хорошо когда есть composer и хороший опыт хотя бы с тремя популярными и понимание того что делаешь, а вот с последним у многих проблемки.
M-A-X
11.04.2016 15:47Это те, кто пишут на фреймворке, зачастую не понимают, что они делают :)
Fesor
11.04.2016 15:57Тут нет корреляции. Люди просто зачастую не понимают, что они делают. И когда новички начинают писать свои фреймворки «потому что зачем так сложно», обычно понимания это не добавляет и выходит намного хуже для бизнеса.
M-A-X
11.04.2016 16:55-11. приходится работать после горепрофи на Yii. Это ад.
2. > обычно понимания это не добавляет
Если ты не умеешь делать базовые вещи на языке, а лезешь во фрейворки это понимания не добавляет вдвойне.
3. >И когда новички начинают писать свои фреймворки
Новички не пишут свои фреймворки, они просто пишут код.
4. >и выходит намного хуже для бизнеса
По нормальному новичков к важным процессам не стоит допускать.
5. >«потому что зачем так сложно»
Если новичек понимает, что фреймворки чрезмерно усложнены, то он молодец, что не пляшет под эту дудку.
Фреймворк не панацея от рогатых программистов.
П.С.
Чем-то сторонники фреймворков напоминают сторонников майдана. :)Fesor
11.04.2016 17:361. Верю, потому не добавляю его в список фреймворков у которых все хорошо. Это весьма специфичный фреймворк и я не рекомендую его новичкам. Однако сильные ребята которые прекрасно знают что такое хорошо и что такое плохо могут делать интересные штуки на нем.
2. по поводу понимания… в целях обучения — пожалуйста, пишите что хотите, но на коммерческих проектах только проверенные и стабильные решения, особенно если у вас нет за плечами хотя бы 5-ти лет серьезной коммерческой разработки (то есть вы еще не умеете писать тесты а уже считаете себя умнее остальных).
В конце конвов помимо роутеров и шаблонизаторов, вам проект еще надо написать, а это нередко не менее сложная штука и сосредоточиться лучше на этом.
3. новички так или иначе пишут свои фреймворки. Сначала маршрутизацию свою навояют, потом шаблонизатор, потом «класс для работы с базой». Как-то так это происходит в среднем.
4. Полностью согласен. Но они как-то влазят, ибо рынок труда не насыщен.
5. Фреймворки не усложнены. Там не сложно, там много. Серьезно, даже если мы возьмем самый какой-нибудь сложный пакет на PHP — доктрину например, то если разобраться там все компоненты системы не особо сложны. Их просто много. И много их что бы покрыть 95% юзкейсов возникающих у разработчиков. А все это ведет к уменьшению издержек.
p.s.
к вопросу о адекватности. Вы можете просто рассписать тут какими проектами занимаетесь, количество людей в команде, среднюю длительность проектов и уровень их сложности. А далее мы можем уже продолжать конструктивый разговор на тему «нужны фреймворки или можно обходиться библиотеками и забить на загоны по инверсии зависимостей».M-A-X
11.04.2016 17:58Текущие рабочие проекты огласить не могу, так как я неполиткорректный на хабре :)
Продуктовая компания.
У сайта-визитки посещаемость порядка 300 000 в день. + АПИ.
В команде веб 6 человек.
Личные проекты:
их несколько, к примеру
http://kvartirale.com/
>В конце концов помимо роутеров и шаблонизаторов
А зачем их вообще писать.
У меня роутингом занимается нгинкс, а php и сам шаблонизотор по себе.
Понапридумывают проблем на ровном месте.
KISS.
malinichev
02.04.2016 13:10+2Я буду на Phalcon писать, как и раньше, как и год назад)
Параллельно буду делать на Laravel, надо расширяться
akubintsev
02.04.2016 14:51Писать — что?
Конечно в лидерах по такому опросу будут RAD-фреймворки из-за количественного преобладания задач по созданию типовых веб-сайтов.
А если я занимаюсь поддержанием и развитием legacy кода под большой нагрузкой, в котором много backend логики реализовано?
Я лично выбрал Silex.
zBit
02.04.2016 23:24Когда писал на PHP, пару лет назад, очень понравился Phalcon. Если бы сейчас дали задание реализовать проект на PHP, то я выбрал бы именно Phalcon.
Cttr
03.04.2016 03:00Хотел Symfony2, но там пока непонятные дела с mongodb-odm-doctrine, поддержка ext-mongodb (привет php7) — с помощью php драйвера. Поэтому пока взор упал на Laravel
remotemethod
03.04.2016 16:11Выбрал бы конечно Laravel или Phalcon. Да и смотрю Zend выбирают все меньше и меньше, это наверное потому что он суров к стандартам.
lebowski
03.04.2016 22:04Выбирающим Yii: фреймворк абсолютно не известен на западе.
Если вдруг вы захотите вкатиться на Upwork или другие биржи — ваш выбор LaravelFesor
03.04.2016 22:38-1Apple выбирает Symfony. ну это так, накинуть)
SerafimArts
03.04.2016 22:56+1Что Laravel, что Symfony — однофигственно. Для относительно опытного разработчика не будет никакой разницы между ними, т.к. они оба слабосвязанные и с одинаковым успехом можно использовать как L5 + Doctrine + Twig, так и Symfony + Eloquent + Blade (ну для примера).
Чего не сказать о Yii, там надо довольно сильно помучаться, что бы выдрать AR из ядра, да и идеи Yii довольно сильно влияют на мышление разработчиков и перейти на Symfony им будет проблематично, надо весь мозг себе перестраивать будет.
P.S. Это я по себе сужу, т.к. использовал немного Yii, перешёл на Laravel и скоро перебираюсь на Symfony, хотя и сейчас уже использую его компоненты вовсю.
naghtigall
03.04.2016 23:39+1Забыли старый, добрый Codeigniter. Он кстати готовится к 4 версии на РНР7
Fesor
04.04.2016 00:24К слову неплохая стратегия. Берем легаси на CI, мигрируем его на CI4 + php7, а затем постепенно снижаем связанность и заменяем CI на отдельные компоненты какие-то. Хотя в принципе можно пропустить этап с CI4.
remotemethod
05.04.2016 00:23+226% (560) Laravel 5
27% (547) Yii 2
Это как так получилось?
Совпадение? Не думаю!
Saturnych
06.04.2016 12:36-1судя по комментариям и минусоплюсам, тут сидят фанаты всякой фигни.
плюс несовсем понятно обсуждение, почему PHP сам по себе хуже.remotemethod
07.04.2016 03:28Тоже имею интерес узнать, что нынче не фигня.
M-A-X
11.04.2016 13:12Фреймворки фигня, что непонятного? :)
Fesor
11.04.2016 13:21Для того что бы подобное утверждать, приведите формулировку «что есть фреймворк». А потом задумайтесь, может ли быть так, что фреймворка вообще нет?
M-A-X
11.04.2016 14:32а) фрейморки — это то, за что здесь голосовалось
б) загугли:
https://ru.wikipedia.org/wiki/Фреймворк
Многие путают фреймворки с библиотеками, поэтому такая вырезка:
Фреймворк отличается от понятия библиотеки тем, что библиотека может быть использована в программном продукте просто как набор подпрограмм близкой функциональности, не влияя на архитектуру программного продукта и не накладывая на неё никаких ограничений. В то время как фреймворк диктует правила построения архитектуры приложения, задавая на начальном этапе разработки поведение по умолчанию, каркас, который нужно будет расширять и изменять согласно указанным требованиям. Пример программного фреймворка — CMF (Content Management Framework), а пример библиотеки — модуль электронной почты.
Также, в отличие от библиотеки, которая объединяет в себе набор близкой функциональности, фреймворк может содержать в себе большое число разных по тематике библиотек.
Другим ключевым отличием фреймворка от библиотеки может быть инверсия управления: пользовательский код вызывает функции библиотеки (или классы) и получает управление после вызова. Во фреймворке пользовательский код может реализовывать конкретное поведение, встраиваемое в более общий, абстрактный код фреймворка. При этом фреймворк вызывает функции (классы) пользовательского кода
П.С.
Накиньте чуток кармы, а то отвечать не могу. Нету сил ждать 1 час. :)Fesor
11.04.2016 15:12фрейморки — это то, за что здесь голосовалось
Вы же понимаете что это определение вообще ничего не объясняет?
Многие путают фреймворки с библиотеками, поэтому такая вырезка:
Многие думают что фреймворк и приложение неотделимые друг от друга понятия. Хотя фреймворк, это строительные леса для приложения.
Было бы странно если бы мы строили дом, а строительные леса и инфраструктура были бы намертво впаены в стены. Случись что с инфраструктурой, например труба лопнула, пришлос бы ломать стены что бы добраться. Обслуживание такого дома будет явно обходиться сильно дороже.
Словом распространенное заблуждение в том, что фреймворк влияет на архитектуру приложения. Это далеко не так. Нормальные фреймворки, вроде Zend, Symfony или Laravel, вообще ничего нам не диктуют. Основные архитектурные ограничения накладываются в отношении UI для нашего приложение, а последнее ничего не должно знать о UI (MVC там, разделение ответственности).
ORM — это уже опциональные штуки. Они далеко не всегда нужны (например если мы используем mongodb — у нас нет связей а стало быть не нужны и ORM). Да и нормальный фреймворк предоставляет возможность выкидывать ненужные компоненты и заменять их своими.
И даже если мы будем делать все на отдельных библиотеках, со временем у нас выростет прослойка между приложением и библиотеками (инверсия зависимостей), и эта прослойка и будет нашим фреймворком.Delphinum
11.04.2016 18:07Нормальные фреймворки, вроде Zend, Symfony или Laravel, вообще ничего нам не диктуют
Не диктуют, но предлагают. Применять их предложения иль нет, дело ваше, и это есть хорошо.
А вот библиотеки ничего не предлагают в принципе, иначе это уже не библиотеки. О том и идет речь, когда говорят что — фреймворк влияет на архитектуру приложения.
M-A-X
Самопись.
Не нужно обходить грабли фреймворков и приделывать костыли к велосипеду, чтобы он ехал :)
Fesor
Как хорошо вы описали работу на самописах. В целом если тесты пишите — то как хотите делайте и на чем хотите. Если же нет — то… для таких людей есть особенное место в аду.
M-A-X
> то как хотите делайте и на чем хотите
А я только за себя и говорю.
Остальные пусть мучаются с чем хотят. :)
И да, программирование на фреймворке — это тоже велосипедостроение, когда есть типовые решения для того же корпортала и т.д.
Fesor
типа конфлюенс купить и не париться?
M-A-X
Конфлюенс мне не нравится, то ли его не сумели настроить. :)
Есть какая-то украинская фирма, не помню название, есть SharePoint.
webmoder
В итоге вы получаете свой велосипед со своими костылями и граблями, которые также придется обходить.
M-A-X
В итоге я получаю Лексус ручной сборки. :)
Граблей нету, так как я их не расставлял.
Стараюсь не делать вообще, чем делать костылями.
В своих проектах костылей не держу.
К сожалению на фреймворках костыли приходится использовать, так как настаивает заказчик.
:)
Blast
Вы уверены, что обладаете достаточной квалификацией, чтобы отличить костыль от качественного решения? Что не разложили грабли по незнанию либо недосмотру? Что получается лексус, а не заниженная приора?
M-A-X
>Вы уверены, что обладаете достаточной квалификацией, чтобы отличить костыль от качественного решения?
Я вижу, когда необходимо применять некачественное решение на фреймворках и пытаюсь этого избежать.
>Что не разложили грабли по незнанию либо недосмотру?
При текущих требованиях граблей нет.
Когда они появляются при изменении требований, то сразу выпиливаются.
:)
Fesor
А ваш клиент платит соответственно, а мог бы получить какой-нибудь опель и ехать а не дом закладывать второй раз.
вы просто пока на них не наступили, но они есть, там где-то под листвой.
А как вы тогда называете "временные решения"?
Я прям так и вижу "слушай чувак, мне надо фичу запилить, сделай пожалуйста так что бы кастыль вот в этом месте".
M-A-X
> А ваш клиент платит соответственно
Самопись только для себя. На работе и CMS, и фреймворк. :)
Гипотетично:
а) у меня клиенты не нищеброды
б) себестоимость Лексуса выходит по себестоимости Опеля, а то и ниже :)
>мог бы получить какой-нибудь опель и ехать
Вот он уровень фреймворков.
Хотя скорее получаем подбитый танк для передвижений по городу :)
>А как вы тогда называете «временные решения»?
Я не отожествляю временные решения и костыли.
>сделай пожалуйста так что бы кастыль вот в этом месте
Нет, я предупреждаю, что, возможно, при таких требованиях будет костыль в таком-то месте.
Заказчит отвечает обычно: Ну раз никак иначе, то ок.
:)
Fesor
Абсолютно бесполезная статистика. Намного интереснее было бы посмотреть корреляцию между: предпочитаемым фреймворком, опытом коммерческой разработки, опытом работы в команде, средним размером проекта. Только для размера проекта надо метрики еще выдумывать.
Я же маленькие личные проекты я скорее буду делать на Ayres шутки ради, а коммерческие — symfony.
p.s. ошибся веткой.
bardex
Вопрос "какой фреймворк лучше" почти каждый день спрашивают на тостере, это неизменно приводит к холивару. А в данном голосовании вопрос задан: на каком фреймворке вы будете писать приложение, т.е. подразумевается, что стадия сравнения, споров и выбора уже прошла, и тимлид или команда или бизнес решили: по факту будем писать на…
И речь в голосовании идет именно о средних и крупных проектах, маленькие личные — ни в счет.
Хочется узнать фактический мейнстрим на 2016 год, то есть что будет на самом деле, а ни этот хороший, а тот плохой.
Fesor
Тут выборка не репрезентативна. Вы выберите "мэйнстрим по мнению остатков хабравчан". Именно по этому меня лично больше интересует корреляция "выбор фреймворка" — "опыт в коммерческой разработке" — "опыт командной разработки". Это позволяет чуть по другому взглянуть на тренды. Мол Laravel и Yii выбирают в основном новички, более опытные чуваки сидят на Symfony, Zend. Есть хипстота которая не использует фреймворки, а так же опытные дядьки которые на компонентах собирают свои фреймворки под конкретную задачу.
Мэйнстрим — это бесполезная штука.
Big_Shark
Тогда вопрос как мне кажется не очень корректно задан, так как на работе я буду писать на symfony2, а для себя на laravel5. И я подумал что спрашивают именно про меня и про мои предпочтения, и я ответил laravel5.
bardex
нормально, если вы пишите средне-крупный проект, для статистики подойдет, вы же тоже наверняка прошли стадию сомнений/выбора.
Fesor
Ты пишешь для себя средне-крупные проекты? Как-то сомневаюсь.
Big_Shark
Ну если мне дадут новый проект и скажут выбирай, то выберу laravel, почему нет. А для себя я пишу всякую фигню только которую и проектом то сложно назвать.
Delphinum
В статистике интересна не итоговая цифра, а именно корреляция, о чем и говорит товарищ Fesor.
claygod
Раз уж упомянули, то расскажите подробней об этом фреймворке.
Fesor
Ну это фреймворк-пример, собранный из разных компонентов вокруг проекта amphp. По сути этот не фреймворк даже, а просто http/websocket сервер на php, построенный на корутинах. Что-то типа node.js + async/await. В рамках этого проекта уже реализованы библиотеки для удобной неблокируемой работы с сокетами, http, есть неблокирующие mysql и psql драйвера и т.д.
Если вы помните такой проект как reactphp — то тут примерно то же самое, но можно писать в синхронном стиле за счет использования корутин и промисов. Никаких колбэков.
DenQ
Тогда уж лучше на ноде писать скажем микросервисы. Если уж об асинхронности речь зашла.
webmoder
интересно, а если речь о SASS/SCSS заходит то вы сразу на Ruby начинаете писать?
DenQ
Интересно, а вы и сокеты будете на PHP подымать?
И вообще, причем тут SASS?
Нужно понимать, что для каждой задачи свой интрумент!
А то сейчас еще найдутся умельцы, которые на php, ОС напишут.
baltazorbest
То есть, Вы хотите сказать что если язык развивается и на нем можно новые вещи делать то это плохо и все равно нужно другой инструмент брать?
DenQ
Вы уверены, что не путаете развитие языка с развитем интрументов?
Просто, я как-то не заметил развития php в сторону асинхронности.
А вот разные, сторонние костыли пытающиеся реализовать асинхронность, многопоточность, вокруг брокеров сообщений(опять же сторонних) — развиваются.
Fesor
yield и корутины доступны в php с 2012-ого года, реализация event loop итого дольше. stream_select — с версии 4.3. Что еще нужно?
это называется распределение задач по обработчикам, никаких "кастылей", просто возможность гибко масштабироваться. Сегодня мы держим все воркеры в одном процессе, а завтра этим занимается класстер. Или MPI предлагаете юзать?
bardex
расскажите пожалуйста, как использовать корутины для асинхронности, насколько я понял, поток программы все равно остается один?
Fesor
Это по научному называется "мультиплексирование потока выполнения".
Если мы например возьмем go и его горутины, но внутри это будет все те же корутины, просто пул оных будет разнесен еще и по нескольким потокам. Это нужно для минимизации эффекта переключения контекста, то есть производительность при сотне полноценных тредов будет сильно ниже чем корутины + малое количество тредов.
Собственно точно так же работает nginx, где в каждом воркере запущен event loop, который работает точно так же как корутины. Профит от корутин в сравнении с обычным event loop в том что мы можем писать код абсолютно в синхронном стиле без единого колбэка. Пример:
Это простенький echo-сервер на PHP написанный с использованием корутин. В C# есть еще более удобная штука, async/await, которая по сути является сахаром над корутинами. В javascript например оно заимплеменчено в рамках es2016.
bardex
спасибо
DenQ
Ок. И как по вашему `yield` относится к асинхронности?
Генераторы и итераторы не имеют отношения к асинхронности или многопоточности. Они вообще о другом.
event loop. Да есть. Но это еще не асинхронность. У него немного другая задача. Но да, ускорить можно согласен.
stream_select. Вы серьезно? Вы еще форки вспоминте. Это вообще не юзабельно.
1 из 10К пэхапешников имел опыт и честь отважно этим пользоваться.
Не так просто существует устойчивое мнение, что в php нет асинхронности и многопоточности.
Пока что нет. Как будет, я очень обрадуюсь.
Fesor
Точно так же, как и event loop в node.js собственно. Принцип работы — идентичный.
Они позволяют контролировать и прерывать поток выполнения так как хочется того разработчику. В приведенном вами примере с нодой генераторы используются для реализации полифила async/await например.
Дайте определение где настоящая честная асинхронность. Треды в PHP есть, но использовать треды в web в 90% случаев не имеет смысла. Golang и его горутины — это пулы корутин раскиданные по отдельным потокам и там как бы тоже не совсем честная асинхронность, хоть уже и ближе. Но мы так же можем запустить n процессов воркеров со своими пулами корутин, и получим примерно тот же эффект, просто не столь удобно.
Мне кажется вы просто не знаете что это такое. Эта штука позволяет нам реализовать на низком уровне event loop.
Правильно, потому как это низкоуровневая штука. Все юзают reactphp/amphp.
pthreads доступен для php уже лет 10 а то и больше. Так что многопоточность есть. Но давайте учтем такую вещь как переключение контекста и подумаем еще раз — а так ли нужна ли нам многопоточность на бэкэнде.
Давайте может определимся чего мы хотим достичь. Асинхронность не нужна, нужна "неблокируемость". С этим у PHP все плохо в плане готовых бибилиотек, но проекты типа amphp радуют.
Fesor
Да, у меня даже опыт такой есть. И в этом нет ничего страшного. Если надо что-то из разряда "стандартное решение" то я конечно же возьму node.js + socket.io, но говорить что нет задач под пых где нужны демоны — это чуть более чем странно.
Как бы основная проблема то в том что большая часть библиотек не оч побочные эффекты обрабатывают, и это основная беда похапэшников.
DenQ
У меня тоже был опыт — подымал сокеты, в прошлом году. Могу сказать одно точно — всю работы можно было сделать намного быстрее и проще. Если б можно было в рамках задачи использовать ноду.
И да оно падало — признаюсь. Падало но редко. Причину выяснить так и неудалось. В либы брокеров не ходил, не смотрел.
На счет демонов — я пока что считаю что пых нужен для того чтобы умирать. Он с этим отлично справляется. Кто в теме поймет.
VolCh
Чем лучше? Особенно, если на PHP уже реализована мощная модель домена. Переписывать на JS и синхронную часть на асинхронный манер? Поддерживать две модели одного домена на двух языках с, как минимум, разной объектной моделью?
DenQ
Зачем что-то переписывать?
Пишем сокеты отдельно, в виде микросервиса. Налаживаем коммуникацию между микросервисом и основным сервисом. Все!
К чему паника?
Fesor
Собственно я так обычно и делаю, просто потому что у socket-io нет конкурентов особо. И это как бы логично, и даже в случае с PHP делал бы так же (отдельный ws-сервер что бы скейлиться было удобнее).
oxidmod
нужно просто выбрать подходящий фреймворк, чтобы не пришлось его преодолевать. А вот если задачи очень уж нестандартные, то стоит подумать о самописном проекте
Fesor
Для того что бы выбрать оный разработчик должен быть хорошо знаком еще с пятком других фреймворков что бы делать какой-то обоснованный выбор.
При любой нестандартной задаче обычно речь идет о каких-то отдельных компонентах, либо о сложностях с отдельными компонентами которые могут возникнуть если проект выстрелит и не сразу. То есть в первую очередь фреймворк должен нас ограничивать от выстрела в ногу, но давать заменять свои части. Фреймворки уровня zend/symfony/laravel это позволяют делать. Yii скажем — нет, вы полностью завязываетесь на его инфраструктуру, но у этого тоже есть свои плюсы.
oxidmod
>> Фреймворки уровня zend/symfony/laravel это позволяют делать. Yii скажем — нет, вы полностью завязываетесь на его инфраструктуру, но у этого тоже есть свои плюсы.
вот потому я и выберу симфони, чтобы по мере необходимости подсовывать свои компоненты
M-A-X
Хоть 1 здравомыслящий человек.
Преодолевать приходится почти во всем, что делаю. :)
Мне не нравится трактование MVC во фреймворках.
И некоторые другие архитектурные особенности мейнстримовых фреймворков не нравятся:
http://blog.kpitv.net/article/frameworks-1/ (статья изначально была написана для хабра, но так инвайт и не получил, https://habrahabr.ru/sandbox/96533/ )
Задачи то в принципе стандартные, это ж веб, только вот фреймворки их не решают, а решают какие-то надуманные проблемы.
Fesor
Mediating-controller MVC, Model2? Какой из них? Классический MVC не применим в stateless-модели выполнения.
Мне в этом нравится позиция авторов Symfony:
DenQ
Вы наверное еще и composer не пользуете?
M-A-X
Может и использовал бы.
Но у меня таких зависимостей нету. :)
DenQ
Т.е. слой взаимоейсвия с БД вы пишите сами?
M-A-X
Да.
Мне не нравятся активрекорды, доктрины и прочий мусор.
Я реализовал API инфоблоков Битрикса для сущностей БД.
Развелось так званых программистов, не умеющих писать SQL.
DenQ
Почему не умеющих?
Если человек пользует AR это еще не значит, что он не знает SQL.
Скорее это намекает на его зрелось, как разработчика.
И тоже самое можно сказать и про др. пакеты и др. языки.
M-A-X
Многие вообще считают, что AR — антипаттерн. :)
Мне лишние дырявые абстракции не нужны. :)
DenQ
"Мне лишние дырявые абстракции не нужны"
Ну да, лучше свои дырявые абстракции
А не те, которые проверены временем
M-A-X
В первую очередь «Мне лишние абстракции не нужны», а уже потом «дырявые» :)
SerafimArts
Я тоже считаю, что AR — это некоторый антипаттерн, что не отменяет его как очень эффективную и удобную штуку. А сможете ли Вы на словах объяснить что в нём плохого? ;)
M-A-X
>А сможете ли Вы на словах объяснить что в нём плохого? ;)
Не смогу, так как плотно его не использую. Поэтому и написал, что некоторые считают. :)
SerafimArts
Рассказываю — AR плох тем, что смешивает работу над хранилищем (БД) с работой над моделью, что там пересекаются области ответственности непосредственно сущности и работой с базой данных, что зачастую такая модель монструозна, что… Ну т.е. проблем дофига.
Но повторюсь — оно удобно. Можно написать
User::getAll()для получения объектов всех пользователей из ресурса (таблицы, в случае с БД) пользователей и не париться. По этому его так называют те, кто смог с ним поработать и понять, что очень жирная модель, приближённая к божественному объекту — это не всегда хорошо. Хотя никто не мешает опять же разделить эти области ответственности, превратив AR модель в своеобразный репозиторий, а энтити иметь кристально чистыми, заточенными под бизнес-логику непосредственно.Вот и все его проблемы.
DenQ
Простите, а что мешает использовать behaviors, events?
Или просто композицию?
Тогда модели не будут жирными
SerafimArts
Эвенты никак не относятся к AR непосредственно (https://en.wikipedia.org/wiki/Active_record_pattern). Задача AR лишь записать и получить модель в бд с указанным состоянием, где объект представляет собой "слепок" состояния таблицы в нужный момент времени, а эвенты лишь следствие этих действий. Я рассказывал о проблемах паттерна в целом, а не способе решения проблем в какой-либо реализации, которая добавляет туда ещё и эвенты.
А под композицией я так понимаю имеется ввиду embeddables? Тогда вариант, вполне.
Но эти действия не отменяют того, что мы смешиваем с реализацию (
$user->name = 'Vasya'), вместо работы с бизнес-логикой ($user->rename('Vasya')). fesor давеча открыл мне глаза на подобную вроде как мелочь, которая в реальности поменяла мою картину мира.DenQ
Под композицией я имею ввиду тип отношений между сущностями. тыц
Fesor
Суть в том, что большинство людей, которые используют AR, используют их как анемичные модельки, как row data gateway, и в итоге бизнес логика сущностей размазывается в лучшем случае по сервисам-менеджерам. Что по итогу приводит к тому, что из спагетти кода мы получаем лазанья код, то есть если мы хотим внести небольшие изменения не затрагивающие функционал на одном уровне, мы должны будем поменять все насквозь, от контроллера до базы данных.
Fesor
давайте вспомним как вообще появился на свет паттерн Active Record. Сидели чуваки, и была у них комбинация из Domain Object + Row Data Gateway:
и все было ништяк, инкапсуляция, разделение ответственности, удобно же. А потом кто-то задумался… вот нет у меня в проекте сложной бизнес логики… я тупо данными оперирую на уровне CRUD. И выходит что для простой прослойки бизнес логики мне надо городить сверху еще одну прослойку объектов… зачем… я лучше прямо в row data gateway вынесу свою простую логику.
И так и сделали, и назвали это дело active state или active record. И для простых проектов — это мега удобно, но проекты посложнее — там уже нужно вводить domain objects, а по итогу выходит что люди начинают размазывать логику по сервисам, и иногда делают их stateful.
Альтернатива — data mapper. И я сейчас не про доктрину, ибо там намнооого больше чего есть. Я сейчас про самую примитивную реализацию. По уровню сложности — вот ни разу не сложнее active record, но вот гибкости и пространства для моневра дает чуть больше.
И проблема сейчас в том, что у людей из полноценных решений только простые примитивные реализации active record, и мегажирная доктрина. А про проекты типа spot2, analogueorm никто и не слыхивал. И в итоге у людей возникает непонимание как все эти вещи юзать. Культ карго и все такое.
bardex
а курсы у вас есть ?
Fesor
Ну вот… на счет того что это антипаттерн не соглашусь, а вот то что его оверюзят там где не надо — это факт. Доктрина — это противоположная сторона — это удобный инструмент для прототипирования и быстрой разработки.
тут другое дело что для половины проектов и ORM в общем-то не нужен. Достаточно table gateway организовать что бы sql не размазывался по проекту. Ну и с учетом трендов типа использования документно-ориентированных баз данных и т.д. достаточно простого мэппера какого.
M-A-X
> для половины проектов и ORM в общем-то не нужен
+
> чтобы sql не размазывался по проекту
+
Fesor
Почему же? Просто мне вот не особо хочется париться по поводу того, какую базу данных выбрать например. В итоге я сначала накидываю логику приложения а потом думаю, какая модель данных тут подходит больше и что выбрать. Скажем если я выберу mongodb — мне по сути ничего вообще не надо. Выберу реляционку — прикручу доктрину, я всеравно все выборки на чтение в большинстве случаев делаю через dbal.
А битикс не мусор?
M-A-X
> Просто мне вот не особо хочется париться по поводу того, какую базу данных выбрать например.
Но по факту большинство не меняет базу. Да и есть PDO. :)
>А битрикс не мусор?
Я взял только знакомый интерфейс, который меня устривал, и расширил его потом. :)
SerafimArts
1) Почему же, я довольно часто сталкивался с кейсом, когда локально используется sqlite, а на дев. сервере и боевом уже mysql и прочие. Причина одна, небольшой проектик, вроде блога или лендинга для исправления мелких багов проще развернуть на простом окружении — php + builtin + sqlite, вместо конфигурирования php + apache + mysql.
2) PDO не меняет SQL синтаксис. ORM и билдеры это делают, подстраивая его под нужную БД. Не весь конечно, но большинство популярных задач оно решает.
DenQ
Дело не в том что ORM меняет синтаксис. Я бы сказал что ORM, немного не об этом. И сравнивать ее с PDO не совсем корректно.
ORM помогает легко вытягиваеть связанные данные, вторая буква в аббревиатуре, как раз на это указывает.
Вместо того что б писать бесконечные left join(которые я люблю), досточно просто написать
$post->comments;M-A-X
> вместо конфигурирования php + apache + mysql
А что там конфигурировать? Взял Open Server и все :)
Да и с импортом/экспортом/дальнейшей доработкой проблем не будет. :)
Delphinum
Не так давно нужно было развернуть небольшой (на самом деле громадный) проект у жены на ноуте, чтоб она подправила там верстку. Стоял у нее Windows и я попробовал Open Server. Как оказалось, теперь без доната эта штука качается с обрезанной скоростью, весит 180 метров, а устанавливается (распаковывается) минут 15.
Я около часа ставит Open Server, затем еще час собирал зависимости и настраивал окружение. В результате плюнул на все и следующим утром накатил Ubuntu Linux. В одну команду поставил окружение (PHP Web-server + bowerphp + sqlite) и отдал рабочий проект.
Этот же проект надо будет передать другому верстальщику, у которого MacOS и нет Open Server. Предложите ему перейти на Win + Open Server? )
Fesor
vagrant, docker?
Delphinum
Компик совсем слабый, а мне лень это все разворачивать, хоть и стоило бы.
M-A-X
>эта штука качается с обрезанной скоростью, а устанавливается (распаковывается) минут 15.
Может у вас нищебродный интернет и ноут? :)
>затем еще час собирал зависимости
Какие еще зависимости?
> В одну команду поставил окружение (PHP Web-server + bowerphp + sqlite) и отдал рабочий проект.
Будто mysql так сложно поставить :)
Такое уже пишут.
>Предложите ему перейти на Win + Open Server? )
Предложите ему перейти на Ubuntu и то, что Вы ставили :)
Delphinum
Попробуйте сами скачать с официального сайта без доната.
У крупные проектов есть такая вещь, как зависимости.
Ну как сказать, вот примерный порядок действий для Win:
Зачем все это когда можно использовать sqlite с теми же возможностями (естественно ограниченными) для локальной разработки, которая развернется с выполнением install.sh?
Боюсь он пошлет вас и меня очень далеко и останется сидеть на чем сидел.
KReal
PHP на винде практичезки из коробки работает, кстати. Web Platform Installer в помощь.
Delphinum
Почему "практичезки" из коробки? Он вполне полноценно работает из коробки на винде.
А можно мне просто PHP с драйвером PDO_SQLite?
Fesor
Ну… разные бывают задачи. А еще есть микросервисы, когда весь проект — это на самом деле много мелких проектов, и у каждого может быть своя база специфичная под нужды.
M-A-X
Все бывает, но у большинства — один цельный проект, а не куча микросервисов, да и там база, как правило, одна. :)
Fesor
Грустно это слышать в 2016-ом году...
M-A-X
Ну нету у меня стороннего кода, который использует композер.
Что грустного тут?
Fesor
У композера еще есть модный автозагрузчик.
M-A-X
Автозагрузка это круто, но мне как-то не хотелось писать для чужих либ автозагрузчик в композере. :)
Для своего кода есть отдельный автозагрузчик, который нету смысла натягивать на composer.
Delphinum
Соль в том, что composer сам пишет автозагрузчик.
M-A-X
О, это круто :)
Спасибо.
Fesor
А чужих либ нет в композере? Может есть уже получше альтернативы?
M-A-X
Ну я только недавно перешел на ВДС.
Мне больше не было чем заняться, как искать, что есть в composer :)
Хотя оказывается 1 либа есть, только на сайте самой либы нету упоминания об установке через composer.
Fesor
Рекомендую, за 4 года там много годного собралось. Вообще рекомендую вам познакомиться с композером поближе, возможно поддержка ваших проектов чуть облегчится.
bardex
Оффтопик, но может посоветуете из composer хороший слой для работы с базой, кроме Doctrine?
Fesor
Смотря что вам нужно. Если именно "слой" — то кроме доктрины по сути ничего больше нет. А так есть Spot2 например, он выглядит относительно приятно.
DenQ
Он видимо и bower`ом тоже не пользуется :)
M-A-X
Нет.
У меня сайты до марта месяца жилы на шаред хостинге.
А там, как я понимаю, нету необходимого npm.
Да и у меня js лежит в cdn. :)
Fesor
Знаете, я вот тоже bower-ом не пользуюсь… npm и все такое. а bower мертвый.
DenQ
Почему bower мертв?
Fesor
https://github.com/bower/bower/issues/505
DenQ
И только?
Я бы не говорил что он мертв, я бы сказал, что он возвожно скоро удейт в сторону.
Fesor
ну… в принципе согласен, я драматизировал. Но вы почитайте конец дискуссии, там просто проблемы с поддержкой тулы, на нее забили.
bromzh
А зачем использовать 2 инструмента (npm и сабж), выполняющих одинаковую задачу?
Сейчас js становится всё больше и больше изоморфным, граница между платформами (браузер, нода, etc) всё больше размывается и нет смысла разделять библиотеки на фронт и бэк.
Fesor
Ну например если фронтэнд — это просто jquery и плагины, то тут преимущества npm перед bower уже не так очевидны.
Delphinum
А если frontend зависимости собираются в один файл внутри какого нить gulp и нужно четко разделять frontend и develop зависимости, то таки bower решает.
Fesor
Вот как раз таки npm тут решает больше.
Delphinum
А уже есть хорошая замена столь ненавистному мною main-bower-files в npm?
Fesor
не использоваь bower, использовать для сборки бандлеры вроде webpack или system.js (ну или любой другой бандлер).
Delphinum
А если автоматическая сборка недопустима и нужно точно указать какие зависимости относятся к frontend, а какие к dev?
Fesor
Поясните, для меня это какая-то надуманная ситуация.
Delphinum
Был опыт невозможности использования автосборщиков на подобе webpack (связано с параноидальной безопастностью начальства), потому только автоматизированная, но все же подконтрольная сборка.
Fesor
Я… даже не знаю что сказать. Я бы на вашем месте просто бы заюзал webpack, а в качестве шапочки из фольги просто запускал бы сборщик в docker-контейнере без доступа к сети.
Delphinum
Дело не в сборке, а в ссылках внутри js файлов. Нужно было собрать проект так, чтобы пользователи без соответствующего доступа не могли любым способом найти js файлы, которые для них не предназначались. Webpack собирает проект с записью ссылок на chunks внутрь самих js файлов, а этого нельзя было использовать. Короче запутанная там история.