PHP: the quiet powerhouse

Yes, that's a valid point, if you mean that smartphones have less resources (memory, CPU) to handle JavaScript execution. But keep in mind that a native smartphone app is a thick client; it has all of the view logic.

Perhaps I need to back up and explain my point better. Maybe people are misunderstanding me because they think I'm talking about what's going to happen in the next few months. Server-side view rendering is not going anywhere anytime soon. But it's on its way out in that it's an anachronistic way of thinking about the web; it's a relic of the past--of the time of web "pages"--and not of the future, of web "apps" and "resources". As long as you are serving content that's primarily to be "read", like articles, books, blogs, etc., server-side rendering has its place.

But look what's happening to the web. Native iPhone apps have to store their data somewhere, so they communicate to the backend via an API. Cars are reading Twitter. Thinking about the past of the web, only browsers consumed web content. Now non-browsers consume web data via APIs, and I see this trend as increasing.

I see a trend where more web apps will be like a "smart database in the cloud", meaning they hold data and business logic and communicate via JSON APIs. There may be a variety of client devices accessing this data in the cloud: native iPhone apps, desktop browsers, other Internet-enabled devices.

The main point is that clients are no longer only browsers. The clients could be a variety of devices running on a variety of operating systems. So it doesn't make sense for the server to render the view and send it down the pipe for the client to display. It makes more sense for the server to send data to the client and the client to decide how to render it.

I'm not claiming that server-side view rendering will go away completely; it has its place with articles and blogs. But with apps, I see a movement toward thick clients and I don't see this trend slowing down. It's hard for me to envision a world in 10 years with less smart phones, less devices hooked to the Internet, and people only accessing web apps and web app data with browsers.

Let me also put this in context of the article's original point, that PHP has a nice feature of being able to be embedded directly in HTML. Yes, this is nice. But my point is that if you are starting your web career and therefore are looking toward the future, the types of web sites that will use inline PHP will be more like content sites and less like web apps. And I expect a bigger demand, higher pay, and arguably more interesting work for web app creators than web content site creators.

This made me cry.

For some reason most of the major frameworks use it, hence their incompatibility with hiphop; then again I could be wrong.

> 1. cheap shared hosting to get started

One can argue that all of the major languages have access to this. PHP doesn't have an edge in this area.

> 2. most hosts offer one-click installation of any sort of application people need on the web (blogs, shopping carts, calendars, social networking, file hosting, etc)

With the rise of the cloud hosts and automated config, as well as more automated tools available (e.g. Chef, Puppet), this is a temporary advantage. Deploying on Linode and Heroku and (insert cloud host company) are getting easier and easier.

> 3. 15+ years of knowledge about what works and what doesn't when attempting to scale PHP to large needs.

No argument here. My points only apply for people starting now, and not for PHP vets.

> 4. ubiquity which keeps a large pool of reasonably priced talent available, which perpetuates the cycle.

No argument here either. My points were being made for individual programmers who are just starting out, and not for companies.

Even from the point of a company though, PHP's current lack of flexibility lowers the chance of innovation imo. The other dynamic languages are just as easy to learn and they just offer more than PHP does.