If you're considering a PHP-based framework for your new server-side application, you're likely to be faced with a choice between the two current market leaders, Symfony and Laravel. Since Laravel is actually based on Symfony and shares the same core components, the distinctive merits of each framework can be difficult to understand. Are we talking about the difference between Coke and Pepsi, or Coke and coffee?

The common current wisdom, which we'll examine, is that Laravel is faster in operation and easier to implement initially, and that it has superior online documentation and a friendlier learning curve. It is better suited to projects which need rapid implementation, with less complex scope or requirements for high-volume scalability. At the same time, Symfony requires more initial commitment but allows for the more efficient reuse of code, and the production of more robust and scalable enterprise-level web applications.

There are no truly neutral organizations out there benchmarking like-for-like, full-scale implementations between the two frameworks, so performance comparisons are inevitably anecdotal. Nonetheless, we'll explore the merits of each and some of the differences between them as they relate to PHP development for enterprises.

Do you consider a PHP-based framework for your new server-side application? You're likely to choose Symfony or Laravel, current market leaders. But what is the difference between them?

Why PHP?

The open-source server-side scripting language PHP has had a frequently painful ride to the top since its inception in 1994. Together with JavaScript and Flash, it had, by the early 2000s, become one of the most derided web technologies. Frequently criticized as an 'amateur' language, PHP seemed incapable of scaling up to its increasing popularity in terms of security, performance and features.

But just as JavaScript became resurgent via JQuery and the demise of Flash, PHP was eventually able to win over many of its critics through long-term open-source collaboration, a bold versioning roadmap, and the eventual development and adoption of large-scale and highly performant frameworks. Among these are Laravel, CakePHP, Symfony, Zend Framework, FuelPHP, PHPixie, and Phalcon.

The Rise of the PHP Framework

Efficient and feature-rich frameworks gave PHP a number of new capabilities and characteristics that would prove essential for large-scale and enterprise adoption. Advantages include:

the increased developer availability that comes from large-scale uptake
the ability to organize and re-use code
the capacity to develop scalable and resilient projects at greater speed
a mature ecosystem of supporting tools and third-party resources

The upshot is that, at the time of writing, PHP leads the league table of server-side languages with an indisputable 79%, trumping the nearest contender, ASP.NET, by a margin of 67.8%.

Usage of server-side programming languages

PHP powers some of the most influential web entities on the planet, including Facebook (via HVVM), WordPress, Wikipedia, Flickr and Tumblr. It also serves the half billion users of social media platform vk.com, as well as the U.S. Department of State, which recently abandoned ASP.NET for PHP.

Among server-side frameworks derived from PHP, Laravel and Symfony have developed a consistent lead over the last few years. Since Laravel is built over the second iteration of Symfony (Symfony 2, released in 2011), it's unsurprising that their remit crosses over a lot.

PHP leads the league table of server-side languages with an indisputable 79%, trumping the nearest contender, ASP.NET, by a margin of 67.8%.

Laravel vs Symfony: Origins and Intent

Symfony

Inspired by Java's Spring Framework, Symfony was created by a software engineer for French company SensioLabs in 2004, and initially released under an MIT license the following year. The first stable version appeared in 2007, and Symfony2, a total rewrite of the code base in 2011, proved the initial spark for Laravel (see below).

Symfony is highly modular, and is frequently used as a library resource of components rather than an integral structure. It's described by creator Fabien Potencier as a “reusable set of standalone, decoupled, and cohesive PHP components that solve common web development problems.” However, he also described Symfony as “a full-stack web framework.”

Sites and projects developed from Symfony (besides direct competitors such as Laravel, Yii, and CakePHP) include Drupal, Spotify, DailyMotion, and the ESA's European Space Software Repository. Projects which utilize components of Symfony include phpBB, Wikimedia, PHPMyAdmin, and the core Laravel/Symfony installation and management packager Composer.

At the time of writing, Symfony is currently estimated to be a supporting or core technology behind 37,457 live websites, and its current version is 4.3.

Laravel

Laravel has been likened to a PHP-oriented version of the core concepts of Ruby on Rails. Previous PHP-based attempts to emulate the elegance and facility of RoR included CakePHP and CodeIgniter. In fact, Laravel was created by Arkansas developer Taylor Otwell as a direct response to the limitations he perceived in CodeIgniter, such as the lack of support for Continuous Integration (CI – see below).

Laravel is more committed to a productive Model-View Controller (MVC) paradigm than Symfony. Though both frameworks are frequently cited as examples of the MVC architectural template, Symfony's creator discounts the comparison:

I don't like MVC because that's not how the web works. Symfony2 is an HTTP framework; it is a Request/Response framework. That's the big deal. The fundamental principles of Symfony2 are centered around the HTTP specification.

Fabien Potencier, Symfony SAS

Though it would be too much to describe Laravel as 'compiled', it is certainly optimized toward rapid development prototyping and deployment. This is a low-level, conceptual diversion in intent, and arguably the biggest difference between the two systems: Laravel was originated as a workhorse for server-side web applications, not an a la carte array of discrete library resources (which Symfony can be used as).

In that sense, Laravel exists downstream from the prestigious list of projects that Symfony can boast, many of which are cherry-picking Symfony's core technologies rather than using it as a framework. Additionally, Laravel is in itself a progeny of Symfony. Therefore, a like-for-like comparison of uptake between the two frameworks is not possible, or reasonable.

Sites and applications developed with Laravel include InvoiceNinja, TrafficJunky, Zoom, Aimeos, Handesk, Lead Management App, Pricefy, and Statamic CMS, among many, many others. At the time of writing, Laravel is currently estimated to be a supporting or core technology behind 107,657 live websites, and its current version is 5.8.

PHP powers some of the most influential web entities on the planet, including Facebook (via HVVM), WordPress (currently representing 34% of all websites), Wikipedia, Flickr and Tumblr.

Is Laravel Faster than Symfony at Runtime?

It's very difficult to confirm the popular idea that Laravel outstrips Symfony in runtime performance. The available sources are not impartial, and massive version changes across both frameworks in the last 3-4 years have rendered many of these accounts obsolete. Also, there is no objective benchmarking service powerful or well-resourced enough to furnish meaningful results across a range of potential scenarios.

Neither could any benchmarking process account for the inevitable differences between hardware and networking setup, latency issues created by third-party dependencies on unrelated technologies or data-streams (i.e. cloud-based data flows), differences in volume, frequency (peak traffic spikes, etc.), geo-based latency (distance to key data centers), and design efficiency (of databases and/or core implementation).

Even if you believe the frequently-cited statistics about Laravel's performance lead over the last five years or so, the margins typically quoted (50 vs 250 milliseconds, Laravel over Symfony) may well be insignificant for your proposed model and requirements. Considerations of 'speed' might be more appropriately considered in the context of development time and costs (see below).

Symfony vs Laravel: Object Relational Mapping (ORM)

Object-relational mapping (ORM) provides high-level methods to access a variety of database types. It abstracts SQL-based queries, operations and functions into the object-oriented programming (OOP) model. This allows for the quicker development of cleaner and more transparent and accountable code related to data queries.

Laravel: Eloquent ORM

Laravel uses Eloquent ORM, which supports four database types out of the box: MySQL, PostgreSQL, SQLite and SQL Server (as well as raw SQL). Eloquent uses the Active Record model, allowing developers to easily pull together Create, Read, Update, Delete (CRUD) transactions, and to make economical 'dirty checking' queries which report only on changed elements in the database.

Eloquent lacks Doctrine's ability to avoid migration scenarios using 'bridge' schemas (see below). However, it can facilitate migrations without the need to define fields in the model—a tool that Doctrine does not have.

Although Eloquent is perceived as one of Laravel's core strengths, it has also come under criticism for failing to remain performant at scale, and for failing to keep business logic separate from database architecture.

When it comes to performance, however, many concede that Eloquent's trade-off between facility and speed (and the fact that it is unavoidably slower in execution than raw SQL) is a fair exchange. Developers often use either raw SQL or Query Builder to relieve Eloquent’s bottlenecks in portions of the code base.

Symfony: Doctrine ORM

Symfony uses the third-party Doctrine ORM, which is also used by other notable frameworks such as Yii, Zend, and CodeIgniter. Doctrine is decoupled from Symfony’s Components and can accommodate a wide range of potential database types, though the Components do not explicitly provide native support for any particular schema.

Doctrine can avoid the need for database migrations by creating an adaptive schema once you have defined a suitable parity model.

Doctrine's mapper pattern creates a very clear division between the database schema and the logical functioning of the application. By contrast, Eloquent can often create uncomfortably close ties between the schema and the application.

However, Doctrine requires the creation of a repository function for each call it makes. These can quickly mount up in more complex applications, making code governance potentially a greater burden than with Eloquent.

Though developers are more likely to have experience with the default packages of either framework, both Eloquent and Doctrine can be used in either Laravel or Symfony as needed.

Query Builder

When considering Symfony vs Laravel, it's worth considering that the latter has a powerful additional tool for requests. Query Builder lacks the model integrity of Eloquent, as well as many of its most useful features, such as relationship handling, mutators, accessors and automated timestamping, among many others. However, it comes with a distinctive speed advantage in making CRUD requests and transactions.

Templating Engines: Twig vs Blade

As with Eloquent and Doctrine, it is possible to mix and match Twig and Blade, the two standard template engines of Laravel and Symfony, via this GitHub project and the TwigBridge repository.

Both template engines implement blocks/sections and Model Inheritance. With Twig, however, functions need to be defined twice, for both the template and the controller. This can lead to a burdensome level of specificity, and some difficulty in code reuse compared to Blade.

Unlike Symfony, Laravel has committed to exploiting the full diversity of PHP functionality rather than sticking to the higher-level functions which make it possible to exploit Symfony as a library resource. Again, this is a design decision and not strictly an 'advantage': Laravel's use of PHP's more idiosyncratic functionality also comes in for occasional criticism.

However, this means that Blade can use PHP functions directly in its templating logic, so that the code is reflected in the controller code. Services can also be instantiated directly into a template with the @inject command—a real timesaver.

Nonetheless, Blade's facility comes at the cost of blurring the MVC model a little, since bringing data logic into the presentation layer affects portability and transparency, to an extent. Since Twig uses a more portable model, it has an active life outside of Symfony, which increases the developer base familiar with it.

Blade also offers Lumen, a useful sub-framework for microservices and APIs. Lumen's functionality can be replicated in Symfony, but not so elegantly.

Continuous Integration in Laravel and Symfony

Continuous Integration (CI) automates the re-testing and validation processes that become necessary when the code base is changed. Both Laravel and Symfony natively support the same six CI models:

Jenkins, via GitHub (with dedicated templates available for Laravel and various versions of Symfony)
Travis and Drone, both Git-based and framework-agnostic CIs
Style, which has templates for Laravel and Symfony
Circle, which also provides dedicated Laravel templates
CodeShip, accessible via Git, with valid parameters

Laravel vs Symfony: Form Validation

Laravel and Symfony approach form validation rather differently. Laravel's validation occurs against input, either from a form or from a manual request validation.The Symfony Validator component, which provides a wider range of general validation services, performs the operation via the instantiation of a Validation class, effectively validating a model on the OOP basis.

Laravel also offers a flexible After Validation hook, granting an additional edge in error handling. In Symfony this would require a new instance of the Validator (and extra files to be created) in order to achieve the same end. However, proponents of Symfony have argued that validation of raw user input should, in any case, be the remit of the form's own validation routines, and that the higher-level approach that Symfony takes is superior in respect to translations.

Here, not for the first time, the difference between Laravel and Symfony seems to come down to the tension between facility of use (Laravel) and maintaining the integrity of a decoupled, higher-level model (Symfony)—themes that underpin the core principles and intents of both frameworks, respectively.

Laravel vs Symfony: Learning Curve, Online Documentation, and Support

Due to its determination to provide portable, decoupled and flexible components, Symfony is generally perceived to come with a higher learning curve than Laravel. This consideration is exacerbated by the superior amount of online learning material and resources available for Laravel.

For $99 yearly, users can subscribe to all the content at Laracasts, a huge community resource which provides open forums and video tutorials. Most of the content is available without subscription. The domain currently has over 65,000 threads, while the complementary (and free) laravel.io forums offer over 15,000 topics.

Symfony has an active Slack Chat and a very well-respected and well-ordered array of online documentation. However, it has diverted previous efforts at forum development over to Stack Overflow.

At the time of writing, Stack Overflow is approaching 20,000 questions related to Laravel, less than a third of Symfony-related questions at that domain. Whether this is because Laravel's dedicated resources are more compelling, or Symfony is more popular (or more problematic!) is open to interpretation.

SensioLabs, the originator of Symfony, offers paid support for the suite, whereas professional consulting around Laravel is only available via independent companies.

Conclusion

Laravel remains a child project of Symfony. It has intentionally jettisoned some of its progenitor's most attractive developer features in exchange for the ability to provide rapid prototyping and deployment. However, some of the shortcuts that facilitate its streamlined development workflows (such as diminished distinction between data and design in certain aspects of the framework) could land a project in trouble if it ever needs to scale higher than originally anticipated.

Symfony's integrity of design gives it the potential to reward a greater initial investment of time and money with a more stable project implementation that's able to scale. If you're impressed by Symfony's prestigious stable of users, it's worth remembering that few of the biggest names in that list are using Symfony as a core framework. Since its mission is divided between the provision of modules and a cohesive framework, Symfony could be argued to have less conceptual integrity than Laravel.

Laravel's long-standing (possibly apocryphal) runtime speed advantage appears to be eroding as the Symfony framework addresses this issue with every release. Therefore, the primary factor in recommending Laravel over Symfony derives from its easier learning curve, as well as its extraordinarily comprehensive online documentation and developer community.

Our PHP developers are up for the task when you need professional assistance. Get in touch to discuss your project and expertly choose its tech stack.

Laravel vs Symfony: Which Is the Best PHP Framework for Enterprise Development?