<!DOCTYPE html>
<!-- ========================================== kroc camen of camen design ============================================= -->
<title>writing · Headless Foxes</title>
<link rel="stylesheet" type="text/css" href="/design/design.css" />
<meta name="viewport" content="width=device-width, maximum-scale=1.0, user-scalable=no" />
<link rel="alternate" type="application/rss+xml" href="/writing/rss" title="Just writing" />
<link rel="canonical" href="/writing/headless_foxes" />
<!-- =================================================================================================================== -->
	<h1><a href="/" rel="index">
		Camen Design
		<li><a href="/">all</a></li>
		<li><a href="/projects">projects</a></li>
		<li><a href="http://forum.camendesign.com">forum</a></li>
		<li><a href="/quote/">quote</a></li>
		<li><a href="/writing/" rel="tag">writing</a></li>
		<li><a href="/blog/">blog</a></li>
		<li><a href="/photo/">photo</a></li>
		<li><a href="/code/">code</a></li>
		<li><a href="/art/">art</a></li>
		<li><a href="/link/">link</a></li>
		<li><a href="/poem/">poem</a></li>
		<li><a href="/audio/">audio</a></li>
		<li><a href="/web-dev/">web-dev</a></li>
		<li><a href="/annoyances/">annoyances</a></li>
		<li><a href="/eve/">eve</a></li>
		<li><a href="/code-is-art/">code-is-art</a></li>
		<li><a href="/inspiration/">inspiration</a></li>
		<li><a href="/windows/">windows</a></li>
		<li><a href="/gift/">gift</a></li>
		<li><a href="/gaming/">gaming</a></li>
		<li><a href="/mac/">mac</a></li>
		<li><a href="/osnews/">osnews</a></li>
		<li><a href="/c64/">c64</a></li>
		<li><a href="/linux/">linux</a></li>
	<a rel="previous" href="/writing/kroc_writes">
		older article →
	</a><a rel="next" href="/writing/mind_heist">
		← newer article
<!-- =================================================================================================================== -->
	<!-- date published or updated -->
	<time pubdate datetime="2011-02-19T18:10:00+00:00">
		<sup>6:10<abbr>pm</abbr> • 2011</sup>
		<abbr title="February">Feb</abbr> 19
	<!-- categories -->
		<li><a href="/writing/headless_foxes" rel="bookmark tag">writing</a></li>
		<li><a href="/web-dev/headless_foxes">web-dev</a></li>
	<!-- licence -->
		<a rel="license" href="http://creativecommons.org/licenses/by/3.0/deed.en_GB">c</a>
		share + remix
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<h1>Headless Foxes</h1>
	<strong>Centralisation—or to give it a distinct name:
	<a href="http://scripting.com/stories/2011/01/04/whatIMeanByTheOpenWeb.html" rel="external">corporate blogging
	silos</a></strong>—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
	This begins with JavaScript on the server. This has of course been possible since the late ’90s, and more recently
	in the form of <a href="http://en.wikipedia.org/wiki/Nodejs" rel="external">Node.js</a>. 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.

<h2>It’s Time for Server-Side Browsers</h2>
	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
	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 <strong>same game code</strong> 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
	<a href="http://en.wikipedia.org/wiki/LAMP_(software_bundle)" rel="external">LAMP</a> 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 <em>type</em> 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.
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
	<nav><a href="http://forum.camendesign.com">‹ Discuss this in the Forum ›</a></nav>
	<a href="mailto:kroc@camendesign.com">kroc@camendesign.com</a>
		<a href="/writing/headless_foxes.rem">Rem</a> •
		<a href="/writing/headless_foxes.html">HTML</a> •
		<a href="/design/">CSS</a> •
		<a href="/.system/">PHP</a> •
		<a href="/.htaccess">.htaccess</a>
	<form method="get" action="https://duckduckgo.com">
		<input type="hidden" name="sites" value="camendesign.com" />
		<input type="search" name="q" placeholder="search…" />
		<input type="submit" value="Go" />
<!-- =================================================================================================== code is art === -->