PHP Framework Madness

I was recently interviewing for a new position as a software engineer and was asked about my experience with different PHP frameworks.  It took a lot of willpower to not simply say “I hate them” and instead make a critical argument against using them.  Maybe I’m just getting old and crotchety at 38 years old, but when I first started writing web applications in 1996, there were no frameworks.  ASP wasn’t even at a 1.0 release and PHP was just a bunch of PERL scripts.  For the most part, we had to write all our applications by hand from scratch.  And it was glorious.  

At some point, other developers started releasing toolkits and frameworks to save us from reinventing the wheel with each new application, which was a good thing.  But later down the road, I feel things went off track.  As frameworks evolved, it started encapsulating more and more things that we were already doing.  Not necessarily because we were doing it wrong, but someone thought we needed to do it differently.  We needed to fundamentally change the way PHP works and how it handles page requests so we could adopt object orientation everywhere, even though it truly serves no good purpose.

MVC became the buzzword of the day.  We’ll separate our business logic, database logic, and HTML page data.  The promise of MVC was that designers could do what they wanted without breaking backend code and angering the developers.  But, we never really got there, did we?  So that designers didn’t have to fool with PHP code, we created templating languages for PHP, which essentially just changed the opening and closing tags.  Oh, and it added another layer of code that had to be parsed, compiled, and executed by PHP.

To me, I see no difference in something like {% variable %} and <?php echo $variable; ?>.  Sure, the former example is shorter.  But is it really worth the extra processing time to make it shorter?  I could just tell my designer, “hey, don’t fuck with anything in PHP tags”.  However, in my nearly 20-year career, I’ve never sent a marked-up document to a designer.  I got changes and used the age-old tools diff and merge to integrate everything together.

And part of the MVC promise is “pretty URLs”.  You know, like /users/edit/1 instead of /users/edit.php?id=1.  Frameworks provide all of this scaffolding to interpret the request string and route it to the proper code.  But I have to ask, does this matter?  What real difference does this make?  When search engines would drop query variables from the URL, it might have mattered (but do you really want a search engine to index a page within your web application anyway?).  These days, they will preserve the query variables when indexing pages.   So the argument for making “pretty URLs” is a strawman at best.

A lot of frameworks also include some sort of ORM – object relational mapping.  A really fancy way of saying, a database interface.  It connects to a database, matches up tables with classes, and allows you to interact with the data in an object-oriented way.  That’s really awesome and I totally support that.  But, ORMs have grown completely out of control.  PHP Data Objects (PDO) insulate us from a lot of the nuances of working with different database systems.

Leveraging PDO, I created my own ORM that comes in around 200 lines of code, including comments and documentation.  I’ve used it in around a dozen projects without fail.  I don’t have to write SQL code in the large majority of cases (unless I’m doing something exotic like a complicated join) and it’s extendable in those cases where it needs to be.  To access data from a table named users, it’s a single line of code:  class Users extends Base_Object { }.  That’s right – the class is empty in the large majority of cases because I don’t need to do anything beyond basic CRUD operations.

Now, when I need to create a database (or table) and for some reason, I don’t have an interface to the database like phpMyAdmin (which is really rare), I have to hand write SQL.  Ahh, you say – an ORM will save me in this situation!  Well, not really.  When your calls end up looking like $table->varchar(20)->primary_key(true), well – how is that any really different from straight SQL?  Sure, there might be some level of error checking that the ORM provides, but you can still do something stupid no matter what method you use.  And database/table creations are such a rare event, it doesn’t justify the size of the ORM.

That leads me to my last point – size of the framework.  One framework which I shall not mention is 22MB in size.  If you intentionally write erronous code so you can see the call stack, you’ll see it goes through about two dozen steps.  I’m sorry, but that’s a lot of code to debug that you hope the framework developers didn’t screw up.  And remember, PHP is a scripted language.  As a reminder, that means that all of that code must be parsed, compiled, and executed on every single page request.  Oh, and don’t forget – all that code is in memory too!

So, I have to ask the all important question of scalability?  I’ve seen frameworks break at 500 simultaneous users on a pretty beefy machine.  If you’re writing a web application that’s going to be used by a large user population, you think about how well it will scale.  Or maybe you’re making enough money, you can throw more servers and a load balancer to handle the load.  (As a side note though, more servers = more energy use = more pollution in the environment.  Your framework is fucking killing the environment asshole!)

In software development, there’s always been one principle that stands the test of time – the simpler the better.  I don’t mean that we can’t have complex applications or we need to skip things like input validation (because afterall, stupid people are ingenious at breaking things).  But do you really need all that code, all that complexity, and the learning curve of having to learn to code to someone else’s arbitrary standards – when PHP has been doing the same basic things for the last 20 years?  Ask yourself if there is truly a benefit to all this extra stuff.

Okay, one more point to make.  If you don’t understand enough about PHP to serve a basic page and embed tags within an HTML page, then you need to reread the book.  You need to get your feet wet with something simpler before you jump in the pool.  You have no business developing a large web application if you don’t understand the basics and can’t do it yourself.  If you’re so dependent on a framework to that extent, maybe you shouldn’t be doing it to begin with.  It’s you folks that don’t know what you’re doing and writing poor code that has brought PHP a bad name.  (You!  Out of the pool!)

Leave a Reply