Could someone translate what this is actually trying to talk about into something clear? This blog post reminds me of someone on weed trying to relate to you this profound idea to you and rambles on stream of consciousness style. He wants there to be no 'centralization' (that is, servers) and have things run on a cloud of people's web browsers, yet at the same time it still talks to mysql somewhere? We won't need any one site to hold data and things just magically work by sending things out into the ether?
I'm left wondering wether the idea is server-side browsers or browser-side servers. Plus, what's the problem with having to deal with JS client-side and something else server-side? And as for this...<p>"I therefore cannot redistribute and decentralise the server-side parts without expecting the end user to understand how to configure and run a server"<p>You can. It's called a desktop app.
This is not a layer 7 problem, its a layer 1 problem. Get your ISP to provide unfiltered nearly-synchronous connectivity with pervasive ipv6 (no-nat) and <i>then</i> we can start getting rid of the client server model.
I built a proof of concept that sort of does this:<p><a href="https://github.com/shazow/relay.js" rel="nofollow">https://github.com/shazow/relay.js</a><p>Someone hosts a hub which just acts as a dumb message-passing relay between browsers via websockets. When a server connects, it sets a code payload. Then when a client connects to the same hub and requests the server, it receives the code payload and a streaming 2-way connection to the server.<p>There's a few live examples like a collaborative whiteboard in about ~40 lines of js.
PhantomJS is quite nice -- headless javascript which leverages webkit for rendering.<p><a href="http://code.google.com/p/phantomjs/" rel="nofollow">http://code.google.com/p/phantomjs/</a>
Making browsers servers as well makes much more sense. At least allowing communication that is peer to peer. This would dramatically reduce network costs for the application owner.<p>There is a Proposal for peer to peer browser communication. See:
<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#peer-to-peer-connections" rel="nofollow">http://www.whatwg.org/specs/web-apps/current-work/multipage/...</a>
An interesting tangent to this discussion is OTOY (<a href="http://www.otoy.com/" rel="nofollow">http://www.otoy.com/</a>), where your browser simply functions as a display and input device; all the heavy lifting of 3D rendering and game logic is processed server-side.
I believe this is what Aptana's Jaxer (<a href="http://jaxer.org/" rel="nofollow">http://jaxer.org/</a>) tried to do. It didn't exactly take the world by storm...but perhaps it was too early...
aka Browser as a Service -- This is something I tought about a few years ago. It's becoming a reality with Opera Mini & Skyfire. <a href="http://virteal.com/UltraLightBrowser" rel="nofollow">http://virteal.com/UltraLightBrowser</a>
Or we could stop treating the HTTP/browser combination as an application delivery platform.<p>It's unpopular here, but it's becoming exceptionally obvious as the correct choice.