Web applications that count on the advantage of not having a bloated desktop footprint need to keep one eye on the scale…

A recent article on CloudAve that brought back the “browser versus native app” debate caught my eye last week. After reading it, the author is really focusing on that piece of the debate which dismisses SaaS and browser-based applications in general based on the disparity in functionality between them and their “bloated desktop” cousins.

Why do I have to spend money on powerful devices when I can get an experience almost similar to what I get from native apps? More importantly, the rate of innovation on browser based apps is much higher than what we see in the traditional desktop software.

[…]

Yes, today's SaaS applications still can't do everything a desktop application can do for us. But there is a higher rate of innovation on the SaaS side and it is just a matter of time before they catch up with desktop applications on the user experience angle.

When You Can Innovate With browser, Why Do You Need Native Apps?, Krishnan Subramanian 

I don’t disagree with this assessment and Krishnan’s article is a good one – a reminder that when you move from one paradigm to another it takes time to “catch up”. This is true with cloud computing in general. We’re only at the early stages of maturity, after all, so comparing the “infrastructure services” available from today’s cloud computing implementations with well-established datacenters is a bit unfair.

But while I don’t disagree with Krishnan, his discussion reminded me that there’s another piece of this debate that needs to be examined – especially in light of the impact on the entire application delivery infrastructure as browser (and browser-based applications) capabilities to reproduce a desktop experience mature. At what point do we stop looking at browser-based applications as “thin” clients and start viewing them for what they must certainly become to support the kind of user-experience we want from cloud and web applications: bloated desktop applications.

The core fallacy here is that SaaS (or any other “cloud” or web application) is not a desktop application. It is. Make no mistake. The technology that makes that interface interactive and integrated is almost all enabled on the desktop, via the use of a whole lot of client-side scripting. Just because it’s loaded and executing from within a browser doesn’t mean it isn’t executing on the desktop. It is. It’s using your desktop’s compute resources and your desktop’s network connection and it’s a whole lot more bloated than anything Tim Berners-Lee could have envisioned back in the early days of HTML and the “World Wide Web.” In fact, I’d argue that with the move to Web 2.0 and a heavy reliance on client-side scripting to implement what is presentation-layer logic that the term “web application” became a misnomer. Previously, when the interface and functionality relied solely on HTML and was assembled completely on the web-side of the equation, these were correctly called “web” applications. Today? Today they’re very nearly a perfected client-server, three-tiered architectural implementation. Presentation layer on the client, application and data on the server. That the network is the Internet instead of the LAN changes nothing; it simply introduces additional challenges into the delivery chain.

But Lori! Desktop applications require installation! They require maintenance, and support! They are more costly! They are evil! An ancient horror that we have worked hard to eradicate from the face of laptops and desktops everywhere!

Let’s get a grip on reality, shall we?

As more and more of that presentation layer logic moves into the client – the browser, the desktop – those same issues are going to arise. Perhaps not on the same scale, but they will arise. When you start relying on libraries – frameworks like Prototype and XAJAX and the like – to provide the underlying framework through which all that interactivity and cool functionality is achieved, you are basically installing software. It’s just as hidden from the end-user as much of the desktop software, at least in an enterprise setting. It still requires maintenance and support and oh how problematic is the support! When an AJAX call goes “bad” it’s not uncommon at all for a web application to fail to provide the means by which the end-user is notified or that updating can be “restarted”. At some point that’s going to generate a support call to someone, and troubleshooting a browser-based application has got to be the most miserable experience on the face of the earth. You don’t have – can’t have – an exact duplicate of the user’s environment because, well, you may not have the same plug-ins installed, or the same version of the plug-ins. You may not be accessing the application over the same network with the same underlying infrastructure that may or may not be causing issues. You may not even be running on the same operating system – or device. But you’re still going to have to troubleshoot it and figure out what’s causing the problem somehow.

Good luck with that.

I’m not saying the evolution of the browser into the modern-day desktop – and that is what is happening – is a bad thing. But I am pointing out that at some point the same issues that once made us look upon browser-based applications as a godsend will crop up and cause the same kind of headaches for IT and end-users and in some cases those headaches will be migraines that never existed when IT had control over the environment.

The days of SaaS and “web applications” claiming an almost moral superiority over “bloated desktop applications” are over. They went the way of “Web 1.0” – lost to memory and saved only in the “wayback machine” to be called forth and viewed with awe and disbelief by digital millennials that any one ever used applications so simple.

Today’s “web” applications are anything but simple, and the environment within which they execute is anything but thin.