Are PHP Frameworks All Hype?

The short answer is, yes.

Let’s explore why that is.

Who in their right mind would try to sell their framework idea by saying, “It’s slower than straight php”, or “it lacks form customization”? I’m pretty sure no one would. This article is based solely on my own personal experience of dealing with web development for over 13 years.

I want to start out by saying that I’ve tried many PHP frameworks. I’ve tried Cake, Magento (a CMS loosely based on Zend philosophy), Symfony2, Zend2, Yii, Codeigniter, Light VC, Laravel, and many other in my own personal time). One thing to note is the amount of frameworks that exist out there just for PHP alone. Why so many? If any one of them were as good as PHP itself, why hasn’t it become the standard? The reason may shock you… or not. PHP frameworks suck! Even Rasmus Leerdorf himself (the creator of PHP) had said it.

Web development and web application development is not the same as any other type of programming. It’s development that creates short lived web pages (applications) and rapid AJAX calls in order to provide the end user with some sort of interaction and/or data management. These little pages, together create the illusion of being “logged in” an application. Applications keep massive amounts of data alive until that application is shut off. Think of the OS that you’re on right now. TONS of things happening in RAM while you’re listening to your favorite music and reading this post. On this particular website, the page has already loaded. Nothing much else is happening. The web app finished rendering a long time ago and is now in a sort of an “off” state. I just want to make sure we understand the differences between web app development and any other type of application development where the data stays alive for the entire duration of the application.

Yes, there are exceptions, such as sockets, but for the most part, most websites render out, and boom, done! The server on the other hand may keep a session alive. If not, your authentication is probably handled by cookies, or RESTful api keys and secrets. Anyway.

Trying to introduce a concept of MVC, previously only used in single language environments (i.e. Java), to a multi language environment (Apache, PHP, MySQL, HTML, CSS, JS, etc) is plain ridiculous. I understand the idea behind separating code, but for a website, it’s ludicrous to think that you can do all of data collection through PHP, or all of the JS calls from PHP, or even CSS rendering from PHP. Websites are a special type of applications that can, and should handle multiple types of languages in order to provide the best experience for end users, visually, and functionally. Imagine if we could only code websites in PHP alone. What a mess that would be.

The simple truth, and this may hurt anyone out there, is that with all of these different frameworks, not one has stood the test of time over a two year period. Everytime PHP gets updated, your frameworks becomes useless. All the bells and whistles just became obsolete. And forget about v2.0 of the framework since nothing is backwards compatible. It’s a complete nightmare.

I always hear the argument about how noobs pick up a framework faster. Faster than what? PHP? Don’t they have to learn PHP first? And if they know PHP, why learn another layer on top? What if you had to hire new developers? You’d have to teach them the framework, and look back at how long it took you to become an expert in the framework, not learn it, but become an expert. Why an expert? Because you made a lot of mistakes while you were learning it, and you can’t afford that with noobs.

Build your PHP code to make sense, and the same goes for code as it does for UI. If it takes more than 3 clicks to get somewhere, it’s probably too complicated. And you know what? No one is going to want to work on that project. Sure, you can hire a framework or CMS specialist and pay them twice as much… but why do all that when you can get two developers for that same price with a simpler system in place? Response / request. That’s it. That’s what the browser understands. Built it that way, and stop calling everything an application as if you were building something in JAVA. Focus on architecture, not frameworks.

The shortest path is one best known. And surprisingly, most php developers know php.

All PHP Frameworks Suck… Except for Mine

The thing about frameworks is that they’re built by developers to meet an out of the box solution. Sometimes, that’s a complicated piece of spaghetti code that can be used for anything, such as Zend 2, and sometimes, it can be a simple scaffolding set up in a very opened Core PHP way such as Yii, but still has the tread marks of included files and unnecessary nested functions, with an abstracted database layer.

The problem I’m having with any out of the box framework is this… Well, there are several problems.

1. Layer of abstraction for database.

I’ve heard this so many times before. What if the database changes? it’s easier to change that layer of abstraction than to go through your whole site and change the sql statements.

The problem I have with this is again, lazy developers will always make things worse for the rest of us. What you don’t realize is that by being lazy, you’re destroying your performance. Let me explain.

Typical mysqli statement:

$sql_i = "SELECT name FROM table WHERE id = ?";
$dbi = mysqli_connect(...
$stmt = $dbi->prepare($sql_i);

echo $name;

Ok, still a few functions to run through. Not bad though when you compare with how Yii, or Zend 2 propel queries for the same data. let me explain.


Yes, it looks smaller, but you’ve just added at least another object, and two more function calls. This is in addition to the back end mysql calls that happen to actually get that data. As far as micro optimization goes, this sucks. You’re not just adding two more function calls and an object; you’re adding an object and two function calls for EVERY QUERY that you run against the database.

In one of my previous work places, the lead developer was so obsessed with micro optimization that he would create arrays that would be build with brackets instead of array_push(). Obviously, the function call is more expensive when it comes to micro optimization. So, it’s ok to not be optimized when it comes to database calls only?

Then, they were wondering why their website loads at over 4 seconds. They had over 100 http request calls. No website should have over 25 calls, I don’t care how complicated your business logic. In the end, that’s what matters. Site speed is mostly determined by the amount of http requests. The problem was that with the framework they were using, it would have been nearly impossible to refactor the site to allow for concatenation of css and js files without writing it in Core PHP. What’s the point of this framework? Which brings me to my second point.

2. No flexibility for custom code

No matter how robust a framework is, it will always have constraints. There are limits to the things you can do with it. Symfony 2 for example, only allows for either sessions or cookies to be set in one call. Sessions are overwritten by cookies. So, in the end, we ended up writing Core PHP to handle both being set. Explain to me exactly what the win was there. If we’re going to avoid the framework and not use the framework’s internal functions, what’s the point of using the framework? Only to have it as a “cool” layer of abstraction? Because you think you’re cool that you know the framework?


Whenever PHP had an update, it was still PHP. New functions that would allow for more things to be done, and deprecated functions slowly making their way out. Slowly. You could still run your old code on the new PHP platform. You didn’t have to change anything, unless you wanted to optimize some of your code.

Have you ever tried upgrading from Zend to Zend 2? Symfony to Symfony 2? A freakin’ nightmare. And what’s ever worse is that with any new update to PHP, you couldn’t take advantage of this new version inside your framework. So, now you’re stuck using an older version of PHP, and a never changing framework, until the new version comes out, not having the guarantee that the new version of your framework will work with your old code.

When PHP updates, it has been usually tested by many more developers than if Yii updates. There’s a larger support group that will help you understand this new functionality. When a framework updates, the only ones that fully understand the framework are the developers of that framework. You have to pick up from the beginning and re-learn it. Sometimes this can take months. And once it’s perfected, a new version comes out. How is this progressive towards development?

PHP on its own is a framework. A much more robust, and opened framework. It will allow you to do whatever you want.

In conclusion, my theory holds true about frameworks. The best framework is the one you build from the ground up. I keep saying the same thing over and over:

“It’s not the tools you use, it’s how you use them”.


Update: 8/1/2014

Happy Friday! Just to make sure we’re on the same page, I found an awesome article that pretty much states what I stated. Do not use an out of the box framework for project that require long term maintenance. Build your own with as little abstraction as possible, and only make functions out of code that absolutely repeats itself. No parameters. Read for yourself and decide. Yes, it’s a bit long of a read, but definitely worth it!