2012 was an excellent year for the PHP community, thanks to many badly needed features being added to version 5.4, as well as the countless projects, advancing PHP to the next level.
In this article, I'd like to review a handful of the issues that people had with PHP in the past, and provide a glimpse at why 2013 just may be the year of PHP!
Why the Hostility?
This may come as a surprise to you, but many people have negative feelings toward PHP developers, and the language as a whole. You likely know exactly what I mean, if you've considered learning Ruby in the past couple of years, due to some sense of peer pressure.
However, before you make any changes, you have to ask yourself: "Why does PHP have such a stigma?"
Well, like many of life's important questions, there is no clear-cut answer. After doing a bit of searching online, for some PHP arguments, you'll find that roughly eighty percent of the arguments against PHP are rooted in ignorance, in one form or another.
Roughly eighty percent of the arguments against PHP are rooted in ignorance.
The Beginners
There are the beginners, who don't really know how PHP works. This results in questions, like "Why can't you listen for button events with PHP?," and similar questions about AJAX.
One Language to Rule Them All
Next, you have the folks who don't know about other language or framework than the one that they currently use. These are the types of people who make arguments, such as "Rails is much easier then PHP," and things like that.
Fighting PHP 4
The third form of misconception comes from the people who haven't kept up with PHP's advances over the years. Instead, they're still fighting the language, as it existed years and years ago. This results in statements, like: "PHP isn't object oriented" or "PHP sucks because it doesn't support namespacing." You get the idea.
Scaling
Lastly, we have the more intelligent developers who believe that "PHP can't scale" or "PHP has no standards," which is completely false. Scaling has less to do with the language, and more with the server and how your app is structured. As for standards? Well, it only takes a quick Google search for PHP-FIG.
It's an unfortunate truth that some arguments, which permeate through the web are either completely false, or updated.
PHP Isn't Perfect
There's truth in every criticism, however.
There's truth in every criticism, however. PHP isn't perfect. When it comes to its implementation of core features and functions, PHP is inconsistent. These arguments are entirely valid.
These inconsistencies are not without reason, though. PHP started out as what we would refer to today as a templating language. Since then, it has gone through multiple paradigm shifts, transforming into a functional language, like C, and then to the fully OOP language that we enjoy today. Along the way, best practices have emerged, and different people have been in control of what is added. This results in a lot of "different" kinds of code in one language. Now you might ask, "Why not just deprecate the bad parts?"
The answer to this question is the same as to why we are still building sites for old versions of Internet Explorer. Don't get me wrong; I would love to just drop it, but massive changes like this can't be done without a bit of time. Hopefully, over time, PHP will advance further into OOP, and begin converting its objects to use their functions with the dot notation, rather than the admittedly awkward -> syntax. So, instead of array_push($arr, "Value");, you would write something, like $arr.push("Value");.
Don't worry; things like this have been happening slowly. Just look at the new PHP 5.5 features. The old function-oriented MySQL add-on has been deprecated, in favor of the newer object-oriented approach.
The Present
Now with the past covered, let's move up to the present. There are a handful of really cool projects and movements, some of which borrow ideas from other languages, in order to propel PHP to the next level.
Let's consider the following:
Composer
The PHP community can now stop reinventing the wheel over and over again, thanks to Composer.
Inspired by tools, like Bundler and NPM, the PHP community can now stop reinventing the wheel over and over again, thanks to Composer. Node.js was the first language that made me feel comfortable with using packages. If you've used it before, then you know what I mean. Packages are installed locally to your project's directory, it's easy to find documentation for most of the plugins, and it's relatively simple to submit your own packages.
PEAR?
PHP did offer an alternative for years, PEAR, but it wasn't overly intuitive or easy to use. It felt bulky for something that ultimately fetched plain-text files. Further, it installed all packages globally. This forced you to inform people which packages you used when distributing your source code. As you might guess, this resulted in mis-matched versions, and other things of that nature.
If you so desire, you can pick and choose your components.
Composer fixes all of this, thanks to locally stored packages, and the ability to create per-project dependency files. This means you can easily distribute your project with this dependency file, and others can use their own copy of Composer to automatically download all specified dependencies, while simultaneously keeping them up to date.
Additionally, Composer is a light application - written in PHP, itself - and comes with an autoloader feature. This works off of the PSR-0 standard (mentioned above), which will automatically load your dependancies as you need them, so your application remains as clean as possible.
All of these features are a definite improvement, however, without community adoption, it means nothing. I'm happy to inform you that it's been very well accepted. Big projects, such as Symfony and Laravel, have already uploaded their components to the Composer library, Packagist. Having the framework split up into components means that you can easily build your own custom framework to match your liking. In other words, no more bloated frameworks. If you so desire, you can pick and choose your components.
Need an example? You could take the database component from Laravel, and pair it with the templating component from the Symfony framework. In fact, the Laravel framework, itself, leverages many well-tested Symfony components. Why rebuild the wheel, when you can instead focus your efforts on other areas?
Laravel
Even if you do have issues with some of PHP's inconsistencies, Laravel abstracts nearly all of it.
Now this wouldn't be an article about PHP's future without discussing Laravel in a bit more detail. We're often asked why Nettuts+ seems to be pushing Laravel as much as it has been. This is the wrong question. Instead, ask "Why not?"
Even if you do have issues with some of PHP's inconsistencies, Laravel abstracts nearly all of it, providing you with the feel and elegance of a language, like Ruby, but with the ease of PHP.
Laravel comes with Eloquent, an ORM that completely rethinks everything to do with databases. I mostly use MySQL with PHP; what you get back from the database is a resource object, which you then have to run through a function to capture the results. In Laravel, everything is returned as standard PHP; you're given objects, which you can modify and save. You can do things, such as combining results from multiple tables to save on database calls (referred to as eager loading), and laughably simple to do things, like validation and custom queries. As a bonus, if you don't like SQL, well all of this can be done with an OOP style, using simple and readable methods, such as find and delete.
We've only seen the tip of the iceberg with what Eloquent brings to the table, but, already, you can see the improvements. Laravel brings this kind of innovation to nearly every field of PHP, including things like templating, routing, migrations, RESTful classes, and more. The best part, though, is that, with each new release, Laravel's creator, Taylor Otwell, continues to raise the bar.
If you'd like to learn more about Laravel, I recommend the Tuts+ Premium course, Laravel Essentials, taught by our very own Jeffrey Way. I'm not saying this as a part of the Nettuts+ staff, but as a person who watched the series. I can honestly say that I had zero knowledge of Laravel going in, and Jeffrey did an excellent job of covering as much as possible.
Ultimately it's not really about the framework, but the community support. As long as there is support for a project, it will be updated and will remain relevant. If your worried about how long it will remain popular, then, simply by actively using it, you are securing your odds!
PHP 5.4 / 5.5
The next thing that I'd like to discuss is the updates to PHP that were released in 2012. With the release of version 5.4 came a plethora of excellent new features. For a full overview of the updates, you can take a look at these two articles here on Nettuts+: 5.4 article, 5.5 article.
But, for a quick recap of my favorites:
Traits
- Traits add the ability to create Class "partials," which allows you to create consistent objects without re-writing everything over and over.
Generators
- Generators let you do some cool things with lists of data, as well as allow you to benefit from all the features that come with lazy-evaluation.
CLI Web Server
- Another great addition is the built in web server, which allows you to test your applications with different versions of PHP, without the need for something like Apache.
Dereferencing
- Dereferencing is not a major addition, but it's nice to be able to reference child elements without the use of functions. This includes things like accessing individual characters of a constant by using only square bracket notation.
The New Password Hashing API
- With the new API, you are given the ability to both encrypt strings, as well as verify and strengthen passwords - all without any knowledge of bcrypt or any other hashing algorithm.
These represent just a few of the new improvements, and their is a whole list of things that are currently being discussed for the next version, scheduled to be released later this year.
Test Driven Development
Finally, let's talk a bit about testing your code. While admittedly a bit late to the game, in 2012, our community saw widespread adoption of the test driven development methodology. I could make up a growth percentage, but I feel that a better indication of truth is to simply looking around on different dev sites and forums. You'll surely see a spike! When it comes to testing in PHP, PHPUnit is the well-accepted standard.
Why is it Important?
Think about your project before diving in, like a cowboy.
Many times, you set out to write some code, but you lose something in the translation. What I mean by this is that you plan on one thing, but when implementing it, you lose a bit of the integrity or functionality. Another common problem arises when writing code for large projects: you end up with multiple classes and files that each have their own dependancies. What your left with is an "intertwined evolution" of functionality that can prove difficult to keep track of and maintain. Like a game of Jenga, by updating one piece, you may break another, crippling your application. These are just two example problems, but there are certainly others.
How Does TDD Help?
Well, you write clear tests before writing any production code. This means, when you get to writing your actual code, it is forced to conform to your original plan. Not only this, but, down the line all, dependencies will be tracked in your tests. If you update a bit of code, and inadvertently break one of the tests, you will immediately be notified.
Yes setting up these tests requires an extra step, but so is thinking before you speak. Does anyone the benefits of that? Of course not. The same is true for tests: think about your project before diving in, like a cowboy.
Additional Learning
- Test-Driven PHP (Premium)
- TDD in PHP
Conclusion
It's an exciting time to be a PHP developer. Many of the inherent problems have or are being fixed. AS for the other issues, we'll those are easily remedied with a good framework and testing.
So what do you think? Are you getting on board? Disagree with me? If so, let's continue the discussion below!
Comments