Pull to refresh

Comments 98

Собственно, почему не взять лучшее из обоих фреймворков? Laravel дает простой и удобный скелет для приложения и у него действительно не лучший AR, почему не сделать бридж? Тоже самое с компонентом Auth — он легко расширяем. В итоге оба сообщества получат плюсы: качественные и более функциональные компоненты для ларавел и приток новых людей в сообщество феи.

С ReactPHP все очень сложно: текущая «стабильная» ветка не умеет в загрузку файлов, а в разрабатываемой планируется реализовать хранение в потоке (памяти). Учитывая, что сейчас все реализации загрузки так или иначе используют работу именно с файловой системой (проксируя move_uploaded_file, is_uploaded_file и т.п.) ждет секс для обеспечения совместимости, либо блокирующий процесс сохранения файла на диск.
Собственно, почему не взять лучшее из обоих фреймворков?

image
Загрузку файлов в отдельный микросервис со своим API и блэкджеком желательно убирать.
1) Во владении русским языком Вы уступаете даже Вите АК. Вы могли, хотя бы, авто-корректором каким-то пройтись?

2) «Это число недавно чуть уменьшилось для фреймворка в целом так как вышли 3 новых компонента, к которым пока еще и документации нет, и тесты там только в процессе, но через короткое время вновь будет 100%»

Тесты пишутся перед написанием кода, документация тут не причем.

3) «PHPixie использует ПХП как шаблонизатор, а это означает что все привычные функции например ucwords, substr, trim итд. уже доступны и новый язык учить не придется»

Не совсем уместное сравнение — Вы можете вставлять чистый PHP (не ПХП) код в шаблоны Blade.

4) «Тут у нас вновь разница парадигм. Laravel как более монолитный фреймворк предоставляет возможности байндинга к моделям, позволяя полностью пропустить код контроллера»

Это семантическая бессмыслица. Laravel позволяет вместо имени контроллера передать closure, и это не имеет никакого отношения ни к байндингу, ни к монолитной архитектуре (которой у него нет).

Во владении русским языком Вы уступаете даже Вите АК. Вы могли, хотя бы, авто-корректором каким-то пройтись?

Уже по ходу прошелся, щас еще попробую =)

Тесты пишутся перед написанием кода, документация тут не причем.

Не все. Я например сначала делаю функциональные тесты высокого уровня, которые просто запускают все и проверяют результат. Это позволяет мне дальше думать над архитектурой. Когда архитектура уже готова можно углубляться в юнит тесты. Глупо писать юнит тест для класса, который я завтра удалю совсем и разобью на три. Конечно тесты в стиле сохранится ли что-то в БД вообще хороши всегда. Если взглянете на тесты к ОРМ, там отдельно есть функциональные которые пишут и читают с БД и отдельно юнит, которые тестируют сами классы.

Не совсем уместное сравнение — Вы можете вставлять чистый PHP (не ПХП) код в шаблоны Blade.

Это не считается хорошей практикой. И для поддержки блоков и наследования придется использовать блейд все равно

Это семантическая бессмыслица. Laravel позволяет вместо имени контроллера передать closure, и это не имеет никакого отношения ни к байндингу, ни к монолитной архитектуре (которой у него нет).


Нет, если вы все таки прочитаете мануал, там четко пишет что при такой конфигурации роутер сам догадается найти пользователя по айдишке и потом передает его в метод. То о чем вы говорите совсем другое.

UFO just landed and posted this here
Может у нас с вами разное понятие юнита. Для меня оно классическое, это один класс. Когда вы пишете например ОРМкку, глупо начинать писать тесты для какого-то маленького класса который например хендлит джойны. Вы сначала напишете один spike-тест, например который получает юзера по айдишке и будуте понемногу рефакторить код пока вам не понравится архитектура. Когда все такие хай-левел тесты пройдут и архитектура вас устроит, вы сможете спустится на уровень ниже и начать тестировать и твикать классы в стиле парсера.

Как раз такими маленькими тестами классов и получается вытянуть покрытие к 100%. А вот эти хай-левел тесты которые проходят через всю систему я держу только для рефакторинга и кавередж ними не считаю
UFO just landed and posted this here
Потому-что на следующий день сутра ты поймешь что надо было сделать совсем по другому. Я ОРМ этот раз наверно 20 переписывал. С первого раза придумать нормальную архитектуру и протестировать можно разве-что CRUD всякий. А когда пишешь темплейтинг тебе свежие идеи лезут одна за другой. И тут важно каждую попробовать и отобрать лучшую, тут и помогают тесты высокого уровня, так как они всегда остаются. А вот если я сегодня начал делать подгрузку связей джойном, и напишу тесты для правильных джойн запросов, а завтра решу что лучше было сделать без джойнов совсем а по айдишкам, то тесты запросов уже тоже можно выбросить, так как этого класса даже не останется. А вот если тест выского уровня и просто проверяет все ли подгрузилось, то ему все равно как я имплементировал.

И вот когда уже я точно знаю какой подход выбрать я напишу юнит тесты.
UFO just landed and posted this here
А думать то как? На стену смотреть?
UFO just landed and posted this here
Отличное сравнение, вы сэкономили мне уйму времени.
Вот бы еще 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 намного популярнее именно в СНГ?
  • Потому что русскоязычное сообщество сильное.
  • Потому что у него всегда была нормальная документация на русском.
  • Потому что я и другие члены сообщества хорошо ездят по конференциям.
  • Потому что у нас технари копают сильнее, ценят стабильность и меньше ведутся на маркетинг.
Намного лаконичнее получилось, мне бы так писать =)

Не надо, у тебя тоже вполне годно получилось. Я впервые услышал реальную критику Laravel (в плане безопасности), вполне себе годный аргумент.

Роутинг. Хорошо настраивается, мощный.

Завязывайте… Я чуть чай на монитор не выплюнул =)
Роутинг в yii — это одна из худших частей фреймворка. Он просто никакой.


В остальном — всё верно.

А можно аргументы? Ну там примеры из других фреймворков, например.

Тоже хотелось бы увидеть аргументированный ответ. И о какой версии идет речь?
С роутингом в Yii и Yii2 ни разу не сталкивался с вопросами и проблемами, действительно гибкий и мощный.
С чем мне пришлось помучатся во второй версии, так это с механизмом публикации Assets. На мой взгляд перемудрили немного.

А что не так с роутингом в Yii2 на ваш взгляд?
Возможность одним правилом описать целый набор однотипных роутов — считаю преимуществом.
Не хотите — конфигурируйте менеджер используя явные правила как в Laravel.
Фича с обработкой роута через колбэк — не аргумент, потому что нужна она чуть меньше чем никогда.

Фича с обработкой роута через колбэк — не аргумент, потому что нужна она чуть меньше чем никогда.

Фича с группировкой роутов ($router->group) нужна более чем всегда. А там коллбек. ;)


P.S. Второй аргумент декларации роутера принимает callable, внутри ларки синтаксис Class@method является расширенным вариантом callable псевдотипа. Всё пролетает сквозь контейнер и отсюда магия с дабл диспатчингом любой возможной функции, хоть коллбека, хоть метода контроллера.

Группировка в Yii тоже есть:


new GroupUrlRule([
     'prefix' => 'admin',
     'rules' => [
         'login' => 'user/login',
         'logout' => 'user/logout',
         'dashboard' => 'default/dashboard',
     ],
])

Группировка роутов в yii2 тоже есть )

Совместимость если и ломаем, то очень осторожно. Обновляться обычно можно даже ничего не перепроверяя.

Нужно было через композер поставить расширение, обновился весь проект, все сломалось, пришлось откатывать. Так что не всегда это работает.
При сильном желании можно использовать тот же Doctrine.

Можно, сейчас так и работаю, но не нравится. Миграции у ларавел больше понравились, на yii мало с миграциями работал

В целом хочу сказать что фреймворк хороший, но мне ларавел больше понравился, видимо потому что лично мне проще было его изучать
В случае с Yii, как и Yii2 всё же лучше хранить версию самого фреймворка жёстко и обновлять по мере необходимости. С Yii2 проблем с тотальной несовместимостью не встречал. В целом же, если в проекте есть тесты, то всё решается.
Нужно было через композер поставить расширение, обновился весь проект, все сломалось, пришлось откатывать. Так что не всегда это работает.
Со времён выхода первого стабильного релиза, максимум приходилось рефакторить проект внедряя новые возможности в старый код. А чтобы что-то ломалось — не помню.
С какой и на какую версию вы обновлялись, и что именно сломалось после обновления у вас в проекте?
Сейчас стоит 2.0.7-dev, обновлялась скорей всего до текущей, какую ошибку выдавало к сожалению уже не помню. Не исключено что это могло быть связано с несовместимостью расширений. Разбираться не было времени, поэтому по времени дешевле оказалось откатиться, и найти способ обойтись без того расширения

Да, похоже самая большая беда в нехватке времени, или в нежелании инвестировать его в изучение инструмента, которым пользуешься. Если потратить это самое время и разобраться, как правило, все становится понятно, а инструмент начинает приносить дивиденды в виде стабильно работающих проектов и легко масштабируемого кода.


И, опять таки, не стоит использовать dev-сборки в своих проектах. Для этого нужно держать руку на пульсе: хорошо знать фреймворк, и следить за тем, что в этот момент происходит на гитхабе.

Да, похоже самая большая беда в нехватке времени, или в нежелании инвестировать его в изучение инструмента, которым пользуешься. Если потратить это самое время и разобраться, как правило, все становится понятно, а инструмент начинает приносить дивиденды в виде стабильно работающих проектов и легко масштабируемого кода.

Согласен, но лично мне проще учить инструменты на реальных задачах, сколько не пробовал изучать ради изучения — ничего не получалось.
И, опять таки, не стоит использовать dev-сборки в своих проектах. Для этого нужно держать руку на пульсе: хорошо знать фреймворк, и следить за тем, что в этот момент происходит на гитхабе.

Ну тут мне уже не приходилось выбирать, проект достался от другого разработчика, предполагалось что он им будет заниматься, но что-то пошло не так и «волчок» указал на меня
Согласен, но лично мне проще учить инструменты на реальных задачах, сколько не пробовал изучать ради изучения — ничего не получалось.

Разумеется, только на реальных задачах в процессе разработки.
Но вы же и не на хостинге пишете код? И обновляете расширения тоже локально, чтобы убедиться в стабильности, перед тем, как делать это на боевых серверах?

Бывает, конечно, что какие-то недокументированные части признаются багом и фиксятся. Смену поведения, даже неофициального, мы описываем в UPGRADE.md. Вообще вся команда стала за последний год гораздо серьёзней относиться к обратной совместимости.


Миграции, если вы работали с ними на старте 2.0, были другими совсем. Сейчас они намного более приятны:


$this->createTable('news', [
    'id' => $this->primaryKey(),
    'title' => $this->string()->notNull(),
    'content' => $this->text(),
]);
Я не против миграций, они мне и в прошлом виде вполне симпатизировали. Просто на текущем проекте предыдущий разработчик адаптировал доктриновские аннотации (ему так было удобней), поначалу и мне казалось удобным, но современем начало жутко раздражать
Да, сейчас все работает, как вы и говорите, да и файл UPGRADE помогает, а если нет — есть система логгирования ошибок.
На моей памяти единственный раз что-то ломалось при обновлении на бете где-то за полгода до релиза (что-то там менялось с csrf-метатегами в layout), но на то она бета — это был домашний проект для обучения, хотя искать ошибку пришлось немало.
Blade и Twig — это две большие разницы. Twig это классический компилирующий template engine, blade — это макропроцессор (фактически сахарок для php-шаблонов), и в нем php-функции как раз-таки можно использовать.

Я, правда, считаю это недостатком: из шаблона не должно быть вообще возможно получить php-ошибку.

Вот-вот, смысла в blade имхо нет никакого.

Смысл — в автоэскейпинге переменных. Это важная вещь, которой лично мне только и не хватает в yii2 с pure php шаблонами — безопасность страдает, если разраб торопился.
Ну уже заставить себя написать в стиле

<?=$_($var)?>


вместо просто

<?=$var?>


не так уж трудно. На самом деле если не доверять разработчикам что они вывод нормально сделают, то к базе запросы их пускать писать уж тоже нельзя. Еще сделают Delete запрос без условий и продакшн потрут
Если есть возможность сделать написание безопасного кода легче чем опасного — это надо делать) Html::encode иногда писать долго и скучно, особенно сто раз подряд…
Кстати, относительно недавно (что ли в анонсе последнего обновления Yii, что ли где-то около) кто-то в комментах жаловался, что AR оказался небезопасным и позволил сделать 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>
Без short tags, которые deprecated уже, страшненько будет. Ну и наверняка это не очень эффективно работает, всякие там вложенные output buffers… Но так-то неплохо, только $_($link), наверное.

Но это еще простой случай. А вот так могете?
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 — няшка :)
Ошибся, да. Пока discouraged, верно. Но обсуждение такое было, точно помню, ну и discouraged часто плавно перетекает в deprecated. Видимо, пока не решились. Но избавление от ини-настроек, влияющих на язык — штука правильная и нужная.

Короткие теги только для нативных php-шаблонов и нужны, если ими не пользоваться — то и не заметишь.
С чего это они discouraged? Вы сами придумываете проблемы.

А насчет скорости работы, бенчмарки посмотрите =) И кстати и ларавел и симфони используют output buffering для рендеринга как и пикси. Так что выдумки все это
PHP 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-ом.
Вот так прочитайте это предложение еще раз. Он discouraged потому что у кого-то он модет быть выключен. Тоесть если вы делаете плагин для вордпреса который должен на каждом хостинге заработать то конечно же лучше полный тег писать. Но если это ваш сервер то вы сами его настраиваете.

Это то же что сказать что все фичи PHP7 discouraged так как не у всех он есть.
Проблемой является сама настройка, меняющая поведение языка: неважно, удобная или нет, важно, что настройка. register_globals и magic_quotes, к счастью, выпилили. Потом на очереди отвратительный mbstring overload (очень на это надеюсь), а там и до short_tags дело дойдет. Просто потому, что настроек, меняющих язык, быть не должно. По register_globals тоже плакали, а сейчас вспоминают только как о недоразумении.
register_globals и magic_quotes выпилили суто по причинам безопасности а не потому что они меняют язык. При чем здесь короткий тег?

В любом случае, вы всегда можете просто использовать длинный, в чем проблема собственно? Кстати тег "<?=$bla?>" теперь доступен всегда вне зависимости от ini настроек.

Так что даже если использовать доинный тег то тол ко в ифах и форичах придется
magic_quotes выпилили, потому что он портит входные данные и вообще глупость несусветная.

Короткий тег конфликтует с xml и некоторыми другими шняжками. Теги <?= и <?php не имеют такой привычки. Отсюда отключение по-умолчанию и рекомендация отключения оных в самых популярных стандартах, взять хотя бы PSR.


Лично я воспринимаю современный код без PSR как код, написанный ньюфагом, которому не стоит доверять. Естественно это чисто психологическое и вполне возможны иные ситуации, но почти уверен, что у большинства тех, кто читал и использует код популярных open-source решений (Zend, Laravel, Symfony, etc) примерно такие же ассоциации.

Ну во первых как я уже писал раза 3 можно просто писать <?= и <?php. Но на самом деле распространять PSR на файлы темплейта как то уж очень притянутотак как они писаны для кода а не для шаблонов. Это то же самое что с endif, в коде класса он совсем ни к чему и руки за такое ломать, но для шаблона самое оно.
Кто генерит XML темплейтингом? гораздо проще ведь использовать 300 библиотек для работы с ним. Зачем вам в XML лейауты и блоки??

А почему бы тогда html так не генерировать? Он (html), как бы совместим с этими 300 xml библиотеками. И шаблон обязан быть с лайаутом и блоками?


Я просто попросил привести пример sitemap.xml, т.к. разделение логики и представления (где сайтмап — это очевидно шаблон представления) — это хорошо. Или я ошибаюсь?

Так в хтмле есть лейауты и блоки. ХТМЛ это язык разметки, а 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>

Получилось вполне читаемо и красиво. А теперь предлагаю запустить приведённый код и наслаждаться фатал эррорами.


После этого можно ещё раз пересмотреть моё предложение по поводу того, что не стоит себе самому палки в колёса ставить.


Мне просто хотелось свою мысль на практике как-нибудь донести, раз объективная аргументация почему это плохо (против вашей "а почему бы и нет" и "это же короче на 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 файлы
<? foreach($urls as $url): ?>


можно еще короче
<?foreach($urls as $url):?>
Кстати, использовать
<?xml version="1.0" encoding="UTF-8"?>

в шаблонах PHP тоже не стоит. :) А вдруг у нас включены короткие теги :)

И длиннее минимум на 4 символа, так как еще нужен пробел.
Будет нормально работать при отключенных коротких тегах.

Не будет, т.к. см.предпоследнюю строчку приведённого кода. ;)

Хм, я куда-то не туда посмотрел, но мне казалось там был только один исходник. Прошу прощения — не выспался, не заметил.

Для новых проектов — никакого, твиг лучше (чем армяне).

А вот легаси портировать проще на blade.
Внесу свои пять копеек и скорее всего совершу суицид. Сразу хочу отметить, что ни чего не имею против какого либо фремворка и это хорошо, что их много конкуренция полезная штука, да и это всего лишь инструмент. Не так давно выбирал фреймворк для enterprise смотрел много фреймворков в том числе и PHPixie, ниже не большое заключение:

CodeIgniter — слишком прост, много писать кода на каждый чих и на то время не понятная судьба с развитием и поддержкой
Kohana — чуть чуть дальше ушел от CodeIgniter но проблемы все те же.
PHPixie — нет документации в коде, нет документации по компонентам, маленькое сообщество и на тот момент очень мало функционала, возможно это результат недостатка документации.
Yii — подкупает всех простотой и заявленной высокой производительностью, но на самом деле при его использовании enterprise у всех разработчиков только боль, страдания и кровь из глаз от обилия написанного кода и html внутри PHP классов.
Laravel — не стабильность интерфейсов, переписывать проект с каждым релизом не самая лучшая идея.
Symfony — высоковатый порог вхождения, но это решается отличной документацией и большим сообществом. Большое количество поддерживаемых дополнительных компонентов. Собственно его и выбрал и используем уже достаточно давно и довольны как слоны.

Меня всегда удивляет, что большинство разработчиков фремворков оперируют скоростью работы, но вот скорость разработки ни кто не учитывает и как показывает практика серверов доставить всегда дешевле, чем оплачивать кучу часов разработки проекта, особенно кода важно запуститься «вчера». Так же по личному опыту могу сказать, что 98% случаев медленной работы приложений связанны с не продуманной архитектурой, не умением готовить те инструменты которые используются и ну куда же без этого — кривыми руками разработчиков.

Всё верно описано. Но потерялся Zend, который давеча релизнулся в третью версию и стал почти удобоваримым.


P.S. Из перечисленных я бы выбирал между последним и предпоследним:


  • Лара на порядок удобнее симфони, но и постоянно апается (это и плюс и минус), последнее время они перестали сильно ломать обратную совместимость, так что с 5.1 можно запросто перелезть на 5.3.
  • С точки зрения симфони — очень надёжная штука, код, написанный под 2.4 вполне можно завести (с пинками конечно же, но не такими как в ларке) под 2.8. В этом плане (совместимости) проделана огромная работа.
На самом деле в Symfony совсем не высокий порог вхождения, а уж если по изучения Laravel (только именно изучения, в том числе почему и как устроен) то вообще расплюнуть.
Конечно Laravel подкупает своими фишками, на нем просто клево что-то делать. А так наверное что-то большое близкое к корпоративным приложениям все же Симфони, средние, стартаперские и большие любительские проекты можно смело на Laravel делать.
А еще мне очень нравится Slim Framework(в связке с Eloquent), быстро, клево, без лишних правил давящих сверху(ну кроме правил кодинга, хотя опять таки частично ).
Я вот не понимаю чего там такого 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 с тысячей бандлов.
Чего там enterprise я тоже не знаю. Модульность зачастую не нужна, факт, но возможность отключить всё лишнее — иногда полезно. В остальном она очень и очень гибкая. Доработать роутинг — пожалуйста, пишешь свой или декорируешь встроенный. Обработчики сессий, кэширование, почти всё можно заменить своим. Кода получается не так много. ORM для сложных sql запросов и не предназначен, он облегчает рутинные действия. Нужен мозголомный запрос — sql всегда лучше, результат по желанию можно привязать к entity и получить сразу объекты. Формы там шикарные — особенно когда нужна вложенность на несколько уровней и коллекции.
От enterprise там пожалуй обратная совместимость. Крупный проект без проблем переезжал c 2.3 на 2.7 и 2.8. Всё работает.
>На мой взгляд любой, даже нормальный, фреймворк — это боль.

+100500.

А можете более подробно описать, с какими проблемами Вы столкнулись на фреймворках?
Не могу с Вами согласиться.
Как минимум, можно использовать минималистичные фреймворки, которые не будут реализовывать тот функционал, что Вам не нужен.

В любом случае, вопросы роутинга, шаблонизации и работы с БД всегда открыты и зачастую достаточно стандартны.
Yii — подкупает всех простотой и заявленной высокой производительностью, но на самом деле при его использовании enterprise у всех разработчиков только боль, страдания и кровь из глаз от обилия написанного кода и html внутри PHP классов.

У нас как-то нет боли в том же Stay.com от обилия кода… что-то мы делаем не так. И HTML внутри PHP классов у нас тоже нет.

Дык боль обычно не от фреймворка, а от бездумного написания кода по примитивным примерам из документации без понимания — с таким подходом и с Laravel, и с Symfony будет боль. Это явно не ваш случай ;)
Yii — подкупает всех простотой и заявленной высокой производительностью, но на самом деле при его использовании enterprise у всех разработчиков только боль, страдания и кровь из глаз от обилия написанного кода и html внутри PHP классов.

НЕ любите кошек? Да просто не умеете их готовить!
Если изначально писать проект на YII как описано в элементарных примерах, не смотря на то, что знаешь чтобы будет нечто большое и сложное — да будет много проблем, если все таки немного сразу подумать над архитектурой и следить по ходу дела — можно и на YII писать большое и сложное.
PHPixie наверное клевый, много раз о нем слышал, но так в деле не пробовал. Нов се же одним из ключевых плюсов в сторону Laravel будет то что он на порядок(а в гугле так на несколько порядков) популярнее. Это существенный перекос, который для меня один из ключевых. PHPixie уже достаточно существует чтобы стать полноценной звездой, но пока не стал, значит не повезло? Или есть другие причины?
Laravel это приятный фреймворк с англоязычным ярким (тейлора одни ненавидят, а другие любят за его деспотичность) хедлайнером, понимающим толк в маркетинге и красивом дизайне. Это большое дело, «русскоязычным» фреймворкам за Laravel не угнаться в ближайшее время, будь ты хоть в два раза лучше :) молодежь, навязанные западные ценности, вот это все… *закуриваю трубку сидя в своем кресле-качалке*
Ну я больше не из-за западных ценностей(вернее вовсе не из-за них), чисто из практических соображений. Вот тот же nginx взлетел, считается нашим продуктом, удобный, авторитетный, проверенный.
А фреймворк, или что другое, не должен быть русскоязычным или американским или еще каким, он должен быть удобный, популярным(а значит извините, но придется развивать прежде всего английскую версию) и интересным.
Ну и повторюсь, PHPixie с виду интересный, просто нет времени да и желания пока что его использовать, впрочем если вы СИЛЬНО советуете, то задумаюсь, но статья меня слабо убедила.
Технически PHPixie лучше сравнивать с Lumen.
Laravel же это немного другая весовая категория.
Почему? Пикся давно уже не микрофреймворк, в ней куча всего из коробки

Тогда предлагаю начать думать хотя бы над докблок декларациями ;)

https://github.com/PHPixie/Framework/blob/master/src/PHPixie/Framework/Components.php

уже есть, не везде, но в самых востребованых местах точно
В статье был упомянуть чат, можно ссылку на него?
UFO just landed and posted this here
Не вижу смыслов в данных статьях.
Ну сравним мы скорость, удобство и т.д.
Но это даст нам только картину для старта а полной версии конечного продукта нет.

Что взять для крупного проекта, что для среднего а что для финансовой архитектуры и т.д.
Как по мне, любой фреймворк выбирается прежде всего из-за своей архитектуры и возможностей. Т.е. сначала надо подумать что у вас будет на перспективе.

Несколько раз встречал проекты, где люди выбирали тот или иной фреймворк основываясь на базовых данных.
Спустя год, упирались в какие то стены, т.к. изначально не продумали.

P.S.
Я вообще люблю создавать приложение из кирпичиков, которые как можно меньше друг от друга зависят.
А так как я фуллстак, то мне удобнее работать с шаблонизаторами типа twig
Несколько раз встречал проекты, где люди выбирали тот или иной фреймворк основываясь на базовых данных.
Спустя год, упирались в какие то стены, т.к. изначально не продумали.


Ну так как бы фреймворк и предназначен, чтобы быстро из стандартных (не самых оптимальных под проект) кирпичиков сложить домик.
Что-то серьезное пишется на самописи (не, конечно можно и бороться с ограничениями фреймворка, докупать сервера).
RLY?
А считается ли самописью фреймворк созданный в недрах крупной компании(или не крупной) для решения своих задач?
А считается ли самописью доработанный до нужд проекта фреймворк?

В какой момент самопись становится фреймворком, а фреймворк самописью?
Кстати, правильное замечание.
Но сторонники мейнстримовых публичных фреймворков считают, что стоит использовать только их и никакой альтернативы не видят.
Также они думают, что невозможно изпользование самописного кода, что для реализации каждой следующей задачи будет писаться все с нуля.
Также они упускают, что эти фреймворки тоже появились, как чья-то самопись.

П.С.
Говоря фреймворк, я подразумеваю публичный мейнстримовый фреймворк.
Sign up to leave a comment.

Articles