It is time to take the WWW behind the shed and put it out of its misery.

Almost everything that makes up the WWW is a hack. HTML, HTTP, SMTP, are all antiquated technologies. These old technologies were engineered with the sole intention of delivering and sharing text documents. Early web browsers and e-mail clients shared this same basic vision in the beginning. Even today, most media requires plug-ins and other technologies in order to be shared over the web. Where is the problem? It lies in the expectation in the end-users of the Internet. Over the last several years, the major players on the Internet are not delivering documents, but services and applications, which infer an expectation of user experience.

The expectation of a controlled user experience is not a reasonable expectation of the Internet. The Internet by definition does not have any of the building blocks for a true user interface. Cookies are a terrible way to manage state, and HTTP+HTML has no traditional support for static or persistent elements. To go further, the standing trend over the last several years has been to deliver web-based applications. The complexity of these applications has been growing over the years to include two-way communication, streaming data, persistent state, and all of the other elements that traditional computer applications contain. All trying to be consistent across dozens of different browser/OS combinations with different connection rates and privacy and security restrictions.

HTML Limitations

• Inconsistent across different platforms
• Not intended to be used as a UI framework
• Poor state control
• No built-in multimedia control

HTTP Limitations

• 2 connection limit per DNS host name
• Does not support Keep-Alive

The worst part of this combination is that the services that rely upon these technologies to deliver their service have little or no control upon how the two interact, because their service is a slave to whichever web browser the client uses to access them.

Standing Hacks

• Frames
• DHTML and DOM
  
• Plug-ins and ActiveX objects
• Java Applets
• XMLHttpRequest object

Java Swing

Java's Swing framework was probably the first reasonable attempt of a resolution. Its failures and shortcomings were few. Java is too heavy of a language for a UI framework. It isn't powerful enough to be fast and efficient. Java Runtime Environment has too much access to the client's machine, and not enough security for most people. On top of this, Swing's anti-aliasing and 2D drawing is less than attractive.

XULRunner

From those wonderful guys at Mozilla, XULRunner utilizes XML and JavaScript and runs within the Gecko Runtime Environment. It is still young, but shows great promise.

Adobe AIR

Adobe's Integrated Runtime, which was previously named Apollo, shows great promise. Not only does it utilize Flash and Flex, but also JavaScript and HTML. There are quite a few Open Source Flash initiatives such as MSASC and SwfMill for compiling ActionScript and XML into SWF files. Also, ActionScript has matured nicely over the years. If Adobe open-sourced an ActionScript compiler, this may just be the winning platform for the best way to build and distribute your applications.

While HTTP and HTML will most likely remain the foundation blocks of the Internet, I have great faith that many of the services out there with web-delivered applications will be looking towards other technologies such as AIR or XULRunner in order to better control the user experience and deliver richer applications.

Update:
This blog post criticizes web browsers failure to utilize multi-threading in multi-core systems. It is a valuable point and felt it worth adding here. http://pinderkent.blogsavy.com/archives/147

AIR: Adobe Integrated Runtime

AIR: Adobe Integrated Runtime

Some products have already pownced on this still-beta framework. And, I think with good reason. AIR can utilize any mix of HTML / JavaScript / Ajax / Flash / Flex development resources in order to deliver cross-OS desktop applications.

AIR has similarities to XULRunner. AIR is a runtime, like Java J2RE that needs to be installed onto the client's machine. The difference here is that while Mozilla and Sun may be household names to any geek with a computer, they still don't have quite the same name recognition that Adobe has with "normal" users due to their products (Flash and Acrobat). So the potential adoption curve of AIR is far greater.

AIR is beautiful. Flash content means superior anti-aliasing, and makes it far easier to animate your application. Even the installer is pretty.

If AIR gets even a quarter of the traction that Flash or Adobe gets, AIR is going to be very attractive, very fast. At that point, I see a lot of incentive for fat-client web applications to port their application if for no other reason than to eliminate the many, many pains of cross-browser support.