Currently, I’m in the process of switching back to Laravel after spending many years becoming a specialist and writing a book about Symfony. 

In the past year or so I have noticed the gap between Symfony and Laravel grow wider, companies choosing Laravel over Symfony. Laravel has become more popular, with a developed ecosystem of competent tools (many of which are built on Symfony components) and a community of friendly, open-minded and innovative developers. It feels at times like Laravel is slowly leaving Symfony behind.

But It’s not about the technology, it’s all about the attitude and mentality, which is reflected in the technology. Symfony has been slow to adapt to change in market demand for more contemporary and efficient programming. It seems Symfony has also been plagued by its own success, the backwards compatibility promise has ultimately prevented innovation and change.  

Going back to Laravel reminded me just how quickly you can get the ball rolling with a new application. 

Let’s look at factories and seeders as an example. Define your models, generate your migrations, factories and seeders. Seed your database. So quick! This all comes with Laravel by default. 

If we were to do this in Symfony we would have to require an extra package, DoctrineFixturesBundle to be specific, find and install your own faker as the framework doesn’t have or recommend one, then manually define your fixture logic, this is even syntactically more verbose and complex than the Laravel equivalent. 

User::factory(50)
 ->has(Review::factory()
  ->count(random_int(0, 50)))->create()
   ->each(function (User $user) {       
    $trades = Trade::inRandomOrder()->take(random_int(1, 5))->pluck('id');
    $user->trades()->attach($trades);   
   });

In 8 lines, this is creating 50 users each with between 0-50 reviews and between 0-5 trades (skills). 8 lines! 

Laravel is nearly unrecognizable since I last used it a few years ago. They have built upon the infrastructure that had. I was staggered at the sheer number of variations of combinations you can use Laravel. Laravel/Alpine, Laravel/Livewire, Laravel/React or Vue, Laravel/Filament and many more.

But more importantly there is either an installer that sets everything up for you or clear documentation showing exactly how to use all of these tools with Laravel. They have embraced the change. 

In Symfony, the form component is a perfect example of the opposite of this, it hasn’t fundamentally changed in years even though new and powerful frontend tools have been created since then, like HTMX, Alpine, Inertia and so many more. In Symfony now, it really feels like you're fighting the framework to integrate these tools effectively. 

The Symfony community loves to play the unopinionated programming card, stating that it’s not our business what or how people use the components or what with. Yet, officially they are still pushing Stimulus in their documentation. They mention React and Vue, but there is absolutely no reference to the aforementioned JS packages, why not? 

Don’t get me wrong, Stimulus is great and I’ve used it a lot! But let’s be honest, even that is feeling a bit clunky and verbose compared with Livewire, Alpine or HTMX. 

Of course, some particularly dense people will be shouting that these are Javascript libraries, nothing to do with Symfony. Well, Symfony doesn’t exist in a vacuum, it’s part of a larger ecosystem and plugging into that ecosystem will determine its popularity and success. 

The introduction of Live Components was a fantastic new addition to Symfony, but I hate to say it, but it really just feels like a bad copy of Livewire. 

For example in Laravel you can route directly to a Livewire component. In Symfony you still have to go through a controller render a view and then add the Live component to that view. Then you don’t know if you are using a controller or a live component to handle an event. 

Let’s look at something more PHP specific. I wouldn’t be surprised if the development speed was notably faster in Laravel, I know it is for me. I think this is born out of mentality. In Symfony, it feels like you have to learn the framework specifics, before you can actually build anything. 

Whereas in Laravel it feels like it’s a tool for building stuff, the focus being on making cool things, not learning the Laravel specifics. This is highlighted in the Router, give the get() method an array or FQCN, the framework will figure it out.

Route::get('/', UserSearch::class)->name('services');
Route::get('/, [UserController::class,'index'])->name('services');

The most notable release that Symfony has had in the past couple years was the Scheduler component. This was a highly demanded and anticipated component, the community had been pleading for it for years. Laravel has had this functionality since version 5, back in 2015. The Symfony Scheduler component was released in mid-2023.

There is one clear and jarring difference between Symfony and Laravel. It seems Laravel threw the book out on this one. Symfony definitely adheres to better coding practices. 

Let me be clear, I love Symfony and wish only success for the project. This article is not a hatchet job on Symfony. But obviously there are clear issues with adapting to contemporary demands.

Before even publishing this article, the Symfony community's reaction is depressingly predictable. Completely ignore or outrage that a lowly peasant such as myself would question their approach or methodology. Rather than starting genuine dialogue in which we could collaborate and bring about more than surface value changes. But we all know that in its current form Symfony can not practically incorporate real change.