NodeJS фреймворк с синтаксисом Laravel

 (и без лапши в коде)

Ну вобщем да, с контейнером еще можно жить, тут не спорю. Хотя на уровне ларавеля симфонийский контейнер не сложнее.
Blade некорректно обрабатывает include — в нем нельзя изолировать контекст
как пример — попробуйте в цикле вставить шаблон с переопределенными секциями.
Основной геморрой был с фасадами и с orm.

franzose согласен на первый взгляд кажется сложно, но только на первый (все новое всегда кажется сложным). Вот вы можете привести конкретный пример сложности в контейнере Symfony или его понимания? Просто единственное что может показаться сложным на мой взгляд это описание структуры конфига (config.yml) через DI Configuration. И опять же, это только на первый взгляд. Все возможные и не возможные примеры описания структуры конфига есть в бандлах для Symfony (у каждого бандла есть Acme\DemoBundle\DependencyInjection\Configuration), нужно просто чуть чуть почитать документацию и залезть внутрь. Сложно говорите? Возьмите PhpStorm + Symfony plugin + конфиги сервисов в XML, вы получаете полноценный автокомплит по всем сервисам и параметрам контейнера в любом месте в вашем проекте! Даже есть в контекстном меню создать services.(xml|yml) за вас! IDE делает половину работы за вас.

Что касается Blade, просто примитивный шаблонизатор. Никаких преимуществ, очередной свой велосипед, почему было не взять Twig, хотя бы Smarty? Многие дизайнеры с ним знакомы, он удобный и легко расширяем, проверен временем!!! Вопрос зачем? Я отвечу, никто не хочет разбираться как добавить какой то там Twig_Extension, можно ведь просто сделать в любом месте приложения (конечно нужно как минимум в ServiceContainer) Blade::extend() и получаем какой то простенький тег. Blade просто не умеет крутых штук, например множественное наследование на сколько знаю там хреново работает, получить весь контент предыдущих блоков не возможно (могу ошибаться, давно не проверял). Blade это просто красивая обертка для использования

<?php echo ... ?>

внутри шаблонов, ведь вы спокойно можете внутри Blade {{… }} вызвать любую PHP функцию или исполнить код. Какой это к черту шаблонизатор? PHP сам по себе изначально шаблонизатор, так чем Blade лучше? Согласен на примитивных задачах вполне подойдет, но я более чем уверен вы не разделяете логику и отображение нормально используя Blade. Вспомнил, там не нет даже тега {% spaceless.%}. Я всегда ставил Twig вместо Blade если была возможность.

Да при желании вообще то к Larvael можно любой компонент или библиотеку прикрутить. Doctrine, Twig, FormBuilder, Yaml есть как пакет для Laravel. Можно запустить Laravel внутри Symfony (есть готовый Bundle), можно запустить Symfony внутри Laravel. Я даже хотел прикрутить Symfony Container в Laravel и настроить двухстороннюю связь между ними и вы не поверите получилось!!! Даже дошел до того что можно использовать любой бандл Symfony внутри Laravel, использовать его сервисы внутри Laravel как будто они зарегистрированы в его контейнере (ну допустим serializer или annotaion_reader). И знаете что? Я просто начал использовать Symfony :)

Геморрой был связан:

1. Для Api есть пакет DingoApi. Как только мы регистрируем провайдер для всего приложения он тупо перезаписывает стандартный ExceptionHandler который будет выводить ошибки как JSON ответ. Уже нужны какие то хаки что бы провайдер подключался только на определенный путь. Т.е в ServiceProvider что то вроде:

if (Str::startsWith(Request::path(), 'api')) {
    $this->app->reg.....
}

Использование Request для определения необходимости подключения провайдера это уже какой то хак, можно конечно в на стороне веб сервера сделать ENV_VAR если путь начинается с /api/ и потом проверять по этому флагу, но по сути какая разница как, какие то хаки начинаются сразу. И да, если мы не подключаем DingoApiServiceProvider на все приложение, а где то в приложении вне /api/ используется что то из пакета DingoApi мы получаем ошибку.

Symfony Serializer в сто раз удобней чем Transformer'ы в DingoApi, тут просто стоит попробовать и все понять самому :)

2. ORM. Да она простая и для блога катит, но это тяжелейший класс который тянет за собой каждая модель. Допустим вам нужно добавить 1000 новых записей, вам что бы использовать их в связях с другими моделями нужно внимание сделать save() на каждой сущности (конечно можем обернуть в транзакцию и все же это не то что предоставляет нам Doctrine, делаем persist() и когда надо flush() при этом спокойно работаем с моделями как будто они в базе...).

Во вторых, честно говоря уже не помню в чем именно было дело, но когда мы пытаемся сделать Translatable, Softdeletebale, Metable и еще что нибудь в одной модели это начинается ПРОСТО АД потому что они жуть как мешают друг другу, все завязаны на события внутри одной модели и т.д, в общем жуть. Конечно если вам надо просто вытащить или положить данные в базу несколько строк вполне подойдет :)

3. Всякие мелочи которые решались каким то костылями потому что иначе никак. И все это вытекает из максимального упрощения кода и архитектуры, он просто не всегда расширяем.

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

Что бы собрать вместе все пакеты которые нужны для крупного проекта придется доставать бубен и плясать. Можно и самому написать все пакеты, так может сразу еще один свой фреймворк? :)

franzose, в целом плюсую, это выглядит как-то так «Все что не Симфони — плохо». Хотелось увидеть нечто иное. И да, ларавел действительно прост, но я не уверен что это его минус. Тем не менееiborzenkov спасибо вам за вашу критику)