From PHP’s early beginnings to running 82% of the web today, learn about the creation and resurgence of this popular language.
Listen and Learn:
- How did PHP, with a seemingly “bad” reputation, became a fully featured object-oriented language?
- What does movement towards cloud deployment mean for PHP?
- How to get involved in your local PHP community/meetup group
Interested in learning more about PHP and popular applications such as LAMP and Wordpress? Check out our library of Bitnami packaged apps that use PHP (plus exclusive training from php[architect])!
Stuart Langridge: These are the Bitnami Open Source Leaders Series and Interviews. I'm Stuart Langridge, and I'm talking to Eli White, who's one of the co-owners of php[architect] and a pretty big noise in the PHP world generally. How's it going, Eli?
Eli White: All right. It's going well.
Stuart Langridge: One of the things I want to talk about here is that PHP has something of a bad reputation, but it has a bad reputation among people who don't know anything about it. Specifically, the language as well as the structures have changed quite dramatically since a whole bunch of people wrote PHP in about 1999. Can you talk a little bit about what's changed and how?
Eli White: Sure. That's a huge topic because there are tons of things that have changed. If we wanted to pick a place to start, if you just want to talk about the language itself, and if you're looking at 1999 or 2000 (which in technology terms are ages and eons ago) it has evolved truly as a language. In the beginning it went from being this little scripting thing, not much more than server-side includes where you're dropping little bits of code in the middle of your HTML, to becoming a fully featured object-oriented language and taking on all sorts of other stuff. That's actually one of the really unique things to me about PHP as a language. Some may say it’s the only one. Some may say it's one of a few. I'll let other people debate that, but it's the fact that it is a language that itself is truly an open source project. In that I mean there are lots of programming languages that are open source projects, but there's often the one person behind them (or that team of two or three people behind them) that are deciding where the language goes and what features it should have or not. Whereas PHP embraced the idea that there's an internals mailing list where anyone can join and any who have input or who are involved with the project get voting rights onto PHP's core. People come up with proposals, they throw proposals out, and it gets debated. There's a voting process that happens to see whether or not something will or won't be added, and so it's this very big democratic process that leads to the fact that PHP continually grows (and I'll use the term borrows) ideas from other languages.
So if everyone really loves some specific idea from JavaScript, for example, and they think it’s the greatest thing, within a couple of years PHP will suck that idea in and now we can do that in PHP as well. It’s that amount of constant growth and iteration that has really taken PHP from those early days where anyone such as myself with a computer science background that was looking at that 1999 PHP code and was gacking at it and going, "This is horrible and look at all this stuff people have done," … it's now a very robust language wherein you can do really good things and you can build gigantic web sites like Facebook completely in PHP… and, that works.
So if everyone really loves some specific idea from JavaScript, for example, and they think it’s the greatest thing, within a couple of years PHP will suck that idea in and now we can do that in PHP as well. It’s that amount of constant growth and iteration that has really taken PHP from those early days where anyone such as myself with a computer science background that was looking at that 1999 PHP code and was gacking at it and going, "This is horrible and look at all this stuff people have done," … it's now a very robust language wherein you can do really good things and you can build gigantic web sites like Facebook completely in PHP… and, that works.
Stuart Langridge: That's interesting because, as you say, one of the things that has changed is the core language itself, but exactly as you said at the end, one of the big complaints everyone had about PHP was the code was all over the place. It's all very unstructured. You see individual PHP pages doing things and then a few other things and that was it. There's no motion of an overriding framework or being able to reuse components from other places. Since those days, we've seen other languages come up such as Ruby, or JavaScript or Python, and they've developed systems for doing things like sharing components. JavaScript has MPM. Python has Pypi, so on and so forth. PHP now has the same thing.
Eli White: Right, with Composer.
Stuart Langridge: Yeah, so how does that work? PHP always had things like PAM and PECL, but what's the change that Composer brought about? And how did it come about? Was it embedded on the PHP's internals mail list or was it a third-party project that everyone decided to adopt?
Eli White: It was just a third-party project that was so awesome everyone started using it. And you’re right. In the past, there was PEAR, for example. And PEAR – PEAR was a great project. It was great for what it was at the time, but part of the problem with PEAR is it became what it was and PEAR was great, but it was trying to be this big central repository and anyone could throw things up there. So you started getting into that place of having a lot of proliferation and lots of different things that maybe did similar stuff, different libraries not necessarily having the same level of polish on them, but it was all being put out as the PEAR library.
And the way that PEAR kind of worked to manage its dependencies…it worked perhaps a lot more like a make-script for building a UNIX utility, for those folks who have done that before, where you would have to have a command-line level access to head into the machine you were going to be on, install all these PEAR libraries, which starts bringing in all these related PEAR libraries, and all that gets installed by default. There's ways to work around this, but by default, it was set up around the idea of I'm installing these – all these libraries on this server for any PHP script, any PHP application on this server to use. And so that quickly, for example, became a problem in shared hosting environments where the shared host didn't want to put all these libraries on there, and it became a problem with deployment processes and things as well because it was, again, something designed for you to head on the server and do.
One of the things that Composer brought in is the fact that Composer is quite often used sort of client-side dev-side, where you're building your project locally by Composer pulling in the different libraries. You're specifying ‘I want this library, this version, this library, this version, this library’… ‘I don't care what version. Give me the latest.’ And then Composer's going off and pulling all this together and making an installed version of all that locally, which you could then pick up and FTP to a server and it works, regardless of how the server is configured.
And the way that PEAR kind of worked to manage its dependencies…it worked perhaps a lot more like a make-script for building a UNIX utility, for those folks who have done that before, where you would have to have a command-line level access to head into the machine you were going to be on, install all these PEAR libraries, which starts bringing in all these related PEAR libraries, and all that gets installed by default. There's ways to work around this, but by default, it was set up around the idea of I'm installing these – all these libraries on this server for any PHP script, any PHP application on this server to use. And so that quickly, for example, became a problem in shared hosting environments where the shared host didn't want to put all these libraries on there, and it became a problem with deployment processes and things as well because it was, again, something designed for you to head on the server and do.
One of the things that Composer brought in is the fact that Composer is quite often used sort of client-side dev-side, where you're building your project locally by Composer pulling in the different libraries. You're specifying ‘I want this library, this version, this library, this version, this library’… ‘I don't care what version. Give me the latest.’ And then Composer's going off and pulling all this together and making an installed version of all that locally, which you could then pick up and FTP to a server and it works, regardless of how the server is configured.
Stuart Langridge: That's an interesting point because one of the things that PHP has always had is a superbly easy deployment in that you just FTP a folder up somewhere and it still works, which gained popularity in shared hosting environments. Deploying anything else is still way harder. It requires a host who actually knows and cares about your particular choice of language and so on and so forth. As these new changes happened, something like Composer doesn't alter that, correct? Because you're still building, as you say, your project locally and then it's just PHP when it gets up to the server.
Eli White: Right, exactly.
Stuart Langridge: But how does that change if there are new things planned which will require hosts to be more aware of the PHP that you're doing? Or is maintaining that trivially easy deployment one of the core tenets?
Eli White: I believe that maintaining that trivially easy deployment is one of the core tenets. As you start talking about hosting situations, you do start getting into the sort of infamous debate and argument between PHP coders and their hosts when it comes to versions of PHP where there's a number of folks who will joke that “it's great that PHP is coming out with all these brand new things” and “I hope my host will get that in a few years…or decade”. I will say there has been a lot of push and positive movement to help that clear up in the future. There has been, for a long time now, the PHP internals group has really focused on making sure that migrating small point releases should not be a pain. This was a problem in the past.
I don't remember the specific issues right now, but when going from PHP – obviously going from PHP4 to PHP5 was a major change and things would break. But going even from PHP 5.0 to 5.1 and 5.1 to 5.2, there were just enough backwards compatibility issues that would happen that it could trip people up, and it therefore meant that a lot of hosts didn't want to upgrade. Whatever they were on is what they're on. If I upgrade, it might break something. And the PHP group since then has gotten really good and focused, and there are a few people in particular on the internals list who have made it their mantra to make sure this doesn't happen and that you do not break backwards compatibility at all unless it is absolutely necessary for a security purpose. That’s extremely rare unless you're going to a brand new release. So a point release, like 5.3 to 5.4; 5.4 to 5.5, no, you do not break backwards compatibility to make it easy for hosts to just upgrade. And a lot of hosts have been doing better about that since then.
Now, we do have now on the horizon PHP7, which is a major release number. It will potentially have some backwards compatibility issues. At the same time, the PHP group is actually working – I'm on the internals list and read everything that comes across, and there's a lot of work and a lot of people really pushing towards the fact that, just because we're naming it a new major release number and we could break backwards compatibility, let's not do it just because we can. And they're really focused on making sure that it will be as backwards compatible as possible while still allowing them the flexibility of a major release number to add in new things that maybe aren't backwards compatibility, but anything that's added that way will have a lot of thought put behind it, and the pros and cons weighed and, we're going to gain these huge benefits by doing this, so it's worth this one change.
I don't remember the specific issues right now, but when going from PHP – obviously going from PHP4 to PHP5 was a major change and things would break. But going even from PHP 5.0 to 5.1 and 5.1 to 5.2, there were just enough backwards compatibility issues that would happen that it could trip people up, and it therefore meant that a lot of hosts didn't want to upgrade. Whatever they were on is what they're on. If I upgrade, it might break something. And the PHP group since then has gotten really good and focused, and there are a few people in particular on the internals list who have made it their mantra to make sure this doesn't happen and that you do not break backwards compatibility at all unless it is absolutely necessary for a security purpose. That’s extremely rare unless you're going to a brand new release. So a point release, like 5.3 to 5.4; 5.4 to 5.5, no, you do not break backwards compatibility to make it easy for hosts to just upgrade. And a lot of hosts have been doing better about that since then.
Now, we do have now on the horizon PHP7, which is a major release number. It will potentially have some backwards compatibility issues. At the same time, the PHP group is actually working – I'm on the internals list and read everything that comes across, and there's a lot of work and a lot of people really pushing towards the fact that, just because we're naming it a new major release number and we could break backwards compatibility, let's not do it just because we can. And they're really focused on making sure that it will be as backwards compatible as possible while still allowing them the flexibility of a major release number to add in new things that maybe aren't backwards compatibility, but anything that's added that way will have a lot of thought put behind it, and the pros and cons weighed and, we're going to gain these huge benefits by doing this, so it's worth this one change.
Stuart Langridge: One of the big potential advantages of moving towards an all- component architecture is that, at least in theory, you can pick up and use a component in any one of the environments. Now, there was a stage a few years ago where you have this kind of component architecture, but the components only work with one particular thing. You are the symphony person…or you weren't. And if you were the symphony person, you could use symphony components, and if you weren't, then you couldn't. The idea, as I understand it, behind this change is that that no longer is the case, or it shouldn't be the case.
Eli White: Very true.
Stuart Langridge: Is that actually coming true as was expected?
Eli White: I believe it is, and this even gets back into that discussion of the people looking at code from 1999. There has been a huge change over the last four or five years, let alone over the entire lifecycle of PHP, as to how people write the code. In the beginning, a lot of that, people looking at the code and cringing, is because everyone was, you know, rewriting the same code all the time. Everyone was writing a database access layer themselves. You fast-forward five years or whatever, and now, well people are actually using reusable components, but the problem is that there are 100 different database libraries out there and which one are you using. Well, I'm using this one. Well, that's different than the one I'm using, and there was a lot of issues with that.
Well, besides Composer now coming in and making it easy to bring in reusable components, one of the other big things that has happened recently in sort of this renaissance that PHP is experiencing right now is that more and more of the bigger projects, the projects that, for lack of a better term, have won the game in that they're still around and that they're still growing, are starting to build their own systems, their own frameworks in such a way that all the components are reusable. And there's been a lot of talks at conferences and on social media about these groups working together because, for example, why should Drupal and WordPress and Zend Framework and Symphony and whoever else all write their own database access layer or all write their own routing component that does the same thing. They all end up having to write the same thing and maintain the same thing if one group can write that and maintain it and make sure it works, that frees up all these cycles for the other groups to just go off and do what they need to do that makes their project unique.
And one of the biggest cases you can see now of where this has been happening has been with the latest version of Drupal that's coming out. Drupal now has gone through this process of going through their entire code base and tossing out huge sections and replacing them with direct components from Symphony, from Zend Framework, some other libraries out there, so now when you actually do a modern Drupal install it’s pulling in parts of Symphony and parts of Zend Framework, that the Drupal folks are not maintaining themselves…they don't need to worry about that. They can focus on making the CMS and application aspects of Drupal better and not focus on, “Wait, how should this database access library work”?
Well, besides Composer now coming in and making it easy to bring in reusable components, one of the other big things that has happened recently in sort of this renaissance that PHP is experiencing right now is that more and more of the bigger projects, the projects that, for lack of a better term, have won the game in that they're still around and that they're still growing, are starting to build their own systems, their own frameworks in such a way that all the components are reusable. And there's been a lot of talks at conferences and on social media about these groups working together because, for example, why should Drupal and WordPress and Zend Framework and Symphony and whoever else all write their own database access layer or all write their own routing component that does the same thing. They all end up having to write the same thing and maintain the same thing if one group can write that and maintain it and make sure it works, that frees up all these cycles for the other groups to just go off and do what they need to do that makes their project unique.
And one of the biggest cases you can see now of where this has been happening has been with the latest version of Drupal that's coming out. Drupal now has gone through this process of going through their entire code base and tossing out huge sections and replacing them with direct components from Symphony, from Zend Framework, some other libraries out there, so now when you actually do a modern Drupal install it’s pulling in parts of Symphony and parts of Zend Framework, that the Drupal folks are not maintaining themselves…they don't need to worry about that. They can focus on making the CMS and application aspects of Drupal better and not focus on, “Wait, how should this database access library work”?
Stuart Langridge: And that kind of resharing is absolutely the idea, obviously. PHP is a big enough deal that you've got two different kinds of products. You've got framework to help developers build things in PHP, but you've also got projects which happen to be written in PHP but don't particularly expose that to their end users, something like WordPress or Drupal.
Eli White: Right.
Stuart Langridge: In essence, most of the users neither know nor care that it's in PHP. They're using the interface of the software itself. Now, those existing projects, things like Drupal and WordPress tended to go off in their own direction and not hugely participate in the PHP community, but are you seeing other products like Drupal have coming back to the fold, I suppose you'd describe it?
Eli White: They are, and I think again that's part of this resurgence and renaissance that PHP is seeing right now is, in each their own way, all of these folks are now getting together and realizing that together we are much greater. Altogether, via the latest stats, PHP runs 82 percent of all web sites. You know, that's massive.
Stuart Langridge: Yes.
Eli White: Yeah, now of that, 25 percent of those are WordPress because WordPress runs about 25 percent of the web. And then, like, 5 percent's Drupal and 4 percent's Magento, and it goes down the list. But, each of those communities separately can be big, but when we all work together, again, we're 82 percent of the web, and that's a huge wonderful thing, and like you were saying, the communities are recognizing that. They are coming together and, I've specifically been seeing it in lots of different ways. At conferences now, there's been a lot of Drupal folks and WordPress folks coming to PHP conferences and PHP folks going out to their conferences and really starting to mingle. At PHP World that we hosted in DC just this last November, you know, we specifically worked to get the WordPress, the Drupal, the Magento, the Laravel, the Joomla, all those folks together, and there were actually some great things that came out of that as just having them all sit around a table at lunch and chat.
And now – and I said they're each coming their own way. They're all coming together to be part of the community. That doesn't necessarily mean everyone's going to go and use Zend's DB for their database library now because there's still some amount of ‘each project needs what's best for them’ and probably the best example and side-effect of that is specifically WordPress because WordPress is becoming – the WordPress folks, all the great people over at automatic, they're becoming very involved in the PHP community. They're really connecting with the PHP community far more than they used to, say five years ago. But at the same time, a lot of that connection is them actually connecting with us and explaining to the greater PHP community, ‘We're doing stuff differently but there's a reason and here's why’.
There have been some great talks from folks like Andrew Nacin, who's one of the lead developers for WordPress, specifically talking about how ‘because we happen to run on 25 percent of all web sites, we have to be a little more inclusive with our code base’ which means much of WordPress isn't using those reusable libraries because they were able to run tests and see that only 10 percent of all servers we're installed on happen to support this one library or happen to even be running PHP 5.2. And so their base requirements are a lot lower, which means they have to do a lot of their stuff in-house. But at the same time, they're now communicating. They're on mailing lists with folks together, and there's been a lot of information shared very recently when there was a big security breach that was happening with Drupal. A lot of the lead devs of WordPress and of Drupal were working together to help get that problem fixed on Drupal and to make sure that that problem didn't exist in WordPress. And that's something where, five years ago, you would not have seen happen. You would not have seen that amount of cross-communication.
And now – and I said they're each coming their own way. They're all coming together to be part of the community. That doesn't necessarily mean everyone's going to go and use Zend's DB for their database library now because there's still some amount of ‘each project needs what's best for them’ and probably the best example and side-effect of that is specifically WordPress because WordPress is becoming – the WordPress folks, all the great people over at automatic, they're becoming very involved in the PHP community. They're really connecting with the PHP community far more than they used to, say five years ago. But at the same time, a lot of that connection is them actually connecting with us and explaining to the greater PHP community, ‘We're doing stuff differently but there's a reason and here's why’.
There have been some great talks from folks like Andrew Nacin, who's one of the lead developers for WordPress, specifically talking about how ‘because we happen to run on 25 percent of all web sites, we have to be a little more inclusive with our code base’ which means much of WordPress isn't using those reusable libraries because they were able to run tests and see that only 10 percent of all servers we're installed on happen to support this one library or happen to even be running PHP 5.2. And so their base requirements are a lot lower, which means they have to do a lot of their stuff in-house. But at the same time, they're now communicating. They're on mailing lists with folks together, and there's been a lot of information shared very recently when there was a big security breach that was happening with Drupal. A lot of the lead devs of WordPress and of Drupal were working together to help get that problem fixed on Drupal and to make sure that that problem didn't exist in WordPress. And that's something where, five years ago, you would not have seen happen. You would not have seen that amount of cross-communication.
Stuart Langridge: So if people are looking at building things with WordPress and thinking ‘Wow, this is all new. I should get into this.’ What's the best way of doing so? I mean PHP didn't particularly have a central place you can go and look like projects. It's everywhere. So if you wanted to be part of the PHP community, find out more about this, I know you've got things like PHP Tech and PHP World that you already mentioned that you guys run as conferences. What's the best way to get a sense of what's going on and find out all about this sort of thing?
Eli White: Again, obviously conferences, whether they're ours or someone else's, any conference is always a great place to go and connect. There's a couple things that I would really point people towards. One is, if you happen to be someone who uses IRC, the PHP community as well as all the framework communities as well as Drupal and WordPress, they're all very active on IRC, and specifically on the free news IRC, there is #PHP, there's #PHPC for the PHP community, and then there are rooms for almost every single project you could possibly want if you join hash and enter a project name, chances are there's an IRC room with people talking about it and communicating.
Of course, social media like Facebook and Twitter are very active as well if you even just start searching. If you go on Twitter and search for PHP and start seeing the people who are regularly talking about it and start following some of them, you will get involved, but one of the best ways, in my opinion, to really start getting involved with the community in finding other resources and making those connections, is to find your local meet-up. I almost absolutely guarantee you that if you go to “meetup.com” and search for PHP and in your local area, you will find a local PHP user group within driving range for you that you can go to meetings, start listening to people talk about stuff, start connecting with other people. And I would say that, if you do a search for PHP in your local area and meet-up does not bring up a meet-up yet, congratulations, you just volunteered. You're starting a PHP meet-up in your local area because obviously one is needed.
Of course, social media like Facebook and Twitter are very active as well if you even just start searching. If you go on Twitter and search for PHP and start seeing the people who are regularly talking about it and start following some of them, you will get involved, but one of the best ways, in my opinion, to really start getting involved with the community in finding other resources and making those connections, is to find your local meet-up. I almost absolutely guarantee you that if you go to “meetup.com” and search for PHP and in your local area, you will find a local PHP user group within driving range for you that you can go to meetings, start listening to people talk about stuff, start connecting with other people. And I would say that, if you do a search for PHP in your local area and meet-up does not bring up a meet-up yet, congratulations, you just volunteered. You're starting a PHP meet-up in your local area because obviously one is needed.
Stuart Langridge: One final question. PHP traditionally has been, as you mentioned, the shared hosting environments. And then at the other end of the scale, people deploying their own servers. But since then, we've seen a fairly big rise in the notion of cloud computing like EC2 and Rackspace. Are you seeing a lot of people move to use PHP in that sort of environment? If you are, do you have some sense of how they're doing it? Such as Bitnami's one click deployments, and so forth. Are you seeing lots of people using the cloud for deployment of PHP or is it still aimed towards a kind of a shared hosting or run-my-own-servers environment?
Eli White: No, actually there's been a lot of movement that I have seen with PHP moving to cloud deployment. For whatever reason – I think there's some reasons, but they're my own personal ones, so I won't mention them, but a lot of it happens to be towards Amazon – you know, Amazon Web Services, and part of that is because PHP has become so ubiquitous and it's just included in pretty much any base Linux install anymore, that you can go to Amazon, for example, you can click a couple links to spin up an instance of Ubuntu, and PHP is already on it. You know, it's there, it's running, you have a web site with PHP. You know, it's that simple to do it, and the fact that cloud hosting has started getting, you know, the costs continually go down. You know, it's a very unique market at the moment when it's something where, you know, like Amazon reduces the costs of everything every single couple months. You get an e-mail of, hey, everything's two pennies cheaper now.
So it's about the same price a lot of times. If you're running just a little pet project on the side and you can buy a $10.00 a year shared hosting thing, okay, fine. You can't compete with that kind of pricing. But if you're actually throwing a project out there, something that’s going to be hosted and needs a little bit of CPU running, the cost of running a cloud server, even paying for it up front as if it wasn't a cloud server, has gotten so cheap that the benefits of having your own server, or “virtual server” that you can do whatever you want with it that are so big that so many people are going out to do it, and it's not just on Amazon Web Services. I've actually done projects on the Microsoft Azure cloud because, yes, you can run Linux on Azure. They set it up to make that fairly easy and there's actually a whole subgroup of the PHP community that are huge fans of Windows Azure and some of the one-button type installs that they can give you sort of, like what Bitnami can as well, not nearly as simple as Bitnami's where it's literally one click and it's running, but more a customized AWS version where you've spun up the server and then said, “Oh by the way, I wanted it to have WordPress if you don't mind.” And we will add it to it for you.
So it's about the same price a lot of times. If you're running just a little pet project on the side and you can buy a $10.00 a year shared hosting thing, okay, fine. You can't compete with that kind of pricing. But if you're actually throwing a project out there, something that’s going to be hosted and needs a little bit of CPU running, the cost of running a cloud server, even paying for it up front as if it wasn't a cloud server, has gotten so cheap that the benefits of having your own server, or “virtual server” that you can do whatever you want with it that are so big that so many people are going out to do it, and it's not just on Amazon Web Services. I've actually done projects on the Microsoft Azure cloud because, yes, you can run Linux on Azure. They set it up to make that fairly easy and there's actually a whole subgroup of the PHP community that are huge fans of Windows Azure and some of the one-button type installs that they can give you sort of, like what Bitnami can as well, not nearly as simple as Bitnami's where it's literally one click and it's running, but more a customized AWS version where you've spun up the server and then said, “Oh by the way, I wanted it to have WordPress if you don't mind.” And we will add it to it for you.
Stuart Langridge: Excellent. Thank you very much for talking to us and explaining everything that's going on. Eli White of php[architect].
Eli White: Thank you very much.