It really depends on your goals and how much you care about the architecture/maintainability of your codebase over time...
I'm a DevOps engineer working with teams of php Devs. If it were up to me we'd be using symfony, but the Devs need to make their own choices (and possibly mistakes) and chose laravel.
The biggest reason for choosing symfony over laravel for me is that, although laravel is alot quicker to build with (there's alot less 'plumbing' to be done). It makes it far too easy to write code that is very hard to maintain, and has poor separation of concerns.
For instance, the facades and app->make function in laravel allow you to utilise any service, be it a database, a queuing system, or a redis cache from ANYWHERE in the application. Without highly experienced developers keeping an eye on this, you'll tend to see things like database calls being made from blade templates. This is horrible to debug and pretty much destroys the concept of MVC (which most php Frameworks are designed to follow).
Also, eloquent is a huge pain due to model class structures not being very explicit. What I mean here is that if I wanna know which fields exist in an object, I can't just look in the class definition and see the class properties; I end up having to look in migration files to see the name of the public property that needs changing (if your lucky there may be a few arrays, with some strings in which are the property names). Also if you have alot of business logic associated with your models such as when I set X value on this model it should affect its y value, you're gonna have to create a lot of wrapping services to encapsulate logic which should actually exist in the model itself (normally in setter methods). Otherwise you find yourself duplicating logic all over the shop.
Dont get me wrong, laravel can be an awesome framework to use, but you need to learn to ignore some of the more standard practices in laravel...and use doctrine instead of eloquent. Seriously, I can't state enough how much better doctrine is.
The way I always try to explain why I'd choose symfony over laravel is this: symfony requires more plumbing than laravel, but this plumbing is a necessary evil which helps ensure a healthy codebase. When using symfony you have to think alot more about 'how do I access that service from here', and then do it through proper channels (i.e. dependency injection) as symfony only really allows things to be done in certain ways, whereas in laravel you can just use a facade from anywhere.
I know I'm slating laravel alot here, but I do see laravel being suitable for an agency that will throw a site up somewhere and then forget about it...if you're gonna be maintaining it yourself forever and are bothered about a well structured codebase, symfony is the one.
As a bit of background, I've worked on large scale e-commerce sites in both symfony and laravel. The symfony site, was pretty standard symfony (with some problem areas mostly due to poor oversight and rushjobs; not the framework). The laravel one required quite alot of restructuring to meet the requirements for speed of delivery whilst keeping clean code (try implementing Domain driven design in laravel;not fun). And oh yeah, you can probably guess, we replaced eloquent with doctrine.
No framework can help lame developers from writing terrible code.
I've seen people without experience tricking Java & Spring. It was blood and sweat, but they did it :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It really depends on your goals and how much you care about the architecture/maintainability of your codebase over time...
I'm a DevOps engineer working with teams of php Devs. If it were up to me we'd be using symfony, but the Devs need to make their own choices (and possibly mistakes) and chose laravel.
The biggest reason for choosing symfony over laravel for me is that, although laravel is alot quicker to build with (there's alot less 'plumbing' to be done). It makes it far too easy to write code that is very hard to maintain, and has poor separation of concerns.
For instance, the facades and app->make function in laravel allow you to utilise any service, be it a database, a queuing system, or a redis cache from ANYWHERE in the application. Without highly experienced developers keeping an eye on this, you'll tend to see things like database calls being made from blade templates. This is horrible to debug and pretty much destroys the concept of MVC (which most php Frameworks are designed to follow).
Also, eloquent is a huge pain due to model class structures not being very explicit. What I mean here is that if I wanna know which fields exist in an object, I can't just look in the class definition and see the class properties; I end up having to look in migration files to see the name of the public property that needs changing (if your lucky there may be a few arrays, with some strings in which are the property names). Also if you have alot of business logic associated with your models such as when I set X value on this model it should affect its y value, you're gonna have to create a lot of wrapping services to encapsulate logic which should actually exist in the model itself (normally in setter methods). Otherwise you find yourself duplicating logic all over the shop.
Dont get me wrong, laravel can be an awesome framework to use, but you need to learn to ignore some of the more standard practices in laravel...and use doctrine instead of eloquent. Seriously, I can't state enough how much better doctrine is.
The way I always try to explain why I'd choose symfony over laravel is this: symfony requires more plumbing than laravel, but this plumbing is a necessary evil which helps ensure a healthy codebase. When using symfony you have to think alot more about 'how do I access that service from here', and then do it through proper channels (i.e. dependency injection) as symfony only really allows things to be done in certain ways, whereas in laravel you can just use a facade from anywhere.
I know I'm slating laravel alot here, but I do see laravel being suitable for an agency that will throw a site up somewhere and then forget about it...if you're gonna be maintaining it yourself forever and are bothered about a well structured codebase, symfony is the one.
As a bit of background, I've worked on large scale e-commerce sites in both symfony and laravel. The symfony site, was pretty standard symfony (with some problem areas mostly due to poor oversight and rushjobs; not the framework). The laravel one required quite alot of restructuring to meet the requirements for speed of delivery whilst keeping clean code (try implementing Domain driven design in laravel;not fun). And oh yeah, you can probably guess, we replaced eloquent with doctrine.
A Great saying.
This right here is a fantastic comment. This is very helpful, and mirrors some of my own thoughts.
Thank you kindly for taking the time to write this. I think this really tipped the scales for me toward Symfony.
😁👌
No framework can help lame developers from writing terrible code.
I've seen people without experience tricking Java & Spring. It was blood and sweat, but they did it :)