PHP MVC Frameworks preview of 2018 (Phalcon 3, Symfony 4, Laravel 5.x and others)

It’s that time of the year again, when we take a look at the world of PHP MVC frameworks. We get ready for the trends of 2018 and plan our roadmaps. Also, we’ll take a quick detour to look at some seagues in the areas beyond PHP MVC.

Web development changes year over year, if not faster. MVC has been a revolutionary paradigm for modern web apps. It helped millions of developers build awesome applications and launch exciting startups. Yet there is a reason I keep butting in with the notions of microservices and serverless technologies. These unrelated topics are actually excellent supplements to one another. To clarify, I believe some points in my previous post were misconstrued as competition. Instead I hope you’ll see the relationship for what it is. An evolution.

Obligatory Google Trends Chart

2017 panned out pretty much as predicted. Laravel and Symfony stayed in the lead, while most other PHP MVC frameworks continued to fall behind. (Please don’t misinterpret the chart above as an indication of winners and losers, it’s simply a reference to gauge an interest in a particular search term).

The innovation is not stifled. There are some new players on the block. Especially Phalcon framework, which definitely deservers an honorable mention.

High level view

Generally speaking we saw that most PHP frameworks took a step up to offer PHP 7+ support. While, some like [cough] CodeIgniter, still kept the feature set as in PHP 5.6.

You may notice that I rarely discuss CodeIgniter despite its popularity. It is a simple and straightforward “framework” to build an easy app, but as your system begins to grow you quickly realize that you need a more structured approach.

The core has a lot of “code smells” (like complex nested if/else conditions). It doesn’t seem to respect PSR standards, doesn’t utilize some of the latest tooling like composer and latest PHP features. Documentation has been pretty stagnant as well. Perhaps CI 3, will offer something new and exciting, although considering the alternatives, a simple way to “glue” some things together is unlikely to make it to the top of my list.

Likewise, I am somewhat biased against the Zend framework, as one might have noticed with my previous rants about its lack of standards, complexity of configuration and a very heavy learning curve. Unfortunately Zend 3, which was recently released, doesn’t offer much in terms of improvements. Like many of the “new” versions of the PHP MVC frameworks it boasts an nearly quadrupled increase in performance. However, most of these gains are due to the support of PHP7, which is inherently faster. And 4x performance isn’t really that great when it takes ten time as long to build something in the first place. Then compare it to Phalcon, which is a thousand times faster…

I think Zend is an ugly beast of a framework with poor documentation, lack of any structure and all-in-all it is still a collection of components, but not nearly as elegant as those of the Symfony developers. (Just for a quick reference, compare the Symfony’s “Form” component’s implementation and documentation vs Zend).

Laravel 5.x

Just as it has been true for the last few years, Laravel continues to lead the PHP Frameworks movement. We have discussed its ease of use and relatively short learning curve in the past. To boot, you have access to Laracasts for learning, as well as a great ecosystem and tools like Envoyer, Dusk, Forge, Spark and a few others (important mention goes out to Homestead vagrant for local development).

I’d say that out of the box Laravel is the only framework that can truly allow a developer to easily bootstrap an entire application lifecycle (SDLC) from `git clone` to fully-fledged production deploy, using all the tooling within the framework’s ecosystem.

Laravel had at least two major releases in 2017 (Laravel 5.5 and shortly upcoming 5.6, if I am not mistaken … not to be confused with PHP versions).

Unlike other frameworks it actually introduced interesting architectural improvements to the routing system, the templating system and various tooling features.

Just as many other PHP frameworks, the latest releases of Laravel completely abandon support for PHP versions below 7. I say: “good riddance”. Honestly it sucks if you are stuck in a PHP 5.x environment, but really there is no excuse to run something that is over four years old in production.
OK, let’s add some context here. We are talking about PHP, which is relatively easy to upgrade, test and deploy. (If you don’t yet have a plan to upgrade to PHP7+, you’d better spend your January 1st with a napkin charting out an escape plan).

Additionally we have Lumen, which offers an elegant micro-framework (built on top of the familiar Laravel or “Illuminate” components). It can be easily integrated into the Laravel MVC stack as it is fully compatible with Laravel core.
If you wish to use an “Eloquent Model” from your MVC Laravel app inside the Lumen API app, you can do so very easily by adjusting configuration (pointing Lumen to make use of Laravel’s models).

Most other frameworks do not offer such flexibility. You either have to wire together your own components or use stand-alone applications and figure out how to bridge autoloaders or even make the service container accessible in a consistent manner across your applications.

It should come as no surprise that the Laravel framework is under constant development. Being so popular there are a lot of contributions, peer reviews, and tooling (such as IDE plugins) available specifically for Laravel (Lumen).

Looking to get started on a new project? The choice is simple, you can’t go wrong with Laravel. Unless you have some very specific and unique requirements.

Perhaps one of the frameworks below can satisfy those…

Symfony 4

If I was going to mention one framework, which has been a rock-solid staple of the PHP community, it has to be Symfony. Symfony components (PHP libraries) comprise many of the other tools and frameworks (i.e. Laravel and Yii) in the PHP world. The company behind the PHP framework, Sensio Labs, has been around for about twenty years and are responsible for pioneering tools like composer, defining PSR standards and providing incredible services such as Sensio Insights and

Stability, consistency and extreme modularity is what traditionally made Symfony great and thus popular among developers.

With the new version 4, we are seeing even more innovation introduced with Symfony Flex. Something that I mentioned in my previous post is a seeming tug of war between monolithic and micro-architecture apps. Fabien Potencier (creator of Symfony) addressed the same issue in his post in great detail… but not only that, he pivoted Symfony 4 to favor composition over inheritance approach.
In short, it means that there is no longer a dependency on one large core codebase, i.e. the `symfony/symfony` bundle. Rather each item or module, like form validation, can be easily turned on and off via Flex (auto-discovery and auto-configuration).

Symfony Flex automates the most common tasks of Symfony applications, like installing and removing bundles and other Composer dependencies. Symfony Flex works for Symfony 3.3 and higher. Starting from Symfony 4.0, Flex should be used by default, but it is still optional.

— Symfony framework

Additionally it provides the necessary tooling to handle projects large or small and allows you to swap the components in and out as needed. Keep the bloat down and functionality up.

So why wouldn’t you pick Symfony over Laravel for your project? The only reason I can think of is a bit of a simpler learning curve for Laravel. Additionally it seems like you can find a solution to almost any Laravel/Lumen related question or error, since it has so many users (especially novice ones). Ability to lookup solutions to problems via StackOverflow or blog posts should not be underestimated.

If you are just starting out and trying to decide between Laravel and Symfony, I recommend that you write a simple app like a “Blog” with comments and authors, or a “To-Do” list with input for tasks and triggers for completion.

An app of this “size” should contain no more than a couple of database tables and should allow you to understand the basic philosophy and development approach of the PHP framework you are researching. See which one suits your way of thinking and fits your requirements. If the basic review of documentation and blogs like this one do not paint enough of the picture for your needs, roll up the sleeves and get to codin’… it’s the best way to know for sure.

And as a pro you should probably approach such a comparison using a TDD (or BDD) approach. Thereby unleashing the power of test suits (which must be) available with the framework; if it’s indeed worth your time.

Phalcon 3

This time around I’d like to talk about Phalcon MVC. Although it may seem just like another PHP framework (do we really need another one?), what makes Phalcon different is that it’s not a typical PHP MVC that you’d install via composer. Instead, it is a C-based, compiled PHP extension that is blazingly fast.

Unfortunately I would say that this is the only major area where Phalcon stands out. It’s crazy fast, but otherwise it’s rather bland. I can’t imagine too many developers would expect to write up their own `index.php` file and routes from scratch (or by via clever copy/paste). Likewise, there does not seem to be any skeleton structure that would guide a developer as to how to get started. That being said, if you’ve worked with other frameworks it should not be hard to figure out.

Manual bootstrapping process aside, the framework is reminiscent of the early releases of CakePHP as it’s still rather limited in features, but has a somewhat familiar structure and syntax. Even the terminology of “models” and their “behaviors” should ring a bell with those who’ve done some CakePHP work in the past.

Overall, Phalcon’s ORM makes use of PDO and has a simple and consistent syntax. Phalcon may be a new player, but it certainly has a unique edge in the space. Considering it has over 8.5 thousand stars on Github, the framework definitely has a strong momentum.

Why would you use Phalcon over some other framework? Speed. Plain and simple.
If you don’t feel like bothering with caching strategies or setting up additional hardware (or software layers) just to handle extra requests, Phalcon may be exactly what you are looking for. After all it has all the features to build a solid MVP-version of the application and make it really fast out of the box. Seems like a perfect use-case for an app that focuses on the speed of processing first and foremost.


Once again, I would have to place the remaining frameworks i.e. CakePHP, Zend, CodeIgniter and Yii into the “other” category.

I just don’t see enough benefits to pick any of the above (“other”) frameworks over the aforementioned competition. This is not to say that the these frameworks do not have anything to offer, but their edge and niche is much smaller compared to the big players.

For example CakePHP really stood out as a top framework back in 2014, however it has lost its edge over the years and got overshadowed by the ever-popular Laravel. That said, CakePHP still has many beloved features and mantras such as convention-over-configuration approach. Plenty of automagic for request handling and form validation. As well as and an excellent ORM featuring a Repository pattern.

Yii, especially version 2.1 release, will bring forth the latest PHP support and an improved ORM. I can’t say that it stands out in any specific area. Its learning curve is likely similar to that of CakePHP. It is not quite as powerful as Laravel and definitely lacks in the ecosystem.

I would chose it over CodeIgniter or Zend, but it seems to fall more than a few notches below Symfony and Laravel. The framework is pretty much in the same boat as CakePHP 4. The framework is growing and is relatively powerful, but it is introducing features, which were available in other frameworks for quite some time at this point.


So what about microservices? After all my previous post focused on them quite heavily. Some people mistakenly interpreted that as a “demise of MVC” or some other apocalyptic prediction.
It is unfortunate that my attempt at bridging the concepts did not come across as clear as I would have liked.

My goal is to focus on the trends and to consider “miroservices” or “serverless” as part of a normal evolution of web development.

First we had static sites, we eventually managed to hook up dynamic content from some DB. Repetitive tasks were abstracted into libraries, which eventually evolved into MVC (or similar style) frameworks.

Microservices is simply the next level of abstraction, further decoupling various functions of your application into a separate layer of business logic. The important take away is that microservices allow you to ensure separation of concerns not just within the application layer (i.e. Models vs Controllers) but also within the deployment architecture. JSON API requests may be served by the AWS API Gateway, while front end is serviced via AWS EC2, yet both application talk to the same data store.

Let’s put it this way… if you haven’t received a call from a recruiter in 2017 saying “Yeah, we’ve got this PHP shop but now they are moving some of their platform and services to NodeJS and Docker”, well I guess you haven’t been paying attention.

Just like many PHP devs (or back-end developers or holistic of full-stack) picked up jQuery and frontend skills along the way after the rapid demise of DHTML in the early 2K’s. I’d say in the coming years separation between frontend and backend becomes more distinct as multiple client consumers (browsers, phones, tablets, tvs, robots) will simply become interested in JSON data.

Rich client UI libraries are easily handled by JavaScript (ReactJS and Angular) and cached at the edge (CloudFlare). While backend mostly serves as a data provider for the client consumer.

Do not despair. Backend architecture still drives the vast majority of your stack. That said, it is more important than ever to be well-rounded. One module of the application shall not compensate for the competency of the other. Today we are able to architect amazing applications from the the minute details of user UI to those of API results caching. In no small part to many years and rigorous work by the Open Source community.


In the coming year we are going to see more companies implementing microservices (and/or serverless) architecture and I strongly recommend getting yourself familiar with some of the popular platforms such as AWS Lambda. And the incredibly powerful Serverless Framework.

No this isn’t PHP MVC, but it will be an outstanding supplement to your skillset as a backend developer. Perhaps you could make it your new year’s resolution to learn more about NodeJS or GoLang.

Otherwise I suggest that you brush up on your ReactJS and Redux skills and get some functional programming concepts down, as those skills are going to be in high demand.

… and have yourself a happy new year!

p.s. For those more adventurous I highly recommend getting familiar with some blockchain technology such as Ethereum and its underlying contract language Solidity. Better yet a framework like Truffle.

Also published on Medium.

  • Paul Hendry

    how can you say laravel and symfony lead – when symfony is almost neck and neck with CodeIgniter according to your graph :s

    • Because the graph measures Google search volume. It’s barely an indicator of the quality of the framework.

      I wouldn’t bother writing up a detailed analysis of why a specific framework is better architecturally, if all that’s needed was a chart.

      You need multiple data points to make an informed decision, framework or not.

      • Paul Hendry

        my point was that your statement comes after the graph – which leads people (or at least me) to think your statement is made of the graphs’ analysis..

      • i edited the sentence to better explain the purpose of the graph.
        still even on the graph symfony is overtook CI in the recent years, although both show similar search volume. more likely because of CI’s lack of documentation :)

  • Mark Richards

    Does anyone know the meaning of “seagues”, as was used in the summary or introduction to this article. I do not believe that it is a spelling mistake, somebody on the Editorial team clearly believes it exists and if that be the case, I certainly have no idea of its meaning.

    • I’m not an editorial team… :)

      • Mark Richards

        I too considered that possibility but if that was the case, it would have implied a serious spelling error. As programmers we are offended by such blatant errors. The use of a linter or spell checker would have spared the editors of PHP Weekly the shame of looking like a bunch of muppets.

%d bloggers like this: