Symfony 2.0 and the PHP Ecosystem

Unless you've been living under a rock, you have already heard a lot about Symfony 2. The buzz on the Internet, and especially on Twitter and on blogs, have been terrific so far. Today, I won't really talk about the Symfony 2 features. If you want to give Symfony 2 a try, you'd better read the "Quick tour" tutorial on the Symfony reloaded website. This post is more about one key aspect of the Symfony 2 philosophy. Hopefully, it will help you better understand the reasoning behind most of our decisions.

Symfony 2 is all about having a better core architecture. The old Mojavi classes are now all gone. They have been replaced with a more flexible foundation. This will allow Symfony to be used to develop both very small websites like personal homepages and also very big ones that have specific needs. The new architecture also gives us the opportunity to fix the mistakes we made in symfony 1 and to incorporate all the feedback we received during the last four years.

Symfony 2 still aims to be a full-stack framework but with a slightly different philosophy. You know that we don't like to reinvent the wheel, and so symfony 1 is already built on top a lot of different third-party libraries (Propel, Doctrine, Swiftmailer just to name a few). For Symfony 2, we have decided to take it to the next level. The Symfony core team will concentrate more on providing a great low-level architecture and we will rely even more on third-party libraries whenever possible for everything else.

The first visible decision we made was to replace our logger and caching libraries with the Zend Framework ones. We spent a lot of time writing these classes and maintaining them over the years, but whenever we take a decision for Symfony 2, we try to think about what is best for the project in the long run. It's never about personal ego.

But of course, we won't use a library just because it exists. Five years ago, I decided to create lime for our unit tests, instead of using an existing library like SimpleTest or PHPUnit. And I did that for some good reasons: among them, I wanted a simple way to write unit tests to lower the barriers of entry to unit testing. But things have changed a lot since then. First, PHPUnit is now the de-facto standard library for unit testing, and PHP developers are more comfortable with the whole testing concept. So, the core team has decided to switch from lime to PHPUnit for Symfony 2.

I like what Paul Lomax tweeted some days ago about that: "Use what's out there; realise it sucks; write your own; wait until others suck less; dump your own; use other."

Using PHPUnit instead of lime basically means we have less code to maintain ourselves. It's like having Sebastian Bergmann on board; one more great PHP developer helping us making Symfony better. But using PHPUnit also has a lot of other advantages:

• We will play well with others (Zend Framework, Doctrine, Propel, ...);
• You will have better integration with tools like IDEs, Continuous Integration servers, ...;
• You will benefit from features that are not available in lime;
• You will have less Symfony-specific things to learn.

Bernhard will keep on working on Lime 2, but he will also have more time to work on core Symfony features like the new form framework.

Using third-party projects is great but only if they can be integrated into the Symfony core in a cohesive and transparent way. That's where the Dependency Injection Container comes into play. Symfony 2 is entirely built around a Dependency Injection Container. Besides the flexibility it gives to the developer, it's also a great way to easily integrate third-party code. If you are curious, have a look at the DoctrineBundle plugin or the Swiftmailer one to see what I mean.

Keep in mind that Symfony 2 is not ready for prime time. We have published a preview release to gather feedback early in the process. So, feel free to play with the new code base and don't hesitate to provide as much feedback as possible.