It should enable much more performant (and battery friendly) 3D content on the web. WebGL has a level of synchronization in the main render loop of the browser that is just not the right way to do it, and WebGPU fixes that.

Additionally it is more suited to GPU based compute, which can be used to accelerate neural network inferencing, though not quite as well as dedicated NN accelerators which are fairly common these days.

I would tend to agree that the business case for these things is not as strong as many would like though, and things have a distinct habit of ceasing to be interesting the moment they are widely achievable.

So there’s no real use case. Got it.

There is a very clear use case in the first sentence of their comment though?

Unless your stance is that WebGL itself had no real use case, which is just silly.

Why does a web page need GL?

I don't know, ask any online maps site.

Or, say, literally any number of e-commerce sites that give the user an interactive and/or customisable view of products and not just static imagery.

Or, say, any number of pages that embed complex data visualisations.

"Why does a graphical UI platform need performant graphics" is an incredibly tautological question.

It's likely to become the best way to run cross-GPU-platform gpu code in the medium term

That already existed via middleware engines.

such as?

Do you mean the clusterfuck that is matching carefully your compiler, ID, hardware, instruction set architecture, incompatible dependency versions, installers, package managers, etc.?

So far, WebGPU was the first and only time that I was able run Stable Diffusion on my own hardware.

https://websd.mlc.ai/

Unity, Unreal, Ogre3D, Open3D, Godot, Stride, Defold,....

Assuming you want to use 2024 hardware features in 2024.

These are game engines. What if I want to run GPGPU code in a cross platform way?

They didn’t say it would be the only way, just that it would be the best way

I feel like WebGPU actually holds some amount of promise as a cross-platform convenience. I'd agree that there's not a great reason to update your native code for this right now though.

If you're writing new gfx code though and are more familiar with web technology, there's definitely utility there. That's the bigger value prop: that people with web development skills can work on more pro (GPU-required) applications.

Perhaps it can be used to avoid the outrageous 30% app store fees.

"trying to replace native code with web pages? "

No one wants that. But many like to write their apps only for one plattform - and then still have them run allmost everywhere.

The web is the best we have to achieve this. And this will greatly improve the possibilities.

Edit: My app will soon finally use no more html elements. It is not a "webpage".

> No one wants that.

I very much do want that since the WebGPU API is far easier and nicer to use than Vulkan or OpenGL. Also, it makes apps much more accessible to distribute them over web, and it is much more secure to use web apps than native apps. Unfortunately WebGPU is way too limited compared to desktop APIs.

You say no one wants that, then you describe doing exactly that.

If your “app” runs in a browser window—a window presented by a browser engine—it’s fundamentally a web page. (They’re two distinct words.)

I .. hate those pedantic discussions. But here you go: a web page by common understanding is mainly something to look at. Page implies document. A web app is a bit more. (And many tech people hate it, that browsers can do more)

So no, I do not want to replace native code with a web page. But in some cases with web apps.

Can you have an electron app without HTML elements? A pure WebGPU + Webassembly program?

YEah, but why wouldn't you want HTML CSS to render your ui.

I'm going to revisit electron / nw.js for games again this year. Last time I tried 4-5 years ago I could not get smooth animation with request animation frame.

Performance.

I recommend pixijs.

But it depends what you do, smooth animations of some elements is possible with html. But in my case it got complex and html was the bottleneck. Now I have the same assets in Pixi and it runs around 100× faster. No more lags, no stuttering. No more html.

(Allmost, some static content is still HTML, but that is fine, as long as the DOM does not get modified)