When I first sat down to write this article, I asked myself, “Self, exactly how long has PHP been around?” I was shocked (and felt a bit old) by the answer. The original development began around 1994, but PHP as most people know it (PHP3) was originally released in 1998. Twenty one years ago. TWENTY ONE YEARS. That kind of lifespan for anything on the web is pretty impressive.
The Early Days
I first started using PHP with version 3. At that time, I was just getting into programming and was still learning the basics. I didn’t know anything about Objects, or what Object Oriented Programming was, but PHP was something that was easy to pick up. I could use it for scripting, or for driving terrible web pages (which I thought were absolutely awesome at the time).
Most of my knowledge was born out of looking at other people’s work and examples on the web, so most of what I did followed that paradigm. I usually had one really large procedural file, or at least split up “pages” between different files. Web forms got kinda tricky because sometimes they would post to a separate file, but I thought I was hot stuff by putting the form processing in the beginning of a page surrounded by a big if statement. If the post variables existed, do stuff with them then show the page, or just show the page (I’m doing programming!).
As I matured in my craft and started learning more about Objects and some other best practices, I gradually understood that what I was doing was horrible and wrong, but most of the web up until that point was written that way – large procedural files. Sometimes there was some code sharing by virtue of require statements, but for the most part it was a wild west of no frameworks and an “anything goes” kind of mindset.
One example I like to go back to is some of the early versions of phpBB. The main loop to generate the forum indexes or content pages is a HUGE procedural mess. The code comments are equally fantastic – Things like “main render loop…. ok.. here we go…”. Even the original developers knew it was a mess, but just rolled with it. The sad thing is that this render loop (which is hundreds of lines long) can be replaced today by 10-20 lines of angular.js code. TWENTY lines… That is the power of Objects and frameworks.
PHP Matures – PHP 5
By the time PHP5 rolled around, we started getting a lot more support for Object Oriented Programming. Even a lot of the built in functions to PHP had object equivalents. Just go check out the datetime documentation and you can see what I’m talking about.
So, we have objects and are creating code, but there was one major problem. If I had a file that defined a class… a Foo class, it could be overridden by another file that is included later on if it also had a Foo class. PHP didn’t support namespaces.
For the most part, that wasn’t necessarily a problem. A developer usually was in full control of their project, so they just made sure not to name things the same (however, this spawned things like enumerating classes: Foo, Foo2…, etc). When we started sharing code, however, is when things started to fall apart.
If my friend made an awesome widget I wanted to use, I had to make sure all the classes he used were named something different from mine or I couldn’t use his widget. This made cross-project code reuse complicated at best.
PHP 5.3 to the Rescue
The biggest thing (for me) that came with PHP 5.3 was namespaces. If you are unfamiliar with namespaces, they are like an address for your class file. You can have multiple classes named the same, but if the namespace is different, that’s ok (Mr. Smith at 123 test street and Mr. Smith at 456 test street).
Other Object Oriented languages use this concept to sandbox code, which makes it VERY easy to share and reuse pieces. My only issue with PHP namespaces is how it was implemented. Most other languages use a dot (.) to separate namespace names, but PHP uses a backslash (some.class vs someclass). This is mostly due to not breaking older code since PHP uses the dot (.) for string concatenation, but still.
Constructs
From the early days, index.php files tended to be… cluttered. If you were using a lot of different files, sometimes there were a ton of includes at the top of the file (or scattered around). When classes came around, the app just simply had to know about the class. This caused a paradigm of the index.php including EVERYTHING (all classes your app needed to run), then servicing the request.
With small apps, this isn’t necessarily a bad thing (that you would readily notice) but for larger apps, this is a death sentence. There was an app I was working with that had a CMS component to it. With that, you had to make a PHP request to retrieve images – to get the image location and size from a db server to show it. That operation by itself isn’t all that complex or full of overhead, but with the way the app was written, the index.php loaded the ENTIRE app before servicing any requests. At best, that image came back in 200 ms. At worst, it would take 2-4 seconds – all because of wasted cycles loading unnecessary files.
With that in mind, each request should only really load the classes necessary to complete the task at hand. Some frameworks include a dynamic class loader (Pholdbox is one), but these are easy to build if you wanted to try it yourself.
Final Thoughts
PHP has come a long way and will continue to get better. By virtue of being backward compatible it will still have its quirks, but as long as future development gets more and more object oriented, PHP has a bright future. New versions have very promising features and enhancements coming. The best thing you can do is write the best code you can and take advantage of what PHP has to offer.
