The Brick Factory’s development team has been writing custom PHP applications for ourselves and clients since 1999, and PHP development has changed quite considerably since then. At that time, and for years after, there were few available frameworks with which we could build our applications on, so all of our applications were developed from the ground up, with later applications taking advantage of some reusable code libraries (most of which came from our ImpactWatch application, and others from our online training service).

In 2005, we started using WordPress for blog sites, and later, in 2007, we started to use Drupal for more complicated sites. Both can, to varying degrees, be called application frameworks (Drupal considerably more so than WordPress), and using these tools allowed us to create many websites covering a wide range of needs for our clients must faster than we could have if we had to write everything from scratch.

Actually, at one point before we adopted Drupal, we started to write our own CMS tool, and stopped when we realized that the amount of time we’d have to spend building it to meet our needs would be considerably larger than just using an existing open-source platform. And even if we succeeded in building something that met our standards, ultimately, we’d just be re-inventing the wheel that Drupal, WordPress, Joomla, and 40+ other CMS systems (according to Wikipedia) have spent years refining. And where’s the fun in that?

So, we’ve spent the last several years refining our skills with Drupal, even contributing back a few bug fixes and a Drupal module (Splashify) to the community, and we think we’ve gotten pretty good at Drupal site and module design and implementation.

In December, we started planning for Sway, our next internal project. We have some ambitious goals with Sway, and we wanted to get something to market relatively quickly, so it was obvious early on that we had to use a framework of some sort. This meant we couldn’t use the internal workings of ImpactWatch or Training, as aside from a few reusable components, they were never designed and developed to the point of being significantly useful in other applications.

It also put Drupal out of consideration, as what we had in mind would require so much custom work that the strengths Drupal brought to the table would be outweighed by the time we’d spend working against it. Also, we wanted a chance to use the latest and greatest technologies. PHP 5.4 has been available for just over a year, and we wanted to be able to use it. Drupal 7, by comparison, doesn’t take advantage of many of the new features in PHP 5.3, let alone PHP 5.4.

Ultimately, we settled on Symfony, and in January, started developing Sway using Symfony 2.1 (and quickly upgraded to Symfony 2.2 in March after it was released).

As an added bonus, working on Sway will give us a head-start in learning to use Drupal 8, which is expected to be released later this year. Core components from Symfony are being used in Drupal 8, so we’ll be able to put some of our experience working on Sway to use on any Drupal 8 sites we start working with. Both Symfony 2 and Drupal 8 use the Twig template engine, so our designers will have time to become familiar with Twig before we have to start using it on Drupal sites.

We’re looking forward to what we’ll be able to accomplish with Sway, and with future versions of Symfony and Drupal. This should be an exciting year!