
Mozilla Pushes the Web to New Levels as a Platform for Games - bpierre
https://blog.mozilla.org/blog/2016/03/14/mozilla-pushes-the-web-to-new-levels-as-a-platform-for-games/
======
tangue
Two years later : "Mozilla will sunset it's games team to focus on Internet
for dogs" Sarcasm aside, I saw XUL, I saw Thunderbird, I wrote code for both,
it's hard for me to believe in Mozilla.

~~~
hackuser
Every organization retires products, for which many people wrote a lot of
code; I'm not sure what the objection is here, other than to that reality.
Google does, Microsoft does, Twitter does, etc. Open source organizations do
it too. Only enterprise vendors will support unsuccessful products for a long
time, such as IBM's long support of OS/2.

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.

~~~
tangue
Though I understand this point, I have the naive assumption that Mozilla
should be different, a kind of sweet spot between GNU and commercial products.
And I have the feeling that it's now a market-oriented corporation turning its
back on hackers.

------
maho
Do these new technologies enable lower mouse-event latencies? I struggle with
making even the simplest 2d apps in a canvas element, because they always end
up feeling sluggish. This was and still is a major point where Flash beats
HTML5.

~~~
adrusi
You don't want to use mouse events for games. You probably want to use
window.getAnimationFrame and then just query cursor coordinates.

The mouse move events have to be filtered to be less frequent to accommodate
some of the limitations of the JavaScript concurrency model.

~~~
blaisio
Neither of the APIs you mention exist. Maybe you mean requestAnimationFrame?
That still doesn't solve the problem of getting the current mouse coordinates
though. Currently, the only way to get them is through events like mousemove.

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.

~~~
adrusi
Whoops, yeah it's been a while since I worried about stuff like this in
javascript. I guess what I remembered doing was keeping track of cursor
position in a global, updated on every mousemove to simulate immediate mode in
a requestAnimationFrame callback.

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.

------
Touche
I'm really disappointed with how slow publishers are being to adopt these
technologies. If you look at the timeline[1] asm.js came out 3 years ago,
fullscreen API 4 years ago. And I can't hardly find any non-demo WebGL games
on the web. I'm not talking AAA games, just something beyond "here's something
I built at a hackathon".

[1][http://www.openwebgames.com/#/timeline.html](http://www.openwebgames.com/#/timeline.html)

~~~
chadaustin
As someone who has tried, there are just too many things wrong with the web as
a platform. I'd love to use it to ship great customer experiences, but:

1) Web Audio is awful -- [https://chadaustin.me/2014/09/web-platform-
limitations-part-...](https://chadaustin.me/2014/09/web-platform-limitations-
part-2-web-audio-api-is-a-mess/)

2) You STILL cannot prioritize XMLHttpRequests.
[https://chadaustin.me/2014/08/web-platform-limitations-
xmlht...](https://chadaustin.me/2014/08/web-platform-limitations-
xmlhttprequest-priority/)

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. :)

~~~
pcwalton
> 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.

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.

~~~
chadaustin
Hi Patrick! To be clear, I think the web platform is largely headed in the
right direction _. It 's just a question of velocity, especially relative to
other application ecosystems like iOS's App Store. When a product cycle is on
the order of a couple years, but even simple new capabilities (like XHR
priority) take years of discussion before anyone implements it at all, then we
basically can't assume anything beyond the current web capability set when
planning a product. And the current web capability set is not good enough for
the kinds of experiences people take for granted on native!

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.

~~~
pcwalton
I agree that we need to move faster.

(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.)

------
JasonSage
These kind of announcements from Mozilla have become quite regular, and every
time I find myself wanting an Electron- or nwjs-like technology to evaluate
the possibility of shipping a real app with it.

~~~
robterrell
Why would you do that? All of the disadvantages of the web stack in the
middle, none of the advantages of a stand-alone app.

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.

~~~
JasonSage
> 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

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.

------
_greim_
This is awesome and I hope it ushers in an era of the web being a platform for
high-performance apps in general.

------
hackuser
I love Mozilla's dedication to the open Internet and their innovative,
strategic thinking about it. This seems like a way to nudge developers off of
native apps and onto open technologies.

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.

------
golergka
> Unity, one of the largest and best-regarded game engines in the industry,
> showed that the Web stack is ready for prime time by removing the ‘Preview’
> label from their amazing WebGL exporter which takes advantage of WebGL and
> asm.js.

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.

------
TazeTSchnitzel
Shared Array Buffer is exciting, this opens the way to threading in asm.js and
WebAssembly.

------
mtgx
What about Vulkan for WebAssembly?

