Why previous attempts failed
No wonder that people keep asking this, WebGL is very new, and previous attempts like VRML or Director 3D have failed horribly. The reasons why those previous technologies failed are simple:
- They sucked. No, really. Have you ever tried programming something using Director (Lingo anyone?) or VRML? No'? Be glad. Their interface wasn't nice, and they were too high level.
- It just wasn't the right time. People just recently have started being used to play games with tons of megabytes of data directly on websites. And now, they want 3D. Also, today everyone has built-in, relatively fast 3D hardware.
- Programming stuff in 3D is complex. So locking people into your own, non-open, limited technology like these probably wasn't the best idea.
Why WebGL is better
WebGL isn't based on a plugin. It runs directly in the browser, and is a public standard, managed by the Khronos group. It's low level, meaning it is complicated to use for newbies, but you can do basically anything with it. For experienced programmers, it hasn't even to be learned, it's just like OpenGL ES. For these reasons, it is accepted by programmers. And although the release of it's stable 1.0 specificiation was just a few months ago, it already is available in Google Chrome, Firefox, Safari and soon in Opera. It even already runs on several mobile devices, including the iPhone. And even Microsoft's InternetExplorer isn't the show stopper anymore: using the ActiveX plugin IEWebGL, you can run your WebGL code also there. Most average users probably won't even notice they just installed that plugin, I've tried it out with CopperLicht. :)
So it's no surprise that you see programmers forums get filled more and more with WebGL questions and demos. Also the downloads of my CopperLicht library are getting more and more. More and more companies seem to be interested in my WebGL editor CopperCube. And even Adobe seems to plan for the near death of Flash, although they recently released a (surprisingly nice) 3D API for their flash player: They are working on HTML5 tools now, and already killed off Flash for mobile devices.
So all in all: WebGL appears to stay. It's a great technology and will be used. Just as with all new technology, it just needs a bit of time to get people used to it.
seven comments, already:
Do you think Native Client would be a better technology if the other browsers adopted it, just like they did with WebGL?
George - 18 12 11 - 08:35
I don’t think so, Native Client is just like Java or Active X: a box running in your browser, feeling like foreign body.
niko - 18 12 11 - 09:21
i however think NaCl will be the next big thing. performance does not suck there and at least chrome provides means to run single executable on all platforms. and its not like java or activex. java requires plugin, activex requires IE. NaCl on the other hand is meant to be built into the browser directly, so no plugin would be needed. So what that executable is so called “foreign body”. If its implemented across browsers and it works – users will never care about detail of game being contained in nexe file instead of js file. Since google is pushing NaCl i think they just might convince other browsers to implement it, ofc if NaCl gets good enough. Today its still in early stage, but i definitely can see its potential.
rndbit - 18 12 11 - 10:30
Being tied to JS is WebGL’s fatal flaw – sure it will probably replace Flash, but anything serious will still need better performance. The question is whether JS will change fast enough or whether it’ll be overtaken by NaCl. Personally, I hope for the latter, because there’s just so much more you can do with it without re-inventing all the wheels (in a slower technology).
Steve () (link) - 18 12 11 - 13:51
This article would more aptly be named “Should WebGL be the future?”. It makes good arguments towards the benefits of using WebGL – unfortunately they hardly matter that much.
There are reasons why WebGL will not be the “go-to” 3D solution for the web in the foreseeable future:
– Microsoft will not support it. Now whatever their real reasons might be, they state security as being their biggest concern – and rightly so. Delegating a whole bunch of security responsibilities to the graphics driver (of all things) will be a problem. (which is not to say that other solutions do not suffer from that problem too)
– Flash provides basically the same features and is supported on pretty much all browsers. Let’s face it: Most web users have flash running right now with Stage3D capabilities and they are a much larger market. WebGL provides no real benefit over Stage3D for the majority of developers either. The idea that Adobe is burying flash is a misunderstanding: They are burying the mobile flash plugin, which has simply always sucked and they can not get it right, performance wise or conceptually. But the mobile platforms don’t need browser plugins or even HTML5 (which arguably runs as bad or worse on mobile when reproducing flash-like content) for good user experience: They have apps. Flash to App publishing is still part of Adobe’s strategy.
Compared to installed base and market size, issues like performance or “open standards” are not very important. I would like for WebGL to be the future – I would still bet my money on Flash. It’s really not the developers who decide this, it is the market.
Krustovsky () - 20 12 11 - 00:15
Internet Explorer is not the issue here, that’s why there is IEWebGL. And Flash: Well, this doesn’t work on mobile devices. The market of the future. WebGL is better there.
pelham1 - 20 12 11 - 05:40
If you require another plugin for the leading browser, you’re really back to square one. As I’ve already said, Flash may not work as a mobile plugin, but Flash can publish to Apps and will likely support Stage3D there too. If you want a compelling experience on mobile, you will want an app. No matter what you do, you will have to change the mobile version anyway, as the input methods on mobile are fundamentally different. As for WebGL being better on mobile: Right now it doesn’t even exist and there’s no telling when it will arrive (who knows if and when Apple will even support it) and how well it can really perform. In any case it will very likely not be better than Flash apps, so if all you want is share a codebase, Flash might still be the better option. If you don’t care about sharing the codebase, do a native app.
Krustovsky - 20 12 11 - 22:28