Headless Foxes

Centralisation—or to give it a distinct name: corporate blogging silos—will continue to exist and continue to hold the keys to the kill switch for as long as our concepts of client-server design still revolve around big-iron sitting in a room doing its own thing with its serious-business technologies distinct from the client-side.

I learnt PHP because it is ready-to-roll on OS X and is readily available on cheap hosting packages everywhere. When I write in PHP the only way to go is centralisation, I am inevitably steered in that direction. The world makes Facebooks and Twitters because you program in one set of languages and technologies for the server, and another set for the client. I therefore cannot redistribute and decentralise the server-side parts without expecting the end user to understand how to configure and run a server—something very different and a whole order of magnitude more difficult than the client browsing a web site.

In order to make a decentralised web we need to move away from iron-specific technologies and toward client technologies on the server, so that the concept of a client and a server are a flexible, reversible and distributed concept.

This begins with JavaScript on the server. This has of course been possible since the late ’90s, and more recently in the form of Node.js. The benefits of JavaScript on the server are obvious, you can re-use chunks of code on both client and server and you only need to remember one language instead of two to program with. Despite the time-saving nature of this JavaScript on the server has never really taken off, even with all the Node.js hype. The problem is, even with all the Node.js hype, is that you are still coding an architecture specific to a server to serve a different architecture to the client. You are still programming on the principle that the server is a big hunk of iron in a server farm to directly feed the clients. You can distribute your server-side JavaScript because your clients don’t have Node, they have a browser and likewise Node can’t do what your client-side code does, such as hardware-accelerated WebGL, Canvas, Audio-processing and an increasing number of capabilities driven by user experience.

It’s Time for Server-Side Browsers

If we want to break away from an inherently centralised programming model and make developers lives easier we need to make the client and the server one and the same. Equal in capability and equal in developing tools and technologies.

A headless browser would be a web browser running without a GUI. All the features of the browser, such as DOM and WebGL and HTML Video, Audio and Canvas; more than just a JavaScript engine as currently is being done. This headless browser could then be run on a traditional server to take the role of PHP instead. Why would you want to run a browser on a server?

Imagine that you wanted to provide a fall back for clients that didn’t have WebGL in their browser—or their 3D hardware wasn’t powerful enough for the task (say it was a mobile phone, even). You could detect this and then run the same game code that would normally run on the client, on the server, and stream the result to the client as video!

If a server is just a browser instance and the client is a browser instance then this completely changes how a web developer can think about development and debugging. What if Firebug was a server itself? You made AJAX calls to it, and it ran the “server-side” JavaScript in your browser, the same as it would on a live server. No longer would you be tied to the infrastructure of your live environment.

Because you have the same HTML and JavaScript APIs available to you on the client and server, imagine writing your database code using the HTML local database APIs so that when running on the client it uses the client-side storage, but the same code running on the server could be mapping those standard APIs to a proper database server like MySQL or CouchDB. Just because you’re running a headless browser and using JavaScript doesn’t mean it can’t scale to big iron as well. Imagine what this means for working offline, or programming locally. When you could pull your live server’s contents into any supporting web browser and program offline locally before pushing back to the live environment when you next have a connection. No FTP, just HTTP_POST. When your whole development environment is any web browser on any computer, not a carefully customised LAMP installation.

When a server is any web browser, headless or not, then data can begin and end on either side with transparent portability between any number of clients and servers and scalability between a single browser, a centralised server farm, or a cloud of a million browsers—nowhere in particular. Your native apps could be servers, talking to each other via JSON. Talking to your web browser, who could in turn talk to your native apps.

When running a server is as simple as visiting a web site then communication becomes decentralised and we won’t need Twitter and Facebook any more, we will just choose what type of communication we want; private, public, time-shifted, live.

I strongly suggest to Mozilla or Opera to get working on this now, before Google or Apple do.