The "biggest" WebGL game I'm tracking these days is Wild Terra: http://www.playwildterra.com/
But https://www.starbreak.com/ is also a pretty fun MMO in its own right.
But there are hosts of others hiding within non-traditional gaming sites, like the BBC.
I think browser-tech games haven't figured out the marketing/monetization paths. I think the rational response to the loads of risk found in making money on games is to produce lots of smaller games to see what sticks rather than investing tons of time into single, larger titles.
That doesn't mean that larger projects aren't out there, I just think the risk/reward curves of game development don't lend themselves to experimenting with weird technologies as well without morphing the gaming experiences beyond what we'd normally call games.
Good examples of HTML 5 instead of Flash, but not great examples of the web as a serious games platform.
I think if we're talking about the web as a serious games platform we have to widen the scope of the discussion from graphics/sounds and include both the network effects of online players and the true multimedia approach the games can have, especially when paired with social media.
Here are some features web games can use because they run on the web platform that the authors don't have to write themselves:
* Speech recognition
* Peer-to-peer communication
* WebVR
* getUserMedia
Wild Terra is a lot like Ultima Online, 1997 (even more like Lineage 1, 1998), and Starbreak is a simple platformer (like, for example, Maple Story, 2003).
They're a step up from Flash, but 15 to 20 years behind game consoles and native PC gaming.
1) Web Audio is awful -- https://chadaustin.me/2014/09/web-platform-limitations-part-...
2) You STILL cannot prioritize XMLHttpRequests. https://chadaustin.me/2014/08/web-platform-limitations-xmlht...
3) The input APIs are janky
4) High frame latency in Chrome, low frame rate in Firefox
5) Allocating more than a couple hundred megabytes is risky -- it might even crash your process (I've filed a few bugs against Chrome on this)
6) SIMD.js is a least-common-denominator approach, meaning you pay a penalty on one of x86 or ARM, just like we saw with the JVM and floats.
7) JavaScript still doesn't have int64.
8) Still no efficient memcpy.
As far as I can tell, the web is not on track to catch up to native platforms in terms of customer experience anytime soon. That said, you could probably ship some small things on this tech and get away with it, but in no way would they supplant a native iOS or desktop app.
[begin rant]
The WHATWG is a bunch of out-of-touch buffoons who have an opinion on everything even when they're not close to the problem domain. Browser vendors try too hard to work together, meaning if anyone has an objection about any API, it won't ship. (Or will take years.) The Extensible Web Manifesto seems to have had no effect. There are no conformance suites, so you can't actually rely on APIs working the same across all browsers.
[end rant]
I'm a strong believer in the open web as an enabling democratizing force for all kinds of content, but I no longer have faith that web standards bodies and consortiums of browser vendors will get us there anytime soon.
EDIT: That really got me worked up. Better than morning coffee. :) But I'd be remiss if I didn't call out a small group of amazing people who are, without much support, pushing the platform forward. Alon Zakai, author of Emscripten, is a visionary and has had a HUGE impact on the feasibility of games in browsers. Dan Gohman, even though I've disagreed with his opinions on how SIMD.js should work, does extremely influential work. Patrick McManus is awesome. Vladimir Vukicevic pushed WebGL, which is one of the few good web APIs. Also, major props to Google's PNaCl team as they've retooled towards WebAssembly. I'm sure I'm missing people. Contrary to what I might have indicated, there ARE people with taste who do great work. :)
Hell, WebSockets doesn't have UDP. That's like the cornerstone of low latency networked games.
It was never designed for this, and upgrading the core language to do serious computation will be like putting lipstick on a pig or a sticking plaster on a wooden leg.
You're correct though Emscripten and WebGL are amazing things, but ultimately hacks. With browsers scurrying to implement ASM.js support, JITs etc... (because most JS developers write shonky code and interpreting JS is not fashionable any more)
JS considered dangerous. DO. NOT. USE.
It was never meant to be a layout markup language, we already had SGML for that.
Interpreting JS is so "fashionable" that most browsers (all but Chrome/V8) keep around their interpreter, and most code runs in it. That's because, contrary to popular belief, most JavaScript code is cold and not performance critical.
I'm interested in where these interpreters are, as Mozilla has had a JIT for ages (for example) ... if they kept their interpreters about surely it would be just for non-jit compilation targets?
I think it lost because Web Audio was the Chrome proposal, with implementation, and Chrome had/has the mind/market share.
For apps (not necessarily games), I'm convinced these days that the problem is not JavaScript at all, and so I'm not sure most of your points are relevant. Native apps on any platform barely ever use SIMD (outside of the system stack, which the Web APIs also use), for example. The problem is that the CSS rendering stack is old and needs to be revamped.
As far as games go, I'm not in the industry, and I completely believe you. But I'm optimistic, with Web Assembly and a redone browser architecture, the Web is on the right track. Not there yet, of course.
I thought that was the point of the 5+ year long flexbox? Are you telling us that didn't do the job?
I think Flexbox pretty much fixed the complaints about the expressiveness of CSS for UIs (unless you're forbidden from using it for browser compatibility concerns, of course).
Now you're saying that CSS needs to be revamped. Great. Anyone working on that? Either way we're looking at, what, 5 years minimum before first browsers have this new thing that's really about performance this time, for real.
That's not true. Do a search for [flexbox floats performance] and you'll see that the goal was not to improve performance of floats. Floats are only a performance problem in parallel implementations, which nobody was talking about at the time flexbox was created.
> Now you're saying that CSS needs to be revamped. Great. Anyone working on that?
Gotta love HN snark. I work on that every day, 50+ hours a week.
And I'm not saying revamp the specs. I'm saying revamp the implementation.
I hope that changes! I think the web would move faster if browsers would stop cooperating so much with each other. Increase the rate of churn; let the best APIs win.
Some niggles: I personally think anti-fingerprinting measures are overweighted, especially given that preventing fingerprinting is basically a lost cause. I also think there's room for more "unspecified behavior" in the web, e.g. it sucks that we have to pay a penalty so that NaN can have perfectly consistent behavior on all platforms in SIMD.js.
(Given my struggles as of late with trying to get 5-year-old OpenGL functionality working on the Mac, though, I wouldn't necessarily paint Apple as the gold standard here. At least in my experience, Apple is probably the worst of all the major native vendors when it comes to things graphics-intensive apps care about.)
And for that, I'm grateful.