JavaScript or PHP – Why It Sometimes Matters

It's all about whose computing power gets used – yours the application provider or yours the end user. If you're the user, you probably don't care since you are waiting for your browser to show you something in either case and you already paid for your computer. If you're the application developer, you may care a lot because you have to pay for server processing cycles one way or the other but you don't have to pay for user machine cycles.

If you are not involved in providing web applications in any way, you may want to bail out of the rest of this post at the end of this paragraph. Before you go an interesting factoid is that PHP stands for "PHP: Hypertext Preprocessor" – the acronym is recursive. Of course, if you're not a nerd you may not think this is interesting so I'll give you one more factoid. You may have noticed that many web addresses end with ".php". These are web pages that are created on the fly on servers using PHP. Pages which are more static OR are made dynamic on the user machine often end with ".htm" or ".html". Now you know.

OK; only us nerds are left now. You all know that a page which is pure HTML is pretty static; appropriate for lots of things but pretty static. But you also know that you can add some JavaScript and have the page become interactive; even better, you can use AJAX (Asynchronous JavaScript and XML) and load all kinds of data into an existing page to create an interesting and dynamic application. This data doesn't even have to be XML.

Pretty much anything you can do with JavaScript on a user's computer you can also do with PHP on your own server. The two languages are similar so the complexity's about the same either way. One huge exception is that you can't do anything with PHP that requires lightening fast interaction like reacting to a mouse-over, a click, or a key-press instantaneously. All PHP interactions gotta go from the user's computer to the host and back and that takes noticeable time.

One thing that you can do in PHP on your server that you can't do in JavaScript is load data or XML from domains other than the one the current page or iFrame was served from. That can be a significant limitation. You also can't keep your code secret if it's JavaScript; it's there in source form on every user's computer. You may want to keep it secret either because it's where your value comes from OR because it would be a security risk to you or the user to expose the code.

Many APIs like the Facebook API or the Amazon S3 API assume that you have a server at your disposal. I did manage to use S3 and maintain necessary security with only a client application and no server but had to jump through hoops to do it (see Amazon S3 – Backstory for Nerds - Part 1 and Amazon S3 – Backstory for Nerds – Part 2). 

In many ways it's easier to test and debug using PHP than JavaScript. The problem with JavaScript is that different browsers treat it differently. You sometimes have to ask in the code what browser you're supporting. You have to do extensive cross-browser testing. I spent (wasted) most of today on a problem caused by the fact that Firefox fills in the "Content-Type" header in an HTTPRequest and IE doesn't. The PHP you run on your server is going to execute the same way no matter what browser the user has – of course, the resultant HTML may not image the same way but that's a problem no matter how you do you development.

You can mix JavaScript and PHP so you can use each to get around the limitations of the other.

That gets us back to whose CPU cycles do you want to burn. If you're planning to have a blockbuster virally-spreading world-changing application (which, of course, you aren't going to charge for) then you don't want to have to buy a huge server farm. You can outsource to Amazon EC2 or perhaps use the Google apps server; but millions of users are still gonna be expensive to support. That'll often be a good reason to use JavaScript and the user's cycles rather than PHP and cycles you pay for. The user isn't hurt by this because she's already waiting for her machine to do something and just wants it done fast – it may, in fact, happen faster with local JavaScript execution than if an interaction with the server is required.

The P2P services, including Skype and BitTorrent and Napster, all rely on user resources – both bandwidth and computing power. My guess is that many web services running in browsers will be successful because scalability is instant and "free" when each user's machine provide the resources to handle most of the incremental load that user represents and when the bandwidth for communication between application and server is used sparingly. That's a big reason for doing as much in JavaScript as you can.