A Threnody for Silex
Silex is dead.
I am sad.
But I can see the future, and it is bright.
Silex started as an offshoot of the Symfony 2 framework from Sensio Labs. Both projects were created by Sensio's founder, Fabien Potencier. Igor Wiedler was also a key contributor to Silex, and was a primary figure in the community's initial adoption of the microframework.
At first, Silex acted as a proof of concept that SF2's componentized design had a role to play in the broader PHP ecosystem. Over time, it was embraced by many in the community as an excellent backbone for projects that pulled libraries and packages from various sources to create seemingly-bespoke solutions.
In 2010, I had been building a web application in Symfony 1.x, and I was not completely happy with the full-stack approach it encouraged. I felt it put too much emphasis on code generation, which left me feeling like I was playing with the computer equivalent of plasticine. It also felt like it was trying to solve every possible problem for every possible project that could be built for it, instead of just providing the tools to solve the problems.
Symfony 2's Beta landed on the scene at the end of that year - it seemed rather revolutionary for a PHP framework. A huge departure from the concepts of Symfony 1. Many of its components were brand-new and purpose-built with a vision of them being actively reused outside of the framework.
This focus on reuse made it possible for Silex to leverage the functionality of Symfony 2, and suddenly the vision seemed perfectly geared to modern PHP development: nothing should be trapped in a silo anymore. This feeling was amplified by PSR-0 (the first Autoloader standard from the PHP Framework Interoperability Group) and the advent of the Composer package manager.
The pairing of Silex and Composer allowed developers to take an a-la-carte approach to smaller projects.
Suddenly, projects that would have taken up to a month to get up and running in a demoable state could be knocked out in a week - with tests!
It's not all rosy, of course. Sometimes taking a project from that demoable state to a full-fledged production application proved to be a bit more challenging than expected. Silex, however, still had an advantage in that situation: the same controllers that were created to deliver Silex applications were reasonably easy to drop into a Symfony 2 project, or sometimes an entirely different microframework, full-stack framework, or even a purely custom implementation.
Although it certainly wasn't the first micro framework ever, and not even the first for PHP, it was the one that I gravitated towards. I even started writing a book about it in 2014. It's still a work in progress. I make a smidgeon of progress every now and then, when the mood strikes.
In June of 2018, Silex will be officially EOL. I don't know what I'll do about my incomplete book. It seems like a waste to give up, but it also seems futile to continue. Maybe I'll port the book itself to another framework.
But like I said at the start, the future is bright. Symfony 4 has created a bridge between the a-la-carte approach of micro frameworks and the Last Suit You'll Ever Wear philosophy of full-stack frameworks. Its goal is for the initial footprint to involve as few components as possible, and for other components to be pulled in later using Flex (which is a layer on top of Composer that pre-configures packages from approved "recipes") and Composer. Quite a Silex-like approach, in fact.
I'm excited to see what people do with it.
Links of Interest:
- Hello Symfony 4!
- The end of Silex
- A discussion of porting Silex apps to Symfony 4
- A real-world PR that ports an open source Silex project to Symfony 4
- An alternate approach: Consider porting from Silex to Lumen
- Still want a microframework? Consider using SlimPHP
Published: January 17, 2018
Tags: opinion, coding, development, dev, php, legacy, computer-history, silex