Cover of the book Symfony 5: The Fast Track

Symfony 5: The Fast Track is the best book to learn modern Symfony development, from zero to production. +300 pages showcasing Symfony with Docker, APIs, queues & async tasks, Webpack, SPAs, etc.

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.

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.


Its great that the Symfony 2 devs are looking at re-use of existing libraries to enhance and make Symfony better, but I would recommend some caution. Start using too many libraries and you give up control. Also, you can start turning into nothing more than a patchwork of everything else.

Symfony must be careful not to lose what makes symfony (note the change in case :P) great. I'd honestly prefer a delay in release because core developers want to get their own better way of doing things incorporated than just "selling out" to get things done.
The dependency injection foundation that Symfony 2 has is great. I'm starting to use it of course and feedback will no doubt be plentiful!

P.S. Great talk at #phpuk2010 !
@Gareth: I understand your point and be reassured that we won't always use third-party libraries. We evaluate the alternative solutions quite extensively before making the switch. Using the ZF logger was a no-brainer. Switching to PHPUnit was less evident at first. And for core technologies, we will provide our own for sure: that will be the case for the form framework, security, ...
Great post Fabien, I thought that your decision about PHPUnit is excellent.
The Dependecy Injection is awsome.
Impressive. I'm confident that Symfony will continue to innovate quickly while sunk costs are ignored and the focus stays on the frameworks core value.
Great post!
Is Symfony 2 will use Zend_Cache 1.* or 2.* ?
I personally hope that the routing gets improved. I agree that's its easy and often sufficient. But sometimes it's limiting the URL schema very much. E.g. you cannot use many different seperators like /, _ and - in one url. Yes I know there is the seperator option but I mostly doesn't work the right way. Maybe include a regular expression routing with named subpatterns (a nice feature in PHP regex). Also a REST architecture is not very easy to build with it.
I think Zend Routing solved this better.
My opinion is that the Symfony framework is being renew in a better structure that looks more simple and powerful. The only thing that worry me is how I'll update my current projects to Symfony 2 in the future.. anyway I'm happy that I've chosen Symfony.
Will Symfony 2 come with Doctrine 2? :D
Is there anything Symfony 2 can learn from ASP .Net MVC 2.0?

Attributes enclosed in brackets for example: [Required] [HandleError] etc...
MongoDB ORM built in? ElasticSearch?
Built-in LDAP Authenticaton classes would be great!
Good coders code, great coders reuse...
Almost two years ago I started with symfony and discovered a whole world of a new better way of making things easier and faster (with a little steep learning curve, though ;) ). Now with upcoming release of Symfony 2 and all its new features I must say It was the right decision then and now to use it.

I think use Zend_Cache and Zend_Log in Symfony 2 was a brilliant move!

Excellent work guys!

@Tiago: I think that's more than sure.
My big question is... I'll ve developing a Symfony 1.4 application in the following months. Will it be possible to upgrade do Symfony 2.0 once it's released easily or not?
It's very nice to see that you embraced the de-facto standard when it comes to unit testing.

Maybe this would be a good time to embrace the de-facto standard when it comes to coding style as well (4 spaces for indentation, opening brace at the end of the line for control structures).
Isn't PHPUnit based on PEAR and therefore introducing additional dependencies, like on the awfull PEAR library?
Like petersaints, we are also starting a new large project that has to be up and running by August. I would also like to know how much effort it will be to upgrade from 1.4 to 2.0. As far as ORM is concerned, we have always used Propel, but it looks like we'd better start using Doctrine on this project, since Propel will no longer be supported in Symfony 2.0.

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.