PHP
Article
By Vlad Kobilansky

The State of PHP MVC Frameworks in 2017

By Vlad Kobilansky

This article was first published on ZenOfCoding, and re-published here with the author’s permission.


A simple question prompted me to sit down and write this follow up to my article from about a year ago.

Q: Any thoughts about where things are today? (2/24/2017)

A: “I’d say it’s pretty much down to Laravel and Symfony at this point; when it comes to PHP frameworks. I don’t feel that there is any specific value to using CakePHP, Zend, CodeIgniter, Yii, etc. if you are starting a new project.

Only if you already know those frameworks or have developers that are used to working with them, I could see a reason to use them.

When real development starts you have to be able to find tools, plugins, answers to common problems. And with Laravel and Symfony communities and constant development of new “modules” or features, you never feel like you’re left behind. Laracasts alone (even if you don’t develop in Laravel) are simply fantastic.

Whether it’s integration with services like iron.io or other SaaS providers, support for a wide variety of data-sources, local dev env like Homestead, these frameworks and supporting modules are much more forward driven.

Complimented by Lumen for quick API development Laravel really shines as a great approach to rapid application development and prototyping nowadays. Not to say that it’s somehow limited [when it comes to building] larger applications.

Generally speaking, however, we’re definitely seeing a shift towards a container-based architecture, where MVC plays a much lesser role. It’s all about microservices, orchestration and building apps as “functions” (i.e. AWS Lambda and similar services). Perhaps it’s time to brush up on your Node/JS and GoLang skills :)”

Although I felt generally happy with this answer, I couldn’t help thinking that elaborating on some of these points and taking a fresh look at where things are would be a good idea.

Before I jump into the strange topics like “GoLang”, let’s actually take a step back and glance at the trends in 2017, in the PHP MVC Frameworks World.

PHP MVC framework trends in 2017 (CakePHP, Laravel, Symfony, CodeIgniter, Zend)

I would say that the trends we’ve observed in the past are holding up. Laravel is still pushing forward, while most everyone else is falling behind. There is a little uptick in Symfony popularity, probably due to the much awaited release of Symfony 3.

(I have tried more specific searches for comparison such as “CakePHP 3”, or “ZF2”, however those did not produce statistically significant trends).

This year I’ve included CodeIgniter because it is very popular, as evident. I received a number of questions about CodeIgniter and my thoughts on where it stands in the PHP MVC community…
Well to keep it short, CI is still out of the competition because it’s not a true MVC framework. I don’t know what to call it other than an organized collection of POPO’s …

Let’s just take this quote directly from their manual:

CodeIgniter has a fairly loose approach to MVC since Models are not required. If you don’t need the added separation, or find that maintaining models requires more complexity than you want, you can ignore them and build your application minimally using Controllers and Views.

When it comes to building a framework I simply disagree with this approach. Perhaps it’s a decent boilerplate, hence CodeIgniter’s popularity, however there must be some discipline enforced by the framework, otherwise the eventual product winds up being a mess of spaghetti code, wrapped into some sort of a “pattern”.

Moving on, Symfony 3 brought us some decent improvements in developer experience, dependency injection and a number of other features. Like many PHP counterparts it now offers a micro-framework. ZF3, comparatively, delivered a set of improvements, like support for PHP7 (finally) and even a micro-framework of its own… but like their manual says:

For Zend Framework 2 MVC users, the differences are subtle…

I was really hoping that they would say that the differences are dramatic, that there was some great architectural improvement, wonderful new modules that help you develop things in a modern way. Alas, for the most part ZF3 remains pretty similar to ZF2.

Long Story Short

Here’s how I see the world of PHP frameworks today:

  1. Symfony or Laravel, depending on your needs
  2. The rest

Hands down, Laravel stole the show. The amount of information available, Laracasts, world wide developer talent, simple pattern implementations, integrated testing toolsets, active record implementation in the form of Eloquent, lightweight version in Lumen, local development using Homestead (Vagrant) make this framework really stand out for new and seasoned developers.

However Eloquent models can get unruly and rather large in size, too many Laravel services may be created (not to be confused with microservices) and people start thinking about Repository pattern implementation where it doesn’t belong. Thus a Monolith is born.

If you are not comfortable with the active record pattern and need the added flexibility of Repositories, or perhaps you’re seeing too many anonymous functions for your liking, then use Symfony + Doctrine.
Do I consider Symfony a gateway to monolithic applications? To some degree, yes. However, it is probably the most elegant one.

Overall, I would not call it a drastic change from the last year. Still, we need to take a look at the bigger picture: a properly designed application goes beyond just MVC; it’s about infrastructure, deployment pipeline, decoupled architecture. All of these can be achieved in an MVC stack, but one needs to be extra mindful to avoid the Monolith.

Advent of Microservices

Earlier I’ve alluded to the rise of the microservices and the need to brush up on GoLang or Node skills.
Indeed, even in the PHP MVC article it would be silly not to mention a clearly happening move towards microservice oriented architecture (MOA); and it’s gaining momentum like you wouldn’t believe it.

While the two concepts are not mutually exclusive there’s no reason trying to find parallels between the two, as they really do represent different, albeit intersecting philosophies.

As an example, putting your MVC app in one container and MySQL in another and then linking them together, doesn’t necessarily represent a proper MOA.
This is certainly a better approach, in fact much better, than trying to install MAMP, XAMPP or whatever other clutter you need in order to get your local machine to serve an application.

Additionally, it may solve some issues like ease of running a local environment across different platforms (developers) and perhaps deployment strategy, in some cases, but you are stuck with an MVC Monolith in your app layer/container.

--ADVERTISEMENT--

Destruction of the Monolith

This “destruction” is what microservices are all about.
While MVC addresses your code structure and organization by providing a solid approach to the separation of concerns, this concept is extended even further by the containers/services/MOA.

Instead of just separating your views from your models, you are now separating each “chunk” or logical unit of your application into an individual service, designed to properly handle its own responsibilities.

If your MVC app has a “Search” controller, action, and relevant Model methods, then we already have an example of a monolithic application.

In contrast, using MOA approach, we’d have a service for each one of those processing units. As an example:

  • Router Service
  • Request Service
  • Query Service
  • DataSource Service
  • Response Service

Wait, but aren’t all those “services” are just a part of an MVC stack. Well, yes, exactly. They are the building blocks of our Monolith.

With MOA each service runs within its own environment, and as developers, but more so as architects we are free to design the best approach to solving a specific need.

As an example if I were to write an Image Processing Service within a Laravel environment, I’d probably be using something like PHP-GD2 extension, which may not be the most efficient way to process images. A C++ service that handles my needs of image processing, may be a lot faster and definitely more robust at scale. To elaborate even more we could now take the output of the Image Processing Service and send it off to DataStore Service, CloudStorage Service and Queue Email Service.

Solving this same challenge with a bunch of cron jobs and possibly a couple of separate MVC apps and custom scripts is how we did things back in the day (i.e. 2 years ago). Time to move forward.

Scalability

This is where the problems start (or end, depending on where you are headed). On one hand it’s hard to scale a Monolith, if you build more and more logic into the same MVC stack you’ll be stuck with, perhaps, a well structured application of horrendous complexity.

On the other hand if you build a thousand microservices in a variety of languages, how do yo manage THAT mess?

There is more than one disaster that has been reported.

There are various container orchestration tools (like Kubernetes, Swarm, Mesos), container deployment services (i.e. GKE and AWS ECS), however few enterprises have nailed the Docker architecture. There are definitely success stories in building out of the infrastructure using Docker or other container technologies (i.e. GKE). Most of these stories come from companies that can afford to spend resources on architects, devops, DBA’s and engineers. Still, as it stands now there are countless debates about how to deploy a well orchestrated and elegant MOA. One size definitely does not fit all in this case and there is a multitude of ways to solve your challenge.

Either way you’re not going to solve this problem alone (DevOps FTW!), and not until you’ve hit a relatively massive scale, will this problem actually need solving. Maybe it’s not the right time to over-engineer.

A happy middle for today (and for those that deal with apps of lesser complexity or traffic requirements) is to offload many typical services to third party providers. Almost everything is available as service now. Background jobs, image processing, authentication, data analytics, logging, email sending, queue systems need not be built within the same MVC stack, rather an Architect should think about what could be offloaded to a SaaS system for a low monthly cost (i.e. search by Algolia) or perhaps a custom-built docker service running in some cloudy space, which handles that annoying image processing.

I guess the point here is that you should not jump into a re-architecture project head first, do not dump everything you have today, and release docker swarms wherever imaginable. There are ways to gradually roll out an improved foundation by decoupling what’s possible, learning about bottlenecks in the system and applying the notion of separation of concerns to these problem areas.

Conclusion

2017 is going to bring us more conversations and production deployments of container-based and MOA. My points and ramblings about Docker, using GoLang or Node, do not mean that PHP is “dying” or anything of that sort … I feel that as developers we need to stay on the cutting edge of things, so if microservices is where it’s at, then why not learn GoLang? It is ideally suited (due to low footprint, speed and parallel processing) for developing tiny containerized apps. Node and GoLang are fun because they allow you to build little services, who are all part of a larger tribe, link them together, and release them as an epic swarm of Docker containers if you so desire.
Yet, all this awesomeness and cutting edge solutions and languages does not mean that PHP is somehow no longer relevant or is otherwise “dead”. We’re definitely going to be building MVC stacks and API endpoints for a while.

One of the issues, which has not been solved by MOA, is that while containers help us to kill the Monolith on the backend we are still faced with many architectural issues in our front-end layer, UI or the view.
We can build an awesomely robust backend application, but in the end it will respond with a JSON, which somehow must be rendered in the client application. Does it matter if the eventual response object arrives from a simple PHP, let’s say, Lumen driven endpoint (URL) or an orchestra of decision making and processing units decoupled by a messaging interface? This, indeed, very much depends on your needs and the requirements of your application.

For this year, learn Laravel keep an eye on Docker, GoLang and definitely focus on the deployment pipeline. Getting from local to production should be smoother than it has been for a while now, especially when building your MVC apps.

  • HMS10

    What do you mean “Symfony or Laravel, depending on your needs”?
    What about Phalcon? Is not it the fastest PHP framework?

    • Bruno Škvorc

      It is, but it’s questionable if that speed gain is even necessary any more these days. Some modern benchmarks would be cool.

      • Pinco Pallino

        Symfony is bloated. Twig is slow like hell and it has the same functionalities as Volt, which is blazing faster. To boost the performance Symfony needs a bootstrap caching file. The configuration is horrible and these bundles are nidicolous. Performances are really important, that’s because Facebook did HHVM and the Hack language. Phalcon is far a better choice. Symfony has some good components, like the Console or the DomCrawler, but the framework itself is full of shit, complex and slow.

    • Herloct

      In my benchmark, phalcon really fast only when bootstrapping code, to showing up hello world or templated view.

      When database involved, the performance isn’t significant then any other frameworks.
      Well, it still faster than laravel and symfony though…

      • Pinco Pallino

        Phalcon is faster, fullstop. The routing is faster, the ORM is faster (if you want to use it) and so it is the template engine. And you don’t need necessary a YAML file for the configuration, you can use a faster INI file, which is enough, especially for MOA.

        • Xander

          I bet that most of the use-cases will never come to a point where somebody woud complain about the performance issues of the framework.

    • cons of phalcon:
      1) very unusual database active record. No raw sql, no eager loading, hard to learn and use
      2) performance isn’t much better than any other framework in real application
      3) too much thing you need to do on your own.

      With that said if you need performance you don’t choose php.
      You choose php for rapid fast development and phalcon doesn’t give any of this :(

  • Laravel apps are a bit of a bother because of all the magic, smoke and mirrors they use, what with the facades etc. When you know Laravel well, it probably doesn’t matter as much, but I’ll always prefer knowing which class and object actually gets called, and certainly prefer dependency injection over global “static” calls.

    Not to say Symfony is much better, with its configuration files and annotations.

    I usually go for Silex. It’s not perfect, but I think it strikes the right balance. I can also roll my own with as little as:

    {
    “require”: {
    “pimple/pimple”: “^3.0”,
    “aura/router”: “^3.0”,
    “zendframework/zend-diactoros”: “^1.3”
    }
    }

    • Xander

      Since version 3.1 I’ve been choosing Laravel for my projects.
      At work I have used Symfony and I actually like Symfony’s way of configuring things better. Still I will choose Laravel for my next projects. It feels more alive and right now, if you know what I mean.
      I never use facades. You could, but I’d rather __construct(Factory $view) and then do $this->view->make(‘home’) then View::make(‘home’); or view(‘home’);
      Whatever your project needs I guess.

      • Théo FIDRY

        > It feels more alive and right now,

        You mean more hype? Because with all the changes happening in Symfony, I don’t know what you mean by alive, check the GitHub project you’ll see… :P

        • Xander

          Ok yeah indeed. Symfony repo is alive. Laravel on the other hand released these tings the last 2 years. And new exited stuff is coming..like the mysterious Laravel Horizon.

          – Laravel Forge(easy php servers),
          – Laravel Envoyer(zero downtime deployment),
          – Laravel Dusk(Testing framework),
          – Laravel Mix(Frontend tooling helper),
          – Laravel Scout(awesome fulltext search),
          – Laravel Doctrine(datamapper),
          – Laravel Lumen(fast microframework),
          – Laravel Spark(plug and play saas),
          – Laravel Valet(osx super fast local dev env.),
          – Laravel Homestead(local dev env based on vagrant)
          – Laravel Passport (a full OAuth2 server impl. in a matter of minutes)
          – etc.

          Then there is learning resources like Laracasts and the recently opened massive Test Driven Laravel TDD course(which is great for all php folks and beyond).
          Nevertheless, I really like Symfony too. Both are frameworks I support with a lot of love.

    • Mark Kasaboski

      Annotations are a choice. Symfony doesn’t force you to use them.

    • dojovader

      Thanks this is the same reason i stick with Symfony too, am not a fan of magic

  • Cory Long

    I’ve used all the frameworks mentioned except symphony, and I primarily use CodeIgniter. I’ve never found arguments that it’s possible to write bad code with CodeIgniter a particularly persuasive against it. I suspect CodeIgniter is as successful as it is because it’s intuitive to use, it helps as much as it can without getting in the way. Laravel, which I also love, has layers of abstraction, and a lot of specific Laravel concepts are needed to solve some problems. CodeIgniter isn’t going away, because it fills a need. I’d like to see it received better and discussed more often. Thank you for including it.

    • Herloct

      But CodeIgniter 4 looks a lot like Laravel, without many of it’s magic, blows, and whistles…

      • I think they have start copying Laravel concepts in it. One thing is missing is composer they should also add support of composer.

        • Cory Long

          Composer support is coming in CodeIgniter 4. Honestly, while I see the benefit of composer, I think there’s too much dependence on it, but that’s a whole other discussion.

          • Yes composer is love <3

          • Geovanny Morillo

            Really i hate composer… dont ask me why.. i did my own framework (prestomvc) only to get rid of it lol

    • Mark Kasaboski

      To be fair, you can write bad code in any framework and in fact bad code exists in every framework. Everyone writes bad code throughout their career. Either because of inexperience or because they’re forced to cut corners to meet a deadline. But this is how we evolve. It’s hard to know what you don’t know. We all have to go through these growing pains.

      The reason why CI was so successful is because it was one of the earliest PHP frameworks and its barrier to entry is very low. A lot of junior devs start with it because of exactly that.

      As you grow as a developer, though, and you begin to learn things about design patterns and SOLID principles and functional programming aspects you’ll find that a framework like CI (in its current form) just doesn’t cut the mustard and you’ll move on to other frameworks.

  • brzuchalski

    Those trends on a chart are simply searches by keyword. So I think there were lot more problem solutions searched over google than other frameworks. It’s good because this makes feel more PHP developers haven’t got so much problems with Symfony, Zend, etc. than with Larevil.

  • While I understand the concept of Microservices, I’d really like to see some sort of example in code for me to get the complete picture. Like how one service is connecting to another and getting data, how to design my app based on MOA, how big should it be etc.

    Maybe sitepoint can provide an example of it?

    • Mark Kasaboski

      So for example you could have an authentication service. There’s no reason for the authentication code to exist within your main user facing application. It could be an OAuth based service and what you would do is curl (read Guzzle) your credentials over to the your auth service and get and access token back. Once the authentication is done and you have authorized your user (scopes), that state is saved in the user’s browser in the form of a secure and http only cookie. Your user is now in there like swim wear.

      All communication between systems is generally done via RESTful APIs.

      Another example could be an email queueing system. Guzzle over all of your applications emails to the email queue. The email queue will either send them out immediately or defer them to a later date that’s determined by your application.

      Something like that is a huge benefit to large systems where emails can pile up and the server is working at full load to send them all out for a given period of time. It being on its own process separate from the main application is the big win here.

      • aznain

        Thanks for the nice reply.

  • Todd Zmijewski

    Very well said. I agree 100%.

  • Tony Marston

    > If your MVC app has a “Search” controller, action, and relevant Model methods, then we already have an example of a monolithic application.

    Rubbish. You are attempting to redefine what “monolithic” means which I find unacceptable. Wikipedia defines a monolithic system as one “in which functionally distinguishable aspects (for example data input and output, data processing, error handling, and the user interface) are all interwoven, rather than containing architecturally separate components”.
    If you have implemented MVC then you already have architecturally separate components, which means that it does not meet the criteria for being called monolithic.

  • Peter Popelyskho

    After symfony, laravel is like a toy for a little kid) Don’t get me wrong, Laravel is a good framework, but Symfony is my choice.

  • DarkLogic

    larathis, larathat, … come on! Get over it. There is a ton of great framework out there. All posts talking about Laravel as THE php framework just sound elitist and pretentious to me.

  • Herloct

    Yep, it change too much from an outdated codebase to a lot modern one.
    For me it a good news, but for those dinosaurs that hate modern php dev, i hope it wouldn’t create a conflict on CI community…

  • Pinco Pallino

    This is an advert, not an article. The arguments are simply ridiculous.

  • Drepto Sahil

    such a cheap article unfortunately.

  • nobrandheroes

    Just a heads up if you are interested.

    1. Laravel has a debugbar package. It might be a reskinned version of the one that is in Symfony, I’m not sure since I haven’t used Symfony that much. It is quite nice though.
    2. I think you can do annotations through a package, but it isn’t really the Laravel way. Convention over configuration and all that.
    3. Packages work like Bundles, but aren’t as easy to set up (they aren’t terrible, just no command line). It is a good enough solution that I’ve started the habit of putting all my code in packages so I can more easily upgrade core later.

    Both fill different niches, and both are great for different reasons, but they really overlap quite a bit too.

  • As for me laravel is easier for starting and the view engine is the best from all php frameworks.

  • There are many comments about the “smoke and mirrors” of Laravel. I counter with, use phpstorm. Laravel is built like a c# application with magic. You need an enterprise level ide to work on an enterprise level mvc.

    I like that laravel takes advantage of php instead of being scared of it. Magic is cool.

    I tend to role my own framework if I can. It’s lighter then the mvc’s and more functional then the light weight variants. And uses magic.

  • All of them follow the shared-nothing for code and bootstrap(open files, create objects, parse the routing…), those are the things that can be shared without compromising the stability.
    And the shared-all for sessions and user cache, those are indeed the things that should be shared-nothing.
    So why to bother? If your framework* or app code schange in every single request and the user’s session/input is immutable, use a PHP framework.
    *Phalcon is the only one that fixes the “framework code” issue.

  • David Connelly

    Terrible article. It’s clear to me that you don’t have any meaningful experience of the technologies that you’re so eager to ridicule. All I’m seeing is sound bites and surface level waffle. This kind of garbage hurts web development communities. It’s irresponsible, poorly researched and deserves to be called out.

  • Xander

    Laravel and Symfony are both two awesome frameworks. You just do not know your stuff.

  • Xander

    I like this thread. I also do not talk about things being inferior or worse etc. That is just dumb, right :D I’d like to thanks you for the answer. I do want to say that the laravel list could also be longer if I added DotENV and loads of other packages.

  • The Informer

    the benchmarks put Laravel stone last. fat free framework is the easiest one to learn. I love it

  • I am a very, very happy user of Fat Free Framework.
    For quick traditional / REST / API backends it’s superbly fast and utterly easy to learn (good documentation even if it’s not Laravel level).

    I am working in a team developing one business application and I am about to start a very large project with it.

    I have tested and loved other frameworks but none comes close to Fat Free Framework speed and ease of use.
    It’s not a “candies” container and you won’t find facades or other fancy stuff. It’s for compact-yet-features rich development with as few loopholes and performance hitters as possible.

Recommended
Sponsors
Get the latest in PHP, once a week, for free.