I imagine that this, in addition to WebAssembly, could lead in the future to playing more complex games from the browser with the benefit of being platform agnostic (in kind of device, hardware architecture, OS) as long as the browser, the OS, and the hardware is compatible. Am I wrong?
The main problem isn't CPU and GPU performance, those problems had (to some extent) already been solved with asm.js and WebGL, at least for some types of games. It's all the other APIs and the general "feature churn" in browsers which are problematic for games.
Some examples:
- The fullscreen and pointerlock APIs show popup warnings which behave entirely differently between browsers.
- Timer precision has been reduced to around 1ms post-Spectre/Meltdown, and jittered on top. This makes it very hard to avoid microstuttering (we don't even need a high-precision timer, just a way to query the display refresh rate... but guess what, there is no way to query the display refresh rate)
- WebAudio is ... I don't even know what... all we need is simple buffer streaming but we got this monstrosity of a node-based audio API. And the only two ways to do this in WebAudio are either deprecated (ScriptProcessorNode) or not usable without proper threading (audio worklets), and guess what, threading is also disabled or behind HTTP response headers post-Spectre.
- Games need UDP style non-guaranteed networking, but we only get this as a tiny part of WebRTC (DataChannels).
...and the list goes on. In theory there are web APIs useful for gaming, but in practice those APIs have been designed for entirely different and very specific high-level use cases (such as creating an audio synthesizer in a webpage, or creating a video chat solution for browsers), and those rigid high-level APIs are not flexible enough to be reassigned to different use cases (like games). The web needs a "game mode", or better a "DirectX initiative", a set of low level APIs and features similar to WASM and WebGL/WebGPU, and if not designed specifically for games, than at least low-level and generic enough to be useful for games.
This isn't a new idea, see the Extensible Web Manifesto:
https://extensiblewebmanifesto.org/
(backup: https://github.com/extensibleweb/manifesto)
But the ideas presented there didn't seem to have much of an impact with the web people (with the notable exception of WebGPU).
> Timer precision has been reduced to around 1ms
> threading is also disabled or behind HTTP response headers post-Spectre
It seems like you've written a long-winded complaint that you have to add a http header (like this[0]) to your server's response? Though it's true that the Spectre stuff broke everything for a little while there (and there are still ergonomics-related teething problems with headers that are being worked on).
> Games need UDP style non-guaranteed networking, but we only get this as a tiny part of WebRTC (DataChannels).
WebRTC DataChannels work fine though? Does it matter that it's a small part of the whole WebRTC spec or that server-client use is a bit of a hack? Either way, WebTransport hits origin trial in Chrome in about a week, and it's specifically designed for UDP-like client-server communication, so the WebRTC approach can be swapped out once that is stable.
> It seems like you've written a long-winded complaint that you have to add a http header (like this[0]) to your server's response?
So how does this work on Github Pages or other hosting solutions where the user has no control over the web server configuration?
> WebTransport hits origin trial in Chrome in about a week
How long until this shows up in Firefox, and will Safari ever support this before it's deprecated in Chrome again because another better solution shows up?
> how does this work on Github Pages
Spectre called for some drastic measures, and it'll be up to Github/Netlify to decide how they react. Developers who want simple hosting solutions for their little projects will host elsewhere (e.g. replit.com, glitch.com) if they need to. This isn't exactly a massive obstacle if you've set out to build a complex game in the browser. It's just a couple of headers...
>How long until this shows up in Firefox
WebRTC data channels work fine in the mean time. Have you seen games like krunker.io and dotbigbang.com et al? It's perfectly possible to create real-time games in the browser using WebRTC.
It is an obstacle (at least a massive annoyance) for library authors (like this: https://github.com/floooh/sokol). Those libraries can be used for extremely simple and small WASM snippets embedded in blog posts (like here: https://floooh.github.io/2019/01/05/wasm-embedding.html), or in "proper" games hosted through "proper" hosting services which allow to set the response headers.
Right now the choice is to either support WASM threading, but tell library users that the library will most likely not work on the hosting solution of their choice, or not support WASM threading and work everywhere. At least to me it's clear that "works everywhere" is better than "it's complicated", so I'll ignore WASM threading until the problem is solved somehow (either most hosting services turn on those response headers, or there's another way to enable threading without requiring control over the web server configuration).