Centralisation—or to give it a distinct name:
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
in the form of Node.js. The benefits of
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
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
A headless browser would be a web browser running without a GUI. All the features of the browser, such as DOM and
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,
you be tied to the infrastructure of your live environment.
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
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
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.