The technology is only going to get better. The whole point of these demo's is to show what is possible even now when the specs aren't finalized and the technology is barely adopted. Give it 3-5 years and I would be willing to bet you'll need to eat your words.

That's the point, isn't it? We already have all these fast, battle-tested game engines Heck, we have 15-year-old game engines that run on the browser (or do Flash games no longer count?). Is it really worth it to toss all that out and switch to WebGL?

Used to think that when I was high on WebGL in summer 2011. Sure some progress was made since then but really not as much as I expected. I really thought "by 2013 this will run on ALL browsers and on MOST mobile devices out-of-box, no config flags needed". We're still not there yet by a long shot.

So you're saying it'll be another 3-5 years? That's cool by me, I'll check back in 3-5 years then. This stuff is easy enough to pick up for anyone who has a grasp on basic modern OpenGL workings anyway..

- html5 games are defacto multiplatforms, since tbey must support all the popular browsers, and underlying systems (mobiles, tablets, PCs...). Compare this with the Wintel supremacy of early RTS days,

- This is technology preview material, available to a potentially very large audience. I don't think RTS did get such exposure during their development, especially during the eary days, when people wanted to disclose as little as possible to the listening competition in the gaming news channels (nainly magazines).

I think that the problem is that WebGL is young and there are LOTS of ways to shoot yourself in the foot perf-wise. Only a few teams have really figured it out and the rest are making the tech look bad. But the performance is there if you're an experience graphics programmer and you know your way around JS wackiness.

Thus far, HTML5 games seem more like a replacement for basic 3D flash games more than anything. Whether that will change at some point in the future I don't know, but at this point I have not really been wowed by anything.

In the end of the day it's just a script running on top of Open GL.

I, too, like to strip naked outdoors in a Chicago winter and then complain about how the city isn't keeping its streets reasonably well-heated.

So I will use [x] to find a game in [y] and then [z] it to play.

Where: x = {Chrome|Firefox|Steam}, y = {some-sort-of-web-app-store|Steam store}, z = {cache|install}.

I guess the success will depend on how easy and rich x-y-z experiences are, but you will still have to register, pay and download.

That's the advantage of the web over native APIs, and why I think its ethos will eventually win out - it is better for developers and users, but not for the corporations who would like to sit between the two as intermediaries.

They are, but I very much doubt these guys are using the DOM or CSS. And if they're using asm.js then they're using a very different JavaScript, too.

Granted, it's a terrible abuse of a CSS, but it's also a perfect example of how I'm supposed to be wowed by a buggy HTML5 demo my PC could render better in every way 15 years ago.

And no one has answered my question yet. What benefit does HTML5 bring me as a gamer? Why are HTML5 games better than native games in my steam library, especially considering DSL is my only option for Internet here?

* The ability to play the game without installing anything

* The ability to play the game on other peoples computers

* Cross-platform accessibility (Windows, OSX, Linux? Doesn't matter.)

Obviously you haven't played any HTML5 games. They all make you wait to download game data. And if the Internet gods have been good to you, it won't be cleared from your localstorage next time you start it up. Steam is far better.

* The ability to play the game on other peoples computers

So can Steam.

* Cross-platform accessibility (Windows, OSX, Linux? Doesn't matter.)

10-20% of the games on Steam have Linux ports, and most of the others run fine under Wine.

So 2/3 are better on Steam and the 3rd is primarily a benefit for the developer.

I don't see HTML5 being used for creating cutting edge games. I do see it being used to create smaller, less graphically intense games that easily hook users.

more people making games and more people playing them. i don't think anyone thinks the browser is the end all be all platform to deliver a game. just like some games run on OS X and some don't, and some games are on Steam and some are not. some games will be in the browser and some won't.

i hear you on the technical concerns. lots of problems. but the vendors recognize this and have a vested interested in fixing it.

ps - how can we start an hn sc2 group

Not a really good rationale when it comes to game development.

Agreed. But you're missing the point. In those 10 years those of us who played in the native universe will not be the target market any more. Just like we listeners of Pink Floyd and Metallica aren't the target buyers of Justin Biebers and Lady Gagas of the day. The latter are as successful, immersive and relevant to those who matter.

> JavaScript, DOM, and CSS are terrible technologies to base any gaming system off of.

Now this is an opinion based on the current_level_of_performance (which I agree is not at the expected level.). But it's not a great way to judge what the future could hold. It's definitely a bet, like you said let's be honest with this.

Native will always fundamentally beat non-native, that's a plain fact.

Consider the barriers to browser performance:

Hardware acceleration - already there with WebGL and for video codecs The JS language - this can be swapped out for something more performant - various options exist but it will take time and a brave vendor to do so. Rendering speed of HTML etc - this can be improved, both by simplifying things like the box model and by improving the renderer, we've already made huge strides int this area for standard UIs.

These are solvable problems - eventually web properties could easily be compiled (in a sandboxed language or VM), and become native. I don't think there's necessarily a difference between a sandboxed process in a browser VM, and a sandboxed process on the desktop. Just because browsers are still developing and in the past have not been performant in comparison to native APIs, doesn't mean things always have to be that way. So while the present performance comparison of native to HTML means native wins (as long as you don't just do everything in webgl say), things don't have to stay that way.

The greatest strength of the web platform is that it is simple, open, and extensible. This also makes it a bit of a mess of competing standards and leads to a problem with legacy cruft (like the reliance on JS), but it has held up remarkably well, and has proven flexible, simple and incredibly popular. It's difficult to charge people money for content on the web, but not impossible and that's more to do with culture than technical challenges. It's also difficult to lock people in on the web - that's something people hate about native which isn't going away.

Eventually I expect the internet, and the web in particular, will reduce operating systems to a badly debugged set of device drivers (Andreessen was prophetic in that regard), and operating systems will be replaced as a concept and become simply the interface to hardware, which implements some standard APIs for the web and acts as a container for the VM which runs the code. We're not far from that situation already, and it is preferable for consumers and creators/developers. The only thing standing in its way are the vendors of large ecosystems (hardware and software) like Google, Apple, MS and Amazon, who have a vested interest in corralling and controlling their customers and keeping them inside an area where they set the rules and can take a cut on every transaction.

I'd argue the resurgence of native mobile platforms is the last hurrah of native, and simply another attempt to lock people into an ecosystem controlled by one company, it will fail as people start to realise their loyalty to say Apple is not rewarded. We'll probably see these companies grudgingly adopt the web, while still trying to corral their customers (it's what companies do when they get to a certain scale), but on the web that is much harder to do, because it's an open API, controlled by no-one.

Most things running on the desktop aren't sandboxed. Whether they should be or not is a different matter.

Hardware acceleration will by necessity be limited when one is required to sandbox, as in a web browser. It's the difference between accessing an array item by "arr[i]" and accessing an array item by "if i>arr.len || i < 0: crash, else arr[i]". Some checks can be compiled out, but some cannot. And there will always be cases where a human can identify that something cannot happen but a compiler cannot prove it. Look at the number of cases in the Linux kernel where there's assembly macros, for example.

As for the web being a "simple, open, and extensible" platform, I'd argue otherwise. Simple? Have you looked at the amount of mostly-duplicated css required to just do a simple cross-browser gradient? Open? Good luck using anything besides HTML/javascript/CSS. Even Java is blocked by default now. Extensible? Only if by extensible you mean "you can have any language you want, as long as it's javascript."

I agree that native locked-down mobile platforms are the worst of all worlds. That being said, I don't see why non-locked-down native platforms are bad.

Simple - I do think the simplicity of the web is is its greatest strength - it does limit what you can do with the web, but it also means it is not too hard to either produce content or create a browser (though nowadays the browser part is pretty challenging). CSS gradients are a good example in fact of the messy web process of experimentation, consensus, and eventual convergence - you will soon be able to use the prefixless style and not worry about several prefixed versions. Personally I'm not sure prefixes are a good idea anyway, but they do go away eventually.

Open - I meant as in anyone can contribute to the standard, and any vendor can write a browser, no one party controls it, as they do native platforms. I'm quite happy Java is blocked given who controls Java :) On the server of course, you can use whatever you want, whatever framework, language and paradigm you like, which is quite liberating when compared to say creating apps for iOS.

Extensible - well the standard actually allows for other languages, and JS being the only scripting language is more a quirk of history than anything else - there have been moves to allow byte code instead (Nacl), and I suspect that's the way things are heading - to a sandboxed VM which will run any compiled language. When that happens then a huge range of languages will open up, just like server side.

That being said, I don't see why non-locked-down native platforms are bad.

The biggest reason they're bad from my point of view is that they don't cater as the web does to hardware not invented yet (as the web does), obsolete hardware, or to other hardware platforms and are locked-in to a particular chip and instruction set, even if not locked down to an API. The other disadvantage is that you are locked in to whatever API (and typically language) the platform has chosen - everything must be written with that language, or with glue code interfacing to that language.

That's the big difference with the web - it defines a limited reference platform (the browser) which can be made for any hardware, and anyone can target using any server side tech they want. There is a clear division between client and server, and both can change completely without invalidating the other. That's a very powerful abstraction and one which I think gives it an advantage as a platform against any native platform which rivals it.

The problem of WebGL is simply it has very low penetration. By my research, currently only 35% of desktop users can use WebGL with GPU acceleration (FYI, Flash 10: 95%, Flash 11: 75%; Flash 11(Stage3D with GPU): 70%). Now that IE11 is supporting WebGL, this might be a matter of time. However I foresee it would take 5 years or so to achieve 80%.

And, note that WebGL only has functions of OpenGL ES 2.0. Currently WebGL2, which has functions of OpenGL ES 3.0 is being developed. On the other hand, native games already utilize OpenGL 4.x. What API is used in native games when WebGL2 becomes popular? I imagine raster-based rendering might be obsolete at that time.

And I think people already know the web can't handle Oculus Rift, probably one of the most interesting, innovative and fun gadget in this decade. Of course you can use it on browsers with a NPAPI plugin. Oh, hey, the web people said plugin is obsolete and evil! Don't use plugins!!! Don't play with Oculus Rift, you, PLEASE!!!

I admit the web platform has some value on some points, but if people think HTML5 is the (only or most) cutting-edge and innovative technology, that's not correct. Absolutely not.

I don't think anyone could argue that - the web is a messy consensus, and definitely doesn't include cutting edge, innovative tech (except perhaps server-side if you want). That's not its strong point but I think the other points in its favour do make up for it.

Re WebGL, I suspect if we see killer app(s) come out using it, penetration will spread quickly and it will be kept up to date by browser makers. At present it's a bit of a chicken and egg situation.

I believe so, yes.

Assuming there will be 9 billion web users sometime into the future, non-native will be enough for most of the stuff though.

In quality, perhaps. In sales, profit and market share, I'm not so sure.