At work, we’re trying to choose which PHP framework to use for our next project. As we’re breaking up our monolithic app into services, only micro frameworks were considered by the team. This choice was made to avoid the pain points we’ve encountered using our current full stack framework.
Not all full stack frameworks are created equal, however. Having worked with Symfony before, I proposed it as an option. As expected, I’ve had some pushback from my fellow coworkers. The main reason being that Symfony is bloated and overkill for our needs.
This is sadly not limited to my team. Despite multiple efforts by Fabien–the creator of Symfony–the framework has always had a reputation for being too complex and over-engineered. While the components themselves are very well received and used in many large projects, the full stack framework still has a bad rap.
In this article, I’ll try to show why Symfony is not the bloated framework you think it is. I won’t be talking about building your own framework with the components or using the microkernel trait. Those are fairly well covered by others. I’ll be looking at the big bad standard edition.
Let’s examine some of the reasons for this perception. Most people mention one of these when criticising the framework: Doctrine, Verbosity, or Configuration.
Doctrine is complex/bad/slow
Symfony does not offer a component to interact with a database. Instead, it provides an easy integration with Doctrine, a powerful ORM. The integration is completely optional. You can opt to only use the DBAL as a PDO layer or exclude it completely. However, this doesn’t keep people from blaming Symfony for Doctrine’s “issues.”
Doctrine also suffers the same misconceptions from developers who misuse it. An ORM is a tool that solves 80% of your problems. For the other 20%, write your own queries! A quick google search for “why doctrine is bad” yielded this SO thread where a user complained:
In my latest project, in which I tried out Doctrine, I hit several walls. It took me days to figure out a solution for something that I knew I could have written in SQL in a matter of minutes. That is soooo frustrating.
Instead of wasting those valuable days, why didn’t you write a simple SQL query? Doctrine allows you to write a native query easily. It even gives you tools to hydrate your objects from the results if you’d like.
Another argument commonly used against Doctrine, and ORMs in general, is that they’re slow and you don’t know which queries get executed behind the scenes. Once again this is another false claim by unknowledgeable users. The Symfony profiler, one of Symfony’s best features if you ask me, gives a breakdown of all SQL queries along with their execution time. It even supports AJAX requests.
It’s the developer’s duty to analyse, profile, and refactor their application before it reaches production. If you don’t, please don’t blame the tool.
Symfony is too verbose
Yes, Symfony is verbose. That’s a fact, so I’m not going to delve too much deeper into the topic. All I’m going to say is this: To accomplish any task, no matter how simple, there are steps that need to be accomplished. Symfony, is a set of loosely coupled components that offers you control over these steps. It allows you to change each and every one. Other frameworks use magic in order to appear as “simple” and “easy to use.” I honestly don’t see verbosity as an issue; I prefer being explicit. If typing five more words is an issue for you, you’ve certainly chosen the wrong profession.
//Getting a user by ID in Symfony
//Getting a user by ID in Laravel
Symfony uses too much configuration
Again, this is not completely untrue. Symfony has a lot of configuration and you’ll absolutely be spending some time in YAML or XML files.
How then, should a framework allow you to configure its inner workings? Some choose convention over configuration. While it’s true you wouldn’t have to configure as much of the application, conventions are opinionated by definition. In the end, you’re letting the author of the framework dictate how you write your application.
Symfony makes some assumptions about how you write your application, but configuration provides an easy way to override those assumptions. Additionally, configuration can be written in PHP, XML, YAML, or as annotations in many cases.
Additionally, after the initial project setup, you’ll primarily deal with one config file ( services.yml), where your DI config lives.
Symfony is not a perfect framework. As with any other tool, it has its pros and cons. Even I cringe at the simple mention of the security component, and the form component occasionally makes me want to bang my head against the wall. However, I know that I’m always in control, and overriding any service is as simple as implementing an interface. If I dislike anything, I simply don’t use it.
The framework does not tell me how to structure my app or write my domain model. Do I want to try out a Command Bus architecture? A Domain Driven Design approach? Action Domain Responder? Write your decoupled domain separately then hook it up with Doctrine. If you don’t like Doctrine, use a simple query builder and wrap it in a repository. Hell, write SQL in the controller if you’d like. You’re in control.
Honestly, I think the people who complain about Symfony being overkill or bloated haven’t used it enough or haven’t bothered to learn how it works. If, however, you’ve had a bad experience and have a different opinion, please write a comment below.