Definitely not. The performance is pathetic, the feature set is pretty basic.
WebGL is where compiled 3d apps/games were, like, 20 years ago. Yes, I know it will improve, but so will compiled products. The sheer fact that WebGL is interpreted and is a poor-man's subset of OpenGL, puts it at permanent disadvantage.
Of course, you could have some trick allowing for compiled graphics code to be run within the browser, analogous to the Chrome Native Client, and with all the DirectX/OpenGL features. But that's no longer WebGL, that's just a smart trick to run old-school code within the confines of a browser environment. You might just as well write a stand-alone app.
20 years ago? That was the time of Wolfenstein 3D. :)
Much more thant that is possible with WebGL... Take a look at some of those demos available. (example: http://www.ambiera.com/copperlicht/demos.html) You can always workaround that performance problem. No need to program some CPU cylcle swallowing AI for now.
Well, maybe 20 years was too far of a shot. But I assume you're associated with the Irrlicht game engine, so I assume that when you write "is WebGL the future?", you don't mean "will it be useful at all?" or "will some silly casual games be possible in WebGL?", but whether it will be a legitimate gaming platform, capable of competing with desktop gaming (which is where Irrlicht competence lays, afaik).
And to that I say firmly: no.
I like the demos you've linked to (and I've seen them before), no doubt they're quite impressive, considering the constraints of the browser environment.
But when I put them in context of what one could run on a computer natively, these demos remind me of Quake I. Sorry.
And BTW, I really hate to put you down like this. I have dreams of my own of one day writing an MMO game, that would mostly be handled by a server and the client would run in a browser. Perhaps the clue is not BF3-level graphics, but something "decent" on the graphical side and a really cool world and mechanics within the game.
I'm just a little frustrated at how inefficient all this web stuff still is. Imagine even your own demos - rather simple graphics by native standards - but with much larger world and many more characters. It would grind to a halt even on a mid-range PC, not to mention an iPad or a cheap laptop.
Still, I really wish that you create a plug-and-play graphics engine for web game developers, that would allow people like me to fulfill their fantasies. :) Wish you all the best!
WebGL is interpreted? What do you mean? Modern JavaScript runtimes are DEFINITELY not interpreted, and the idea of an interpreted graphics API or GPU is nonsense.
I'm not going to get into a semantic argument, perhaps to you Java is not interpreted either, but to me anything that doesn't compile to a binary directly executable on the CPU is substandard in terms of performance. And I'm sorry to surprise you, but in 3d graphics we're still starved for processor cycles, otherwise we'd have ray-traced, globally illuminated games with huge environments to play with.
It's JIT compiled and WebGL shaders are compiled as well. It is a native code executable on CPU, read how Crankshaft in V8 works.
It's true that JS is at the moment N times slower than C++ (N in range 1 to 10). It's not true that you need to use JS that much to have great graphics. Everything you pointed out is done on GPU afaik.
And if you wait a year or so, JIT + type inference will make JS basically as fast as C++.
Well, I'm not that familiar with the internals of JS engines, perhaps some browsers are capable of partial compilation. On the other hand, this is a dynamic language (as in: data types and other pieces of code can change in run-time), with limited features, like data structures (wanna benchmark linked lists or kd-trees in C++ vs JS? I doubt N=10 is skeptic enough). I'm not sure if I write path-finding or collision detection or line-triangle intersection with their respective data structures in JS, it will turn out anywhere in the ballpark of real compiled code. (And this is pretty elementary stuff in 3d games.)
Now we are getting somewhere ;) Graphics are not an issue, physics may be. Still, you would be surprised how fast compiled JS can be. It requires some discipline but if your code is good, performance is not that bad. And some data structures are actually waaay easier and smaller in JS (e.g. graphs). These are pros and cons of high level language.
By the way, there are also typed arrays which are translated directly to native code and were designed with WebGL in mind. I'd say that garbage collector is now the biggest issue of JS games. But it's improving, don't be skeptic.
EDIT:
Actually, I did a small lecture a week ago, about performance tips. It's probably far from perfect as I don't work on browser engines, but it may give you some hints about making JS performance C++-like.
http://www.smashinglabs.pl/lectures/js-performance/
I'd say that's an absolute minimum in terms of sophistication. And yet, some of it barely runs on a modest hardware setting. (Core2duo 2.5GHz, GF 8600GT.) [EDIT: Well, OK, in Chrome it runs OK, but still, these are tiny windows. Full-screen wouldn't be so nice.]
Now, imagine that you want to write an MMORPG. You make it just a little prettier than those demos, but more importantly - expand the world and add many more characters. It would bring _any_ gaming rig to a halt. (And yes, I realize that you don't display the whole world at once. But still, you need much more than there is on these demos.)
I dzięki za linka, fajne rzeczy na SmashingLabs i AiGameDev. :]
These demos run perfectly well on my Intel card. There are also interactive music videos like http://www.ro.me/ or http://lights.elliegoulding.com/ which are running fast enough. OpenGL ES is almost the same as OpenGL, the only feature I've found missing so far was geometry shader.
What in my opinion stops graphics from being better is model size that has to be transferred. You wouldn't wait 2 hours for game to load, would you?
WebGL is not a poor-man's subset of OpenGL, its the same subset that is supported by most mobile devices (OpenGL ES2.0). What are you missing? Quads? 3D textures? NURBS?
And yes, we know that JS is interpreted and that it's no use for building anything more than a clock on your webpage, right?
Could you write (graphically) Battlefield 3 in WebGL, assuming you'd be able to compile it to run efficiently?
As for your second question, JS is very useful, I love JS, I write 90% of my code in JS. But we're talking sophisticated 3d apps here, not whether it's useful at all.
JS is not very pleasant to code with, so writing an actual game logic could be a bit painful, but so is development for PS3 and it's done somehow. It's not a question of performance, rather about workflow and structures provided by language.
JS has gotchas and some really bad parts, but if you know the language well and know what you're doing, I think it's quite pleasant actually for many problems. Have you done much programming with JS, and if so, what was so unpleasant about it?
Though, I think I've heard pretty much all the complaints against JavaScript, many of which are addressed by using something like CoffeeScript.
I'm using Google Closure to get rid of the bad parts, but still it's not very good. I did some testing with game AI, graphics and so on - JS is far from perfect for such things. Maybe it's a lack of tools, maybe of some features I was used to in C++ or maybe it's that all the books and tutorials are targeted for C++.
It doesn't really matter, browser games are the future and no matter how complicated it's going to be, somebody will be good enough to write them. We already passed "demo era" and some games are really good, like https://chrome.google.com/webstore/detail/bhoaojooagiaaiidln...
>> WebGL is not a poor-man's subset of OpenGL, its the same subset that is supported by most mobile devices (OpenGL ES2.0).
WebGL is just that, a poor-man's subset of OpenGL. As is OpenGL ES 2, which is a standard that's deprecating very fast as mobile GPU's pack more and more kick-ass.
OpenGL ES standardization efforts are badly left behind the development, as graphics vendors are adding more and more extensions to GLES in their implementations. These extensions tend to be a little stripped down versions of desktop GL features and the worst thing is that they're not quite compatible with desktop GL or even similar extensions form other vendors. Next version of GLES (codename "Halti") has to be standardized pretty fast or it will be out of date by the time it comes out.
If you want to write high quality 3d games or graphics using GLES2, you will have to use vendor specific extensions and write code specifically for the devices you intend to ship on. If you're doing something very basic, you may get away with using only the features in GLES2, but you'll still have to consider how to match the performance to the wide array of GLES2 conformant devices out there. It also helps if you're a part of a major graphics vendor's developer partnership program, like it or not.
WebGL's standardization cycle probably even slower. It took a while for the spec to reach maturity and major browsers implementing it. AFAIK, there's no extension mechanism to gain access to not-yet-standardized features. When the next version of OpenGL ES comes out, how long will it take for it's new features to come available to WebGL? Is the WebGL API even designed for extendability? Who are the industry players willing to contribute their engineering efforts to building WebGL specs and implementations?
>> WebGL is where compiled 3d apps/games were, like, 20 years ago.
20 years is a bit of exaggeration. Doom 1 was released 20 years ago.
Feature-wise WebGL/GLES2 matches a desktop GPU circa 2004 or so. Doom 3-ish feature set. Performance wise it's a bit behind, but this varies so much from device to device that it makes no sense to take this into a discussion when we're talking about API standards and their features.
I agree with OP. The fact that a native app is 10X or more "better" is simply dwarfed by the low friction of full immersive 3D casual games right in the browser.
The question is not "how many polygons can you render?" but rather, "how many polygons do you need to render to provide the desired experience?"
So it's a threshold question, not a contest where the winner is determined by benchmarks.
Why should there be less friction to go to a web page rather than install a game?
I think a more honest comparison (in theory) would be to compare a site used to serve music with spotify. For those that use spotify a link that opens up spotify is probably vastly superior to anything a site can do, that's not to say that the site itself doesn't have any value. But the act of playing music is something spotify better at - and that mainly is just because (if you use spotify) you have your music collection in one place. That's where you go to play music.
Playing a game locally doesn't have to be more than pressing an hyperlink. Steam is probably the, currently, best place for this but, I know, relying on something such as spotify, steam or flash sucks. But there is nothing to say that we can't have an open android/iOS-market-like place for doing this. Apple and Microsoft will push their own markets and I'm surprised that the notion of a third party market hasn't come any longer than steam. I guess people are just too greedy.
There really shouldn't be any reason for why running it in the browser should be any better than running it locally. Have sandboxing as an option (or requirement), similar to what apple does, and go nuts.
I miss the days when running low-level code in an all-purpose browser was something that was considered moronic.
I think installing a game feels like a commitment. If all I need to do is open up the browser and the game will start playing I can just check it out without making that commitment, it will get me to try it if I'm undecided, if I don't like it I can just close the window and be done with it.
You mention Spotify, I think Pandora is a great example of overcoming that feeling of commitment. If I go to the Pandora website I can listen to music right away by just typing in an artist. If I go to spotify I need to download some client and who knows how hard it will be to get rid of. If I complete the downloading step then I need to sign up for the service (I know they changed it to facebook login recently so I don't know if it's the same) just to start listening. I don't even know if I will like the service at this point because I haven't even got to try it yet. I think I would describe this as friction.
I tried to address that in my post.
Installing a browser is just as much a commitment right?
Installing spotify is a commitment, but if you already have spotify playing a song in spotify isn't a commitment even though that means that spotify will have to look it up and download it for you.
Yes, you already have a browser installed. But soon you will most likely have a "market" installed as well (in a few years you probably have to actively avoid it if you don't want it bundled with your OS). The market just have to make a distinction of apps that are "light" and doesn't bloat the system. It could even remove it automatically after x days of not being used. Similarly to how spotify would cache a song you downloaded. Or a browser does... (hello html5 and local storage)
Compare with smartphones where they did this distinction by calling applications for apps instead.
Why should there be less friction to go to a web page rather than install a game?
Perhaps there shouldn't be as much friction to install a game as going to a web page, but you can't deny that installing a game is currently not nearly as streamlined and easy as clicking a link. Even though it could be, or even should be. The main issue is that you have to wait to install the full game. A WebGL game would instead just download the minimum required to play the first level, and get you started playing the game ASAP.
The other thing though about a game being tied to a link is that it becomes a part of the web. Others will link directly to the actual game, rather than a page that lets you download/install the game natively. This ease of sharing is what makes it really powerful to have an in-browser game. The web is simply the ultimate form of distribution. It also seems less invasive compared to installing - you are not making any changes to your computer. Just close the web page, and it's gone (ignoring cookies/cached files). Whereas a native game will create all sorts of shortcuts and basically embed itself into your system. This is more of a perception problem with "installing" in the eyes of the average consumer.
I agree. But currently WebGL doesn't exist (in practice) either.
And nothing you said has anything to do with WebGL. See android market where you can install apps from a web page. See Origin, launch games from the browser. Installing, running an native game doesn't have to be more than answering "yes" to the question "do you want to play this game?". And I have a hard time seeing how it should be harder to uninstall than a game utilizing WebGL and local storage...
Keeping the game sandboxed and basically treating everything that is downloaded as a cache - no problem.
And streaming content to a native-game isn't exactly rocket science either, there just haven't been a need for it when you still have this cumbersome install process that you have today.
Do this and you would get an awesome separation of performance critical low level code and the web resulting in a vastly reduced attack vector (basically going from push to pull). As a bonus you would get much better performance.
> But the act of playing music is something spotify better at - and that mainly is just because (if you use spotify) you have your music collection in one place. That's where you go to play music.
Spotify is worth installing because it gives me all music in one place. If I had to install one app per title, I would not consider it at all. That is how games are. You have to install each title individually. That makes Spotify much more similar to the browser than it is to installed games.
But you don't feel like you are installing google just because you go to google.com are you? Doesn't have to be any different for games. Well, the difference is that a game probably have a lot more content but that's nothing you get away with just because you use WebGL.
You only have to install one application that handles all your games (or applications) just like spotify handles all your music and your browser handles all sites.
> You only have to install one application that handles all your games (or applications) just like spotify handles all your music and your browser handles all sites.
The experience today for serious 3D games is, a full install for each game. Platforms like Flash and Unity attempt to do what you say, be the 'spotify' of games, but in general game devs ship their own proprietary native code.
I agree on mobile/tablets the existence of an app store infrastructure is more 'web-like' than the experience on desktop/laptops. In the end, this is a bit of semantics -- Google's native client stuff is probably the ultimate solution technically, sandboxing full-speed native code instead of relying on Javascript for client logic. However that is farther down the pike in terms of cross-platform adoption than webGL.
It all comes down to a tradeoff between adoption and bleeding-edgeness. My argument is with regard to what the situation will be if/when webGL is running on 90+% of browsers, including mobile and tablets.
Future of what? I don't know any use case where I would want 3D graphics on my web pages.
Running games in a browser? That's a stupid idea to begin with. Browser should be just a document reader, and games are not documents.
Why are we reinventing wheel again? Games used to be crappy, and now we want crappy games again? Why is it so amazing if something runs in a browser? Why don't we think about other solutions like making native apps more web-like?
Why is it so amazing if something runs in a browser? Why don't we think about other solutions like making native apps more web-like?
What's amazing is that something that runs in the browser will run on every platform where there is a browser (with some proper care of the inevitable small standard deviations). No such luck with native apps.
What magic script lets you natively compile OpenGL code for Mac, Linux, Windows & portable platforms without having to write any platform specific code?
Who said anything about not having to write any platform specific code?
"with some proper care of the inevitable small standard deviations"
Is exactly what I would say is required to make a game run on different platforms. It of course depends on what you want to do, but if you limit yourself to the subset that is the browser there shouldn't be any real problems at all.
Plenty of games run in the browser already, without 3D. There are also plenty of use cases for in-browser 3D that aren't game-related. See Google MapsGL or the Google Body Browser. It has huge potential for education in the sciences - I've seen a number of interesting medical teaching tools appearing.
One of the benefits of WebGL vs native application, is the ability to combine it with the entire set of document-based browser features that you're already familiar with. In fact, this is so useful that some native games these days are doing the opposite - embedding a browser kit into the game for the sake of the UI.
Distribution via the web is much easier. Telling people to install a .exe usually scares them, but pretty much everybody can go to a web page. And you don't have to worry about updates.
37 comments
[ 4.9 ms ] story [ 60.1 ms ] threadWebGL is where compiled 3d apps/games were, like, 20 years ago. Yes, I know it will improve, but so will compiled products. The sheer fact that WebGL is interpreted and is a poor-man's subset of OpenGL, puts it at permanent disadvantage.
Of course, you could have some trick allowing for compiled graphics code to be run within the browser, analogous to the Chrome Native Client, and with all the DirectX/OpenGL features. But that's no longer WebGL, that's just a smart trick to run old-school code within the confines of a browser environment. You might just as well write a stand-alone app.
And to that I say firmly: no.
I like the demos you've linked to (and I've seen them before), no doubt they're quite impressive, considering the constraints of the browser environment.
But when I put them in context of what one could run on a computer natively, these demos remind me of Quake I. Sorry.
I'm just a little frustrated at how inefficient all this web stuff still is. Imagine even your own demos - rather simple graphics by native standards - but with much larger world and many more characters. It would grind to a halt even on a mid-range PC, not to mention an iPad or a cheap laptop.
Still, I really wish that you create a plug-and-play graphics engine for web game developers, that would allow people like me to fulfill their fantasies. :) Wish you all the best!
https://chrome.google.com/webstore/detail/oohphhdkahjlioohba...
I'm not going to get into a semantic argument, perhaps to you Java is not interpreted either, but to me anything that doesn't compile to a binary directly executable on the CPU is substandard in terms of performance. And I'm sorry to surprise you, but in 3d graphics we're still starved for processor cycles, otherwise we'd have ray-traced, globally illuminated games with huge environments to play with.
By the way, there are also typed arrays which are translated directly to native code and were designed with WebGL in mind. I'd say that garbage collector is now the biggest issue of JS games. But it's improving, don't be skeptic.
EDIT: Actually, I did a small lecture a week ago, about performance tips. It's probably far from perfect as I don't work on browser engines, but it may give you some hints about making JS performance C++-like. http://www.smashinglabs.pl/lectures/js-performance/
I'd say that's an absolute minimum in terms of sophistication. And yet, some of it barely runs on a modest hardware setting. (Core2duo 2.5GHz, GF 8600GT.) [EDIT: Well, OK, in Chrome it runs OK, but still, these are tiny windows. Full-screen wouldn't be so nice.]
Now, imagine that you want to write an MMORPG. You make it just a little prettier than those demos, but more importantly - expand the world and add many more characters. It would bring _any_ gaming rig to a halt. (And yes, I realize that you don't display the whole world at once. But still, you need much more than there is on these demos.)
I dzięki za linka, fajne rzeczy na SmashingLabs i AiGameDev. :]
What in my opinion stops graphics from being better is model size that has to be transferred. You wouldn't wait 2 hours for game to load, would you?
And yes, we know that JS is interpreted and that it's no use for building anything more than a clock on your webpage, right?
As for your second question, JS is very useful, I love JS, I write 90% of my code in JS. But we're talking sophisticated 3d apps here, not whether it's useful at all.
http://www.youtube.com/watch?v=DQrC5YLKFUY
http://www.youtube.com/watch?v=Lmvj6-CFbbA
JS is not very pleasant to code with, so writing an actual game logic could be a bit painful, but so is development for PS3 and it's done somehow. It's not a question of performance, rather about workflow and structures provided by language.
Though, I think I've heard pretty much all the complaints against JavaScript, many of which are addressed by using something like CoffeeScript.
It doesn't really matter, browser games are the future and no matter how complicated it's going to be, somebody will be good enough to write them. We already passed "demo era" and some games are really good, like https://chrome.google.com/webstore/detail/bhoaojooagiaaiidln...
WebGL is just that, a poor-man's subset of OpenGL. As is OpenGL ES 2, which is a standard that's deprecating very fast as mobile GPU's pack more and more kick-ass.
OpenGL ES standardization efforts are badly left behind the development, as graphics vendors are adding more and more extensions to GLES in their implementations. These extensions tend to be a little stripped down versions of desktop GL features and the worst thing is that they're not quite compatible with desktop GL or even similar extensions form other vendors. Next version of GLES (codename "Halti") has to be standardized pretty fast or it will be out of date by the time it comes out.
If you want to write high quality 3d games or graphics using GLES2, you will have to use vendor specific extensions and write code specifically for the devices you intend to ship on. If you're doing something very basic, you may get away with using only the features in GLES2, but you'll still have to consider how to match the performance to the wide array of GLES2 conformant devices out there. It also helps if you're a part of a major graphics vendor's developer partnership program, like it or not.
WebGL's standardization cycle probably even slower. It took a while for the spec to reach maturity and major browsers implementing it. AFAIK, there's no extension mechanism to gain access to not-yet-standardized features. When the next version of OpenGL ES comes out, how long will it take for it's new features to come available to WebGL? Is the WebGL API even designed for extendability? Who are the industry players willing to contribute their engineering efforts to building WebGL specs and implementations?
20 years is a bit of exaggeration. Doom 1 was released 20 years ago.
Feature-wise WebGL/GLES2 matches a desktop GPU circa 2004 or so. Doom 3-ish feature set. Performance wise it's a bit behind, but this varies so much from device to device that it makes no sense to take this into a discussion when we're talking about API standards and their features.
The question is not "how many polygons can you render?" but rather, "how many polygons do you need to render to provide the desired experience?"
So it's a threshold question, not a contest where the winner is determined by benchmarks.
I think a more honest comparison (in theory) would be to compare a site used to serve music with spotify. For those that use spotify a link that opens up spotify is probably vastly superior to anything a site can do, that's not to say that the site itself doesn't have any value. But the act of playing music is something spotify better at - and that mainly is just because (if you use spotify) you have your music collection in one place. That's where you go to play music.
Playing a game locally doesn't have to be more than pressing an hyperlink. Steam is probably the, currently, best place for this but, I know, relying on something such as spotify, steam or flash sucks. But there is nothing to say that we can't have an open android/iOS-market-like place for doing this. Apple and Microsoft will push their own markets and I'm surprised that the notion of a third party market hasn't come any longer than steam. I guess people are just too greedy.
There really shouldn't be any reason for why running it in the browser should be any better than running it locally. Have sandboxing as an option (or requirement), similar to what apple does, and go nuts.
I miss the days when running low-level code in an all-purpose browser was something that was considered moronic.
You mention Spotify, I think Pandora is a great example of overcoming that feeling of commitment. If I go to the Pandora website I can listen to music right away by just typing in an artist. If I go to spotify I need to download some client and who knows how hard it will be to get rid of. If I complete the downloading step then I need to sign up for the service (I know they changed it to facebook login recently so I don't know if it's the same) just to start listening. I don't even know if I will like the service at this point because I haven't even got to try it yet. I think I would describe this as friction.
Installing spotify is a commitment, but if you already have spotify playing a song in spotify isn't a commitment even though that means that spotify will have to look it up and download it for you.
Yes, you already have a browser installed. But soon you will most likely have a "market" installed as well (in a few years you probably have to actively avoid it if you don't want it bundled with your OS). The market just have to make a distinction of apps that are "light" and doesn't bloat the system. It could even remove it automatically after x days of not being used. Similarly to how spotify would cache a song you downloaded. Or a browser does... (hello html5 and local storage)
Compare with smartphones where they did this distinction by calling applications for apps instead.
Perhaps there shouldn't be as much friction to install a game as going to a web page, but you can't deny that installing a game is currently not nearly as streamlined and easy as clicking a link. Even though it could be, or even should be. The main issue is that you have to wait to install the full game. A WebGL game would instead just download the minimum required to play the first level, and get you started playing the game ASAP.
The other thing though about a game being tied to a link is that it becomes a part of the web. Others will link directly to the actual game, rather than a page that lets you download/install the game natively. This ease of sharing is what makes it really powerful to have an in-browser game. The web is simply the ultimate form of distribution. It also seems less invasive compared to installing - you are not making any changes to your computer. Just close the web page, and it's gone (ignoring cookies/cached files). Whereas a native game will create all sorts of shortcuts and basically embed itself into your system. This is more of a perception problem with "installing" in the eyes of the average consumer.
And nothing you said has anything to do with WebGL. See android market where you can install apps from a web page. See Origin, launch games from the browser. Installing, running an native game doesn't have to be more than answering "yes" to the question "do you want to play this game?". And I have a hard time seeing how it should be harder to uninstall than a game utilizing WebGL and local storage...
Keeping the game sandboxed and basically treating everything that is downloaded as a cache - no problem.
And streaming content to a native-game isn't exactly rocket science either, there just haven't been a need for it when you still have this cumbersome install process that you have today.
Do this and you would get an awesome separation of performance critical low level code and the web resulting in a vastly reduced attack vector (basically going from push to pull). As a bonus you would get much better performance.
Spotify is worth installing because it gives me all music in one place. If I had to install one app per title, I would not consider it at all. That is how games are. You have to install each title individually. That makes Spotify much more similar to the browser than it is to installed games.
But you don't feel like you are installing google just because you go to google.com are you? Doesn't have to be any different for games. Well, the difference is that a game probably have a lot more content but that's nothing you get away with just because you use WebGL.
You only have to install one application that handles all your games (or applications) just like spotify handles all your music and your browser handles all sites.
The experience today for serious 3D games is, a full install for each game. Platforms like Flash and Unity attempt to do what you say, be the 'spotify' of games, but in general game devs ship their own proprietary native code.
I agree on mobile/tablets the existence of an app store infrastructure is more 'web-like' than the experience on desktop/laptops. In the end, this is a bit of semantics -- Google's native client stuff is probably the ultimate solution technically, sandboxing full-speed native code instead of relying on Javascript for client logic. However that is farther down the pike in terms of cross-platform adoption than webGL.
It all comes down to a tradeoff between adoption and bleeding-edgeness. My argument is with regard to what the situation will be if/when webGL is running on 90+% of browsers, including mobile and tablets.
Running games in a browser? That's a stupid idea to begin with. Browser should be just a document reader, and games are not documents.
Why are we reinventing wheel again? Games used to be crappy, and now we want crappy games again? Why is it so amazing if something runs in a browser? Why don't we think about other solutions like making native apps more web-like?
What's amazing is that something that runs in the browser will run on every platform where there is a browser (with some proper care of the inevitable small standard deviations). No such luck with native apps.
"with some proper care of the inevitable small standard deviations" Is exactly what I would say is required to make a game run on different platforms. It of course depends on what you want to do, but if you limit yourself to the subset that is the browser there shouldn't be any real problems at all.
One of the benefits of WebGL vs native application, is the ability to combine it with the entire set of document-based browser features that you're already familiar with. In fact, this is so useful that some native games these days are doing the opposite - embedding a browser kit into the game for the sake of the UI.