What about Silex in a Symfony 4 world? During the last few months, and as an
exercise when working on Flex, I have migrated several applications from Silex
to Symfony 4. And the conclusion is that Symfony 4 feels like using Silex.
Using Symfony 4 and Flex feels as lightweight as using Silex. You have full
control about what features you want to enable or disable. The directory
structure of both kinds of applications is similar with limited depth. And
Symfony 4 is superior when it comes to the ecosystem. Whenever you need
something, odds are that a bundle already exists for it. And for major ones, a
recipe makes integration a breeze. And that217;s a great selling point of Symfony
4: it scales from very simple applications that just need a router and classes
for HTTP messages to a monolith including bells and whistles.
Moving away from Silex is also made simpler as Symfony 4 almost auto-configure
all your services. So, migration from Pimple is mostly about removing all the
code without any replacements in the Symfony config.
For all these reasons, I would say that Silex is not needed anymore. So, we’ve
decided to not support Symfony 4 in Silex, or at least not add the new features
added in 3.4. The current stable version of Silex is still maintained for bugs
and security issues. But its end of life is set to June 2018.
Having a unified community around Symfony 4 and Flex is great news and one
implicit goals of all the work we have done during the last few years around DX