Web apps are browser-based, not browser independent
Web apps aren't a free pass on IT management. Issues such as plug-ins, security settings and browser version requirements mean that managing Web apps can be a lot of work.
IT administrators may think that Web-based applications free them of management responsibilities, but that's not the case. The problem is that Web apps are browser-based, not browser agnostic.
Web apps: Promises and problems
The promise of Web applications is great. Along with shifting processing loads from local resources to Web servers, there are no fat apps to maintain on users' desktops, no virtual applications to package and no management requirements, right? Wrong. All the features and capabilities that make today's browsers so powerful and complex also cause some problems for IT.
Plug-ins and helper applications first became popular with Netscape Navigator in the 1990s. Modern browsers are dependent on plug-ins such as QuickTime, Java applets, Adobe Shockwave player, Microsoft Silverlight and many others. Without them, the rich Web experience we know today wouldn't exist.
In addition to plug-in requirements, specific browser requirements cause issues. In 2001, Microsoft introduced Internet Explorer 6 (IE6) with Windows XP. Microsoft made a strong push for IE6 because it allowed Web apps to read and write to the local system, giving them capabilities and feature sets approaching those of local fat apps.
This also made IE6 unsecure, leading many to declare it the worst browser ever. Unfortunately, while most of the world moved past IE6, many enterprises standardized around IE6 and had to continue supporting apps for a heavily patched, out-of-date browser.
Issues such as plug-ins, security settings and version requirements mean that managing browsers can be a lot of work. With large enterprise line-of-business applications, the problem compounds. In fact, when Brian Madden and I visited Oracle in November, we learned that one of their biggest VDI use cases is browser compatibility.
Oracle has made a general push towards Web-based applications over the last decade, but with so many acquisitions and huge projects, browser requirements for their products are so complex that in their demo environments at trade shows they simply push out a VDI-based desktop containing browsers with the appropriate requirements.
Web app management
A Web app that is truly browser independent would solve all of these problems. There would be no need for any plug-ins or special settings. But accommodating every single browser might be unrealistic. Just think of how difficult developing a Web app would be if you wanted to include text-based browsers such as Lynx. There's no way to cast the net that wide.
To accommodate a wide variety of browsers or loosen plug-in and security setting requirements, you would have to surrender Web app features and capabilities. It is up to administrators to decide where they want to draw the line between feature-rich Web apps and easy browser compatibility.
Everybody has personal preferences, but it is still reasonable to require users to utilize one or two particular browsers. The users, who might not understand how plug-ins work, do understand that they can only use certain browsers for particular corporate Web apps. If an administrator wants to deploy heavier Web apps that have very specific requirements, they have to accept the management responsibility.
At the end of the day, Web-based applications aren't a free pass on management. Instead, IT administrators must pick their battles wisely, weighing the trade-offs between browser compatibility and features.
ABOUT THE AUTHOR:
Jack Madden is a blogger at BrianMadden.com covering all things desktop virtualization-related, including storage, management, hypervisors hardware, consumerization, cloud computing and a myriad of other topics. Jack is also the guy that gets sent out to talk to lots of vendors and try out all of their products.
He has been involved behind the scenes at BriForum events since 2008 and was the Media Editor for BrianMadden.com before it became a part of TechTarget.Follow him on Twitter @JackMadden.