Symfony: the Myth of the Bloated Framework

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 scenesOnce 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.

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.

Conclusion

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.

Credits and further reading, viewing:

  • Iltar van der Berg

    Regarding security and forms, I’ve written a few posts about this on http://stovepipe.systems, feel free to check it out. Once you get the hang of it, they are really easy.

    • aminemat

      Thanks! I usually manage to bind them to my will, it’s not not painful though!

  • Peter Sedik

    > An ORM is a tool that solves 80% of your problems. For the other 20%, write your own queries!

    You can do this of course, but this can then easily break certain OOP design patterns and established good practices. For example, when an experienced developer works on a large projects with many participants, he can make certain assumptions just by looking at the OOP model. And suddenly, you stab him in the back by introducing some hack to circumvent the ORM design patterns presented in the 80% of the codebase. Of course, sometimes it might be perfectly justified, but I also understand developers who don’t want to go the route you are suggesting. It then may be less confusing to not use ORM at all.

    (But overall, I agree with the spirit of the article.)

    • aminemat

      I totally agree, but writing your own query does not mean you’ll work with PHP arrays! you can hydrate your objects manually or even let Doctrine do that for you, you should always expect valid domain objects no matter how they were fetched from the database.

    • gopal

      I totally agree with you and i also used ORM, trully say its awesome and it makes my work too easy..

  • Actually I managed to achieve everything with Doctrine 🙂 at times it was difficult but it is a matter of learning..and the gain is huge here..great article though..I had exactly the same issue when deciding on our API framework..and thanks god we went with symfony instead of a micro framework..in long term you see why it is so useful

  • phan7om

    How about it’s request performance? For symfony it is normal for about 2-3ms+ per request even in production with composer –no-dev –optimize-autoloader and opcache configured, what else can I forgot? Many other frameworks much lighter and feel good on weak hardware on same tasks.

  • saka

    Fucking noobs. Stick this in your head: PHP does not have annotations.

  • Reinier Pelayo

    I agree with the verbosity of it and how it sometimes becomes the killer feature. I can always abstract the verbosity into a service and achieve the same ‘magic’ other frameworks provide by default and that’s the beauty of it. I can bend it to my will instead of overwriting, which sometimes proves harder to do if it’s already abstracted by default.

  • Nordine Bittich

    Symfony was my very first framework, and I thought it was the best until I’ve discovered other frameworks such as Spring boot in the java world. You should try it, Convention over configuration, and if you want to customize something, you can do it easily, either by changing the default configuration properties, or by overwriting the default configuration itself (and I never had to do it, properties is enough)

    Developing in symfony is painful specially when you don’t use it everyday. After two weeks in another project, do you still know how to configure a custom service? I didn’t. I always had to go back to the documentation in order to understand what I wrote two weeks before. I like a framework when it doesn’t try to make me an expert of it.