Way back when I first dove into web programming, PHP was the obvious choice for my needs. It was available on virtually all web servers, had excellent documentation, and could handle everything I needed to do (and much, much more). These things are even more true today, and PHP is still my middleware of choice. However, I have noticed that the way I use PHP has changed in recent years.
Back in the day — by which I mean up until about 3 years ago — I built sites entirely with PHP. During a typical page request, PHP would do stuff like start a session, query a database, process some data, and finally, generate a metric ton of HTML that would be returned to the user’s browser. In other words, all of the user interface was generated server-side by PHP. Occasionally I’d include prototype.js or jQuery to do a bit of form validation or a typeahead drop-down list, but I generally avoided JavaScript. Mine was a very “round-trippy” approach that eschewed the Ajax techniques that were becoming popular at the time, in favor of a drop-dead dependable experience in virtually all browsers.
Then came the iPhone.
In 2007, the iPhone kicked off a tidal wave of interest in mobile computing. Like thousands of developers, I was starstruck by this magical little device that put the Web in my pocket. Always connected, first-class browser, intuitive touch interaction — it’s truly amazing, and I wanted to jump in with both feet.
When the iPhone was first announced, Saint Steve told 3rd party developers to build web apps if they wanted to program for iPhone. I was ecstatic about this, because:
- I was a web developer, not a Mac developer.
- I figured that this would lead to rapid innovation in the browser, e.g., JavaScript API hooks into all the cool device features that the iPhone offered.
Of course, Jobs ended up reversing his position less than a year later with the announcement of Cocoa Touch and the iTunes App store, and the holy war between mobile “web apps” and “native apps” was born. Cocoa Touch is an amazing framework, but as a web developer, I’m quite disinterested in developing for a particular platform. So, rather than diving into Xcode and iOS, I dedicated myself to finding ways to craft a web app experience on mobile devices that rivaled the native app experience and was cross-platform.
Okay, so what does this have to do with PHP?
Here’s the thing. My round-trip approach to PHP-based web development became untenable. It’s just too expensive to resend the entire UI to a mobile client with every request. And when I say expensive, I mean it both figuratively and literally — certainly there is an annoying performance lag associated with a full round trip to the server, but a potentially bigger issue is that you’re unnecessarily eating away at the user’s monthly bandwidth allotment. I needed to take the Ajax plunge, and in a big way.
Fast forward to today. Much to my delight, we now have a convergence of new technology that makes building web apps — mobile and otherwise — much easier. jQTouch, Sencha Touch, and more recently, jQuery Mobile take a lot of the pain out of writing cross-browser JavaScript for mobile browsers. CSS3 gives us transforms, transitions, and animations that allow us to easily add sophisticated visual effects. And, most drastically, HTML5 defines an slew of powerful new features — geolocation, canvas, sockets, workers, client-side data storage, offline application cache, cross-origin resource sharing, and so on, and so on, and so on.
As a result, I find myself building my UI (and the lion’s share of my business logic) with static HTML, CSS, and JavaScript documents that talk to a server-side API built with PHP. This API-based approach can greatly minimize the amount of data sent across the wire, because I can cache the static files locally and just request relatively small data updates from PHP (usually in the form of JSON). This also has several secondary advantages. Here are three biggies:
- Division of labor
- Once you’ve set up a server-side API, you can easily have your app designer work on the front end without knowing the slightest bit about PHP, templating languages, or any other server-side technology. Hell, you don’t even have to give the designer access to the server — they can just code against the API with files sitting on their desktop.
- Multiple clients
- The computing landscape is undergoing massive growth and transformation. We are seeing screens as small as a credit card and as large as a billboard. There’s also a big split emerging between devices that support touch input, mouse input, and to a lesser extent voice input.
- Differences in physical size, interaction modes, and device capabilities demand that we provide user experiences optimized for the terminal in question. Exposing a server-side API built with PHP makes it feasible to support multiple front-end clients, whether they are thin clients built with HTML, CSS, and JavaScript, or fat clients built with proprietary native frameworks.
- The benefits of this approach have been demonstrated by Google, Yahoo, and maybe most dramatically by Twitter, who documented and released a simple API to the developer community at large. Thanks to this, Twitter clients of all shapes and sizes have found their way into every corner of our digital lives. Starting with an API allows this sort of seemingly-infinite flexibility, and I’m sure it contributed greatly to Twitter’s adoption.
- Future-proofing
- The computing landscape is evolving so rapidly that it’s very difficult to predict what’s coming next. Lots of smart people are working on radical new technologies that will alter the way we interact with computers, and more importantly, each other. Everything from holographic projections of live sporting events to brainwaves as user input are on the table. In my opinion, the best way to stay flexible in the face of surprising new developments is to provide a robust API to handle as much of the backend heavy lifting as possible.
Start with your API
These days, I start virtually every project by defining the API. I’m particularly fond of the RESTful approach, but in practice I usually just roll my own, because it’s so easy to do with PHP. There’s probably a great REST library out there for PHP, but I haven’t had the need to look for it yet.
For front-end web work, you’re going to want to get familiar with the new awesomeness that is HTML5 and CSS3, and most importantly, learn JavaScript! It’s a very similar syntax to PHP and should feel fairly familiar. (There’s even a PHP Advent article about it.) However, there are some very important differences between PHP and JavaScript that you really need to internalize before you can call yourself an expert. For a road map of the land mines, I highly recommend JavaScript: The Good Parts, by Douglas Crockford. If you program for the Web, it’s a must read.
To wrap up, I’d just like to say that there’s never been a better time to be a web developer. The convergence of ubiquitous connectivity, cloud services, and interactive touch screens are creating an environment where virtually anyone can build compelling user experiences that have a massive reach with very little barrier to entry. So, get back to your text editor and start coding; break time’s over!
