Understand how the Symfony project evolves and why it is always worthy to get involved, but differently.
In 2011, when I started my studies in computer sciences I learned the PHP using symfony 1.3, and I realized my very first student project on the beta of Symfony 2.
At the time, we were moving from a fully integrated full stack framework with a back office provided to a framework that followed what was found in the Java community: besides, many components of Symfony2 were strongly inspired by JEE.
PHP 5.3 had just come out and with it the ability to start designing object-oriented correctly. Fabien Potencier finally imposed this prerequisite (initially, Symfony2 required PHP 5.2.7), then Composer was used, and the documentation was complete and in English.
Zend Framework 1 was losing his popularity, and no more startup was launched on it (in France) when on the contrary we saw appearing some “Symfony developer” job offers in the most successful french companies. A few years later, nobody could conceive of using anything other than Symfony to make a PHP project.
Large Open Source projects have started to migrate on Symfony components: if it was not first, SensioLabs has talked a lot about Drupal8 because it is one of the biggest CMS on the market. EzPublish, PHPBB, PrestaShop and many others followed, some with a full stack framework approach and others by incorporating only a few software bricks.
A vibrant and mature ecosystem
The Symfony ecosystem has been enriched with ever more specialized solutions and responding to concrete business problems where the Standard Edition framework (so-called “full edition” or “meta-package”) has no scope. Have appeared among the most famous:
- The Laravel framework, easier to access and RAD-oriented framework;
- The Oro platform and the entire associated ecosystem: Oro CRM, Akeneo, OroCommerce, and Marello;
- The Sylius eCommerce framework;
- The framework specialized in the design of API RESTful API Platform;
All of these solutions are extremely popular and require real Symfony skills.
In 2017, what will be the place of Symfony Standard Edition in the ecosystem? Fabien Potencier decided that there would be no more Standard Edition after the 3.4.
Welcome to Symfony Flex!
Indeed, the creator of Symfony plans to replace it by a composer plugin called Flex that facilitates the creation of Symfony applications.
The developer will have the responsibility to choose and add dependencies that he/she needs. The system works according to a “recipe/template” principle where YAML files describe what Flex should do: add a dependency, configure and register a bundle, or create a folder for example.
Flex comes with two sources of “recipes”: an official source validated by SensioLabs and a community source where everyone can add their recipes and make them available to everyone.
To put it simply, imagine that you want to realize a RESTful API in 2017 using Flex: the ideal would be to use API Platform. As API Platform is available via Flex you only have one command to run to get to a complete application that works.
I have to admit that this approach pleases me a lot and that it reinforces the point of view that I defended for several years: a Symfony project not focused on its framework but the maintenance of software bricks of very high quality and well documented. Perhaps we had to wait for the relative success of Symfony 3 and the popularity of solutions like Akeneo for this awareness, but I’m convinced that the Symfony Core team is now moving in the right direction.
If you are looking for more information about Flex, there is not yet any official documentation, but Fabien Potencier has produced a series of articles about the project that I encourage you to read and experiment since the composer plugin is compatible with Symfony 3.3 and usable independently of the Symfony 4 release ;)
Ok! But why should I learn Symfony in 2017 then?
In 2017, you don’t (necessarily) have to learn the Symfony framework, you have to learn and understand the Symfony ecosystem:
- How a Symfony application reads an HTTP request and returns a response;
- How a Symfony application builds and makes available objects (called “services”);
- How a Symfony application dispatches and listens for events throughout the application lifecycle, and how to look and create its events;
Becoming familiar with these notions made you able to quickly be comfortable with API Platform, Akeneo, Marello, Sylius, Drupal8, Laravel, and the Symfony Standard Edition framework.
What about the components?
I am a huge fan of Symfony components: they are maintained by a big community, very well documented and evolve regularly.
The learning or use of a particular component obviously depends on the project. Here is my list of the most useful libraries:
- The Console component: provides a complete console with arguments and options management, essential for PHP in CLI mode;
- The Debug and VarDumper components: they provide a better stack trace in case of error and the
dumpfunction as a replacement ofvar_dump; - The Finder and Filesystem components: they provide a nice API for searching and manipulating folders and files;
- The Polyfill- * components: they allow the application to use functions that are not available, either because of the PHP version or the absence of PHP extensions;
All of these components work in “standalone” and are used in the most large PHP projects.
So keep learning and investing in the ecosystem: Symfony (framework) is dead, long life to the Symfony project!