That storm already happened. It was called Unity. And since then others have joined, like Unreal.
WASM + WebGPU doesn't bring anything to the table here other than being a decade late, slower, and with fewer features. Why would anything outside of a web app touch any of it? Why would steam bother? You still have to build so, so much platform-specific stuff to make it work (input, audio, windowing, etc...), why would you do all that and then just pay a massive performance overhead to avoid compiling a whopping ~5 times?
WebGPU could potentially see a use as a middleware for things that want to use the GPU but aren't concerned all that much about performance or overhead, things like image filter effects. But there's also no shortage of existing solutions for them, either, like bgfx (as well as domain-specific offerings like halide of course)
Don’t get me wrong, I’m card carrying Unityman and just backed off of XR development recently in favor of more stable webdev work… but WebGL as a solution to high-performance browser gaming was an absolute shitshow from start to finish and I’m not even sure WebGPU lands in time for anything useful to be done with it to deprecate WebGL “support”. I assume that the lightweight 3D solutions based on threejs, etc. are going to drag the rest of the game engine industry kicking and screaming into whatever best solution arises and this wasm-as-k8s sounds like a neat component of that.
Games on the web face far greater issues than WASM or WebGPU can solve (like a complete lack of an asset delivery pipeline), unless you're only after casual flash-style gaming anyway. But mobile largely replaced that market.
To give you a scope of the problem of game assets, "small" indie games like Stardew Valley or Terraria are close to 500MB. How on earth are you going to deploy that on the web?
And if you are assuming a reliable, super-fast internet connection to stream game assets over (along with paying for the CDN to host it), well cloud gaming already does this better and already exists in a meaningful way. Why struggle to fight with the incredibly pathetic limits of a web browser when you can just stream a video?
With lazy loading? Or just an installation progress bar. What's the problem? The user has to click on the permissions dialog, allowing extended space usage, and that's it.
>reliable, super-fast internet connection
It wouldn't need a connection more reliable than what Steam requires for proper functioning.
>along with paying for the CDN to host it
I assure you the costs for a minimally successful game are minuscule when compared to the 30% cut Steam takes.
What you lose is the exposure that a release on a store like Steam gives you. That's not an insignificant problem, and is much more problematic than all the technical stuff you've mentioned.
>Why struggle to fight with the incredibly pathetic limits of a web browser when you can just stream a video?
Answered in a different comment.
And now you're back to 2006 era performance on a good day. 72 Mbit/s would be considered a pretty good internet connection. It's also the speed of a PS3's blu-ray drive.
People have been complaining about the 80-100MB/s on the outgoing generation of consoles for a long time now. Regressing by ~10x isn't a compelling argument.
> Or just an installation progress bar. What's the problem?
Without background downloads or updates? Every time someone wants to play your game, they're forced to stare at a progress bar that can easily take upwards of an hour depending on the game ("smaller" 3d games like subnautica push 10GB)? And you somehow don't see the problem?
> I assure you the costs for a minimally successful game are minuscule when compared to the 30% cut Steam takes.
And I assure you that you don't have to deploy on steam, either. You can both be a native game and get all the benefits of it and not pay anyone an app store fee! You don't have to suffer the web's treadmill of being a decade+ behind to have that.
If it's loading faster than user "consumes" assets, it doesn't matter how fast it is. It's not different for native games that allow you to play earlier than the whole thing finishes downloading.
>And you somehow don't see the problem?
Don't stupidly update the entire thing every time? Send deltas? Don't update as often? As for not having background updates it's a minor issue anyway (I for example don't start Steam unless I'm going to play), and there are Progressive Web Apps and Service workers to solve this issue.
>You don't have to suffer the web's treadmill of being a decade+ behind to have that.
Whoever needs the latest features can of course use a native platform. For developers who don't need the latest features or especially heavy graphics, WASM+WebGPU will be a viable option. That's all.
>You can both be a native game and get all the benefits of it and not pay anyone an app store fee!
And the user has to risk trusting me executing native code, which would definitely lower conversion rate.
AAA titles are already constrained by hard drive bandwidth, which is measured in Gbps on newer systems. They can’t keep all assets in memory. You’re going to have to have a top tier internet connection to get the same performance.
On top of that a browser thread can’t rely on having much more than half a gig of RAM assigned to it.
AAA titles are famously heavy in both GPU and CPU loads, and nobody is proposing to run them in a virtual machine, especially in the 32 bit one. ( memory64 is at the proposal stage)
Someone watching YouTube videos is sucking down hundreds of megabytes if not gigabytes per hour: the higher-resolution the video the more bandwidth required. Most video game assets require less bandwidth (megabytes per minute of consumption time), and can be cached locally.
When designing games for the web, creators will have clear incentive to apply more aggressive compression to everything they send over the wire and figure out how to make do with smaller assets, to cut bandwidth. Games designed to be downloaded have a relaxed size budget and can afford plenty of inessential bloat.
This is completely incorrect. Games regularly saturate and are limited by the 80-100MB/s that can be streamed from a PS4 or Xbone hard drive. This is in fact the biggest differentiating feature of next gen consoles - the switch to NVME and even streaming directly from disk to the GPU, bypassing the CPU bottleneck.
Meanwhile YouTube video, and indeed most streaming video, is well under 10MB/s. Netflix is even content to only recommend 25mbit/s for 4k HDR content.
> Games designed to be downloaded have a relaxed size budget and can afford plenty of inessential bloat.
This is such an arrogant and asinine statement. Games already exclusively ship highly compressed assets. They aren't just pissing away storage space for the lulz, and if they only tried a little harder could somehow cut sizes to 1/1000th of what they are today. Especially not to satisfy the needs of a platform that provides nothing but problems and headaches.
You can't simultaneously claim that WASM and WebGPU will enable a new era of high quality web based games while just entirely ignoring all the actual problems with shipping games on the web. Which WASM and WebGPU literally solve none of the issues. WebGL2 is already competitive on feature set and capabilities with mobile, and yet casual web games are still largely dead - a regression from the flash era, even.
> This is completely incorrect. [...] YouTube video, and indeed most streaming video, is well under 10MB/s.
10 MB/s is the same as 36 GB/hour. So we are in agreement.
But what game uses more than 36 GB of assets for 1 hour of play? I can’t imagine that is at all common. What kind of assets are they shipping that use that much data?
Think of it as if video keyframes were 1GB. Video streaming wouldn't exist in such a world as nobody is going to watch a loading spinner for 20 minutes. No, it'd all be a world of pre-fetched, downloaded content. Which unsurprisingly is exactly how game stores & consoles work.
Here's some coverage of the storage architecture of new consoles and why it's such a big upgrade: https://www.anandtech.com/show/15848/storage-matters-xbox-ps...
Trying to shove lazy asset loading over the internet into that picture just doesn't work.
Yes, and my estimate was “hundreds of megabytes if not gigabytes per hour”. So apparently Netflix also agrees with me.
> Games need to load that much data in under a minute.
This is based on design decisions from the programmers, not some kind of iron law of nature. Obviously you can’t just drop a game designed for one set of constraints into an entirely different context without change and expect it to work precisely the same way.
No, it's based on that's what textures and model quality expectations are. Reducing that size is directly reducing image quality.
You can make a web based game that looks straight out of 2002, sure. But you can't make one that looks contemporary, and WASM+WebGPU aren't changing that.
And of course no game developer is going to bend over backwards and make their game look like shit so it can run in a web browser for no reason other than to satisfy the ridiculous beliefs of web evangelists.
A friend of mine just got 350 Mbps optical fiber to his house. I was wondering what would come along to eat up that kind of bandwidth, you just answered the question. Someone playing a game on the web could also be seeding the thing on bit-torrent at the same time, thus cutting down the hosting fees for the developer.
2. The reason we don't see them anymore is because it's far easier to monetize them on mobile.
An interesting article on the topic (not written by me): https://www.fortressofdoors.com/tag/instant-games/
3D API for 2010 hardware or last generation raytracing hardware, what do you prefer?
Unity cannot do anything against castrated 3D APIs.
No wonder streaming is where everyone is going instead.
That is absolutely not going to continue being the case.
> No wonder streaming is where everyone is going instead.
"Pixel streaming" is great if you don't have latency requirements or your client has a poor GPU, but otherwise native 3D is superior.
Heck, 10 years of Web 3D and still there are no proper debugging tools that match native ones.
The ecosystem will explode, and the tooling will come with it.
Most devs would obviously still use unreal engine etc, but these engines will be able to give you improved performance of your games by utilizing WASM
In fact I'm quite certain that whenever portability or security ran up against performance in WASM's design, that performance always lost. Those other two goals were definitely a higher priority for WASM's designers.
Stable, portable byte codes are always inherently lossy. Information that could be (and often is) useful to optimizers is lost in that conversion. Then the conversion from byte code to running code also is on the hot path - it's on the hot path of starting execution. This is the same problem existing byte code solutions face, like CLR & JVM. WASM didn't manage to magic a solution where nobody else had. It's the same thing that's been done to death, just with "web" slapped on the front of it & bundled in a browser. That part of "being in a browser" makes it interesting for web devs, sure, but in the broader context of "all of computing" it's... just not? It's what we already have had (and been using!) for decades.
However, I think it would be possible to make systems in which similar instances, because they are written in a type-safe, memory-safe language in the first place, could bypass WASM and both start up fast and run fast optimised code.
I have done some research on portable bytecodes, and have some novel ideas for getting more performance, but I agree that the inherent problem remains. One thing that help make optimised C/C++ fast is that optimisers assume that undefined behaviour doesn't get triggered. But in a system for portable code, you can't just assume - you'd have to prove that it can not exist to be able to do the same optimisations, and that is far from straightforward. And when it triggers, it has to work the same say, or it won't be portable (bug-compatible) between hardware.
And since WASM uses linear memory and lacks things like ASLR, the code in the sandbox cannot achieve the same level of protection it could if it was in a hypervisor.
Also, not sure where the comparison to a hypervisor is coming into play. As @kllrnohj mentioned hypervisors are relying on actual hardware.
That is why we have signed binary execution to start with, WASM doesn't support any of this.
except it is, WASM is designed to be AOT compiled to native code.
Sure there is a bit of difference, WASM needs additional bounds checks and WASM also doesn't have all the info a more high level compiler has.
Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting.
Interesting, I didn't know that. How does WASM handle different architectures? Do you build different binaries for x86/arm? Or does it do it the Apple way with the giant bundle that contains all binaries?
> Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting.
Agreed, that was badly worded. Like you said, one could compare a module written in Unity and compiled to whatever Unity compiles to/is implemented in these days with a module in WASM.
Edit: Or does the AOT mean that the format that is shipped is some non-native format but the client compiles everything before the first run?
The same way JavaScript or C#/Java do. It's a bytecode format (typically the first stage in today's JavaScript engines is to turn into a bytecode), which the different engines then JIT for the OS and architecture they are running on.
For more details on a couple different engine implementations, you may find the below of interest.
- https://v8.dev/docs/wasm-compilation-pipeline
- https://hacks.mozilla.org/2020/10/a-new-backend-for-cranelif...
AOT is a counter part to JIT:
- AOT ahead of time (but still on the system, e.g. just before running)
- JIT just in time (while interpreting code you notice a hot section and turn it into native code)
So what most WASM runtime do is parse the WASM byte code, running certain checks for wellformedness and emit assembly (with necessary bounds checks, etc. to not escape the WASM sandbox).
This doesn't mean you can't interpret it, or interpret + JIT it, it's just that AOT seemed like a better choice then JIT or pure interpretation for WASM, as just interpreting it isn't fast enough compared to JavaScript JIT/or asm.js, to make it worth adding it to the web.
https://careers.unity.com/position/software-developer-unity-...
Our startup is working on support for Unreal to support WebGPU from 4.24 onwards, and we've already upgraded support so developers can use WebGL 2.0 instead of WebGL 1.0 like was available previously before Epic made it a community supported platform extension.
What all of them have, is being able to take advantage of 2022 hardware in 2022, with 2022 3D APIs.
As far as I know WebGPU doesn't lack any significant features beside raytracing (They are prioritizing the MVP, and raytracing could come later). Some of the newest features like mesh shaders are not yet supported by the native engines either, because there isn't a sufficient hardware base. Intel for example will support mesh shaders only in the yet to be released Alechemist GPU.
10 years later there still isn't something at the same level of Infinity Blade.
It definitely won't kill Unity or Unreal, but I have hopes that it will make developing without a ready-made engine a bit more attractive at least!
Want Vulkan/DX12/Metal without boilerplate?
Just use Ogre or Godot, among endless other options.
Even Qt is better than what WebGPU is capable of.
Castrated how? A single digit performance loss compared to the most extremely complex graphics APIs which aren't properly cross-platform?
>Want Vulkan/DX12/Metal without boilerplate?
>Just use Ogre or Godot, among endless other options.
"I want a graphics API!"
- "Use this game engine or this old and outdated graphics library instead"
>Even Qt is better than what WebGPU is capable of.
Ah, is it? Do you have any example of implementing forward+ rendering in pure Qt? No? What about GPU compute? Not that either?
> - "Use this game engine or this old and outdated graphics library instead"
That is the actual answer for when people ask that question, most of the time. Almost nobody is asking for a raw GPU API, which is what Vulkan, DX12, and WebGPU are. Rather they want a graphics API. Something that provides utilities and helpers. Something that can actually load textures, models, and animations. Or has a particle effect system.
But if all you want is a GPU API, as I mentioned far higher up in the thread there's no shortage of those today either (like bgfx, or even Angle). 'native' WebGPU isn't addressing some unserved market here.
Although if you actually do want a GPU API, there's also a good chance you actively don't want to use a middleware like WebGPU since it limits what you can do and gets in the way...
I'm mostly thinking of indie game devs who decide to write their games from scratch (which still happens, though it's becoming rare), or up-and-coming game engines such as Bevy. They might not have a team who can spend the time optimizing Vulkan (while also making sure MoltenVK runs it fine, if they want to target MacOS), and might prefer something more modern than OpenGL.
>WebGPU since it limits what you can do and gets in the way
Does it do that more than OpenGL ever did though?
By its nature cannot be more than that what browser do.
In case you missed the train, Qt now makes direct use of Metal, Vulkan, and DirectX 12.
I guess you were too busy keeping up with WGSL changes to notice that.
What security contraints are you thinking of which are making it castrated? In what meaninful ways is it castrated?
> In case you missed the train, Qt now makes direct use of Metal, Vulkan, and DirectX 12.
So with Qt, can I write a complete renderer with advanced techniques, and have it run on all 3 platforms without changing a single file? If not, how is it relevant to even mention?
Here is a little secret, thanks to extension spaghetti and driver bugs, there is seldom "without changing a single file" unless it is some toy app, instead of being used across all possible consumer hardware.
Plus you are focusing too much on Qt while being defensive for WebGPU on native deployments, there are plenty of other middleware I can use as example.
What are you talking about? Are you saying that https://doc.qt.io/qt-6/qsgmaterialshader.html is less "castrated" than WGSL ? Doesn't look like it. I don't even see the spec, it only says "Vulkan-style GLSL"
>Here is a little secret
Google and Apple definitely have more resources to spend standardizing WGSL (WebGPU has a Conformance Test Suite) than whoever owns QT this time of the year.
Because I still haven't heard a single argument against it from you that isn't extremely vague and handwavey.
For example, you skipping over my questions regarding more details on what you think makes WebGPU bad/castrated, or what is making Qt the better choice over WevGPU? (ignoring the fact that Qt doesn't seem to have a common shader language)
I'm open to hear the reasons, but it seems like your goal is to be contrarian.
And since you need to be Epic or a multi-million funded team with big scale to do an AAA game, but everybody could do a casual (and even more a hyper casual game), I'd say the latter is smarter than sneering on simpler games...
You might not care for those, but billions do. Heck, Wordle could make 10 times the money an average FAANG made in their whole career if it chose so...
WASM is like Java bytecode without access to the Java standard library (like, no `java.lang.String` or even `java.lang.Object`... just the primitives).
But it has a mechanism to call "host" or "imported" functions and to use linear memory (an array of bytes which can be shared with other modules and the host), which is how it actually does anything useful.
I can imagine a version of Java that works like this as well, actually, I wonder if there's ever been anything like that?
"Once".
That GC proposal isn't anywhere close to landing. It's making progress, but it's the "Zeno's paradox" kind of progress where the feature seems further away the more they work on it. I wouldn't be surprised at all if it still wasn't supported in browsers in 10 years.
"USENIX Security '20 - Everything Old is New Again: Binary Security of WebAssembly"
https://www.youtube.com/watch?v=glL__xjviro
Then there are the issues that since WebAssembly doesn't prevent memory corruption, while RCE attacks or sandboxing breaks are not possible, by producing memory corruption, it is possible to eventually trigger alternative code paths that wouldn't be possible in normal circumstances.
A contrived use case would be to validate a user with higher credentials that they are supposed to have, in a WASM based security module.
Then since the external calls from the module are configured from the runtime, one can do man on the middle attacks on the functions being called from the module, thus access data that it wasn't supposed to be made available in normal cases.
And I bet that when the hacker community starts having fun with WebAssembly, as much as they have had with other bytecode formats, more issues will be found.
It's less of a problem in 2021 than it was in 1995.
Ironically, those boycotts are now meaningless given Chrome market share, including Electron.
For desktop use, it just never had a good GUI API.
The future of gaming and the metaverse is cross-platform and free of walled gardens, with developers empowered to distribute directly to their end users online without a middleman required. The reinvention and subsequent golden age of high fidelity 3D browser games will be upon us sooner than most realize.
Links for anyone interested:
https://www.theimmersiveweb.com/
Our Discord:
Given that you mentioned Unreal Engine, why the web and not native?
I mean, this sounds like an awful lot of work to port something to the web, when it already runs in every platform.
How will it reduce walled gardens?
Another question : how, as a player, do you run a game like this offline, or run multiplayer when the game company servers have shut down ?
OpenGL/WebGL aren’t well enough aligned with modern hardware to serve as a cross-platform graphics layer.
That’s where the newer APIs come in. Vulkan, Metal and DirectX 12 all follow similar principles that would work from a technical standpoint, but we live in an age where platform vendors would rather cripple their platform than make it easy to port software. Apple is the worst offender here, because while Microsoft isn’t happy about it and disables it in “metro” apps, at least they don’t prevent GPU vendors from shipping Vulkan support for normal “desktop” apps.
But I’m optimistic about WebGPU: It’s designed to be efficiently implemented on top of the vendor APIs, so platform vendors can’t block it. And it’s low-level enough that it should allow implementing modern games on top of it.
(To clarify: I’m optimistic about WebGPU as an API for desktop applications. For browser apps, it seems like all vendors are on board already.)
Their choice of inventing their own shading language instead of using the ONE standard that the industry finally could agree on (SPIRV) makes me very pessimistic.
Apple is purposefully crippling stuff to retain their App dominance yes, but Apple IS a major part of WebGPU. So it never had a chance and was doomed to fail from the very begining.
Google even had a presentation titled "regaining developer trust" on this topic, but WebGPU continued to push WGSL nevertheless.
> Trivially convertable to SPIR-V
> Constructs are defined as normative references to their [SPIR-V] counterparts
> All features in WGSL are directly translatable to [SPIR-V]
> Features and semantics are exactly the ones of [SPIR-V]
> Each item in this spec must provide the mapping to [SPIR-V] for the construct
So WGSL is essentially just an alternative representation for SPIR-V.
But I don't see how this compromises the viability of webgpu.
It's a textbook case of: Embrace, Extend, Extinguish
Google tried to save it, but that proposal was rejected: https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDU...
The Proposal to work with both WGSL, was also not accepted because it would "weaken the position of WGSL".
"But think of the children/open web!"
Apple knows how to push the right buttons on the Mozilla folks so that they tag along: Rust, wEB-StAnDARds, not invented here.
- SPIRV was done by an evil technological group, not an open and inclusive standard body. We would tie our standard to whatever the SPRIV says, that's not open web. The open web can only flourish if everything is text based! cough WASM cough Rust ist such a modern language! -
It's similar to what happened to WebSQL, except this time it's much worse as it also ruins any hope that WASM might be able to replace all the other technological cruft. Playing the old guessing game of how the transpiler will mangle your SPIRV is simply not something that people want to go back to.
The draft was just updated two days ago.
Are you saying that the direct mapping requirements I quoted above have been abandoned?
Yes.
See these quotes:
Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too"
...
Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point"
...
Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime."
From https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4...
See also:
https://github.com/gpuweb/gpuweb/pull/599
https://github.com/gpuweb/gpuweb/issues/582
https://github.com/gpuweb/gpuweb/issues/566
http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...
https://news.ycombinator.com/item?id=24858172
The process has been very implementation driven, with Naga, the Rust tooling that does the whole conversion shenanigans, growing and changing its IR and semantics steadily. It's ironic that a group that is usually very adverse to having a single implementation of things is now pointing to Naga and arguing that we don't need an easy conversion step because we have all the compiler infrastructure build already.
The group has slowly redefined "bijective" to mean "easily compilable", which would be pretty hilarious, if it weren't so sad.
TBH, I don’t find those arguments convincing, but then, WebGPU is largely a political compromise, not a technical one. In a politics-free zone, they’d have standardized a “WebVulkan”, not made an entirely new thing. That would have been on the table, but Apple vetoed it. The same for a “Web-SPIR-V”.
However, I also don’t think it’s that big of a deal in the grand scheme of things. I’m glad we have a viable standard at all.
I fail to see where your point about trust fits in to that.
The original google proposal was to simply use SPIRV. A compromise was then settled for the intermediary language to be isomorphic to SPIRV, removing some of the warts and edges of it and make verification easier.
However, Apple with the help of the Mozilla folk successfully managed to twist the semantics into something that is no longer easy to translate from and to.
Game developers don't want to work with WSGL, the whole point of the new WASM and WASI ecosystem is to allow devs to bring their own tools.
This is especially bad for something like a shader language, where you want to squeeze every bit of performance out of the hardware, often with hand rolled instructions. Having the browser run a mangled version of the SPIRV that you or your toolchain/engine e.t.c. produced is simply not acceptable.
So you now have a platform target with one codebase that developers can target PC/Mac/Linux, mobile/tablet, and one of the biggest console platforms. I'd say that's pretty powerful.
Apple support for OpenGL is a side effect of NeXT's acquisition, had Copland's efforts succeeded, they would have kept using QuickDraw 3D.
Ah, and Google Maps.
Then there's the huge advantage of encouraging more competition in the CPU market. Something like RISC-V would have a much better chance if you didn't have to recompile everything for it.
I'm surprised native binary is still the standard. Back in the 1990s when I saw Java and then .NET I thought it would be dead by now outside of specialized high performance libraries for things like codecs and cryptography.
> - Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. I could see Steam, for example, creating their own runtime.
> - Embedded electronics, simplifying the development and deployment of IoT devices.
We will finally be able to write code once and run it everywhere! I bet at least 3 billion devices will run WASM. It's a breakthrough, how come nobody came up with such great idea yet?
Cross-platform Virtual Machines have been around for a very long time, enabling exactly the kind of thing you're talking about. So in-fact, lots of people thought about this, and built various versions of this. The browser doesn't bring anything new to the table here: it's yet another high-level abstraction layer which inevitably will incur performance penalties in a setting where performance means everything. People want to play complex, immersive games at 60 FPS with amazing graphics and textures, sounds, single/multiplayer settings, and more.
The browser was never built for modern triple-A gaming in mind, which means the APIs available for game creators will inevitably be less flexible and lag behind the more platform-native APIs we've had for 30+ years. This isn't a precedent by the way: recently developed APIs such as WebAudio & WebWorkers are just awful and don't come anywhere close to what a desktop application can do on a modern OS, and those are often considered "cutting edge". Synchronization APIs and locking primitives are only now being introduced to browsers - https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A... - something games could easily make use of outside of the browser for the past 40+ years.
Lightweight gaming can easily take place within the browser, and perhaps this new technology can make that easier to build and use. But to build a proper heavy-weight game - you'll need much more than a browser can offer.
Completely agree that web despite being perfect for light weight and casual gaming, is not (yet) the platform for AAA games.
https://twitter.com/RReverser/status/1471623675623481356
Yes, wasm threading support on the web uses workers + SAB. There are some limitations (the usual issues with blocking on the main thread on the web), but it works well in production for many things.
Sqlite was successfully ported to wasm, maybe something can grow out of that?
SQLite in the browser and at the edge is going to explode in popularity. A slightly unknown feature of SQLite is “sessions” which would allow you to build an eventually consistent system on top of SQLite.
https://www.sqlite.org/sessionintro.html
I can very much see SAAS type apps wheee each costumer/workplace has a SQLite db effectively deployed to the edge.
Something like cockroachdb's serverless might fit too: https://www.cockroachlabs.com/blog/how-we-built-cockroachdb-...
Cloudflare already has a free caching layer, a freemium eventually-consistent KV store that optimises for frequently-read items, and a strongly-consistent datastore. Besides, they partner with other database vendors too: https://blog.cloudflare.com/partnership-announcement-db/
I think you are referring to the upcoming R2 object store? I’m not aware of what I would think of as a “strongly-consistent datastore” which would be closer to a traditional database with querying. It’s that that I think is missing.
Quite right they have partnered with other db providers, however I think there is a need for something native to their platform that ensures good proximity to Workers to ensure low latency.
Lua, JS and LLV IRM?
Lua and JS are not even binary languages.
LLVM-IR has been considered, but has never been suitable as a compiler target. Code is targeted for a specific arch even before it becomes translated into LLVM-IR. Undefined behaviour in C is undefined also in LLVM-IR, and a portable compiler target can not have any. It is also changing too much between compiler versions (which is a reason why SPIR moved away from it).
BTW. It seems that in the long-term, the use of LLVM-IR in compilers is going to be replaced with MLIR (Multi-level IR).
Cloudflare Durable Objects is exactly this.
- Plugins for desktop/mobile apps, wasm provides a nicely sandboxed environment for them.
- Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. I could see Steam, for example, creating their own runtime.
- Embedded electronics, simplifying the development and deployment of IoT devices.
When it comes to wasm on the server, it’s often talked about as targeting the “edge”. I believe this the next area of massive growth, however the part that I don’t think is fully solved yet is on the database side. If your server app is making multiple database calls from the edge to a central db there is a good chance that it will slower than a traditional (single location) deployment.
What’s needed is a edge first database, we need at least read replicas to be at the edge with your app. Fly.io have something like this with their Postgres’s product. The alternative is to use an eventually consistent db such as CouchBD, but that causes other problems. I’m interested to see if CloudFlare do anything in this area as it’s the part of their stack that’s missing.