When facing the start of a brand new PHP application there is one decision that can’t be overlooked: which framework should you use? Theoretically, you could start with none but assuming the project at hand is anything but trivial that’d probably be a bad idea. The good news is you’re not exactly short of options to choose from.

The bad news is you’re not exactly short of options to choose from… which can make the decision a little harder than you might expect.Then again, even though there are many options out there, simply by scratching the surface you’ll notice that two stand above the rest: Laravel and Symfony.

At a glance, there’s one main difference between Symfony and Laravel which is that Symfony is both an Application Framework and a set of reusable components, while Laravel is simply a Framework (In fact, Laravel uses quite a few of Symfony’s components). For the purpose of this post, I’ll refer to Symfony as a Framework but keep in mind that, because of how it’s built you should consider it a meta-framework. In the following sections, you’ll learn the similarities and differences between them and how to choose the one that best suits the needs of your project.

Points We Will Cover in This Article

• What they have in common
• Installation procedure
• Directory structure
• CLI tool
• Configuration
• Template Engine
• Framework Extensions
• Testing
• Performance
• Security
• Internationalization
• Project governance
• Popularity

What they have in common

Needless to say, the first similarity you’ll notice is that they are both PHP frameworks. But that’s just the beginning. Here are the most outstanding features of both:

• Open Source projects
• Based on the MVC pattern (which means there are no big conceptual differences)
• A CLI tool is available for common tasks
• Code is organized in a particular way
• Testing tools are available
• Cover the full stack leveraging existing projects (ORMs, Template Engines, etc…)
• Can be run on multiple platforms (Operating systems and database engines)
• Have built-in internationalization features
• Can be easily extended

Now let’s get into the specifics so you can get a better understanding of their differences.

Installation Procedure

For the purpose of showing commands I’ll be using a fresh Ubuntu 21.04 box virtualized using Vagrant, you can find the image here.

Prior to running the commands I’ll be showing, you’ll have to install the following:

• PHP 7.2+
• Composer

When it comes to installation, they’re both fairly easy to start with, since both use composer, there’s not much mystery to it.

Installing Symfony

The easiest way to get a symfony project started is by running the following command:

composer create-project symfony/website-skeleton sfTest

This will, assuming every dependency is met, leave you with a basic web application you can further customize to meet your needs.

An alternative installation method, which is actually recommended by Symfony, is to install a new binary in your system.

Should you choose this option, the command used to create a new project is:

symfony new sfTest --full

There are several advantages to using this method, one of them is you have a very handy command:

symfony check:requirements

Which will help you detect and eventually fix any missing dependencies.

Either way, upon successful installation you’ll get a welcome screen telling you what the next steps are.

Installing Laravel

Laravel also offers different ways of installing, the easiest one is running the following command:

composer create-project laravel/laravel lvlTest

Another way to get a Laravel project started is by previously installing a Laravel installer (much like Symfony) by running:

composer global require laravel/installer

And then:

laravel new lvlTest

Directory structure

Symfony directory structure

If you go into your newly created project and ask for a files list you’ll get this from Symfony:

Your code is expected to be organized as follows:

• src will contain all of your business logic (Entities, Containers, Services, etc…)
• templates will hold the presentation code (mostly html-like files)
• tests will be stored in the tests directory
• migrations will be the place for database upgrade scripts

And then there are other artifacts that have a particular place in the project:

• bin is where you’ll find useful CLI tools
• vendor is where dependencies live (common behavior to every composer-based application)
• config is where the configuration will be
• In translations you’ll put the i18n related resources
• var is a directory used internally by the framework, mostly for optimization purposes

Finally the public directory will be the point of contact with the outside world, here you’ll find the application’s entry point: the index...