Web browsers as platforms

by Mike Levin SEO & Datamaster, 07/10/2005

Here’s another interesting dissenting voice of M. Keith Warren that wonders “Will Atlas slow the move to smart clients? […] What are we trying to do but merely mimic Windows.”

Keith ponders similar issues that I do. What is the web browser other than just another level of abstraction and a place to insert an alternative set of API’s to the underlying Windows OS that break the ties to Windows? It is inherently a threat to Microsoft, because apps can be developed that run anywhere with unlimited seats, and no one pays anyone any licenses. Java was a similar layer of abstraction. Sometimes it’s called a virtual machine (as in JVM), sometimes it’s called a common language runtime (.NET’s CLR), and sometimes just a web browser. No matter your semantics, the point is that it offers a slippery slope migration path off of Windows, and Microsoft can’t like that. So, it will be interesting to watch how Microsoft responds to the fact that the alternative browsers are reverse engineering the one little magic bullet in MSXML that makes the Ajax APIs possible: XmlHttpRequest.

There is a project codenamed Atlas that works with ASP.NET 2.0 intended to bring the rich Ajax experience to ASP.NET. Anyone who has followed my website over the past number of years knows that I made a desperate attempt to learn and love ASP.NET, but failed. In hindsight, what I wanted out of ASP.NET was what Ajax is bringing today. But if and when Microsoft creates a decent implementation, I’ll have to go through the VisualStudio.NET upgrade and 2-hour install again, a series of scavenger hunts, and learn to do triple-back-flips again, only just to risk being disappointed.

The ASP/VBScript system I’m using today can be made highly scalable by eliminating the use of result sets by using the OpenRico data grid. Get it? Result sets never really have to be cached! All you ever need is what you’re looking at on the screen at any given moment. Then the UI widgets can be made smarter with the OpenRico Ajax library and Prototype.js library. Then, the only missing piece is a decent way to maintain state. But with Ajax, page reloads are actually occurring less, and the JavaScript variables persist longer. Page-to-page state persistence challenges are alleviated. When a page reload does occur, you only need to pass enough info to build the next screen – usually just a record ID and mode parameter on the querystring. If you don’t like that, you can still use frames for persistent JavaScript variables. And finally, by adhering to the standard W3 DOM, cross-browser compatibility should be maintained.

The bottom line is that like Ajax itself, making the move to the next level of web development is more like a way of thinking than a move to any particular new framework. If well thought out, you are breaking your dependence on most underlying technologies, except the browser DOM, JavaScript and the need for the XmlHttpRequest method. And the apps you can create this way can rival Windows applications.