Why is symfony better for long life big enterprise apps than laravel?

I heard this multiple times. I discussed this with some laravel people and they say "it's just not true".

What I pointed out as well, is that there are more symfony jobs than laravel. Then I got pointed out that this isn't the case either.
Which seems to be true if you check, say indeed in the USA

~ 500ish

~ 1500ish

we see a factor of 3 of difference there.

this isnt the case in germany

~ 1700ish

~ 1900ish

or switzerland
with 90ish jobs for symfony and 60ish jobs for laravel

back to topic.

Why is symfony considered better for long life big enterprise apps than laravel? And do you agree?

I know this is subjective. But subjective answers are more than welcomed.

8 thoughts on “Why is symfony better for long life big enterprise apps than laravel?”

  1. We Symfony itself is a collection of components and bundles. All of these pieces are well tested by time.

    On the other hand, more and more open source projects are built on top of Symfony. This makes me automatically eligible to work on those projects apart from pure Symfony projects.

    That’s why I consider Symfony good for life long enterprises projects and as a life long skill set.

  2. Went through a debate while trying to pick a stack for a different framework recently.

    One side tried pointing out the number of jobs, npm/github activity, etc.

    Unless one is dying or has little traction in the market then activity numbers are irrelevant. As a symfony dev I’d go to work for a laravel shop and vice versa. So jobs are irrelevant.

    Ultimately it should boil down to what the team is most comfortable with and if they don’t have a ton of experience then everyone expected to work with the framework should test them both out. Create projects, create a page, create entities, etc. and work together on a final decision.

  3. Other commenters have made for arguments, I just wanted to add that laravel actually uses Symfony components.

    Laravel had a great headstart with laracasts providing a nice easy way to learn it, Symfony is catching up in this regard.

    “Laravel (Projects using Symfony)” https://symfony.com/projects/laravel

  4. Technical points aside, The amount of timeless tried tested tools laravel has slapped some css on and rebranded as “innovation” kills me slowly..

  5. A bigger project means more complexity. Handling complexity involves more advanced architectures, software designs than a simple Layered, CRUD framework with an MVC delivery mechanism. Example buzzwords: DDD / Hexagonal / CQRS / Event Sourcing, Messaging, SOLID, Data mapper, etc. You can do these with Symfony, but not easily with Laravel.

    Edit: with some of these design principles and architectures the Framework becomes only a dependency of the application, just like any other dependency, which is a good thing when you dont want to reimplement the whole business logic and everything every few years a Framework becomes obsolete.

    Symfony documentation contains many antipatterns, but the Framework itself is very capable and makes it easy to make itself only a dependency.

  6. As a Symfony developer for “enterprise”, when it comes to PHP, everything it does and how it goes about it just makes the most sense to me and is so battle proven and time tested.

    I’ve spent the last two years finding something else, and I’ve been everywhere from node to python to ruby to dot net, and so many frameworks for each one.

    Just the other day my boss and I discussed reviving the old Symfony codebase and it was SUCH a treat. Yeah I’m super familiar with it, and yeah I could be immediately productive with it, but it was such a treat to come back to the basic architecture that Symfony encourages. Everything in it makes sense. It might not be the fastest workflow, Laravel does have that in spades, but you can have a higher degree of confidence that what you’ve produced with Symfony and it’s systems will work and work for a really really long time. Longer than it probably should haha

  7. Also Symfony has an army of OS developers behind it and every change is discussed and monitored.

    I was working with Laravel once and I remember Taylor making some changes that were breaking backward compatibility, without marking it properly…

    So I would never trust Laravel again. It’s too unstable, too unreadable and there is a lot of magic going on under the hood like people already said.

    Laravel might be good for some small projects that You want to make fast. But definitely not for enterprise kind of web application.

    And actually same goes for Doctrine – Doctrine makes us developers lazy and there is some magic going on on its lower levels as well so for bigger apps, debugging or fixing it might be horrible experience.

  8. Though both Laravel and Symfony are excellent choices for enterprise-level applications, we believe Symfony is a better option for stability and long-term support. Laravel is a relatively newer framework (first released in 2011), while Symfony has been around since 2005. So, in terms of stability, Symfony is dependable.

    The Laravel community is also not as large as the Symfony community (in EU anyways), which means fewer people are available to help with development and support. Another advantage of Symfony is that it is supported by SensioLabs, a company founded by the creator of the Symfony framework. You can be confident that SensioLabs will be around to provide long-term support for the framework. So, if you are looking for a stable and supported framework for your enterprise-level application, we recommend Symfony.


Leave a Comment