It’s no surprise that HTML5 has not yet delivered on all its promises. WebGL has some major dependencies on HTML5 issues being resolved before we’ll see many awesome games, efficient 3D content creation apps, or secure 3D enterprise apps. For simplicity, I’ve dumped the issues into two buckets, technical and non-technical.
In the specific case of 3D interactive applications, there are several issues that currently prevent HTML5 to be used as a practical delivery platform. In particular 3D hardware acceleration (GPU) is still not available as a mainstream feature. While the specification for WebGL exists, unfortunately it has not yet been widely implemented on major mobile devices (i.e., no WebGL access on iOS) and on major web browsers (no WebGL in IE 6/7/8/9/10 where the market is still so fragmented it will take years for IE users to migrate up to 10, even if it did support WebGL!) Google and Mozilla (Chrome and Firefox) have been providing an ‘experimental-webgl’ canvas 3D implementation for a while now, but it still suffers from driver issues (see the blacklist/whitelist for WebGL capable drivers). More importantly, the WebGL 1.0 specification is providing a subset of OpenGL-ES 2.0 specification while native applications on desktop have far more capabilities through OpenGL 4.x or DirectX 11.
Pretty much everyone with any knowledge of HTML5 (in general) will tell you that the largest challenge HTML5, and hence WebGL, face is security. Beyond the many blog posts, many Khronos meetings and HTM5 related conferences, security remains the greatest obstacle to HTML5’s adoption, particularly for enterprise and business productivity applications. HTML5 has other obstacles to overcome before becoming mainstream, and those coming from 3D support not the least of them. None of the outstanding API issues such as those maintained by the Khronos Group public WebGL forum will matter much until HTML5 architects and experts finds solutions to more pressing concerns such as security, but also UX (including supporting push notifications), the ability to handle a C++ API (a la NaCL beyond Chrome) or even compute on the GPU (WebCL) for web applications. Another issue with HTML5 is that it is limited on access to device specific hardware. In particular access to file system is very limited due to security concerns, but also to other important device specific inputs – such as camera, microphone, GPS, or simply USD (devices). This alone is preventing HTML5 to be used to create web “apps,” limiting its use to only web pages.
When I look at the politics of WebGL adoption, browser providers such as Google (Chrome), Mozilla (Firefox) and Apple (Safari) all do a pretty good job supporting WebGL. However, Microsoft (IE) has yet to make a decision if they want to jump onto the WebGL bandwagon. Whether they do or not, only time will tell if they lose market share for IE because of it, but their security concerns, and the way they look out for their enterprise IE customers, is admirable, if indeed that is their only true concern.
Mobile is a different story.
Regarding the competition
Adobe and Unity stand out as proprietary platform competition for WebGL. Adobe is not as much of a sleeping giant as one might think and Flash has nicely advanced to accommodate hardware accelerated 3D via Stage 3D. The Stage 3D platform has also gained enough traction to have its own ecosystem of viable support applications such as Flare3D, Away3D, Alternativa and Minko, – all linked to from the Adobe Stage 3D website.
Unity continues to gain traction with significant software updates (Unity Pro 4.0 is now out, and includes advanced animation support via Mechanim) and a strong developer user base (1.5M developers and growing). It’s highly likely that for at least the foreseeable years, it’s proprietary platform will continue to be used by indies, non-game developers, casino gambling developers and other kinds of developers who care more about using Unity’s easy to use editor (and/or require a cross-platform solution) than an open web platform 3D engine.
Khronos made an intelligent decision to open up the WebGL working group to stimulate and encourage open discussion, and their public WebGL forum – where most key discussions take place, was the right move for enabling the most comprehensive WebGL spec development. The other issue however is conformance. While Khronos has done a pretty good job with conformance test creation and testing for OpenGL|ES and COLLADA, they did not initially a) make the tests freely available to be used informally by implementers and thus have their products improved upon because of such testing or b) market the test suites to developers who may not also be Khronos members. Frequently I see complaints about COLLADA being too complex and that COLLADA’s complexity hinders the “adoption of the standard,” but if they knew they could conform to Khronos’ COLLADA conformance suites, they would be more successful adopting, implementing and supporting the standard. Fortunately, that lesson has been learned for WebGL and Khronos is ahead of the eight ball on this one, providing an implementer’s portal on Khronos.org from pretty much the beginning.
HTML 5 is slowly but surely adding all kinds of technologies into the web browser and exposing it to web developers. Perhaps because of HTML5’s collaborative and open nature, as well as the complexity to create and deliver something that does not introduce security issues, it may take years before WebGL exists in a stable deployment environment. Also, Microsoft (IE) who still has a large part of the web browser market still has not decided if they will support WebGL in their browser, of if they will stay on the plug-in path with a proprietary solution, competing with Flash, et. al.
However, HTML5 is leveraging the web architecture, which provides technologies and lets the ecosystem decide how applications will be architectured between the client and the server. This is the strength of the web, the ability for the client(s) to collaborate with the server(s) and split where the data should be stored and processed for a given application, enabling content to always be up to date, and sometimes created on demand by the server. Because the server is visible to many clients, it also enables user interaction, made popular by social applications such as Facebook, twitter, etc.
How to get involved
If you want to learn more about how to get involved making WebGL successful, check out the Khronos web site for all goings-on with WebGL.