Richard MacManus wrote a post today in ReadWriteWeb which aims to wonder whether Google will ever use its Chrome browser to index password-protected corners of the Web.

During this RWW post he mentions Neil McAllister who wrote (yet another post) in July that describes how the Web has moved away from simple HTML-based “pages” onto Rich Internet Applications (RIA’s).

At the end of his post, Neil poses some very relevant questions:

if application developers feel limited by the constraints of standards-compliant browser technologies, should they really be targeting their applications for the browser? Or is the problem that the client platforms simply aren’t evolving fast enough to meet our needs?

I agree. Accessing Facebook (and many other RIA’s) via a browser can easily become a disastrous experience.

One option is having those applications completely migrate from the browser to a dedicated client, which is not necessarily HTTP-based.
Example 1: I could easily imagine a Facebook client that resembles a mashup between ICQ and Windows Live Mesh (just for example’s sake).
Example 2: P2P clients (KaZaA et al.) prove that we can tap into “the social web” without using HTTP. (albeit not a very sophisticated social web in this case)

The problem with such overall migration is (1) having “Web” users losing the ability to tag and link specific content in these external networks, as well as (2) having search engines unable to search and index them. In short, losing hypertextuality.

So… Another option could be partial migration: i.e Creating specialized clients within the browser environment, using plugins and extensions. Today we have — for example — Firefox extensions such as Digg and Google Gears that enhance our web experience, but we can just as easily access Digg.com or Google Docs (docs.google.com) without using these extensions.
However, why not make the use of these extensions a prerequisite if one wishes to use the RIA’s that heavily-rely on them??

Using the Facebook example again… I do believe that the vast majority of Facebook users would happily install a Facebook browser extension if they had no other way to access the Facebook network. This futuristic version of Facebook will be reliant on dedicated software that integrates with the browser.
But the main point is that — to a certain degree — it does integrate with the browser. This RIA-specific integration serves as a gateway between the (Facebook) extension/client and the rest of the “old” Web. (By saying RIA-specific, I suggest that each RIA should develop its own independent and unique method to integrate with the browser environment.)

In other words, it’s true that already today we have to install the Flash player plugin if we wish to “run” Facebook in our browsers. But, couldn’t such an RIA operate better and faster if its core(!) functionality was installed as executable files on our home computer? And thinking even more boldly, shouldn’t we (as high-maintenance web users) encourage such a heavy-weight RIA to feel free to use its own scripting language and/or its own internet protocols?? Imagine having a specific internet protocol developed by (and for) “Web 2.0″ social networks that greatly improves our end-user experience — perhaps something like Facebook://John Doe

As Neil points out, we’ve moved away from an HTML-based Web, and I believe we’re heading towards a Software-based Web. It would be more fragmented, dependent on multiple opt-in installations of “brand-specific applications”, yet still remaining hypertextual.

Obstacles? Plenty! Not all leading browsers currently support extensions in an easy and flexible manner. Also, depending on the form and size of the aforementioned gateways, there could still be many issues with linking and Search Engine indexing. In order to remain hypertextual, such developments should be highly SE-oriented and make use of the latest API’s.

To sum it up, the incorporation of the desktop into the browser is an ever-growing trend these days. It’s a welcome trend. And it could be a very intimidating trend for users and developers alike. Yet we shouldn’t be afraid to push the envelope even further.