я тоже хвалил

просто наткнулся на хвалебную статью про симфони

трешка уже сама по себе чудо )) шанс для цмс снова прикинуться живой ))

а не быть вечно "устаревшей и умершей предыдущей версией modx revo для самых отсталых слоев населения"

странно этого не понимать столько лет находясь в теме ))

Теперь пришло время найти статьи где есть негатив по отношению к симфони. (;

В свое время начал работу с первой версией этого фреймворка с немцами, которые у нас в стране открывали аутсорс-компанию и выбрали этот фреймворк. Потом перешли на вторую и дальше.
По своему опыту могу сказать что мне НЕ нравится симфони именно из-за своего переусложнения всей системы. Сейчас это стало более заметно чем ранее или просто опыта набрался. Разработчики хотели сделать все для идеального кода и разработки, как в Java и у них это получилось - перетащили все что можно и "не можно". Из-за этого разработка превращается в постоянное гугление и чтение документации по самым простым способам разработки. Конечно, когда у Вас мега-память и постоянная работа с этим фреймворком, то, возможно, ему даже можно радоваться. Только это, как по мне, не объективно уже.

Идея с бандлами - условно пакетами с набором готовых решений - сама по себе приятная и пользуюсь многими наработками симфони. В моем composer.js на постоянной основе есть: symfony/console, symfony/filesystem, symfony/finder, symfony/http-foundation, symfony/serializer, symfony/translation, symfony/twig-bridge. Еще пользуюсь swiftmailer/swiftmailer, а т.к. он больше не поддерживается с ноября этого года и его разработчики рекомендуют переходить на symfony/mailer, то скоро еще и этот пакет придется использовать.

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

Все система симфони значительно печальнее в освоении чем тот же ларавель со своим нативным подходом. Симфони изначально предполагал монетизацию и получал большие гранты на работу, помнится даже 6 или 7 лямов $ в свое время от одной организации получил. Т.е. это тупо корпоративный фреймворк со всеми вытекающими последствиями. То что должно было быть простым стало сложным и отнимает времени слишком много для простых и не только проектов.

Интересно

Интересно до тех пор пока не встречаете симфониста, которому все нравится. Есть такие люди, которые обожают боль. ((%
Сразу можно распознать его когда начинается рассказ про симфони как предел качество кода, тестирования, модульности, стандартизации. Очень часто получается из-за этого затягивание сроков разработки и удорожания проекта.
Поставили какой-то бандл? Готовьтесь работать с конфигами, аннотациями - не факт что правильно всё будет работать с Вашей идеей ради которой Вы решили не писать свой код, а поставить этот бандл. ((%

то ли дело слим? 😁

Для своих задач - да, микрофреймворки подходят лучше, чем монструозные full-стек фреймворки. Зачем мне ставить симфони для того чтобы написать API или MVP-проект где важна скорость и дешевизна разработки?
При этом в том же слиме использую проверенные пакеты того же симфони и пишу понятный код, который можно передать человеку не обладающему знаниями по симфони.
Уверен, что объяснить смогу всю систему взаимодействия моего приложения Вам в течении получаса-часа. И Вы сможете что-то добавить в это приложение в течении первого часа.
В симфони чтобы добавить, например, в форму поле нужно в 6-9 местах (конфигах, контроллерах и т.д.) править данные.

ух бля)

Джуну не передашь ;)

Так как он не сможет кодить гугля решение как это можно делать в той же ларавел ;)

А если разработчик адекватный то пофиг :)

От чего же? Был опыт ни с одним клиентом где и джунам все отдают. Даже думаю, что скорее всего именно так и поступают в большинстве случаев. Смотрел кого нанимают и вижу что там редко кто-то реально выше джуна по знаниям, хотя в резюме "сеньёр". (:
Вы не забывайте что приложение уже готовое и, понятное дело, документировано. Т.е. при правках в виде "добавить поле" и т.д. справится и джун.
Ну, и это уже печаль БИЗНЕСА когда он отдает кому-то на доработку ниже уровня нужного для проекта. (:

Обычно, когда архитектура приложения готова, то "кодить находя решение" не нужно. Мы часто стали называть джунами людей, которые не могут <?php написать, а ищут готовое на форумах. Это не правильно, как по мне. Джун должен уметь читать код, знать основные функции, понимать базовые принципы, уметь задавать вопросы. Иначе зачем ему работа?

Сейчас джун это тот кто может нагуглить решение
и выполнить задачу

Сочувствую, в том случае когда Вы нанимаете таких на работу. ((%

Так это еще адекватный :) с этим можно работать а вот когда человек только через 3 дня понимает что написано в задаче и ему 2-3 раза обьясняли что надо :) то это печаль

Стараюсь с такими не работать. (: