OOP PHP Sucks!

Update: Before you bash my head in, let me re-phrase the title… ehem… Today’s misuse of OOP sucks as much as misuse of procedural style.

After considering how the web has evolved, I’ve noticed that is not what you use to code, but how you code it that matters more. Yes, what you use still matters, but how you do it matters more. After trying to work on a project using Zend2, I gave up on it when I noticed the ridiculousness of just rendering a page with some dynamic data on it. Autoloading unnecessary libraries, adding layers of abstraction from propel which really all it does is use unnecessary clock cycles to do the same thing that writing your SQL inside a string, building objects that use something like 5% of its functions, “ingest” template files to create some sort of rendering, adding smarty templatizing on top of it that needs to convert to php tags anyway, and finally, the end result.

For real? We NEED to do all that to just render some dynamic page? Wow! We have come a long way in abstracting the simplest solutions into difficult to understand spaghetti code. I’ll explain what I mean by all this.

Let’s look at what actually happens when a web page gets rendered for end users… after all, that’s typically the medium that end users get to interact with in order to have productive or entertaining lives.

It’s a long trip. Hope you brought a book along for the ride.

– Request gets sent to a server via URL inputted by end user typically via the address bar.
– That url gets to travel to DNS servers that send the request to servers identified by IP addresses.
– The server is hit, the server then access its first landing point (htaccess and folder structures) and makes a smart decision in order to try to build some sort of a response to send back.
– At this point, the server will either send you back a message about how it can’t find a file requested, or continue to try to render something to send back.
– Let’s say some default index.html was found without complicating things too much. And let’s say that this file contains basic html, and hopefully somewhat valid html code that gets served to be sent back as data packets back to the original requester.
– The html code comes back to the browser, gets interpreted by the browser, and the browser does its thing to render out the HTML, style with some css code, and run its internal JS engine to see if it has something to do on the client side.

This is where things can get complicated, but why? We don’t have to complicate things. Let’s keep in mind that the final response is simply a long line of characters. There’s absolutely nothing “object oriented” about it. The browser simply takes what it receives and tries to do its job. It’s that simple.

Yes, some JS gets interpreted as objects by the JS engine within the browser, but that’s not for this discussion. Let’s focus on why PHP shouldn’t be OOP.

Back to the server… Here’s what the browser wants:

< html code >
< script code >
< style code >
< html code >
< html code >
< more html code >
< maybe even more script code >

Done. The browser interprets what it gets… or tries to… and renders stuff on the screen. The browser is your application layer.

I cringe every time I hear web developers saying that they’re building an application… You’re nor building squat. Your job is to create browser readable code. That’s it. Just because you’ve overcomplicated your code so much that only you can understand it half the time does not make you an application developer. Creating a browser… now that’s application development. Until that point, you’re just creating a string of characters.

So, then, webpages started to evolve to create dynamic content… So whenever you land on the root of a site, you’re really hitting a script file… something like index.php. Somewhere on the server, in a configuration file, we’ve created the logic to say that the initial point, the entry point should be index.php… we call this the Directory Index.

This file can simply contain pure HTML code just like your *.html files. But… you can do something magical on them. You can render different content. PHP (as well as VB Script used to do), can make this happen. By using the php tags () respectively, you’ve just told the php engine that there’s some code in between. So… PHP, do your thing. Look between these tags and do some work.

I keep hearing from so many new aged developers about keeping your code separated… something about code separation makes things cleaner. I couldn’t agree more… when you’re talking about keeping your styles and JS separate, that’s a great idea. When you’re talking about adding PHP tags in your pages, why are we so scared? the code is completely separated. There’s HTML and then there’s dynamic code inside that HTML that makes sense to have there. The page becomes a template. You don’t need to have template files nested 10 directories deep. The php file itself becomes the template.

I’ve actually heard this argument before… “But php tags look so ugly… so I use smarty tags”. O_O … Are you an idiot? They look ugly? So that’s why you have to add a layer of abstraction on top of it? Adding smarty is not so smarty, is it?… That layer of abstraction just made your code slower because the PHP engine has to now convert ALL of the curly brackets on the page to “ugly” php tags… You know what? If php tags are ugly, then smarty tags are stupid. If that’s the case, I’d rather be ugly than stupid.

It feels like abstraction has gotten out of hand where we now pull HTML templates inside some private function inside a file nested another 10 directories deep.

This mentality of super abstraction is what I have a big issue with when it comes to development for the web. It’s typically engineers who consider themselves super smart coming from the world of Java or C++ who somehow believe that coding on the web is the same thing as console, or application development. It’s not the same thing.

Let me explain so someone as smart as you can understand. Java development doesn’t have a browser for which you need to write a string. It doesn’t have multiple languages to handle, such as HTML, JS and CSS. It’s one code… assembly. And of course, to make it easy, there have been compilers built that can convert all of your nicely written OOP code in code that the machine understands. It gets compiled, and your code is typically living within the Java engine that you downloaded and installed (not a browser, it’s an engine with which the user never directly interacts). It stays in RAM. HTML code doesn’t stay in RAM. It gets put on a disk (browser cache). The CSS, same thing. The JS, same thing. All those pretty objects that you took all that time to build, are gone! Not in memory. Not on the disk. It’s all gone. Oh, you want to access them? Well, then we have to hit a database on a server somewhere far away from your home in order to re-build whatever you’re seeking. Get it? It’s not the same thing as app development.

If you work with PHP, you’re not building any application. You’re building code that’s to be interpreted by the PHP engine on the server in order to deliver a string of characters back to someone using a browser.

Applications, on the other hand, get installed on consoles, and PCs, and hand held devices. Upon starting the application, a whole bunch of stuff gets loaded in memory, and then the program itself uses those bits from memory. And all that stays in memory while the program is active. Only when you chose to quit the application does the application unload itself from memory. All those “object pointers” for functions and variables get cleared out.

In the end, I suppose some will never understand the difference between application and web page no matter how much you try to explain to them. Or, someone will come along claiming that they’re working on a huge website where OOP is saving their life, or some brainiac engineer claims that they don’t see how they could have built their “web app” without OOP. Obviously they’re not intelligent enough to realize that before “web oop” ALL websites were done without OOP, and they did just fine, because they built them well. It was how they coded them that mattered, not what techniques they used.

This was my rant. Thank you for listening / reading.

Update: After careful consideration, and many of your comments, I’ve come to the conclusion that it’s not OOP that I hate. I think it’s the misuse of it. Writing your models in a way that you have to load all of them for something simple… writing your SQL queries so you have to loop through database requests because you must use ORMs… instead of just writing a query that’s more complex, but increases performance 10 fold… Oh, and what’s wrong with SQL itself? It’s an awesome language to know.

I believe that it’s the way coders have been writing code that’s more of an issue for me than the actual style. PHP is not Ruby. Not everything is an object… especially when it comes to rendering things in HTML.

I’ve been using Code Igniter for my latest two projects and it’s not as painful anymore. I don’t like how it routes things as Apache is much more performant when it comes time to handle routes via Rewrite Module.

I also miss the idea of finding a page in the root (about.php) for an “/about.html” request. However… if you check your routes, it should be no problem to navigate through controllers then views (partials too). Still… looking through three or four different files to find what I’m seeking, is more work than I’d like to do… one file… off the root… about.php. Done. I suppose I can do that if I alter my htaccess file, but then… why am I using CI in the first place?

Anyway… I’ll continue to use a mix of procedural and OOP code as I’ve been doing more of lately. (Using 3rd party libraries has become a bit easier).

Once again, thanks for listening. I hope this can help other “non-believers” to understand that we need to understand our needs before we write any code.

I wonder if facebook or google uses any OOP development on the back end in their websites… er… web apps.