> Laravel just has too much magic that will bite you later on.
Especially when that is not explained in the docs or just in a very vague way...
I tried improving the docs by pointing out where magic (e.g. fix naming conventions) is needed and where not, but the mantainer just turned that into vague mush again (after he had even agreed to the changes).
Also if you need any more details that are not in the docs, everyone points you to paid video courses that assume you have a Mac...
That honestly leaves me with a bad taste im my mouth after trying laravel :/
Unless you want to write a ton of transformers, your models will likely know about your database design. If only by virtue of having the same properties.
I think the parent is objecting to the fact that annotations spray this "external" information right in the middle of the controller/model. FWIW, decent tools let you put this info in separate configuration files instead of code annotations, "decoupling" it from the code.
You are 100% right about that. I've nearly tried almost all PHP frameworks, quite extensively I may add and at the end of the day I found that the less framework I use the better and faster my dev is. Now I just use packages from composer as needed and never ever use them anymore.
For me Laravel was a nightmare to use with Vue. Both template engines (blade, vue) use moustache tags so everything has to be declared inside @vetbatim. Then mix doesn't even compare to ease of vue cli imo. Then the nested directory structure was so confusing (was it inside resource folder, or controller folder). I've never been happier since I ditched these opinionated frameworks
Interesting. Coding without a framework is rare these days. I would like to hear more about how you do the basic infrastructure stuff usually provided by a framework:
This is actually something I have been predicting for PHP for a while. Frameworks are beneficial when languages don’t have built in support for the core needs of your task, so those needs a built into the framework and abstracted away.
With both PHP and JS this isn’t the case, which is why you see SO many frameworks for them: all of the parts are already there so the frameworks are mostly just rearranging things. Ruby, Python, Go, etc are general purpose so the frameworks provide a lot more support.
PHP’s biggest hang up for years was lack of name spacing for good module support so EVERY framework had their own version of every core feature you’d need abstracted around its framework naming schema. Can you imagine every framework writing their own database drivers...because that was happening.
As soon as Composer was released it was only going to be a matter of time before the ecosystem started to clean itself up from 9 different ways to install shared code.
PHP's package manager makes it really easy to pull in components a la carte. Similar to OP, I rarely use a large framework like Symfony or Laravel. I have a base application I wrote which I like, and I layer components I trust and whose API fits my preferences as I require them.
Additionally, the PSR project has standardized a lot of APIs (HTTP request/response, logging, cache to name a few), which means if a package conforms to PSR, you get interop out of the box and can quickly swap implementations if needed.
> The only thing you should skip in both frameworks are 'annotations'. But this is easy to do.
If you are using Doctrine the only alternative to docblock annotations is XML because they are deprecating YAML support.
I really hope they build support in the language itself. I can't understand their fierce opposition to a feature every other major object oriented language has. They are only forcing a large part of the ecosystem, everything that is Symfony or Doctrine based, to use the horrible docblock work around.
Trying both Laravel and Symfony I think there is no need for Laravel (anymore). Laravel just has too much magic that will bite you later on.
The only thing you should skip in both frameworks are 'annotations'. But this is easy to do.