http://www.phparch.com \ August 2019 \ 3Symfony 4: A New Way to Develop ApplicationsFEATURESymfony 4: A New Way to Develop Applications
Antonio Peric-Mazar
PHP has changed a lot in the last few years. It is a faster and better language. With the
improvement of the language, almost all the major frameworks also improved, including
Symfony. In this article, I write about the changes and improvements included in Symfony 4.
Symfony 4 introduces a much better developer experience with a new way of building web
applications. It can be a good fit for small micro-apps or services, but it can also be a good fit
for huge monolithic applications.1 bundles: https://symfony.com/doc/current/bundles.html
2 components: https://symfony.com/components
3 Symfony Standard Edition: https://phpa.me/end-symfony-standard-ed
Does this story sound familiar? Ten
years ago, I started working with PHP.
At first, I wrote some simple scripts,
learning about language and funda-
mental principles. After completing
some simple projects, I began to free-
lance and work on more complicated
jobs. To make my life easier and to
be able to produce features in a faster
and more organized way, I created my
framework. It was dozens of classes put
together to make my life simpler. I had
some kind of router, controllers, form
and database manager, etc. It was pretty
basic, but it worked and performed well.
As my projects became more
complex, I wanted to move to a more
advanced framework. One developer
couldn’t compete with communities
of developers and their knowledge;
also, maintaining a framework is quite
time-consuming. However, beginning
by writing my framework was a great
learning experience. I did my research,
and in 2011, I decided to move to
the Symfony framework. At the time,
Symfony 2 was still under development;
I decided to take one project based on
Symfony 1.4 and move it to Symfony
2, once it was stable. Of course, my
first project on Symfony 2 was during
the alpha7 version (if I remember
correctly) and we built a website for
clothing retailer Replay in Croatia. That
was a hectic experience.
Symfony 1, 2, and 3
The web was different at that time.
On the frontend, we had a small part
of JavaScript which was mostly good
old jQuery and some sort of fullstack
framework on the backend. Symfony
1.4 was that kind of framework; it was a
fullstack framework. It had a clear sepa-
ration between frontend and backend
applications, which shared a database
model. In Symfony 1.4, we didn’t have
any templating engine. Administration
pages were usually generated from
the console as the admin module was
included in the package. You could
download and include some existing
plugins into your project (Composer
didn’t exist at that time), but you
needed to do everything manually. Too
much magic was happening inside
Symfony 1.4, and you could use it only
as a fullstack framework for monolithic
applications; the best fit was for midsize
to large apps.
Symfony 2 was released in July 2011
and brought many changes. Clear
separation of frontend and backend
application were replaced with bundles^1.
In Symfony 1.4, we had frontend and
backend applications separated, and
the idea was to build bundles around
features. For example, a BlogBundle
would include all models, logic, etc.,
for the blog. As stated in the documen-
tation, a bundle is similar to a plugin
in other software but better. Bundles
would allow you to create reusableparts of your application and group
them around the same functionality,
for example, BlogBundle, CartBundle,
ContactBundle, etc. Your application
always contains some custom logic,
which is not easy to reuse in other proj-
ects. Bundles made the organization of
your project unnecessarily complicated.
If you are building reusable code, you
can pack it inside a separate bundle and
use it as a third-party bundle in any
project where you need it. Otherwise,
you don’t need bundles.
But, the most critical change of
Symfony 2 was introducing separated
components^2. It was still a fullstack
framework for monolith applications
but built on top of standalone compo-
nents. The idea behind components is
to pick and set up your composition of
the framework and use only things you
need. It didn’t work very well, so most
people always started a new project
with Symfony Standard Edition^3. This
way of working still provides you with
a bunch of code you didn’t use (it
contains 72 components). If you’ve ever
tried to remove the Twig component
from Symfony Standard Edition (or
the Form component), you know how
painful it is. In most REST API proj-
ects, you don’t need it. But, usually, you
keep all the components as it’s easier
and much less time-consuming. Some
developers leveraged components and
set up their framework for projects, so
we can say that this idea was partially
successful.