AnyHosting

Mobile Gmail will soon be using nex-gen (HTML5) browser standards to make network reliability not matter:

Very early screenshots of Google Chrome running on Mac. Via pinkerton’s blog:

All the buzz about “cloud computing” is great, but isn’t it just a rehash of “dumb terminal”, “thin client” computing, that lost out big against the PC? Yes it is, but not for long; the browser does not need to be the modern equivalent of the terminal, chained to the call/response of HTTP requests in order to provide applications.

I wrote about this a while back, but I think it bears repeating.. HTML 5 includes support for “offline” applications, including client-side storage, which means that that in current and upcoming versions of Firefox, Safari, and Opera will support running web applications locally on the user’s computer, without needing to be in constant communication with the server.

Instead of asking your users to install your application in the traditional sense, visiting the website that hosts your application will cause the client to download and store everything needed to operate on the client side. The application can detect whether or not the computer is online, and attempt to connect to needed real-time, syncing, and other web services as needed, and only interrupt the user if absolutely necessary.

This means that the questionable reliability of having all of your applications hosted “in the cloud” is greatly mitigated, and impact on the end user is quite minimal. Even if your entire site is down, there’s no reason for that to interrupt the user of your snazzy application; in fact, with cross-site AJAX support, the user can continue to fetch and transmit data with other websites (I’m thinking a real-time price comparison site, or something like that, which today would be implemented completely server-side and just fall over in this scenario), so it may be totally acceptable for your site to receive the queued up responses from clients when it comes back up, depending on what your application does of course.

For IE support, you could use something like Google Gears or Adobe Flash’s offline capabilities, until Microsoft catches up to the rest of the world. This is the biggest pain point of the brave new offline world right now, however it’s a very real concern as Microsoft IE still has around 70% of the global web browser market share.. If this is something you need, check out Dojo’s storage classes as a high-level library to abstract away these details for you; if you’re doing a serious AJAX site nowadays you really should be using or at least intimiately familiar with the great toolkits like Dojo, Mochikit, JQuery, etc. There’s no need for handling each browser/version case by hand nowadays, unless you have a really good reason.

There have been decades-long arguments over which is better, the thin client or fat client approach the network computing. Many maintain that the Web is just another turn of the wheel back to the bad old days of computer terminals which are useless without a connection to the Big Computer in the Back; what good is a web browser without Google to search, or Flickr to see your photos?

Some of the real wins you get with a browser is that you can make it share the workload, through rendering and client-side scripting; the upcoming Firefox 3 supporting offline mode for applications, and the Google Gears plugin that does this right now for IE and Firefox are also great steps in the right direction.

The big misunderstanding here about both client-side scripting and offline mode are that it’s not about being on the plane and wanting to browse your photo collection (that’s just a side-effect), it’s about:

• seamlessness – if what the user is doing does not require the network, they shouldn’t be interrupted if their local network, the remote server, or anywhere in between is having problems
• responsiveness – local storage is generally faster than network; it’s also necessary to be local for interactivity and any kind of scripted animation (think gaming).
• privacy – some data you don’t want going across the network, period.

This is why I don’t really understand questions like “does offline mode still matter“  (or more harshly-worded criticisms of the idea) when you take the above into account. It’s about taking the best of the thin client world and the fat client world, and making applications that are always there for the person using them, and always responsive and fast, regardless of connection/network/server status.

The next big push has got to be blurring the line between web application and installed application, as well as the difference between online and offline. Using online office apps or webmail nowadays gives you an equivalent experience to running application, so what’s with the browser controls?

I’d like to be able to take my web applications out of the browser and manage them locally, and I’m not alone. Making apps more desktop-like seems to be the right way to get there.

Mike Shaver makes some excellent points in his blog post “the high cost of some free tools“, addressing the new crop of “Rich Internet Application” or RIA platforms: Microsoft’s Silverlight, Adobe’s Apollo (and Flash), Sun’s JavaFX etc. versus the “open web” where the platform  is not under the control of a single vendor, but a set of specifications and drafts to define the protocols, recommendations from different groups to define the data formats, and a ton of other RFCs.

We’ve got multiple implementations of the server (Apache, IIS) as well as the client (Firefox, IE, Safari). “The web” ends up (in theory) being the lowest common denominator that you can support with the total combination, although in practice people only care about the top 2 or so implementations.

The so-called RIA platforms like Silverlight et. al. generally try to do an end-run around the client, and typically (if Flash and Java applets are any predictor) use the web protocols like HTTP, but eschew the client-side data formats like HTML, Javascript and so forth, the goal being to capture the client and be the only choice.

Part of the strategy of these “RIA” platforms is surely to lock web hosts, content providers, web developers and users to a particular technology stack, and tools are a big part of keeping the producer side happy, and the point I most resonate with from Mike’s post is that human-readable code and the decentralized nature of the web makes  it possible for “mash-ups”, user-side scrips and styles and so forth (not to mention the humble link) make it possible to put things together in ways the original designer could not have envisioned, that is more useful for the end-user.

However, a point I haven’t seen addressed is this – a large amount of revenue on the web right now is advertising-generated. Arguably many users do not want ads, especially pop-ups or flashing images, or other annoyances. However, with such an open system there’s nothing stopping clients from effectively stripping most ads from content, or showing the user the Javascript code behind your nifty new AJAX application. Pop-up blocking is already a feature in all major  browsers, and more complete ad-blocking software for each is just a Google search away.

That’s one thing these RIAs can offer that an open web cannot; they can embed DRM to make sure that your code cannot be viewed and that ads must be viewed. I am sure that some content providers will surely welcome this. This could also be done in a web browser, and I am frankly surprised that this angle hasn’t been tried yet.

But if you restrict the client this much, is it still the web? I agree with Mike’s assertion that distributed evolution and incrementalism is what made the web great, what made it win. Acting as a true collaborative medium, not passive like radio and television, but really interactive and respectful of the user’s choices is what makes the web great today.

(EDIT – fixed IE link)