About a month before writing this article, I needed a website. Although I had a simple portfolio and blog on GitHub pages, the platform had it’s limitations, so I explored other options, from self-hosting to shared hosting. I chose the latter.
A Justification for using shared hosting
Before making a choice, I had to be clear about my requirements. My site would need a blog and host a portfolio. I may use a small part of the site to test out simple web apps or front-end designs. I also didn’t expect to receive a high traffic volume. If I had gone for cloud hosting, I could have utilised servers running on virtual machines with NextJS or Python handling the business logic and PostgreSQL or MongoDB for database storage, yet doing so could be costly and time-consuming. I could see the point of using such services if I was developing a bespoke app that required some special functionality, but as my priority was on developing a website, shared hosting ended up being the more convenient option. I could have used a third-party website builder like Wix or Squarespace, but that option would have been too restrictive. Such services are suitable in many cases but they are not ideal for explorative/experimental web development.
There are also other benefits to using shared hosting, cost being the main one. Shared hosting is extremely affordable now, compared to a decade ago. Many may criticize it on the grounds of performance since one site shares the same server resources with others. Yet, even in the past, as long a reputable hosting provider was used I rarely found that to be the case. The truth is that most sites that use shared hosting are likely to attract low to medium traffic volumes, and they are less likely to consume large amounts of server resources. It’s like keeping several tiny fish in an aquarium; as long as the aquarium is big enough, and there are not too many large fish, everyone is happy. In any case, modern hosting providers place limits on the number of server resources any one site can utilise, this safeguards the performance for others. So, for me, shared hosting is ideal and is acceptable for what I want to achieve.
An old acquaintance
There are a few downsides to shared hosting, the greatest being the limitation on technology. Mostly shared hosting uses some variation on the LAMP (Linux Apahce2 MySQL PHP) tech stack. Why? Because these technologies have a proven track record of working well with shared hosting providers.
I had been avoiding PHP and MySQL for 8-10 years now. PHP was the first language I used for actual work, but during that time I began to develop feelings of ineptitude. Primarily caused by a lack of understanding regarding software development and theory. Since then, I have learned several other languages and even gained a computer science degree. So I never felt the need to look back on PHP. PHP provided me with my initial impression of back-end coding, a mediocre baseline from which I would compare every other back-end technology to. In retrospect, this was an unjustified and tainted view of PHP based on my initial inexperience.
Time to re-evaluate
A paraphrased saying attributed to Miyamoto Musashi is that “In a fight to the death, we must make the fullest use of all the weapons at our disposal…”. Similarly, I can apply this mindset to utilising all the available technologies that shared hosting has to offer. Though I could limit myself to JavaScript, HTML, and CSS and still make a functional site, incorporating PHP and MySQL can expand the possibilities. If it’s there why not use it?
Current popular opinion suggests that developers should develop web services using more modern means, with languages such as C#, Java, or Go. Creating cloud-based services based on these languages is a better approach. That is to say that many believe that PHP has had its day, its obsolete and anyone who uses it is behind with the times. However, I have found that popular opinion does not always hold true, that there is no one technology to rule them all. And the fact remains that PHP was the work horse for web servers for over two decades, it has matured and proven itself time and time again, these facts hold clout, especially when we all must acknowledged that even major commercial organisations still continue to invest in their PHP code base.
The decline of PHP
Various stats will show that PHP is in slow decline, in fact google trends suggests that interest in PHP has decline since 2004, in line with other languages like C and Java. If other languages are following similar trends then it clearly shows that the decline of PHP in not necessarily indicative of its capabilities. The fact is that PHP was only one of few options available to back-end web developers in the past. It is no wonder that it held the top spot in its niche and became ubiquitous, yet as the years have rolled on, new technologies would arrive and dilute share of the market. Server-based technologies built with Java, C#, Python, JavaScript etc. PHP’s decline was not due to it lacking something, but because other choices became available. In today’s world virtual machines and even dedicated servers are becoming more affordable, allowing developers to implement solutions with a variety of technologies. There is also a long-running trend around consolidating web front-end and back-end systems under a single foundational programming language like JavaScript. So in many ways, it makes sense for a developer to focus their attention on learning one language than learning two or three.
We often believe that declines result in end of something, as if there was some sort of inevitable death. But if PHP follows the pattern of decline that other longed lived programming languages like C and Java have shown, then PHP’s future is unlikely to be obsoletion. The decline will eventually flatten out into a glide, which it has already shown to be the case.
PHP is still here, running on most of the web, taking in server requests and spitting out responses, used by small and large enterprises alike.