Browser Bubble

Since the original mosaic browser, the ubiquity, power and importance of the browser has trended in one direction, upward. Many feel this is merely a sign of things to come, but to me, I see it as a bubble ready to burst. There is no denying the role and importance of the browser, and I see no reason to expect it to shrivel up and die, but today, and for the immediate future, the browser as a platform has been leveraged not just beyond its original design, but beyond reasonable limitations.

Like most trends, the browser started by fulfilling a role that was genuinely lacking. The browser provided an easy to use portal into vast amounts of data waiting to be poured onto Web Servers worldwide. Some of browsers competitors (AOL, Prodigy, CompuServe) applied more control to the content in an attempt to create a consistent user experience, and provide greater interactivity. But the browser trumped all of that by allowing a simple brain dump of data. Much of the initial data on the internet was simply text, with sparse hyperlink additions. Interactivity was put on hold in the interests of developing quantity, and the web flourished.

Retailers, like always, flocked to where the customers were and began to establish online stores. The browser adapted well to the online store concept, because much like the initial round of web development, retailers had large quantities of mostly unstructured product information. This data had a great deal of graphics and formatted text, and there were the order processing systems to worry about. But in the large, there was very little interactivity in a web store. Click on stuff you want, enter credit card, poof. In most cases, the back end systems remained unchanged, and the browser handled only the customer view.

Providing a secure method of transferring information in the browser provided some hurdles, and still haunts some users today. Despite a few speed bumps, the browser eventually provided a connection to retailers that many users came to trust, at least a little.

For many users, this little bit of trust, developed into application phobia. To a degree, this is understandable, since an unknown application is certainly more dangerous than an unknown website, and until recently, applications provided few means to validate their authenticity. Today, however, platforms like Java and .NET can provide better guarantees of safety than the conglomeration of technologies that compose a complex web application. Unfortunately, neither platform yet provides great mechanisms for communicating these guarantees to potential application users. More importantly, even though there are some communication mechanisms, the average user does not yet understand them in the same way they understand their browsers.

That’s a big stumbling block for these platforms, but with time it can be resolved. More importantly, for many types of applications, such as those that users use every day, it just isn’t necessary. Only new applications scare users, not old ones. These types of applications also tend to be those where browsers perform the worst. Interactivity in your day to day life is simply a must.

AJAX is touted as the solution to interactivity on the browser platform. While AJAX is a great way to extend the browser platform, it’s not the panacea that it’s made out to be. It starts at a disadvantage by being built on top of the HTML/CSS layer that was never intended or designed to handle complex graphics, animations and all of the other elements that AJAX is being used for. As a result, speed, both of development and of execution, suffers.

Developers must learn a great deal of obscure details about several complete technologies, many of which overlap. Not only do they overlap, but the overlapping pieces are not cohesive in any sense. HTML, CSS, Javascript, Flash, etc. all require different tools. In the rare cases of tools that support one or more of these technologies, they are still treated as separate components or strategies.

All of this harms development speed for non-trivial applications. Trivial applications can benefit from the separated tools because if only one is needed, there is simply less to learn. But as you move into more complexity, the number of tools grows quite fast. Rather than simply learning existing tools in more depth, the web application developer will find they need to piece together a variety of tools.

As processor speeds continue to grow, speed of execution does continue to decline in importance, but most complex applications will still have a few key areas where performance is still a concern. Certainly today, the browser platform is incapable of achieving the same level of performance in these areas as a smart client, but it’s also likely that it will always be this way. A browser must be built on top of a client platform, which at the very least means it’s performance capability cannot exceed the performance capability of the underlying system. Performance capability doesn’t define actual performance, but a browser application is not just hampered by being built on top of one platform, but the need run on top of two layers of platforms, each with multiple implementations.

The first layer is of course the operating system. The browser platform can’t be specific to any operating system, which limits performance optimizations tremendously. The second layer is the browser itself, which is can be limiting not just in terms of performance, but functionality itself. I suppose it’s not entirely true that you can’t be specific to one browser, one platform, but if you are, you’re still limited by the way the browser chooses to hook together with the operating system. You should also begin to question what you’re really gaining from keeping the rest of your application browser based code. Are you really still writing a browser application at this point? Haven’t you lost one of the primary advantages of trust? And the secondary advantage of cross platform accessibility?

If these two concerns weren’t important in the end, why did you write a browser based application at all? Even if they were important, the browser isn’t the only way to get these capabilities.

I hate to stop a post at a point like this. I don’t feel like I’ve really proved anything yet, more just raised a lot of questions. But the question of these two platforms is a very complex one, and so unless I want to write the world’s longest blog post ever I’m going to have to break this up over time. For right now, I’m wondering how many others think the same way. Maybe I’m looking to stir up some controversy too, although I usually avoid that. Guess we’ll see.

Update: Part 2