Everybody hates browser applications

We're moving to Visual Studio 2010 at my company, as we're a .NET shop, and Visual Studio generally makes big improvements with each new version. Visual Studio 2010 is particularly pleasing, with a new easy-to-access extensions "store" built into the tool, much improved graphical layout, built-in support for .NET 4.0 (new VS versions tend to track major releases in .NET), and generally, a bunch of technical candy for the programmer brain.

More esoteric was my joy that Microsoft rebuilt the entire Visual Studio user interface in WPF and .NET. As I've noted in previous blogs, it's less surprising that the developer tools division chose to embrace their own technology (which is a bit like the Pope embracing Catholicism).  It would make a bigger splash if something mission critical from a revenue standpoint - like, say, Office - made the switch, which is unlikely if they can't even convince themselves to use WPF for something like Paint in Windows 7. But, it's gratifying that the .NET dogfood is being eaten by at least one major Microsoft product (that's a coding metaphor for using your own technology, much as Microsoft did with COM way back when), and a Visual Studio written in WPF certainly will help the move towards what, on occasion, is touted as the foundation of their future platform efforts. .NET certainly makes a better baseline to span all the hardware architectures that they intend (hope) to encompass within a common development platform.

I actually installed the RTM about a month ago, which is late by the standards of other MSDN subscribers. Apparently, huge numbers have been using the beta release of Visual Studio 2010 (though the informal "poll" I read might have been a bit skewed by the fact that it constituted attendees at a Microsoft conference). Personally, I only tend jump into a new version when it is released and officially supported. As that has now happened, I'm writing more than basic applications with it, which is why I've belatedly encountered in a serious way the "improved" Help system.

For the benefit of those who have no idea what I'm talking about, Microsoft has rolled out a brand new help system with Visual Studio 2010 that is completely web browser-based. You can download the packages that drive this system, which are then run via a local HTTP process and served up to the browser of your choice (I use Firefox, and that is what gets launched when I go to help). Perhaps the goal was to achieve consistency with the MSDN online library, though if that was the case, they have a ways to go as the online version appears considerably different than the local version.

There are some fairly critical pieces missing. Gone are things like the tree view on the left pane as well as the ability to synch to that tree view from the index, something which has been a mainstay of the Visual Studio help system since I started using Visual Studio back in 1996.  Of course, synching the left tree pane likely sank in importance given that the index itself is completely absent in this version (simply wasn't ready for prime time is what the help system blog explained). To be fair, plans are afoot to release a VS Help version with a proper index in the near future, which is possible because the Help system is now managed by a team separate from Visual Studio. The help system, in other words, can be updated on a parallel track to the Visual Studio release schedule.

The missing features are clearly important, but assuming that those features were available out of the VS 2010 gate, I would still be displeased. I reject the notion that moving the help system to HTML, CSS and Javascript - however packaged on disk - is an "improvement."

This isn't the first time I've felt this way. My earliest recollection of a similar situation is from 1997, and involved the move between major Cold Fusion point releases. Back then, our Nortel division was one of the few licensees of a small company named Allaire (so named after the last names of its founders), and the Allaire brothers even flew out to ask our team a bunch of questions about how to improve their product (as well as feedback on improvements to a product named Home Site, and early web development tool the company had recently purchased).

Moving to a web based version makes some sense for a company that specialized in a framework for server-side web applications (as Allaire did), but I remember finding the web replacement clunky by comparison, even going so far as to write my own MFC-based application to replace it (I was learning C++ at the time, so there were practical reasons to do so). Perhaps I would have been happier had the web interface been more feature-rich, but in 1997, that was rather hard to achieve.

I felt similarly about the management interfaces used for Microsoft IPTV back when I worked in the division. Again, if the application had a bunch of snazzy AJAX extras, I might have felt differently (more on that later), but it didn't. I suggested that we use WPF to write the interface (the technology had been released about a year prior), but the people with the power to make such decisions had no interest in that.

I guess, though, my biggest problem with the conversion to a web-based help system is that it makes little sense from a Microsoft strategic standpoint. Why would MICROSOFT, of all companies, think it important to make a WEB-based mangement ANYTHING, and not, say, a Silverlight version. For IPTV there was some excuse, as the development of the original web management systems preceded the existence of Silverlight (or the official version of WPF, for that matter). The help system for Visual Studio 2010, however - a system designed EXCLUSIVELY to build applications for Microsoft-based platforms - has no such excuse. If Microsoft wanted consistency between the online MSDN library and the offline version, a Silverlight front-end would have made a heck of a lot of sense (the online version, like the offline version, is targeted at development for Microsoft platforms). They could still use HTTP to interact with the "back-end" (however local). Granted, that won't fix the absence of things like a properly indexed help system, but those are technical details that are easy to rectify. My biggest problem is a user interface whose "simplicity" gets in the way of usability (glad I didn't remove the VS 2008 help system).

Don't be confused about what I'm saying. I am NOT declaring that it is a bad thing for Microsoft to aim for a truly standards-compliant browser (which is a not unexpected response when I advocate Microsoft-specific technology over a web standard). Though I was once grumpy about the growth of Firefox, that grumpiness was a manifestation of dread at the prospect of revisiting the browser incompatibilities which made web development hell in the latter-90s (I first started writing HTML for Netscape 2.0). Today, I'm fully of the opinion that if you are going to make a web browser, then it darn well better adhere to the baselines web standards. That bar has now (or rather, will soon) be moved to HTML 5.0, and every browser vendor should work to implement it in a consistent fashion.

However, that doesn't mean that I want Microsoft to become Google and focus primarily on web interfaces. For a product aimed at WINDOWS developers, I see no reason why it shouldn't use WINDOWS technology.

Use Silverlight for the help system, and while you're at it, use the same front-end for the MSDN Library front-end.

I suppose those who bothered reading this far are wondering why I titled the post "Everybody hates browser applications." The point is related to the previous few paragraphs, though more as a back story.

To elucidate, think about the most sexy and interesting web application you have ever used. Odds are it used a high-level Javascript framework like jQuery, had lots of moving and gliding parts, updated sections on the fly, and made heavy use of AJAX-style interactions with the backend.

That, my friend, is a web application doing its darnedest to look like a desktop application. Though the UI certainly looks nice, if you were to peek behind the digital curtain, you'd see that the developer had to do the programming equivalent of banging a block of steel into the shape of a corvette to make it happen. There is elegance and beauty in the way HTML and CSS work, but also a lot of confusion and the suprising ability to make your interface look like a Rorschach test with the careless modification of a few CSS attributes. When you want to write applications that maintain state, you end up fighting the realities of stateless HTTP. Cookies and long-lived Javascript connections to the server are workarounds designed to force web applications to do things that are second nature to desktop applications.

That's why I said everybody hates web applications. The best web applications often look a lot like desktop applications (Google Search is a clear exception, but would you be happy with something similarly low-tech in Google Maps?). The real advantage of the browser as portal to the Internet is the safety of a constrained and interpreted environment combined with UI conventions that cross platform boundaries. That is why the web application will never go away. Users, however, are still going to pine for applications that provide the interactivity, flexibility (and offline capability) of a true standalone desktop application...even if they run in a browser and, through a bunch of markup and scripting gymnastics, force the browser environment to do things it was never really designed to do.