The great PHP MVC Framework Showdown of 2016 – (CakePHP 3 vs Symfony 2 vs Laravel 5 vs Zend 2)

PHP MVC Frameworks preview of 2018 Update

The state of PHP MVC Frameworks, 2017 Update

Hey buddy, it’s 2015!!

I do hope that some of the things I’ve come to see and understand over the years regarding various PHP MVC frameworks will remain true for at least another half a year. I’ve mustered the strength to write this up only after I had at least a few years of professional experience with each of the contenders… and about ten years working with MVC in general.

To be honest this type of post is only useful for a short while. Web development world is too fast paced to definitively say which framework or tool is going to rule the world. Just when something new comes out, another project seems to spring out of nowhere to steal the show.

However as we dig deeper into the features of each framework, certain patterns begin to emerge. We discover coding styles, configuration and setup requirements, modularity, performance, usability, learning curve and overall architecture. Invariably these lead to some sort of character development, a flavor, a unique approach to solve the problem of properly implementing the MVC paradigm. And as we already know MVC is a concept, which is somewhat open to interpretation.

Popularity contest

zend vs symfony2 vs laravel vs cakephp

Glancing at the data from google we can see some clear trends. (Not to be confused with “winners”; not for this comparison).

  • Laravel is the new kid on the block, soaring in popularity.
  • CakePHP is falling behind, largely because Cake3 came kinda late to the game.
  • Symfony(2) is consistently stable.
  • Zend is slowly dying… or not… it’s been a downhill battle for Zend either way.

Why didn’t I include CodeIgniter? While I’ve heard great things about CI3, it’s still in the very early stages and, IMO suffers from the same fate as CakePHP 3. While CodeIgniter is no doubt a popular framework its serious lack of a decent ORM has plagued my opinion of it for years… and to this day I believe that M (aka the Model layer) is the most important part of an MVC framework. Call me crazy, but due to this fact alone I cannot consider CodeIgniter as a strong MVC player. (Each framework has its time and place, but here I’d like to highlight the top contenders, which are ready for enterprise-level systems). Also, I don’t have enough experience with CI… so wouldn’t be very fair to be discussing something that I only know in passing.

That said, while these trends can tell us the general state of things, it is certainly not enough information to make a decision about which framework to use.

We need to really take a look at each one in just a little more detail…

#1 Symfony

In some ways it’s an easy choice. While it may not be the most trendy framework, it is certainly the most stable. Over the years it has captured a tremendous amount of momentum and what made it even greater is the impact Symfony community had on PHP in general, tools like composer, Doctrine or PSR standards are in no small part had become the de-facto standard for many other PHP toolsets because of the Symfony’s efforts (to be fair, not just Symfony alone).
Symfony components not only establish the base for the Symfony2 MVC framework, but the Laravel framework was born out of these very components as well. This definitely goes to show that as far as striving in the PHP ecosystem Symfony seems to be on top of their game.

Their mission statement alone makes me smile:

Symfony is a set of PHP Components, a Web Application framework, a Philosophy, and a Community — all working together in harmony.

Symfony is extremely modular. Everything in Symfony is a bundle (of MVC goodies), which makes the framework architecture very extensible and flexible by design. It works wonderfully well with composer, namespaces and autoloaders… all important aspects of a well structured application.

I would argue that because of the ability to use various ORM systems (i.e. Doctrine or Propel) Symfony is a beloved framework. If we are honest and true to the MVC paradigm, and keep our business logic in the Model layer, having this flexibility of ORM style is a fantastic opportunity for any developer to pick and chose their preferred programming philosophy. That’s powerful.

One should not ignore the community around each framework. Symfony has a very knowledgeable community with many questions having a variety of clever and interesting answers.

That said Symfony is somewhat complex in its structure, it is “bulky” and requires a fair bit of configuration, which can be confusing to grasp at first. However, I also feel that Symfony strikes a great balance of being highly modular and configurable, while maintaining a level of comfort by overall employing rather simple configuration strategies (i.e. YAML files or annotations). Once the developer understands the overall structure of the application things begin to fall into place rather quickly.

#2 CakePHP 3

I love cake’s mantra: “convention over configuration”. While some disagree and say that CakePHP has entirely too much auto-magic, its power lies in nearly effortless configuration. Just follow some basic rules and you can start developing powerful applications in no-time. (Or just turn on “scaffolding” and magically views and forms are created for you, or “bake” the entire app… all based on your DB schema and relevant definitions).

One could say that I am biased towards CakePHP, since I’ve been working with it for so long, and while that’s true I’ve also spent about 4 years with Symfony, Magento and Zend… I have also worked with Laravel 4 & 5 for a little over two years, so I truly hope that gives me enough developer insight and a solid understanding of the underlying concepts of each framework.

And that’s what really distinguishes one MVC framework from another, the philosophy behind it and the code architecture. How did the core team solve the paradigm of MVC? Is the framework truly extensible and scalable? Does it fulfill the meaning of rapid application development philosophy?

This is where CakePHP 3 shines, the developers took the time and effort to learn as much as they can from other frameworks (even such as rails to some extent) and previous CakePHP versions, apply some great principals such as aforementioned “convention over configuration” and ORM that was built from the ground up.
And I have to say of all the PHP frameworks cake’s ORM is probably the most pleasant to work with. There is a bit of a learning curve to grasp the concepts, but once you do… the way it elegantly handles associations between tables as well as data-saving and validation, is just a joy.

Perhaps it simply jives with the way my brain works, but things in CakePHP just make sense.
For applications that require RDBMS functionality CakePHP kicks ass!

Cake’s problem? CakePHP 3 arrived just a little too late and it just isn’t mature enough. There are some great applications already built on CakePHP 2.x, and migrating everything over to CakePHP 3 (there really isn’t any backwards compatibility) leaves people wondering if they should opt-out for Laravel instead, yes I’ve been in that boat myself. I do have a personal dislike for the core lack of support of MongoDB. It is rather simple, while CakePHP 3 supports ElasticSearch (sometimes considered superior to mongo), it’s kind of like including support for PostgreSQL and bypassing MySQL. Modern frameworks should offer support for majority of popular data stores and MongoDB is definitely extremely popular. The beauty of it is that there should be enough community support to make that happen.

… And CakePHP community is fantastic, it often feels like a little “click”, but that is what makes it great. I’ve been a part of that community for years, and have learned a great deal about good architecture and programming by following (or sometimes avoiding :) ) the teachings of great developers behind the framework.

I didn’t get into details of Symfony’s ORM because it uses either of the two pretty much stand-alone libraries. Cake’s ORM is different.
In the previous versions CakePHP 2.x the ORM got some hate because it wasn’t truly OOP and wasn’t very flexible. I have to say that cake developers did a great job refactoring the ORM. The model layer was revamped with Entity and Repository classes, which represent records and tables, respectively. This is a welcome addition and shift, making the ORM a lot more object oriented in nature and provides a great level of flexibility when writing and testing your code.
Additionally there is a certain level of similarity between Symfony’s and CakePHP 3 ORM. I would say that I prefer cake’s just a bit more, but it is due to a much simpler initial configuration and coding philosophy. Practically, however, it truly is a matter of personal choice.

#3 Laravel

The little baby of Symfony. Although it’s almost all grown up you do have to admit that it leverages a great deal from Symfony… and actually that’s fantastic. Not only does it not try to reinvent the wheel, Laravel also keeps things simple. It uses stable, proven and solid Symfony backbone to setup an entirely new way to code within Laravel’s own MVC world.

Perhaps some things are kept overly simple for my taste. Lack of structure is something I cringe at whenever I see fat controllers or logic sprinkled in places where it doesn’t belong (keep separation of concerns in mind)… To be honest, that’s where I lost trust in CodeIgniter.. it was too loose and “open to interpretation”. Of course, there is exactly opposite school of thought, which says “over-engineering is the root of all evil”. And I agree, but I wouldn’t agree with keeping something simple while sacrificing the quality of the code and maintainability.

Technical debt is a real and very serious thing for any IT system, which is present in any modern company be it an accounting system, a CMS, a gaming app, or a web property of some sorts. Trying to repay this debt “later on” can lead to a real bankruptcy.

Unlike CodeIgniter, Laravel does a much better job of enforcing some structure, but not quite as good as CakePHP.

It also leaves the architecture a little more open for 3rd party plugins (packages) rather than following a more strict plugin structure of CakePHP. I would say that such approach has both pluses and minuses. While in most cases it’s much easier to re-use an existing component. Completely relying on third-party libraries can eventually lead to a maintenance nightmare, something that larger Symfony projects often suffer from as well.

Eloquent ORM is Laravel’s greatest strength, as it is its weakness. It reminds me of an earlier version of CakePHP’s ORM. Yeah it’s great and simple, but because it’s so simple it is not as well structured and granular as CakePHP 3 (or something as advanced as Doctrine). However, one would say that this is exactly the way it was intended to be, and I can’t really disagree with that.

Yet, one conclusion I would draw from that is that Laravel is probably best to use as a front-end framework, which does not require complex data store functionality. It is perfectly suited to be a service layer with its integration to and other popular SaaS providers (AWS, S3, sendgrid, etc.), Laravel provides a simple way to build and consume API’s and a clever and (again) simple way to setup routing. As said, it’s a perfect interface to a more complex back-end system if there is such a need.

Unit and functional testing is something that I should have mentioned at the very beginning, but at least I’ll devote a paragraph to it here. Unit testing in Laravel is a pleasure. (Actually all aforementioned MVC frameworks have fantastic testing facilities).

Laravel, following its KISS model, makes no strict guidelines as to how to structure your tests, but it does provide all the necessary tools to write effective functional and unit tests to give you exactly what you are after — good level of code coverage.

#0 Zend

Not unlike Symfony, Zend also provides a collection of components, however… very much unlike Symfony, Zend does an extremely poor job of helping the developer to leverage them. Yes, there is solid documentation and tutorials, but Zend framework is missing the most essential part — The framework.

The collection of components by themselves is great, but every time you write an application or even a part thereof, you have to pretty much write a mini-framework just to get things to tie together.

As far as development philosophy of extremely heavy configuration (yes, the amount of config and coding required to start writing a controller is enough to write a little application in most other frameworks), I simply cannot embrace that.
Additionally Zend does not provide any ORM or a decent API to facilitate an integration of one (like Symfony), which leaves the Model layer entirely too loose. This, as I’ve mentioned above, can often lead to poorly structured and untestable code, fat controllers, and other OOP violations.

Although both Zend and CodeIgniter support Doctrine ORM integration, neither provides a native interface to use it. While the integration may not be overly complex, it again requires more and more overhead and configuration (and coding).

For Zend, it would best to drop the framework effort and dedicate their resources by teaming up with Symfony and really influencing the PHP community in a positive way. All in all we wouldn’t have questions like this. And I don’t think we should. Their components could be very beneficial to the community especially if paired and refactored into Symfony’s ecosystem. Zend’s effort at the “framework” seems to be an uphill battle, while all the necessary aspects of integration are already implemented in Symfony. It just doesn’t make a lot of sense to spend all this time building something that desperately needs the missing link, which is already available in Symfony MVC.

Here’s the thing, if this is what it takes to write a single basic “blog” module that pretty much has no logic, then the framework does not satisfy the requirements of RAD (rapid application development). It makes things hard to configure, maintain and troubleshoot. By contrast in CakePHP all you’d really need is a table called “blogs” with aforementioned fields… talk about automagic.

Controllers, Routing

I would say that all of the above frameworks offer a pretty solid routing system and controller setup. I don’t want to dwell too much on this part, since I really have no complaints or preferences about how each framework chose to handle these parts of the system. Also while routing is important, the controller layer just like the controllers themselves should be light in implementation and mostly delegate requests to other parts of the framework.

I should mention that CakePHP’s routing is pretty clever, with all sorts of interesting options. As you’d expect Symfony’s is very configurable (and in some ways that can be pretty annoying, having to map everything, albeit in YAML files or annotations, which I am not crazy about)… and Zend, as it stands, will require you to write a ton of code to achieve something rather simple.
With CakePHP you get most routing features right out of the box, i.e. you don’t have to setup anything, just name your controllers and views according to the rules and everything will be routed for you.

This is where CakePHP’s routing is powerful, but often misunderstood, because some developers may never have to get to the more complex routing setup. Once you do, then you really have to dig deep to understand all the hidden gems.

Just another area where each framework solves the problem in its own right, but each one does so in a pretty sound technical way following their own coding methodologies.

Templating and Views

While PHP itself was created as a templating language, there are a few reasons why you might want to chose another templating engine to render your views. One obvious reason is that many designers do not like working with embedded PHP code, and while there is nothing scary about it, if you have a front-end team that prefers to work with a specific templating language, then it has to be considered. Thus having a flexibly of choice is kind of important.

CakePHP and Zend use plain PHP views out-of-the-box, while Symfony and Laravel use Twig and Blade respectively. I don’t see anything particularly useful about blade, other than a cleaner syntax than PHP, while Twig offers template rendering/caching and some level of template-layer security.

That said, you can switch your templating engine in each of the frameworks, so if you aren’t happy with the defaults and chose to use Twig, for example, then you have an option of doing so.

If I had to go with a choice of a templating engine that is available out of the box, I’d recommend Twig.

In Twig, your template designer can’t easily take shortcuts. Eg. calling a query in your templates. They’ll have to pass the result to the view or allow access to a certain function (or ask the backend developer). The downside is that it is more work to just call a simple function/filter sometimes.

This alone makes me want to chose Twig over any other templating engine. I’ve seen plenty of apps that do crazy things like attempt to access DB information from a completely unacceptable place (i.e. the View or partial or element, etc.) and then do relatively heavy data manipulation right in the template. This kind of short-cut breaks MVC and violates separation of concerns, therefore from the maintenance perspective and even TDD it should be avoided at all costs.

Nice writeup on Blade vs Twig comparison.


All frameworks have pretty solid documentation at this point. While each one was faulted for lack thereof in the previous years, I firmly believe that documentation for an open-source project is a community effort. No framework should be blamed for lack of docs, however the creators of the framework are responsible for putting forth some foundation for quality documentation of the framework’s features.

With all that said, here’s my quick take on the situation.

Personally I prefer the documentation with open comments as Zend has it, there are often more great answers in the comments than in the doc itself. Given the complexity of Zend the documentation seems to be a little light on the details of some implementations.

Laravel’s is a little skim, because the framework is kind of new, but it does a good job of covering the things you need to get going.

Symfony only covers the basics and I wish it would elaborate on some topics.

CakePHP’s has matured to be quite good and extensive.

That said, you can pretty much find an answer to any common problem with each of the frameworks in minutes, by firing up your trusty search engine.


So who’s the winner? Which framework should you use?
That was a lot of writing with nothing clear emerging so far, although you probably gathered that I like CakePHP, dislike Zend, think that Laravel is slightly overhyped, and feel very passionately about Symfony.
However, my feelings and emotions have little to do with what’s best for your project.

Use the right tool for the right job. (I’m sure that’s what you wanted to hear).
If you need an extremely modular and well supported framework go with Symfony 2, if you want fast prototyping and ease of use go with Laravel 5, and if you want something in-between go with CakePHP 3.

Besides, you should make some decisions before making your choice.

For example: what is your data store(s), how well does the framework support it out of the box? Do you understand and agree with the framework’s coding concepts after looking at a tutorial or two?
How’s the community support? Are there enough documentation to understand how to solve basic things like data validation and traditional CRUD operations? Last, but not least, what technology do you have in place now? If you are running Microsoft SQL server and everyone on your team knows python, perhaps a PHP framework is not the best solution.

The framework has to make sense to you and/or your team of developers. First and foremost development within any framework should be making your life easier, but one should anticipate a learning curve and in many cases it can take well over a year to really understand the nuances of a given framework.

I didn’t include micro-frameworks (i.e. silex, slim) as they tend to fall into a different category. After some pondering I might just do another write up on that. After all, as we see, more and more often the general trend is to move away from complex monolithic applications to a more micro-service-oriented architecture.

Also published on Medium.

  • Aguirre

    Nice article! I’ve starting to dive on PHP and choosing the right framework is my first step. Cheers!

    • thanks for the feedback, if you are going to use some sort of DB consider if the framework’s documentation makes sense. i would say for a beginner frameworks that utilize doctrine, etc. might be a little over the top. i would try laravel. (or cake)… unless you clearly understand or prefer using a specific ORM.

      • Aguirre

        As of now, I choose CakePHP but will also study Laravel. Thanks for the tip!

  • addinall

    All of them are rubbish.

    • khalid

      haha are you ok Man ?

    • sodapop7

      agreed. this is not programming anymore, loading and writing all this shit in 3000 files in order to print a string. The overhead of overheads

  • Eoin

    Nice article – but nothing about performance. I have been using Symfony for a while now and it seems a little slow within the development environment particularly. I will probably look into the various ways of speeding it up but, out of the box, it’s a little slow for me. I’m considering switching. Any views on performance of the respective frameworks? Thanks.

    • Framework performance is a complex subject. I would not recommend measuring an MVC framework performance based on response times alone. First and foremost, a framework should speed up your actual application development. If you are purely after speed any micro-framework, (i.e. Lumen) will be faster and can possibly solve your needs (depends on what you are building). For enterprise-level applications you usually employ caching strategies, DNS, APCu, proper static asset hosting, etc. There are ways to speed up any web application which should be done regardless of the framework. IMO, when you are building a relatively complex app squeezing milliseconds out of your code is a lost cause… most likely your bottlenecks will be in session management, I/O and database.

      • Eoin

        Thanks, yes I realize there are a myriad of considerations when it comes to implementing a framework in a production environment. Is it reasonable to infer from your answer that you don’t think there is a significant performance difference between any of the PHP frameworks? As I said, I’m not so much concerned with the strategies I might employ in a production envrionment at this point.

      • No, there is definitely a difference with “out of the box” performance. So if all you need is to build a quick app with the fastest response times, you should probably look at something like Lumen. Which is going to be really fast, but lack “advanced” features. However, you have an easy path to upgrade to Laravel.. and you basically get the ability to use Eloquent ORM, which is powerful enough to deal with most common DB interactions.

        But then again, CakePHP has “view caching”, which makes your app really fast if used properly.

        Since you aren’t concerned with production “strategies”, I would recommend simply picking a framework that makes sense to you when you are reading the documentation and looking at examples. When all said and done many of them essentially do the same things: routing, form construction/validation, DB interaction, user auth of some sort.

      • ss

        what i think is what i get

    • Ahmed Abderraham

      Symfony’s dev environment has a great profiler enabled by default, plus the dev toolbar, disabled cache, etc… So yes, it will be slow, profiling alone makes for a good chunk of extra processing time. In my opinion, the benefits of the always-on profiler and the toolbar greatly make for the added overhead, and really pay off because they make you optimize your code to the limit.

  • Sergio

    So what are you think about Phalcon? It really different from all others and it gains popularity quickly

    • Alexander Diachenko

      I would say Phalcon is already past it’s peak. There was a lot of people who considered it around the release of version 1.3 or so and moved on because it doesn’t really offer anything of worth. It’s just another new framework with a gimmick attached to it. There is also a debate whether Phalcon really is more performant in a real-world application. But the most apparent problem is stagnating development. As of time of this writing, they are still working on PHP7 support, for christ’s sake.

  • Gustavo Silva

    Good article, i just thing you should change Symfony 2 to Symfony 3. I read the title and to me 2016 is Synfony 3’s year. Symfony 3.0 is an extension of Symfony 2.8 without the deprecated methods.

    Either way good read, keep the good work.

    • Layton Everson

      …or just “Symfony”

  • Saf

    Thank you for this wonderful article, My involvement with MVC concept is about 4 years, I have investigated Zend, YII, Codeigniter and of course Symfony. A lot of developers and programmers say symfony is complex while I found symfony to be the easiest out of them all. Probably I have tried symfony straight after Zend! Also in the last couple of days, I have been learning Laravel which I really dislike, I don’t like how it is structured and sincerely I found Laravel to be confusing! I guess every framework has its own learning curve. My favourite framework of all times goes for symfony, I have been using it now for the past 2 years, it is rich, flexible and agile especially with the console. I totally agree on the other three frameworks, codeigniter has fallen behind the game, Zend doesn’t really have a framework, Laravel is over estimated. I think Laravel has abused the Lambda/closure and the factory design pattern.

    • I agree with most of your views here… I think one thing that makes Laravel attractive to many people is the relatively large ecosystem of support tools and plugins that has been built around it. And I have to say it’s quite nice. Even if you don’t develop in Laravel watching some Laracasts is quite often very fun and educational, I definitely picked up a few good tips here and there.

  • captain_sensible

    Great article ; it would be interesting if you did do smaller frameworks & perhaps contrast what is it that can be done with a larger framework than can’t be done with a small one. If you do micro frameworks please include fatfree which i used for my wifes site & managed to integrate PayPal Rest Api in order to do online transaction .

    My perspective is slightly different from most in that I don’t work in IT & at 60 probably never will. I do dabble in PHP & have been teaching ICT basics to kids from 11 in 3rd world . I just can’t understand the effort to mess about with vagrant boxes , homestead – i’m on slackware14.1 the install just didn’t go well. I then looked at the web hanging at SSH private key and there is an absolute mass of people with issues.


    Many factors outside the framework itself are so important when considering a framework viz: The type of Project, whether Enterprise scale or small medium sized. The architectural skill of the developer as well. CodeIgniter was a saver for me when I had just started as a programmer and it helped a lot in demystifying lots of terms in MVC, and probably design principle. I got to understand what works and what doesn’t as part of me gaining experience.

    I so much love Laravel and Symfony, but many of my trusted more experience developers who have used Symfony before Laravel believe Laravel was badly designed, in which I concur with them. But then again, in theory, you can build a good code without a framework which may even perform better. so, it is up to the developer and not the tool.

    • In a way I agree. Hence why I said “use the right tool for the right job”… that said, you should always consider the tradeoffs .. writing custom code for a simple application is *sometimes* just fine… but in today’s day and age there’s simply no reason for it. If you don’t need a full blown MVC stack.. consider many of the micro-frameworks available today. Implementing routing, database abstraction and form validation are some things i would never ever recommend trying to write that from scratch… unless you have a very good and important reason to do so :)

      RAD (rapid application development) is a very important concept that needs to be thoroughly evaluated and considered when starting any new project.

      As far as which framework is designed better… that’s a tough question, which doesn’t have a right answer… that’s why I didn’t really pick a clear winner at all. (Except I really think ZF2 is not well fitting in today’s world.. although many developers will disagree with me here… and I think that’s great. Having choices that fit best with your own line of thinking and requirements is the most important thing).


    Informative analysis . BTW , if someone has been searching for a a form
    , my business came across a template document here


  • Pedro Reina

    it seem we not have enought with systems Desktops tastes (linux vs windows vs Mac) and now we have to learch many frameworks fighting for the same pastry piece and reinvent what already exists.
    The price is for programmers people and high cost in time learning.
    i knew a little of codeigniter, now i tried symfony and it’s horrorous because many samples of oficial web or youtube samples not works because versions.
    Now i’m thinking about, laravel, phpcake, kumbiaphp…
    I’m afraid of my wrong decision because the cost of learning time is very high and then confusion if studying different frameworks.
    kumbiaphp say very interesting, but I see that is not in the field of job offers websites today.

    • Sorry, but I couldn’t disagree with you more… to me, you are looking at it from a completely different perspective. Learning is evolution, the day you stop learning is day you “die”. First of all, nobody is forcing you to learn anything new. You can get by just by knowing one programming language and doing whatever it is you want to do, without any obligations.
      How can you be afraid of making a mistake in learning? (Making mistakes and learning lessons is exactly what you need to be doing). All knowledge is important. Knowing how NOT to do something is just as important as knowing how to solve a particular challenge.

      Do not be obsessed about different versions and the number of choices in frameworks, or whatever it is that scares you.
      Each framework represents a set of patterns and solutions to common challenges: Database Abstraction, MVC, Observer or Event Listener, Dependency Injection. That’s where things get interesting, regardless of the framework you are attempting to grasp.

      It’s not enough to just learn how to find data in a model in one framework, it will be very hard to achieve anything if you fail to recognize the larger picture of various implementations.

      Be more positive, man…

      • Pedro Reina

        You’re absolutely right, life is 100% learn and never stop it.
        But it is not entirely correct theory “nobody is forcing you to learn anything new” because that is precisely what in my country do business, when you learn something else companies change direction and they expect others things about you.
        It is a relative fear in this sense, if you learn something that is well appreciated then have a nice way. But you can specialize in Django(for example) and if companies do not want it, your prize is null.
        But your explanation of the enterprising programmer is true, I started in teenage, about 11 or 12 years old, I was given an old computer that is the name “Dragon 64”, it had 16Kb of RAM and 4 colors. I kept the videogame cassettes in a drawer and started using his interpreter Basic.
        I love to learn things, but now diversity is excessive.

        You’re right again -> “Do not be obsessed about different versions and the number of choices in frameworks”
        Well, I get angry quickly because time is short and the great difficulty with symfony, and i found little help where the official documentation followed step by step was a conflict in my tests. it’s crazy LOL!
        Thanks for your answer.

      • Ahmed Abderraham

        Learn and understand how service containers work (dependency injection), and enjoy Symfony. Seriously. Es una maravilla.

  • vison

    The best article in all i have seen about php framework comparison. Some thing i can`t agree more. Sorry for my english. I am chinese work in china.

  • Pingback: Creating Your First Symfony App and Adding Authentication – scribdbook()

  • Darryl Porter

    Good read, thanks! A few thing,
    1.) while the symfony framework documentation only covers the basics, each of the components that it uses have documentation section that usually go into the nuts and bolts. In other words, if the main docs don’t have what you are looking for, go the docs of the component in question to get details.

    2.) I agree, Zend is a mess. Over the past decade I continue to return to it hoping that it had gotten better, it hasn’t. I started to use it once to build an enterprise application, but after two weeks, gave up and went with symfony. The main reason for dropping it was the documentation: I never read so much that said so little.

  • janko

    Hi, what about zend framework 3?
    Actually i have a project to prepare and either i will go with php which I already know and zend or laravel or completely change approach and use rails which brings risk

    • when this article was written zf3 was not available. however, even based on zf3 own blog, the changes from zf2 to zf3 are “subtle” … php7 support, faster performance, and focus on improving documentation.

      i still feel that working in zf3 or zf2 environment is very cumbersome. there is still lots of configuration required to get even some basic functionality working.

      considering the options we have, i would not recommend zf2 or zf3 for your new project.

      • janko

        thank you for help

      • Abhilash Engala

        If you guys are zend illiterate then that doesnt mean that ZEND doesnt have any framework. Seems like you all are googlers, none of you seems as a real developer here.

      • well thought out comment.

  • Pingback: MVCフレームワークは水物 – VIEP()

  • Steve

    Any thoughts about where things are today?

    • 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 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 to larger applications.

      Generally speaking, however, we’re definitely seeing a shift to container-based architecture, where MVC plays a much lesser role, IMO. It’s all about micro services, 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 :)

  • Pingback: The State of PHP MVC Frameworks in 2017()

%d bloggers like this: