It's Time for Server-Side Browsers
camendesign.com
camendesign.com
That will eventually lead to decentralised applications, but in the mean time will simply lay the groundwork for it whilst people continue with the centralised model.
There will always be a need for centralised systems, the world is just not going to simply change their entire toolset and paradigm overnight. We must make centralised apps use pretty much the same technologies as decentralised ones first, then coax developers over.
There is no reason (and you provide no argument) that using the same code on the client/server results in decentralization. Furthermore, we have the fact that it already exists and still did not lead to decentralization.
You'd get drafted into storing images for some subset of the intersection of your social graph and several others, and the rest of your images would be served by someone(s) with whom your social graph intersects.
Presumably invitations would be via e-mail, or, if you wanted to be even more decentralized, QR code.
As far as data volume, I've got to imagine the data usage per user would be significantly less than BitTorrent.
The desirable aspect of this system is obvious - the only people who see your data are people who've seen a QR code from someone in your social graph - your FaceTorrent profile will never, ever be indexed by Google.
What if Google started offering, say, free Google Coupons (assuming they roll their own groupon) in exchange for befriending them on FaceTorrent? Not all of my friends and relatives value privacy as much as I do.
"I therefore cannot redistribute and decentralise the server-side parts without expecting the end user to understand how to configure and run a server"
You can. It's called a desktop app.
Quote: "Envjs is a simulated browser environment written in javascript"
https://github.com/shazow/relay.js
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.
There's a few live examples like a collaborative whiteboard in about ~40 lines of js.
There is a Proposal for peer to peer browser communication. See: http://www.whatwg.org/specs/web-apps/current-work/multipage/...
He's talking about it working at the same level as a browser where it sees if you have HTML5, and if not falls back to flash, dynamically.
I can't imagine it being a high priority - fiddly, low return, creates huge performance issues. Lots of basic problems - you don't want someone supplying input to a game over a (latent) network. You don't want to be running instances of performance-intensive games on your webserver.
Still - the proposed idea is distinct from VNC or X.
It's unpopular here, but it's becoming exceptionally obvious as the correct choice.
In 1993, I was the only person I knew with a web browser. 18 years later, we have applied hack after hack to make it into an "application platform." And it's still the same old thing.. a way to deliver hypertext pages to people.
If you want to allow people to sync their files, share large popular binaries or listen to the perfect mix of music, you don't do it over HTTP. Not because you don't understand HTTP, but because you do.
HTTP is also extensible (by design), which has lead to stuff like WebDAV and the like. Stuff that is used large scale, over the web. So the web is not 'just' HTTP.
There's deliberate trade-offs in the web's architecture which means, unfortunately, you can keep coming up with edge-case applications which are challenging (although often not impossible) to implement using web technology. The reality is that a large majority of applications are information-centric, are distributed in nature, need to evolve over extended periods of time, and therefore benefit _greatly_ from the trade-offs that the web has made.
The web's not perfect but it's evolving and - importantly - it doesn't have the benefit of being completely fictitious and living inside the mind of a jilted, chippy geek. No offense. ;)
What is the alternative application delivery platform?
Where is it becoming exceptionally obvious?
Tks in advance.
Currently, the alternative application delivery platform is the App Store, the runaway success of which is neatly proving the point that the web just isn't up to the job of serving applications in the way we've been trying to hack it to become.
That's also where it's becoming exceptionally obvious, as people struggle mightily (even Apple themselves) to create web apps that have a look and feel anywhere close to those of native apps. And users feel the difference, sense the request/response bubbling underneath and the JS churning on top, and reject them.
For whoever downmoded me RTFM: http://paulgraham.com/road.html. If there is a new road ahead write a new road ahead essay close to that form so I can understand. I won't stand for empty vanguardism.
But, briefly, many of the points in Road can still be right with the conclusion being wrong. Yes, data is more important than computer, and server-side computation and storage of data etc is increasingly important.
But the web as the client interface? Network-aware native apps are trumping all over it. These aren't the desktop apps PG speaks of, they're not shipped in boxes and they're not static. They're downloaded instantly, updated easily, network enabled and fully responsive.
Convenience over all is the thing for users, and apps are just more convenient. They don't load themselves from network every time (Gmail, Twitter), they don't have UI elements that fill in slowly as their graphics load over the network (Posterous and a million others), they don't transform without warning (Facebook) and they don't pretend that a way of sharing research papers can support an interactive session without you noticing.
As for the size of the Market, I've already spent way more on desktop and mobile software than I've ever spent on Saas/site subscriptions and I don't see that changing. Where there's a native app I'll almost always prefer it.
Why? Because native apps are better software; a better experience. And when they're supported by (synced/cached) server-side data (and ideally a fall back to a web client if I find myself at some random terminal somewhere) I get the best of both worlds.