Yii vs Laravel a 2019 comparison

(Anas Jaghoub) #1

One the hot topics that whenever you need to start a new tech project you dig into it, spend a lot of time comparing, searching, proving and testing which technology stack, framework, to use.

Generally speaking, the main factors that affect your decision for choosing any technology stack, depends on:

  • Size of the project (small, medium, enterprise).

  • Type of the project (User generated content, e-commerce, blog…etc.).

  • Timeframe given like is it only a POC or will be a core/base to implement on top of it.

  • Size of team, skillset, ability to learn new things.

  • Technology community in terms of size, support, and how often they release, development roadmap …etc.

Taking into consideration the above factors, will play a huge part in choosing which technology stack, framework to choose.


I’ve been hesitated a lot before starting today’s article (Yii2 vs Laravel a 2019 comparison), where a lot of battles, articles and discussions have been done in the last 2 years and keep going. To be fair, these discussions are healthy and provide a huge knowledge share part that keeps up and up.

When I’ve started this article, I decided to have it in a different way instead of having just a comparison table for features of Yii vs Laravel and try to discuss it from another point of view, from a person who has been working/dealing with Yii framework since 2011 until Today and have implemented huge parts of systems that handle 80M+ requests a day for one of its APIs. With a high availability / fault tolerance / and performance taken into consideration with each step of development.

This ended up by having a long article (~13 pages), as I need to share the comparison from a practical experience, and to be fair I’ve to cover as much parts from both frameworks to help you decide which one to choose. That’s why this discussion will be divided into 3 main parts where in each part I will focus on a topic, and at the end of the article there will be a simple comparison for pros/cons that hopefully will help you in deciding which one to choose.

Part 1

Not only a framework!

To clarify things, to be able to have a high available fault tolerance system, it does not only rely on which framework / programming language you use, as there’re a lot of factors play here, from architectural perspective, elasticity, infrastructure. So, you cannot judge that Yii2/Laravel only will give you a high available system, as there’re many factors effect on this.

As mentioned above after more than 8 years of continuous development using Yii/Yii2 I’ll share with you my notes about it in part 1 and 2, then on the last part I’ll share with you my experience with Laravel, and how it compares to Yii.

Why Yii 1?

When I’d started with Yii at 2011, while coming from a Zend / CodeIgniter background, my questions at that time were:

  • What’s Yii? A fast, secure, efficient, flexible, extensible, MVC framework.

  • What does it refer to? Yes It Is.

  • Why should I go with it?

o Small package size compared to Zend at that time.

o MVC support.

o A lot of extensions that will boost your getting started process.

o Very interactive, supportive community that does not leave a question without an answer.

  • Why should I move from Zend to Yii? Zend at that time was the top most used framework, the same company that develops PHP develops Zend. However, the larger size of the framework, and having to write tons of lines to achieve a simple CRUD system, and the long time spent for development, all these factors played a huge part of trying something new that can ease your work.

  • Many other questions like how and how and how? To be honest, my movement from Zend to Yii took me longer time and this reverts to many factors as I was still at my beginnings in development path and was thinking in Zend mindset of how to do things, in addition for not having a real business case that can be implemented in a standalone project.

Getting Started with Yii 1 took me around 3 months due to reasons mentioned above. Then I’d moved to another company where they were starting a new revamping for their site using Yii framework, where I’ve played a major role in implementing huge parts of the system and interacted almost with every component in the framework from MVC, to caching layers, to assets management, to restful APIs, to security and a lot of components / extensions.

To be honest, the documentation, community, and tutorials helped us a lot on how to get things done following best practices and in fast paced manner. However, during that time we followed an agile development strategy, and in 2013/2014 we’d faced issues on different parts like:

Yii 1 Issues

  • How Yii was managing database connections, for e.g. we needed to split read/write operations and at that time this was not supported by the framework itself, and we were enforced to extend the CDbConnection class and interrupt the query before being executed in order to split read queries to a connection and write queries to another connection (master/slave architecture).

  • How Yii was managing assets, as we were looking to serve assets from a CDN and needed an approach to combine assets and upload it to CDN in a convenient way to avoid latency and duplicate operations.

  • For restful APIs there’s no clear approach how to do versions of your API, how to do rate-limit, and this required us to implement our own approach.

  • During that time also, PHP as a language was developing, and major changes were coming, like namespace, traits, types that Yii 1 was not adapting 100%.

  • Whenever you need to use an extension, you’ve to download it, extract it, and copy it to your project, composer at that time was not commonly used in Yii 1.

Part 2

Lately in 2014, Yii had introduced Its second version of framework (Yii2), which was not a backward compatible with Yii1, and forced us to invest sometime reading and understanding the new changes that Yii has come up with, to start planning for a new revamp/rewrite process.

Not only the framework, also the language!

Good news that PHP also has come up with major changes for class autoloading and name-spacing, that encouraged us to speed up the movement to Yii2.

Introducing Composer

Yii2 default installation was via composer, and this was the first major change from Yii1, to restrict developers to start using composer and being familiar of how to adapt it in Yii. Yii2 came up with 2 different skeletons: one is for basic projects which was very similar to Yii1 skeleton, and the other was an advanced template that introduces multiple apps skeleton, more details can be found here https://www.yiiframework.com/extension/yiisoft/yii2-app-advanced/doc/guide/2.0/en/start-comparison

Our use case was fitting more to the advanced template where there’re multiple apps (common, console, backend, frontend, api). More details can be found here https://www.yiiframework.com/extension/yiisoft/yii2-app-advanced/doc/guide/2.0/en/structure-directories

Yii 1 issues has been solved in Yii 2

Yii2 came up with a solution for all major issues that faced Yii1 developers, like assets management, database read/write connections, extensions via composer, and huge effort on restful that gives you the confident that whatever your use case you’ll have it adapted in Yii2 (Yes, It Is) for e.g. (Versioning / Authentication / Rate-limit / Response formatting …etc.) are covered in a very convenient and smart way.

Seamlessly integration with jQuery/Bootstrap, what’s wrong?

On the front-end side Yii2 did a huge effort in providing widgets for manipulating data, how to represent it, and integrated seamlessly. This was a good/bad decision taken by Yii team as the framework become tightly coupled to jQuery/Bootstrap stack and make it difficult on the front-end side to use Yii2 with other front-end frameworks like React/Angular/Vue …etc.

This was one of the main factors why they started planning seriously for Yii 3, where it’s been decoupled from jQuery/Bootstrap stack and focusing completely on back-end side. However, for people who still prefer jQuery/Bootstrap they can still use it for sure, but it’s not enabled by default.


Back to RESTful support by Yii2 framework, as mentioned further Yii2 came up with a full suite solution in terms of routing, response formatting, authentication, rate-limit, versioning, and error handling. I’ll expand more here as this was one the main areas I’ve worked intensively with it and implemented a solution that handles 80M+ requests per day, were in our case we’d multiple clients (Android App, iOS App, PWA) with different app versions and different features / behaviors.

In depth for RESTful support regarding:

  • Routing, Yii2 has a class yii\rest\UrlRule

That by default will create a whole set of child URL rules to support routing based on verbs (GET, POST, PUT, DELETE, HEAD) and route it to the appropriate action to handle the request.

  • Response formatting, Yii2 has yii\filters\ContentNegotiator filter which is smart enough to understand clients accepted response formats and return the response in the required format, like JSON/XML/HTML/Text …etc. And what attributes/entities to have as well, fields&expand query params provide a very useful methodology for how to extend your current resource without the need to duplicate your work/code.

  • Authentication, Yii2 has authenticator behavior that works with different authentication methods like HTTP Basic Auth, Bearer Auth, Query Param Auth …etc. It can be configured to seamlessly authenticate requests and continue/reject request.

  • Rate limit, Yii2 has yii\filters\RateLimitInterfacethat is responsible to prevent API abuse and sending too many requests from the same user.

  • Versioning, this is really one of the topics that has a lot of debates, opinions, drawbacks, advantages, and everyone’s use case differs from other. However, Yii2 provides a solution that guarantees backward compatibility and continuous integration in the same time in a robust way.

  • Error handling, Yii2 follows HTTP standard codes for different errors, and this make it easier for clients to predict what kind of error is happening and behave accordingly, for e.g. unauthorized / internal server error / not found / validation error are of the top used errors in RESTful world.

Yii 2 Conclusion

That being said, as a framework Yii2 really did a great job, and fits in all web development functionalities. Moreover, it integrates with other components and services, be it database SQL/NoSQL, be it caching Redis/Memcached, be it authentication, be it response formatting, be it simple forms, be it unit testing …etc.

Emerging Architecture, different demands

Given Yii2 was launched in late 2014, and we’re now in 2019, a lot of changes / stacks / technologies have been evolved, and different mechanisms, software architecture have come to the surface, in addition to the evolution of micro-service/nano-service architecture, server-less architecture, mobile first products, and progressive web apps. Then the need has become to micro frameworks in order to implement a simple / standalone service that integrates/deploys independently. Hence big systems that are implemented as a single / fat unit is not recommended any more.

Yii 3?

Yii team took these changes / factors into their consideration, and started working on the 3rdversion of Yii, which is still in the drafting phase, there’s no clear date when it’ll be released, and more details can be found on the link https://www.yiiframework.com/wiki/2547/draft-understanding-yii-3

Having this into consideration, that if you’re going to start a new project based on Yii2 you should keep an eye on the draft of Yii3 to make sure you’re / will not using a deprecated feature, and this will add extra headache for you as a software architect to make sure that no breaking changes will happen when you upgrade to Yii3.

Part 3


I’ll discuss Laravel, and my experience with it, advantages, drawbacks, concerns. However, it’s good to mention that I’m still a beginner to Laravel and cannot dig into all components, how it works and main use cases, but I will try as much as possible to provide a high-level analysis and will keep the discussion for you to hear from you as well.

Laravel Skeleton

Laravel based on their site they say that it’s a PHP framework for web artisan. It can be installed via composer, and provides a directory structure consists of (app, bootstrap, config, database, public, resources, routes, storage, tests, vendor) more details can be found here https://laravel.com/docs/5.8/structure

My first concern on this structure, where is the MVC? and it’s already questioned/answered by them on the link https://laravel.com/docs/5.8/structure

Where Is The Models Directory?

When getting started with Laravel, many developers are confused by the lack of a modelsdirectory. However, the lack of such a directory is intentional. We find the word “models” ambiguous since it means many different things to many different people. Some developers refer to an application’s “model” as the totality of all of its business logic, while others refer to “models” as classes that interact with a relational database.

For this reason, we choose to place Eloquent models in the app directory by default, and allow the developer to place them somewhere else if they choose.

In my point of view, for an MVC based framework it’d explicitly define its MVC structure and not leave it for the developers to define it by their needs. As you cannot implement a tool and ask users of this tool to use it however they want without at least a default setting to start from.

The other concern regarding project skeleton, the app directory contains (Broadcasting, Console, Events, Exceptions, Http, Jobs, Listeners, Mail, Notifications, Policies, Providers, Rules) again where’s controllers? It does not exist by default, and to be honest the above structure does not help you to predict how it works without digging into their documentation to learn about it. Convention over configuration is not followed here, and hence you’ve to do some efforts to learn about each of these components / directories and how to deal with.

Another concern about above structure, I cannot see any relationship between the above directories to have it all under one umbrella, and if I want to compare it with Yii2 structure, then Yii2 has a proper structure as each app by default consists of (model, view, controller, components, config, web, assets, runtime, tests), where you can know explicitly where your code should take place.

Laravel Documentation

One of the main factors for speeding up your getting started with a framework is to have guide tutorial that provide use cases and samples how they’re implemented using this framework. In Yii you’ve the guide tutorial that gives you like a tour on the main functionalities and how they can be used, on the other hand for Laravel, their documentation lacks this important feature, it gives you sample code snippets for general design patterns and how they’re applied in Laravel like Facades, Dependency Injection, Containers and Service Providers.

Having such guide will help any advanced developer to start up fast instead of spending too much time for doing routine or small tasks.

Laravel Contracts

One of the main architectural concepts that Laravel came up with is the contracts, based on their definition, contracts a set of interfaces that define the core services provided by the framework, more details can be found on https://laravel.com/docs/5.8/contracts

Laravel Contracts vs Yii2 Components

Contracts in Laravel are useful, and provide kind of abstraction to your code, however whenever you need to use contracts you’ve to require them in your class constructors / setter methods. For e.g. If you want to use Cache contract you need to explicitly ask for it in your class constructor to be provided, On the other hand in Yii they provide the component-based architecture, and components are part of the app instance and can be loaded via configuration, hence you can use any component anywhere by calling it simply like Yii::$app->componentName.

in Yii components usually based on interface, for e.g. the Cache component is an interface that has the below main methods (get, set, has, delete) and any cache class like Memcached / Redis implements Cache interface which is a convenient OOP standard, so when you need to change from Memcached to Redis it’s a matter of changing it from config without touching any code / logic. However, in Laravel contracts should be explicitly provided in each class using it and this adds overhead when having multiple classes using the same components / services and this leads to code duplication.

Laravel Routing

Routing in Yii is a matter of a configuration array that consists of a key => value structure, where the key is the pattern to match, and the value is the targeted controller/action to run. Simple, convenient, and straightforward style. Yii also provides default routing techniques where any controller’s action can be accessed via controller/action pattern, hence you don’t need to write every single action in your routes array. On the other hand, for Laravel, you’ve to write your routes as a function call style, which leads to writing too much code, and every single action in your controller should be defined in the routes.php to be able to expose it.

In Laravel there’s a convenient way for defining routes that render views only, so this saves you a lot of code when you want to define view only actions that does not have any logic. On the other hand, in Yii you cannot map routes to views directly.

Laravel Authentication

Authentication in Laravel comes up with built in implementation for Registration / Login / Forget Password / and Reset Password. Same thing also provided in Yii, and in most cases you don’t need to override the logic for it.

Secured routes in Laravel should be defined in the route config file, by calling middleware Auth right after route definition, more details can be found here https://laravel.com/docs/5.8/authenticationAnother technique to define authenticated routes inside controller’s __construct() method. For me I don’t prefer such approach, as constructing controllers is a framework job, and any customization should go in separate step not in the construction phase.

However, In Yii authenticated routes can be defined inside controller itself in authenticator behavior, where you can define which actions are public, and which actions require authenticated user and this can be defined in simple configuration arrays.

I’ve dealt with both Yii and Laravel authentication mechanism and found both do the job in a simple way, however it depends on tastes and preferences, for me I might prefer Yii’s way, for others might prefer Laravel’s way. In all cases this job should be simple and robust because it’s used almost in your whole application, and it’d be easy to maintain.

Laravel and Facades

One of the main things I’ve noticed during my journey with Laravel its intensive use of Façade design pattern. This provides you a lot of magic and enrich your classes dramatically. However, this kind of magic is not IDE friendly and makes it really hard for you to debug how’s your application work, and how these methods took place. On the other hand, Yii is fully IDE friendly and this makes development time boost dramatically, as you’ve auto-complete, and auto import missing classes …etc.

Another concern is that Laravel intensively using closures/callback functions like jQuery style, however this opens functional programming / OOP discussions which will not lead to a winner. But to help you judge you’ve to read about pros/cons of both functional and object-oriented programming to understand the side-effects of such approach.

Laravel Views

Regarding view rendering, I’ll not dig deep in both Yii/Laravel, since as mentioned before with the evolution of PWA most of web applications now render on the client side instead of using server-side rendering. There’re multiple frameworks to be used for this purpose like React / Angular / Vue and much more. However, it’s good to mention that both frameworks support templating like blade in Laravel and Twig/Smarty in Yii. And in case you need to dig deep you can refer to https://laravel.com/docs/5.8/views

And https://www.yiiframework.com/doc/guide/2.0/en/structure-views


Validation in Yii occurs in models, where you define a set of rules, a set of rules for specific scenarios, and define which attributes to be validated per scenario and this happens in a very clean / robust way.

On the other hand, in Laravel validation occurs in the controller, and could be written in separate classes / facades where you define all your validations logic. For most of validation cases both solutions work, however when you’ve scenarios for validation then in Laravel you’ll end up by tons of lines which are hard to trace and debug.

ORM in Laravel / Yii

Relational data in both Yii and Laravel works in a very similar way in terms of how to define it and how to call it. Yii2 uses ActiveRecord and Laravel uses Eloquent, both are handy and provide you control for whatever you want, and to be fair both documentations can help you a lot in case you’ve any questions on how to do something.


To summarize it up, both frameworks Yii and Laravel can give you whatever you want to achieve at the end of the day, it’s kind of different schools / different tastes for writing code. In terms of robust and well-designed architecture both frameworks are well supported by the teams behind it.

As mentioned before, with the emerging micro-service/nano-service architecture and the demand of having small services that are maintained / deployed independently then the need for large frameworks that do a lot of things is not recommended any more. As most of the services are focused on specific operations / functionalities and hence huge parts of the framework features might not be used. However, the common features like (Request / Response handling, routing, authentication, authorization, manipulating data in/out) are common tasks that you’ll use it in every service.

Yii is developing the 3rd version of the framework, where there’re features deprecated, there’re break changing features, and huge parts till now will keep the same. If you’re about to choose Yii2 as your framework then you’ve to take these factors in your concern.

Yii is an IDE friendly framework, and you can boost your development time significantly, on the other hand Laravel is not. However, Laravel’s syntax is simple and you can be familiar with it shortly.

Think of client-side rendering frameworks like React/Angular/Vue and think how it can be integrated with both frameworks, and what’s the best way for your case.

RESTful support in Yii from my experience with it, was pretty mature and robust, and Yii2 Serializer makes your resources extendible to the most without the need define separate versions on every api change.

Last note, the more your framework of choice helps you boost your development process, and helps you do routine tasks seamlessly, and the more its documentation will help you achieve what you want, then your choice will be most likely correct and robust.

Comments are more than welcomed, and to have it clear from the beginning there’s no winner in both frameworks, but there’s a better understanding on which can help you achieve your use case in a convenient way.

Benefits of Yii over other Framworks?
Apidoc, debug and Yii 3 progress
(Alexander Makarov) #2

That’s a long read but the article has almost no mistakes.

I’d like to voice my opinion about Laravel contracts. The interface/contract idea itself is fine but implementation there is not. Contracts should not be a single package because if you want to use one interface you have to get all the pack on board. I’ve already reported that to Symfony and they’ve fixed it.

(Fahad Ali) #3

After reading a long text, I can say thanks for sharing your experience here.
I am working with Yii2 framework since OCT-2014, and i am still lover of Yii2.
Just for my curiosity, I tried other frameworks also to build same system (just for learning), I found that Yii2 takes very less development time.

I have tried very complex DB queries and very complex validation rules as well, in both case i found Yii2 is better than others.

About structure: It very clear and if you introduce new developer in your team, he can easily adopt it, and very soon he can work without any issues.

Sometimes, I found very hard to do something in RestApis, like it took some extra time for me to build nice web-apis, but this happens only in my case.

Overall, I refer Yii2 over others, but due to laravel also have lot of improvements in its last update (I love how they use Vue as frontend), so anyone can consider it too, But i will continue with Yii2 and looking to get started with Yii3 as well.

Thanks for reading.

(Breg) #4

Interesting and differentiated comparison, thanks.

Personally what drove me off at Laravel is the obvious impulse to do something better than others. In the end a software framework is still a tool, and should IMHO be as simple as possible, or allow simplicity, like not enforce active record, as in Yii.
Yii seems also more transparent in its inner workings to me.


Personally I think the preference of Yii vs Laravel is more of a regional thing. For example in the UK where I am based, it’s all about Laravel. In fact I’ve spoken to many companies who have never even heard of Yii. Also most job adverts I look at will state something like “experience in a modern MVC framework, such as Laravel, Symfony, CakePHP.” I rarely see job adverts that mention Yii.

Having used both frameworks myself I can honestly say that Laravel does things in a more elegant and modern way. This is of course subjective. I don’t know what extent the original poster has used Laravel - as most of his points portray Laravel in a negative light. I think realistically to make a judgement on any framework you would need to use it in some real world projects.

To be honest both frameworks have their plus and minus points and every developer will feel differently about these. The bottom line is, just use whatever works best for you and for the goal you are trying to achieve.

(Néstor Acevedo) #6

Laravel is too popular because its “easy to use” doctrine.

The preference doesn’t come from regional topics, but else tastes. People usually goes with the most popular (clothes, music genre, development tools) and Laravel is one of the most popular frameworks. I have never tested Laravel or Yii as standalone frameworks, I have worked with the app from each one.

Personally, I prefer all my life Yii2 - the app - (I need to check Yii3) over Laravel because, for instance, the Laravel’s “simply, fast routing engine” is not actually simply: you have to use the web.php route file and create any new route to use your desired Controller’s method, while Yii is intiutive, it uses the controller’s action method prefix to build the default routes. Now, again a personal opinion based in my experience, if you have subdomains in your app, if you have some routes with the same name, the FIFO logic in Laravel will use (as FIFO means) the first one controller that can be served as the current route that your app will use, and the regex rules for the routes seems not work, while in Yii, I can separate each subdomain and controller more easy with the regex rules.

Second, the views: I think Yii is more ordered in this, predefining and creating directories according with the controller’s name and naming the files views with the method’s name, while laravel designs only a directory (view) and you have to create the directories and the filenames.

Almost all here we are to have in common: Both frameworks have their plus and minus points, and either one will use each one according with their preferences.

(snuzi) #7

I have also used Yii 2 for Rest API, I found it not as hard as developing Rest API in Laravel. Thanks to RestController, Serializers and DataProviders I could get the Rest API in a good shape. The only thing that I could improve is response time. I want to optimize it a little but I am finding it hard to find some good practices.

(Anas Jaghoub) #8

@snuzi I think the point in serialization you’re pointing to is related to the lazy loading of relations in expand param, right?

In all cases you need to check the Yii debug toolbar and see where most of the time is going and start from there.

TBH with you, optimization part could be on different levels and layers, sometimes could be related to the architecture itself, sometimes to PHP.ini configurations, sometimes nginx/apache configurations. But the key as I’ve told you earlier Yii debug toolbar will help you determine the bottleneck and from there you can go.

(Anas Jaghoub) #10

@Raghavkhanna thanks for your reply and completely agree with you regarding the points you’ve mentioned.

I need just to talk about this point which IMHO summarizes the whole thing.

I completely agree that Laravel’s syntax is easy to remember and sounds clear/easy to understand. But even Yii as well when you try a real-case scenario within couple of hours you’ll get familiar how it works, and how to achieve things.

Another thing also IMHO, that performance should always be the key indicator, but unfortunately, most seniors who I’ve interacted with who didn’t try Yii they resist to give it a try just because it’s a PHP based framework, and really most of the discussions go to endless due to as you know you cannot compare PHP to Java for e.g., each has its own characteristics and uses, but the idea when you’ve a basic CRUD services, Yii really fits in terms of ease of use and speed of development time, and even performance when running.

(Eric) #12

What made me like Yii2 is that there’s less cognitive load when reading Yii2 code compared to Laravel and even Symfony. You can build a robust and secure web app in Yii2 with very thin models (all you need is to define a bunch of validation rules :smile: to sanitize user input) without writing much code, and it all works so well and fast!

Even integrating third-party php libraries into your Yii2 app is as simple as building a simple component and defining it in your config and voila! you can use it anywhere in your code!

That’s what keeps us glued to Yii2, it just works without a fuss!