Within the context of framework history.

Twenty candles on the cake

The history of dynamic websites written in PHP started in 1995, when Rasmus Lerdorf released the code of libraries he developed referred to as PHP/FI, which subsequently evolved into a simple programming language. Three years later Zeev Suraski and Andi Gutsman from the University of Tel Aviv (the Zend company’s name is a combination of their first names) rewrote the code and called it PHP 3.0, which was the actual beginning of the PHP language that we know today. PHP has ever since had its own share of highs and lows, but it has proven attractive due to its simplicity and low entry barrier for new programmers. Unfortunately, developing advanced apps in PHP was troublesome as the language lacked standardization. In 2005, the very first frameworks, including the initial version of Symfony, debuted, which made app development much easier and faster.

These two anniversaries – the 20th of PHP and 10th of Symfony – are a great opportunity to go over how the language and framework evolved over the years and how Symfony improved the development process of complex websites and web apps.

Pros and cons of using frameworks

A framework is a skeleton of an app. It defines the initial structure of each project, its default behaviour and all the rules to follow during development. A good framework should be universal – so that it can be used for a variety of different projects. Besides the skeleton, frameworks often provide a set of libraries, though truth be told they are not actual libraries themselves. They should be thought of as environments in which our apps exist.

The most obvious advantage of using frameworks is eliminating the need of creating the structure of a project every time. However, I believe that the most important advantage is the standardization they provide. Its influence is especially easy to notice when it comes to popular open source frameworks – programmers who use the same framework can easily collaborate, as the majority of common rules are already established by the framework. They may focus on the business logic of their project instead of organizing the code. It’s important for the client as well – when another programmer or company takes over the project, they will be able to understand the development logic easily and also focus on the business logic (explained in the specification).

Most of frameworks are open source projects and are thus tested by many programmers. It significantly decreases the likelihood of errors during implementation. The business logic code also works better than without the framework as long as we follow the rules of the latter.

Of course, a coin has two sides and so does the usage of ready-made framework skeletons. One cannot develop such flexible software, as a framework ought to be, whilst also avoiding making it quite complex or compromising efficiency. It’s a consequence of using many components, the necessity to operate on highly abstract layers and long initialization (configuration load time etc.). Luckily, it’s increasingly less troublesome as the cost of computing power and memory decreases and most responses are cached anyway.

It’s sort of a trade-off – we gain a solid product faster and cheaper than without using a framework at the price of higher server costs or slower responses. Those disadvantages of full-stack frameworks have greatly influenced their development for the last ten years.

Long and winding road

The first stable versions of popular frameworks started to come out in 2005. That year brought three solutions worth mentioning: the Zend Framework, Symfony and CodeIgniter. Zend and Symfony were complex and full of libraries for a whole variety of purposes, which unfortunately made them quite complicated and heavy. Lighter frameworks such as CodeIgniter provided a much needed balance. It contained fewer rules and libraries and thus was easier to use and faster. The downside was that one had to write a lot more code on their own, whilst the fewer rules meant that the code was less standardized and more error-prone. Still, many programmers preferred those light frameworks over their heavier counterparts due to the benefit of shorter response times.

The biggest issue with using those early large frameworks was their inability to split into smaller standalone modules. The Zend Framework was really just a set of classes, but any attempt to extract one module required searching through a long list of dependencies. The next few years, however, saw PHP become a fully object-oriented language. This and the emergence of the new package manager, Composer, paved the way for a new breed of libraries capable of cooperating with each other and new frameworks made of fully independent components.

Stability is an indispensable quality of good frameworks – before one plans on entrusting its project to a framework, one should make sure that it was tested by many programmers and that further improvements and updates will be made in the next few years.

The Symfony2 revolution

After almost two years of development and contributions made by 250 programmers, the very first version of Symfony2 was released. It consists of 21 components that can be used independently, which proved to be a total revolution compared to the other frameworks available at that time. Symfony2’s basic principle is to bring the programmer’s focus to the HTTP standard. From now on they would only need to write code that processes a HTTP request into a HTTP response. The rest is provided by the framework. This greatly simplifies code and allows for the responses to be cached easily.

Besides the ability to split into independent components, Symfony2’s greatest advantage is its use of the Dependency Injection software design pattern, which allows the framework to be very flexible and configurable. The pattern makes code easier to maintain as well. The structure of Symfony2 (and the code of our app) is based on the so-called ‘small services’ modules, each one of which is dedicated to only one task. Those services can connect to each other. A mechanism like this makes it easy to separate dependencies, maintain the code and avoid duplicate code. As dependencies are limited, the services may be tested with little to no effort or even replaced without having to modify a large part of the project.

Symfony2 helps with debugging as well. It provides the ‘profiler’, which informs how long it takes for each part of the code to be executed, and the ‘web debug toolbar’, which shows up at the bottom of a site and simplifies the process of receiving information regarding bugs.

On many occasions, the creators of Symfony2 opted for battle-proven ready-made solutions. Consequently, the standard edition of the framework includes libraries such as Doctrine, Swift or SwingMailer. Of course, we don’t have to use them – we can easily remove them and replace them with other solutions.

App security is one of the most important development aspects for the Symfony2 team. The framework includes solutions meant to protect the developer from online attacks (XSS, CSRF) as well as a large component tasked with user authorization. On top of standard authorization solutions (such as HTTP Basic or HTML form), the component may be expanded with even more methods (e.g. OAuth).

Symfony2 includes a few modules that are practically indispensable for every project as well as several extra modules capable of saving developers a lot of time. Among the latter you can find console development tools, form generation and handling solutions as well as some dedicated to multilanguage systems.

The framework is easy to use, but at the same time far from unsophisticated. Symfony2 is a complex framework, but the creators still managed to make it very intuitive. In case of any problems, its extensive documentation provides great support. The documentation itself is also an open source project so that everyone can develop it and help correct errors.

A very good proof of the fact that Symfony2 turned the world of frameworks around and managed to become a PHP standard is that many frameworks developed later (Silex or Laravel) originated from its components such as HttpFoundation or HttpKernel.

As I mentioned before, stability is one of the most important aspects for framework users. Symfony2 introduced a clear version system. Every half a year a new version is released (with new features). Each one receives two maintenance periods: bug and security fixes are made for eight months, and then security fixes by themselves for 14 months. It provides enough time to make a switch to a newer version. If, however, one doesn’t want to update Symfony2 so often, one may opt for versions 2.3, 2.8 or 3.0. Those were marked as long-term stable (LTS) versions, which means that they receive bug fixes for three years and security fixes for four years. The update process itself is easy too, due to the fact that since version 2.3 the Symfony2 creators have made great efforts to maintain backward compatibility.

Symfony2 is not just a single tool – it’s a whole framework ecosystem. It includes all those programmers who develop their own extensions or adapt other solutions for use with Symfony2 (at this point just about any popular library can be used with Symfony2). As well as those who develop new features, fix bugs or complete the documentation. At the time of writing, over 1,100 programmers had already contributed to the development of Symfony2, more than 800 worked on the documentation alone. No other framework can boast such figures.

As I said before, the Symfony developers (who also use the framework themselves) take great care to make it as effective, secure and stable as it possibly can be. Nowadays, as the software development cost and time to market (the time it takes to release software from the moment it was conceived as a concept) are so important, Symfony2 seems to be one of the best choices.

The future – evolution or revolution?

In the future, Symfony2 will continue its stable development (owing, among others, to its great version system). Two years ago SensioLabs (the company behind Symfony2) received €5 million to further develop its ecosystem. Thanks to these funds, they will be able to extend their activity beyond just Symfony2, developing programming support tools such as Blackfire.io or Insight.

Simultaneously, a 3.0 version of Symfony is in development, seeing as since version 2.3 so many new features have been introduced that backwards compatibility is no longer feasible. The new version is scheduled for release in November. Will it prove as revolutionary as 2.0? I don’t think so, but I still can’t wait for it to come out.