Mozilla Pushes the Web to New Levels as a Platform for Games
blog.mozilla.org
blog.mozilla.org
Shitty apps and shitty tech :) XUL was conceptually nice but in reality a nightmare for efficiency and pretty much it was just hard to work with due to a lack of tooling and solid evolution over time. I don't know of many sad to see it go
Every company has its duds.
You can't do the Smalltalk/JS speculation tricks if you're a compiled AOT language (actually, even worse: a language-independent ABI). So COM performance will always be mediocre.
Every once in a while, the sheikh tells people to build a grand palace, then changes his mind before it's completed. A few madmen will stubbornly continue to work on it.
Every once in a while, the sheikh agrees to build nuclear weapons "because it's better if we do it ourselves in the open, than leaving our enemies free to do it in the dark". The fact that enemies alone cannot do it, is dismissed as a detail.
Every once in a while, the sheikh decides this or that market stall becomes an official Kingdom Stall, where everyone has to shop at least once when they enter the bazaar.
And so on and so forth...
For example FirefoxOS could be considered a failure but I think many things they researched and developed are now part of web standards, especially those concerning offline webapps.
Mozilla also has products they've supported for a long time, including Firefox and Bugzilla.
> I saw XUL
I know they're phasing it out in some ways but hasn't it lasted around 15 years, since before Firefox? Some people think Mozilla stuck with it for too long. It's possible XUL is older than a few (precocious) Mozilla contributors.
And you can use self hosted webmail instead of Thunderbird.
Can you explain why, or point to existing information on this subject?
And on Linux, Chrome's custom toolkit feels much faster than the Firefox XUL. Everything from opening new tab, switching tabs, menus, etc. And using Electrolysis doesn't help. So it's an issue with the XUL toolkit.
The mouse move events have to be filtered to be less frequent to accommodate some of the limitations of the JavaScript concurrency model.
Honestly, it would be wonderful if we had immediate mode APIs for everything instead of being forced to register event handlers, which will always lag at least 1 frame behind.
But as you say, that retains all the disadvantages of event latency.
requestAnimationFrame is designed for immediate mode rendering, so it should probably pass its callback some information about input states or offer some other way of getting that.
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.
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.
I guess I mean, if you can code for WebGL in JavaScript you can probably code for GL in C even if you're not yet aware of that fact. And if you're just using Unreal or Unity, they already export "real" apps.
You're quite right about that. But then writing the rendering code is not the hard part, is it? I'd actually prefer to build my native app in Rust right now, but there's a few things holding me back. Namely:
1. UI layout and rendering: Currently Rust has no packages (that I'm aware of) delivering a good developer experience for building layouts and interfaces. There's a lot of parts to this besides just the layout calculation—there's font loading and text layout, too.
2. Easy cross-platform support: I don't have access to all the devices I'd like to build my app for. That's a relatively small problem, but also one I don't want to worry about if I don't have to. Not only can you write cross-platform logic and interfaces very easily, but the debugging experience for these is also really, really good.
Could I figure out solutions to these problems? Definitely. However, I'd rather spend my time crafting a great user-experience for my game instead of building a layout engine.
The JavaScript ecosystem is great currently, and if web performance is "good enough" for my use case, I don't have a very good business reason to pursue a different technology stack.
However, must the platform be a browser? Why not an open app technology? (Based on Servo?) Perhaps that is too much of a leap to influence the marketplace any time soon.
And still, making a straightforward social game with simplest 3d scene to work in WebGL takes a month of work, and even after that, it hogs 1 Gb of memory, runs around 30 FPS and heats up the CPU like a beast.