At Array 51 we have made a strategic decision to use Symfony 2 as our framework of choice to build custom applications for the projects of our customers and our own products. Honestly, making this choice was not hard. In this blog post we will highlight some of the more important reasons why we currently prefer Symfony 2 over other frameworks such as Zend Framework 2, Laravel, Typo 3 Flow, Aura, …
Just to be clear, we are not trying to start a yes-no-yes-no-… war here, we would just like to clarify the choices we have made until now for anyone who is interested in Array 51 or Symfony 2. :-)
Here are some of the most important reasons for us to choose Symfony 2:
- Great and well maintained documentation
- Clear and consistent standardisation
- Adaptability and flexibility
- Wide spread ecosystem
- Very active and dedicated development team
Allow us to try and clarify and explain our train of thought regarding each item separately below, here we go!
When I (Jasper) was starting out with PHP development without any knowledge of programming whatsover, the PHP.net documentation was really the place I'd spend most of my time. In most cases, each method clearly stated the parameters, response formats, and I was usually able to find many source code samples in the comments section on each documentation page. Combining this with a few very helpful friends allowed me to learn PHP by doing, instead of studying.
From the first releases of some PHP-based frameworks and CMS systems I worked with in the past such as Zend Framework 0.x, Drupal 5/6, and Magento 1.4 most of these solutions didn’t have very extensive documentation or whatsoever when they were launched. Due to this, it was very hard as a beginning developer to dive in and learn the new technology. And the first projects that would be developed in these new systems would sometimes cause a technical debt that you would have to drag with you for the next months/years to come. Simply due to the lack of knowledge, experience and best practices.
Luckily the creators and contributors of these open-source projects really learned a lot from what happened in the past and from each other. Symfony 2 has definitely played, and is still playing a leading role as an example of good documentation, developer education and standardisation.
Out of the box, pretty much all necessary tools (Doctrine, Twig, Swift mailer, Service managers, Security bundles, …) to create a web application are properly structured in the “blank” project setup. From that moment onwards configuring new framework features usually doesn’t take more than browsing through the official documentation and locating the specific use case you’re interested in.
And when you’re not able to find a solution on the official documentation, chances are quite big you will find a solution on Symfony 2 community blogs or of course… Stack Overflow.
In development there are really a lot of ways to solve a single problem. And where there are a huge amount of parameters to consider things can really ugly really fast.
For example, in many legacy PHP projects you'd have a config.php file included in a index.php. In most cases you would find a huge switch case going through a $_GET['page'] variable. And then the magic would begin…
Some standardization has been introduced in PHP through the PSR initiative in the past few years. But it still only solves a very small part of this "n-solutions-for-one-problem"-problem. What's interesting about standardisation in a Symfony 2 Framework context is that most decisions a developer has to make when starting out a project are already suggested for her/him.
A few examples of choices / preferences Symfony 2 framework "embraces" are:
- Directory structure (where app, web, config, assets, src, logs, cache files, etc... are stored)
- Usage of popular 3rd party components such as Doctrine, Swift Mailer, Assetic or Twig
- Introduction of the Official Symfony 2 Best Practices initiative
I believe all of these efforts really help to flatten the adoption and learning curve dramatically for developers that are new to Symfony 2. Without restricting the more experienced developers who want to move away from the path the Symfony 2 framework suggests.
One of the things that often leads to frustration with more experienced developers when using a certain framework or CMS is that they are forced to solve a problem with the tools that toolkit provides.
Often this means that even if there are better PHP packages, libraries or patterns available to implement a certain use case or solve a problem. They simply can not be replaced.
Thanks to the usage of Composer, Dependency Injection and good component oriented architecture Symfony 2 allows developers to drop in any new shiny piece of community created software to replace or extend the framework as desired.
Wide spread ecosystem
Many open-source projects have started adopting and using Symfony 2 components in their projects by using Composer. Doing this allows developers of these projects to focus on the things that matters. By preventing them having to reinvent the wheel time after time for things such as handling and creating HTTP requests & responses.
Generally, due to the improved standardisation the PHP community is going through thanks to the introduction of Composer, PSR-standards, League of Extraordinary packages, ... PHP developers will regain the ability to learn and master more than one framework or CMS system. This has been a very serious problem in the past few years for PHP developers. For example, Drupal or Magento developers hardly had any ability to use 3rd party libraries or community projects like PSR-standards, Doctrine, dependency injection, HTTP request handling, Symfony Console component, ...
This made it every difficult for these developers to switch from one technology to another, introducing a big challenge for PHP web development companies. Because it forces companies to use technologies for certain projects due to a lack of knowledge in the team or resources. Even though there are sometimes better frameworks / tools that could be used for the job.
Learning Symfony, from our point of view, is more like learning how to handle a swiss army knife. By now it’s used by so many other projects in the PHP world it’s safe to say you can find a Symfony 2-using community project for many different use cases from CMS to Ecommerce and CRM systems.
Some examples of some frameworks / products / projects using Symfony 2 components or the framework as a whole:
- Silex, Laravel, ...
- Drupal 8, EZ Publish, ...
- Sylius, Thelia, Elcodi, ...
- Akeneo & ORO Crm / Platform, Mautic, ...
A more complete list can be found on the official Symfony 2 website: http://symfony.com/projects
It became clear over the past few years that the approach the Symfony 2 team has been implementing is the way to go. When reading the latest updates on the Zend Framework 3 roadmap it’s pretty clear they want to head in the same direction of building solid PHP components tied together by a full-stack framework.
Very active and dedicated development team
Last year 2 interesting practical changes were introduced to the Symfony 2 project. First of all, the Symfony Core Team was (re)announced in April 2014, making the development cycle and responsibilities of some key contributors to the project very clear and well documented.
A few months later the Symfony DX (developer experience) Initiative was introduced and this initiative has already introduced some significant improvements for developers in the latest releases.
Automatic blog posts about the development of Symfony 2 in the repository on Github are generated on a weekly basis. Creating a very interesting source of information for anyone who doesn’t actively follow up on the Github activity and such but still wants to keep up to date with the latest developments.
In the next few month we will post regular updates about our experience with Symfony 2 as we are rolling out our first projects. We are definitely excited and we are looking forward to taking on this journey. With Symfony 2 we are confident that we will be able to take on pretty much any technical (web development) challenge. From creating basic CMS websites to developing complex high-end web applications or e-commerce solutions.
Some very interesting articles I came across while writing this article: