Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
simple-game
A personal collection of windowing/graphics/game code to get started quickly on games and graphical applications
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, 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 use cases, and they 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).
Saved in my note, much appreciated.
Yes, I agree building a UI library from scratch is hard and probably not worthy doing (too many people tried and gave up in the middle; probably better to channel that enthusiasm on improving existing ones). I should state that more clearly. I was looking at something more modest, like a canvas implementation based on wgpu that enables others to build their UI libraries on top.
I guess it would be something like Skia, but it also sounds like a tremendous effort, and I could probably just use Skia instead. However, I guess I am not going to match what Skia has (maybe what HTML canvas has is enough?). Also, I have played with skia-safe crate but I personally feel the dev experience could be better (not to blame skia-safe, it's wonderful and even provides a build process that automatically downloads a precompiled skia library).
Thanks for pointing out Iced. I didn't know they are using wgpu under the hood. I will take a good look at their code. I have been reading nannou's code to learn how to work with wgpu. If we skip my last paragraph, I think building a UI library on top of nannou is pretty doable.
[1]: https://github.com/nannou-org/nannou
> This isn't exactly a massive obstacle if you've set out to build a complex game in the browser.
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" web services which allow to set the response headers.
Right now the choice is to either support WASM threading, but tell users that the resulting code most likely won't work on the hosting provider of their choice, or not support WASM threading and work everywhere. At least for me I have decided to ignore WASM threading until the problem is solved (either the response headers are supported automatically by most popular hosting services, or there's another way to enable WASM threading which doesn't require control over the web server).
It's really not that bad. I had some complaints about WGSL a few months ago but it was surprising how quickly it improved. Here are some simple real-world shaders you can look at:
https://github.com/bschwind/simple-game/tree/9de179085a04dd4...
If you combine it with a quick build step to give you shader compilation errors before your program runs, it becomes a pretty nice shading language. There are still a few rough edges but it's not _that_ bad to work with.