End of the Desktop? Google Backs WebGL

Stick a fork in the desktop, it's done! Recently Google demoed a port of Quake II to WebGL and HTML5, showing that even first person shooters are suitable applications to run in the browser. While the tide isn't going to turn all at once, it seems more likely than ever that a browser-based desktop is a viable option and ultimately the way many users will experience all applications.

When Google announced Chrome OS, I was skeptical that a Web-only interface would be suitable for the mainstream market. Sure, some folks could get by with a browser-based netbook, but what about real applications and games. As HTML5 continues to mature, and Google Chrome improves by leaps and bounds, it looks more and more like Web apps really will give the “fat” desktop a run for its money. Most convincing? Google’s announcement that it’s ported Quake to run in the browser sans plugin. At the same time, Google has given me good reason to remain skeptical with its change in direction with Google Gears.

Google is apparently picking up the Web Graphics Library (WebGL) ball and running with it. What’s WebGL? In a nutshell, WebGL is a port of OpenGL ES 2.0 for Web browsers to allow JavaScript apps to make use of 3D in the HTML5 canvas element. Chrome isn’t the first project to embrace WebGL. Mozilla, Apple, and Opera are all working on WebGL implementations in their development releases — though it’s not yet in any of the shipping browsers.

Real Games in the Browser

Google has demonstrated this with a port of Quake II to HTML5 and WebGL. Unfortunately, the company hasn’t provided a hosted version to test it out, but the video seems convincing enough.

Games have been available in the browser for a while. You can play Quake III, the best game ever created by the way, using a cross-platform browser plugin. But the plugin required porting to each major platform and (as usual) Linux lagged behind. It’s hard to see that providing a suitable solution for many applications, since companies are unlikely to want to invest in a separate browser plugin.

But native 3D support in the form of OpenGL/WebGL that requires nothing more than a mainstream browser is a lot more compelling. Launch the application and anyone can run it. We’re not there yet — but within the next year or so the mainstream browsers (sans Internet Explorer, of course) should support WebGL with no problem.

Attack on Windows

Even with WebGL, Windows users are still out in the cold. That’s right Windows users are out in the cold. Because current releases of Microsoft Windows don’t include OpenGL drivers. To rectify that, Google is working on Almost Native Graphics Layer Engine (ANGLE). It’s a BSD-licensed translation layer to allow WebGL API to work on top of DirectX 9.0.

An interesting, you’ll forgive the pun, angle on WebGL is that it threatens to subvert Microsoft’s influence on 3D application programming. Microsoft doesn’t ship with native OpenGL drivers because the company has pushed its own Direct3D APIs over OpenGL. Mac OS X and Linux users have OpenGL, but developers doing game programming or other 3D programming need to target Direct3D on Windows or find a way to supply the OpenGL drivers. By releasing its ANGLE work under the BSD license, it enables Apple, Opera, Firefox, and others to ship the same drivers to enable WebGL on Windows.

If you look at all the love Google is giving developers — APIs to work with Google Apps, WebGL/ANGLE, and plenty of other goodies, it’s clear that Google is reaching way beyond standard Web development and trying to reach desktop developers and ISVs to put apps in the browser where Google rules the roost. No, Google doesn’t have the browser market share locked down yet, but it’s hard to argue that any company has a stronger position on the Web.

With 3D support that’s robust enough for first person shooters on the way, it looks like there’s not going to be a great deal of daylight between Web apps and desktop applications. You might need native applications for particularly resource-intensive work, but within the next year or two it seems likely programmers could match Web applications with desktop apps feature for feature.

Doubts and Deterrents

So, Web applications are ready to replace the desktop? Yes and no. The technologies are evolving rapidly. Within the next few years we should have the components for browser-based apps to supplant most desktop applications. But that’s in ideal conditions, and assumes that users are prepared to take a leap of faith with their providers.

And that leap of faith isn’t justified just yet. While I was researching this piece and looking into the implications of WebGL, Google put out the news that it was dropping support for Google Gears as of May 3rd. What’s wrong with that? Some of the Google Docs customers were using Gears to enable offline mode for Google Docs. When support for that drops, so does support for offline mode.

At some point, Google plans to re-enable offline support via HTML5, which is lovely when it happens — but they’ve provided no interim solution. Whether Google wants to admit it or not, occasionally users go offline but still need to get work done. Worse, this demonstrates a fundamental flaw in Web-based applications that the vast majority of desktop applications do not have: rapid shifts in features and functionality entirely beyond the user’s control.

Sure, Microsoft may throw radical changes at users in new versions of Microsoft Office — but users have the option of not upgrading, at least in the short term. Your Web application can (and apparently will) drop features at the whim of the vendor and there’s very little customers can do about it. This is a scary, scary proposition for users and organizations that are considering adopting Web applications on a massive scale.

It turns out that a compelling advantage of Web applications, seamless rollout of new features, can also be a major liability. What Google giveth, it can taketh away. This is true of all Web app vendors, of course. The lack of official releases seems pretty nifty when it means new goodies show up overnight with no intervention on your part, but when they go away it’s another story entirely.

In short, this isn’t a problem of software, it’s cultural. Web applications historically have not been tagged with version numbers, unless you’re talking about a perpetual “beta” logo. You wouldn’t ask someone “what version of Highrise are you using?” That may need to change before Web applications are entirely viable. As these apps increase in complexity and features, the training costs associated also increase. Companies are not likely to be friendly to rapid interface changes and feature creep when they’ve trained 1,000 customer service reps to use the software.

Progress Rolls On

This isn’t an insurmountable problem. Vendors can implement terms of service that guarantee not only uptime, but also feature availability for specific periods of time. They could communicate with users and tag their products with release numbers and release notes, just like traditional software offerings. It’s hard to imagine that the Web app vendors don’t have these internally, they just need to push them out externally and offer a little more clarity and reliability to users.

Despite my misgivings, Web applications are already mainstays for many users and within the next few years it’s hard to imagine that many standard desktop applications will be available only as “fat” desktop applications. Are you ready for the switch?

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62