I like to keep a close eye on advances in browser-as-rich-client technology, as I think it’s one of the most important areas in the continuing maturation and mass adoption of the Internet. I think there are still several hurdles to overcome before the browser can compete with the desktop in terms of rich client firepower, but the obstacles are falling almost on a daily basis.
Recent Advances
Some exciting developments have popped up recently, here are a few of the highlights:
- Comet: Comet is a technology that keeps an HTTP connection alive between the browser and the server so that messages can be streamed back and forth in realtime. This is very rarely used right now primarily because the technology is so young and there’s no easy way to implement it, making for a high barrier to entry. The stuff going on with the cometd framework is changing that, however, and I’m especially interested in what’s happening with gCometd, which is a Java implementation of comet. Once comet grows up and extends into areas like server-side event-handling it’s going to have as much of an effect on the rich browser application experience as AJAX had.
- Offline Access: One of the big weaknesses in rich Internet applications is the lack of offline access, but there’s a lot of work being done to fix that. In particular, the Dojo Javascript framework now has strong support for browser-side storage, and there’s work being done on top of that to enable entire applications to be run offline.
- Synchronous Server Calls: A big mental barrier to overcome when programming rich browser applications is the lack of support for synchronous calls to the server–asynchronous is really the only game in town. It’s not just: call function A, get result, call function B. It’s more like: call function A, wait for your callback function to be called, receive the result, and then call function B. Certainly not the easiest or most straightforward way to write an application. However, there are some interesting and creative solutions to this problem now thanks to projects like jwacs and Narrative Javascript.
- Threading: The one topic that’s sure to give any programmer heartburn is threading, but the fact is that there’s a lot you can’t do without the capability to write multi-threaded applications. To that end, there’s a lot being done to facilitate multi-threaded Javascript applications in one form or another, such as wrapping server-side Java calls and using interpreted languages on top of Javascript.
- Microformats and Live Clipboard: Even though Live Clipboard has completely fallen off the map recently (seriously, Ray Ozzie, where did you go?), I still believe that it’s a very useful and cool technology and I hope it takes off (moving structured data between sites is just too useful to let die). Microformats, however, are very much alive, and once they’re built into the browser itself I think there’s no doubt that they’re going to become as ubiquitous as RSS. They will be the standard way to publish structured data, and I love having a standard format for widely-used data such as contacts and events. Sites are already building in support, it’s just a matter of time.
Remaining Obstacles
It’s not all sunshine and lollipops, though. There are still several areas that need to be addressed ASAP, especially before these technologies can be adopted in the enterprise. A few of the problems I’ve noticed:
- Lack of Synchronous Server Calls: While the projects attempting to address this shortcoming are a start, the options I’ve looked at pretty much dictate that you write your application in a certain way or they won’t work. This may be something that needs to be addressed at the browser/Javascript level, but I hope somebody comes up with an elegant solution using existing technology.
- Lack of Encryption: Honestly, I really can’t believe there’s not more awareness of this. All it’s going to take is for one mischevious person with knowledge of HTTP sniffing and Javascript to start watching Internet traffic and gobbling up passwords and sensitive communication before this becomes a VERY hot button topic. The problem is, most rich client applications use little to no encryption–there is no good way to secure AJAX calls right now. If you’re lucky, your username and password are encrypted via SSL, but I’ve even seen that rule broken countless times to save a browser refresh. Did you know that all of your GMail and Google Docs and Spreadsheet traffic is flying around the Internet naked?
- Lack of Client-to-Client Communication: One of the big advantages of thick client apps is that each one can exist as its own node on the network and communicate directly with other nodes. Since browser applications are disconnected (well, until technologies like Comet become standardized, anyway), all communication to and from the browser has to flow through the server delivering the app. That means that one client cannot talk directly to another client, creating a chasm between nodes on the network. There are a lot of dominos that need to fall before this one can be addressed–for example it seems ideal to me that clients could talk directly to other clients’ servers instead of using their own server as a middle-man, but that requires a universal client lanuage first. The result of this, though, is that only clients which are connected to the same server have any means to communicate with each other, a pretty severe shortcoming.
- Lack of a Standardized Object Model: The browser DOM is really only an object model as it applies to the user interface. It’s like the Win32 API before libraries like MFC and OWL were built on top of it–just about everything has to be coded by hand. I believe the next big leap in rich client technology will come when a standardized schema and object model is developed as a launching point for new applications, I have to believe that Microformats will play a role in this as they’re the closest thing to a standardized schema that we have right now.
Hopefully the problems will be addressed and the advances will continue to advance, and we can do away with fat-client applications completely sometime in the next year or two. It’s definitely an area that bears watching, as it’s going to touch every site on the Internet as it continues to develop.
