It's a pity that tfjs never truly developed any decent ops. E.g. you need lgamma to implement the cap for zero-inflated poisson regression and tfjs simply doesn't have that: https://github.com/tensorflow/tfjs/issues/2011
Those guys simply dropped the ball on the floor, and the further framework development fizzled out.
I tried to find if WebGPU could be a replacement, but it's very hard to find a good description of the API surface. MDN also doesn't seem to help much – https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API
I really hope that one day I'll find something similar to pytorch, only in typescript. Tell me I'll live long enough to enjoy that day.
Exactly, the lack of the deep learning frameworks to train decent models on the client side forces us to use pytorch on the server, leading to centralized data collection, privacy concerns, copyright and data ownership issues.
Imagine the world where you could trivially train a model entirely on the client side, without uploading all that data to the cloud. Then we can settle on federated learning or simply use ensembles of models trained on different clients, all without sharing data with the server.
This looks heavily geared towards graphics. I’m interested in the compute capabilities of WebGPU to build an in-browser simulator (e.g. physics/quantum). Anyone know of any good resources for that? (Samples, best practices, etc.)
I think Steven Wittens’s work at acko.net and https://usegpu.live/ is your best bet here. I’ve been working for a couple of years on building a computer algebra / physics system in Clojure and integrating it with Steven’s previous work on MathBox, with some in-progress demos like this:
Use.GPU looks like it will be close to a drop-in replacement for MathBox, running on WebGPU. Maybe someday I’ll actually be able to build my general relativistic ray tracer, with explorable symbolic physics all the day down…
Fragment shaders can only go so far. Can you do in webgpu something like this?
outputTexture2d[inputTexture2d[inputPosition]]++
In other words, if you have a large texture with (x,y) coordinates of points, can you draw another texture that shows a density cloud of these points? In webgl2 it becomes a phd level problem.
Total graphics / shaders / GPU noob here. Does that mean you'll essentially get free visualisations (albeit non-sensical ones) as a byproduct of your computations?
The WebGL equivalent sites were a delight to go through; So well structured and thoughtfully displayed. It's so great to find a resource you can put some trust in amongst all the outdated and fragmented code out there.
Looking forward to ploughing through this when I have the free time to.
Question for discussion: when have we reached the point where the Browser Feature-creep is too much and we say "okay, a browser probably doesn't need this"? Because after seeing WebUSB and WebGPU I think my personal limit has been reached.
> Because after seeing WebUSB and WebGPU I think my personal limit has been reached.
Sure, but where do you draw the line really? For me, having WebUSB and WebMIDI for example is useful, I want to be able to interact with synths over MIDI in the browser, or be able to access other accessories. I also love the idea of GPU access, so my personal limit has not been reached.
Multiply this by every vendor, developer and user of every browser who contributes to the specifications, and you end up with probably 1000 different directions everyone wants to move in. How do you decide which is the right direction?
Right now, the choice you have is which browser you use. If you don't want WebUSB or WebGPU or anything else "new and fancy", choose a browser that doesn't implement those things.
Browsers are just “standardised” OS at this point. Really, what is the difference? It seems to me that people basically wants a 1 to 1 mapping between every OS feature to browsers. I wouldn’t be surprised if this standard will fall apart in the next decade once Chrome runs everything. That is to say Chrome is the standard. I am already seeing websites drop support for Firefox and won’t even load using it.
I want to be able to interact with synths over MIDI in the browser
Help me understand why this is. Is it because there aren't native programs for the platform you're using? Is it to allow plug-ins or other abilities that wouldn't otherwise be available? Is it so that you can sync up with other musicians and play together in a way that wouldn't be possible without a browser?
choose a browser that doesn't implement those things.
The way feature creep have been going lately, in about six months that will mean Lynx.
I'm not going to argue against these features, but I find that last argument you raise to be a rather dull and useless one. Yeah, I'll just go ahead and pick from one of the hundreds of competing implementations to find one that doesn't. Oh, wait, they don't exist.
It's like saying "if you don't like the laws(/taxes/whatever) where you live, go somewhere else" and acting as if I can just hop on over to Mars. I can't.
WebUSB was actually useful to me not long ago. I installed Home Assistant and its ESPHome[1] companion, and ESPHome had support for using WebUSB to upload the firmware to a blank ESP8266 I had. I didn't have to install or set up anything on my Windows machine, and the whole process was very quick and convenient.
It seems clear to me that the main issue here is that a lot of programs aren't closely tied to the hardware or the OS. Building them to be so is an annoyance for both users and developers. As Scott McNealy said, you don't need to know how to operate a nuclear power plant to turn on the lights, and most users just want to get stuff done.
That we have three major operating systems still going relatively strong is evidence that there are differences that matters to people. But for a lot of applications those differences don't. The WebXYZ stuff thus increases usability a lot by simultaneously solving the cross-platform compatibility issues and distribution.
In my ESPHome example above literally opened the website, plugged in the USB cable to my device, clicked a button on the web page and the job was done.
So while I don't really like that the same web browser is used to surf other web sites, given that these WebXYZ components present additional security risks and fingerprinting opportunities, I can't deny that they're useful.
I had a similar pleasant experience with a Wooting 60HE keyboard I purchased recently. Updated my keyboard’s firmware and settings right in Chrome! So much nicer than downloading icky gaming peripheral software. I’ve been told a lot of that stuff is borderline spyware.
Excited to try it out with some ESPHome projects too now.
The issue of the Web's lack of distinction between document viewing features and being an application platform (with access to system resources and private data) is decades old. Unfortunately, the question has been academic for decades as well: before the advent of HTML5, proprietary browser plugins gave Web sites the same abilities (ActiveX and Flash being notable, as were their security vulnerabilities). Flash was ubiquitous circa 1998-2008; your typical user would always have it installed. Nor did the typical (non-techie) user know that the Web was not originally intended to be an application platform, or the implications of it being used as such.
Free yourself from the notion that a web browser purely browses The Web.
It's nowadays also a cross-platform insta-deployment GUI application runtime environment with mostly bad native OS integration and performance characteristics (both ~improving, there's even native filesystem access now).
> Free yourself from the notion that a web browser purely browses The Web.
Free yourself from the notion that a web browser should do anything more than browsing the web. native applications have existed for decades, no reason to bloat the scope of a browser.
Why does it bother you that browsers have many features? At this point browsers are essentially a cross-platform VM and it really seems like this trend will only accentuate in the future.
Those are the main reasons. And seeing how browsers are essentially designed to run other peoples code with minimal to no vetting processes, I consider this a serious issue.
because I want limited scope tools. if I want something on the GPU, I can just write a native tool. I dont need the browser to do anything beyond web browsing.
WebPSU - this will allow your browser to directly access your computer's power supply. simply plug your appliances into your browser and they can use the same power that your computer has access to.
Who's the royal we here? It's great that you have personal limits. But why should "we" care about those?
Seems like a perfectly reasonable new feature to me. I'm actually looking forward to people using this to build some cool stuff. Why should that not be a thing?
WebGPU in browser isn't really interesting to me. But I do like WebGPU in native applications, as we are yet again in scenario where Windows prefers DX, OSX their own Metal and Vulkan is yet again mostly linux only player, and popular WebGPU implementations have backends to all of these (+ more).
Windows supports Vulkan just fine. People use DX because of Xbox and tooling - the existence of yet another API won't change that. And neither will WebGL be better on macOS than MolenVK.
Yep. I just read through the entirety of this guide specifically to better understand Mach, which uses Google's WebGPU implementation for everything graphics-related.
I think of the browser as another kind of OS, and as Microsoft keeps making their OS worse the browser is a nice reprieve. The more that goes into the browser the more I can ditch Microsoft and hopefully be rid of it all together.
Though ironically maybe given that the browser can do so much is the reason that Microsoft has to focus on ‘value add’ crap instead of just a rock solid OS. Which sets up a self reinforcing cycle. Microsoft should recognize that this was intentional move by Google and not take the bait.
I think one of the main drivers of new browser features is ChromeOS. Manufacturers are selling a lot of Chromebooks, especially to schools, and because ChromeOS is primarily a conduit for running Chrome, the best way to add features to Chromebooks is by adding to the browser. From Google's point of view, anything ChromeOS needs is a candidate for a new browser feature.
the more important question is whether the browser's surface area for bugs and perhaps security vulnerabilities are worth the marginal increase in features that most people might not use!
Why exactly would programs running in web browsers not want the ability to access the most powerful piece of hardware in a users machine? WGPU unlocks an enormous amount of space for userland programs to explore.
I agree there have been some questionable 'advancements' in the web spec recently (web workers as a solution to multithreading, for example, were hilariously inadequate for quite a while), but as far as I can tell WGPU is a solid effort to unlock browsers as an actually interactive platform, instead of the fairly static image/text display devices they are today.
Maybe our visions of what browsers could or 'should' be are different
At least for me a browser should be an interactive document viewer. Not CAD, not file conversion, not writing OS images to an SD card, not generating GCode. Ingesting HTML, CSS, and JS and turning it into an interactive view of that XML document nothing more, nothing less.
I tend to feel that way mainly towards new features that are very similar to ones that already exist. eg. WebGPU being a more advanced form of WebGL. Yes they work differently, but they generally solve the same problem.
Eventually I'd like to see WebGL deprecated, and perhaps an extension released to reimplement it. Or it could be adapted to translate calls to WebGPU, rather than having a completely separate implementation.
Is that realistic? No, of course not. Browser vendors take backwards compatibility pretty seriously, and WebGL is used on a ton of websites. Still, that'd be my preferred solution for avoiding said feature creep.
How do I render text with GPU? Do I render text on texture with CPU and then send that texture to GPU? Do I vectorize it and draw millions of tiny triangles to approximate those vectors? It's interesting for me to explore WebGPU as a canvas for app development, but it's not obvious to me how to draw text and text is everywhere.
One of the most exciting features of WebGPU, especially over WebGL, is the ability to run compute shaders. That opens up an entire class of 2D vector graphics rendering techniques using compute shaders, including Vello. It's still in early stages, but the current code does include text rendering. There's a very rough demo at https://levien.com/vello-demo (the demo doesn't do variable fonts but the code can), and we'll be polishing that in time for Chrome M113 going stable.
Most web games use the dom as a layer over top of the 3D canvas and then use 3D to 2D projections to align the elements. This allows you to use regular HTML and CSS for a lot of text elements.
Also, you can render and rasterize fonts + dynamic text to a texture and UV map it to a quad in 3D space if you need to. This is pretty inexpensive and easy to do as well.
Lastly, the most difficult but performant option is using a shader to compute the font rendering. This is basically moving the font raster from CPU to GPU and there are various shader examples for this in GLSL (popular shader format used by WebGL/OpenGL) that you can use.
From personal experience, if you're trying to make a game that cares about its frame rate, do not ever use the DOM for anything, ever. It routinely takes several frames to layout a single absolutely positioned element.
I recommend the second option. Rasterize your font with stb_truetype to a bitmap, and draw quads yourself
The easiest is just to use a html canvas element and draw text to it and then upload that as a texture map. This can handle kerning, ligatures, emojis, different fonts and languages. Writing your own font layout tool is horribly difficult and only do it if you must.
If you have a couple of different sizes of texts you can render out each character into a sprite map and render a quad per character which is probably the fastest and works for most 2D UIs. You can prerender ahead of time or have some runtime code that renders the characters with a given font using the 2D canvas api. You will need also need to store the characters sizes somewhere unless it’s a monospace font
If you need to scale the text arbitrarily or render it in 3D space you can look at multi channel signed distance fields (MSDF) which also renders out each character but encodes some extra data which makes them scalable. It has pretty good results
It depends on the quality and performance requirements, but you are basically on your own (e.g. the browser's integrated text rendering won't be of much help unfortunately - at least if performance matters). You need to bring your own font data and 'pre-rasterize' glyphs either on the CPU or GPU into a font cache texture, or render directly on the GPU using an approach like Slug or Pathfinder.
Of course there's also always the option to overlay DOM elements over the WebGPU canvas if you just want to render some 2D UI on top of the 3D rendering.
Note that this approach is useless on its own if your app needs to render user-created text because nowadays everybody expects emojis to work and look roughly the same as on Apple’s platforms, which means detailed multi-colored layered vector shapes that SDF font renderers can’t handle.
> Do I vectorize it and draw millions of tiny triangles to approximate those vectors
That is becoming feasible, using something called mesh shaders. The millions of tiny triangles will only be created on the fly inside the GPU, you will just send the vector geometry.
This is true, but there is a lot more to the story. For one, WebGPU does not (yet) support mesh shaders, though it may later as an extension. For two, consider a glyph such as "o" that has two contours. Real triangulation generates a mesh that only generates triangles between the outer and inner contours, and mesh shaders aren't good at that. There are techniques compatible with mesh shaders (cover and stencil) that draw twice, incrementing and decrementing a winding number stored in the stencil buffer (see contrast renderer[1] for a clean modern implementation), but it does require nontrivial tracking on the CPU side, and can result in lots of draw calls to switch between the cover and stencil stages unless sophisticated batching is done. (The outer contour is drawn as a disc with winding number +1, and the inner contour is drawn as a smaller disc with winding number -1, so the inner part ends up as 0)
Compute shaders avoid all these problems and work on WebGPU 1.0 today.
You could convert the paths in a font file into a series of triangles using some vertices as a control points for quadratic bezier curves. Then some code for laying out the glyphs in a line. Much of this could be done on a shader I think.
This is great! I have been meaning to get more into WebGPU!
One question: Does anyone know more details about the Firefox WebGPU story? Even on this site's homepage, if you access it from Chromium with WebGPU enabled, you get nice floating rotating triangles, if you access it from Firefox stable, you get, understandably, static triangles. But if you access from Firefox nightly, with WebGPU enabled, you get a dark background and the error:
TypeError: navigator.gpu.getPreferredCanvasFormat is not a function
You can probably use "bgra8unorm" where getPreferredCanvasFormat isn't available, that seems to be the preference for at least Blink and WebKit.
Chrome doesn't support rgba8unorm on Mac, probably because Apple seems to have chosen bgra8unorm as their format for their Metal API for some reason, so you'll have to use BRG rather than RGB if you want to support Apple hardware at the moment.
Regarding all the arguments about ever-increasing browser complexity and the resulting inefficiency:
Why is nobody asking the reverse question: How to make operating systems more like browsers??
From the end user's PoV (consider someone who isn't computer savvy) what are the actual objective differences in usability, between the OS and browser?
--
• OS: Apps have their own windows and menu bars.
• Browser: Multiple apps run in a single window, and have no menu bar.
-
• OS: Need to download and "install" apps before you can use them.
• Browser: Just type the app's "name".
-
• OS: Need to make sure apps are compatible with your OS and hardware. Need to keep apps updated. Need to delete apps when out of local storage space.
• Browser: Nope.
-
• Browser: Lets you share links with people to show them exactly what you're seeing in an app (YouTube, HN, Reddit)
• OS: Nope.
--
SO. Instead of constantly reinventing the wheels that have been perfected by operating systems for centuries, and then machete'ing through the resulting struggles of power and politics between the OS and browser,
All of this is perfectly possible. End users don't seem to want to use these features for native apps for some reason, though, and developers seem to have all switched to the web instead of building native experiences.
It makes sense: native apps need to be developed for Windows, macOS, Android, iOS, and maybe Linux. Web apps need to be developed once. Android apps will work on Android, ChromeOS, Linux (after some setup), and Windows, but I doubt Apple is going to add an Android runtime to their platform any time soon.
App stores are on every major platform and custom URIs for sharing app state and views are implemented on phones already. Most people seem to run their desktop applications either full screen or nearly full screen. Pin the Windows task bar to the top of the screen and you've basically got yourself a tab bar. I don't know about macOS, but Android and Windows will start clearing caches and temporary files automatically under storage pressure. Sandboxing applications is available on all platforms as well.
I don't want every website to become a native application, though. I don't trust most websites enough to download native code from them. Let's not go back to the ActiveX/Java applet days where you needed to download some scary code for every website you wanted to visit.
I don't see why I would benefit from WebGPU support, I think I'll leave it disabled by default. It's probably one of those technologies that'll be useful for platforms with overbearing control (i.e. how game streaming on iOS is made possible). Maybe some small itch.io games will make use of it so I don't need to download Some Guy(TM)'s native executable every time I want to try a small experimental game.
The better question is do we even need so many apps to begin with? Do we need YouTube, Dailymotion, TikTok, Vimeo all to be their own app? Or should they all just use the something like NNTP but for video sites?
I have been trying to add WebGPU support to https://www.fciv.net - however the Three.js 3D engine I'm using isn't ready for WebGPU yet, and no current browsers support WebGPU yet.
The Three.js people have been working on WebGPU support for several years now. I'm not how far they've got but there were already some cool demos a year or more ago.
Readit News
There are also several ONNX runtimes using WebGPU in case you want to run models written with PyTorch.
Imagine the world where you could trivially train a model entirely on the client side, without uploading all that data to the cloud. Then we can settle on federated learning or simply use ensembles of models trained on different clients, all without sharing data with the server.
BTW, I did have some experience with ONNX, also ran into problems with some ops (like nn.SELU not working correctly in the browser - https://pytorch.org/docs/stable/generated/torch.nn.SELU.html...).
https://emmy-viewers.mentat.org/dev/examples/simulation/quar...
https://emmy-viewers.mentat.org/dev/examples/simulation/toro...
Use.GPU looks like it will be close to a drop-in replacement for MathBox, running on WebGPU. Maybe someday I’ll actually be able to build my general relativistic ray tracer, with explorable symbolic physics all the day down…
outputTexture2d[inputTexture2d[inputPosition]]++
In other words, if you have a large texture with (x,y) coordinates of points, can you draw another texture that shows a density cloud of these points? In webgl2 it becomes a phd level problem.
Looking forward to ploughing through this when I have the free time to.
Sure, but where do you draw the line really? For me, having WebUSB and WebMIDI for example is useful, I want to be able to interact with synths over MIDI in the browser, or be able to access other accessories. I also love the idea of GPU access, so my personal limit has not been reached.
Multiply this by every vendor, developer and user of every browser who contributes to the specifications, and you end up with probably 1000 different directions everyone wants to move in. How do you decide which is the right direction?
Right now, the choice you have is which browser you use. If you don't want WebUSB or WebGPU or anything else "new and fancy", choose a browser that doesn't implement those things.
Help me understand why this is. Is it because there aren't native programs for the platform you're using? Is it to allow plug-ins or other abilities that wouldn't otherwise be available? Is it so that you can sync up with other musicians and play together in a way that wouldn't be possible without a browser?
choose a browser that doesn't implement those things.
The way feature creep have been going lately, in about six months that will mean Lynx.
It's like saying "if you don't like the laws(/taxes/whatever) where you live, go somewhere else" and acting as if I can just hop on over to Mars. I can't.
It seems clear to me that the main issue here is that a lot of programs aren't closely tied to the hardware or the OS. Building them to be so is an annoyance for both users and developers. As Scott McNealy said, you don't need to know how to operate a nuclear power plant to turn on the lights, and most users just want to get stuff done.
That we have three major operating systems still going relatively strong is evidence that there are differences that matters to people. But for a lot of applications those differences don't. The WebXYZ stuff thus increases usability a lot by simultaneously solving the cross-platform compatibility issues and distribution.
In my ESPHome example above literally opened the website, plugged in the USB cable to my device, clicked a button on the web page and the job was done.
So while I don't really like that the same web browser is used to surf other web sites, given that these WebXYZ components present additional security risks and fingerprinting opportunities, I can't deny that they're useful.
[1]: https://esphome.io/guides/getting_started_hassio.html
Excited to try it out with some ESPHome projects too now.
It's nowadays also a cross-platform insta-deployment GUI application runtime environment with mostly bad native OS integration and performance characteristics (both ~improving, there's even native filesystem access now).
In any case it's Good Enough (C), so it sticks.
Free yourself from the notion that a web browser should do anything more than browsing the web. native applications have existed for decades, no reason to bloat the scope of a browser.
edit: wow, I had no idea and I've been a web dev for over a decade lol
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=webkit
Those are the main reasons. And seeing how browsers are essentially designed to run other peoples code with minimal to no vetting processes, I consider this a serious issue.
Every new feature is more space for security issues to exist.
Seems like a perfectly reasonable new feature to me. I'm actually looking forward to people using this to build some cool stuff. Why should that not be a thing?
Though ironically maybe given that the browser can do so much is the reason that Microsoft has to focus on ‘value add’ crap instead of just a rock solid OS. Which sets up a self reinforcing cycle. Microsoft should recognize that this was intentional move by Google and not take the bait.
Deleted Comment
I agree there have been some questionable 'advancements' in the web spec recently (web workers as a solution to multithreading, for example, were hilariously inadequate for quite a while), but as far as I can tell WGPU is a solid effort to unlock browsers as an actually interactive platform, instead of the fairly static image/text display devices they are today.
Maybe our visions of what browsers could or 'should' be are different
Eventually I'd like to see WebGL deprecated, and perhaps an extension released to reimplement it. Or it could be adapted to translate calls to WebGPU, rather than having a completely separate implementation.
Is that realistic? No, of course not. Browser vendors take backwards compatibility pretty seriously, and WebGL is used on a ton of websites. Still, that'd be my preferred solution for avoiding said feature creep.
Deleted Comment
https://github.com/atrosinenko/qemujs
https://jamesfriend.com.au/pce-js/ibmpc-games/
https://leaningtech.com/webvm-server-less-x86-virtual-machin...
and so on...
The OS runs on hardware, what do you think is below the OS you're running?
Deleted Comment
Dead Comment
We could have had them three years ago.
Also, you can render and rasterize fonts + dynamic text to a texture and UV map it to a quad in 3D space if you need to. This is pretty inexpensive and easy to do as well.
Lastly, the most difficult but performant option is using a shader to compute the font rendering. This is basically moving the font raster from CPU to GPU and there are various shader examples for this in GLSL (popular shader format used by WebGL/OpenGL) that you can use.
I recommend the second option. Rasterize your font with stb_truetype to a bitmap, and draw quads yourself
If you need to scale the text arbitrarily or render it in 3D space you can look at multi channel signed distance fields (MSDF) which also renders out each character but encodes some extra data which makes them scalable. It has pretty good results
Of course there's also always the option to overlay DOM elements over the WebGPU canvas if you just want to render some 2D UI on top of the 3D rendering.
That is becoming feasible, using something called mesh shaders. The millions of tiny triangles will only be created on the fly inside the GPU, you will just send the vector geometry.
Compute shaders avoid all these problems and work on WebGPU 1.0 today.
[1]: https://github.com/Lichtso/contrast_renderer
One question: Does anyone know more details about the Firefox WebGPU story? Even on this site's homepage, if you access it from Chromium with WebGPU enabled, you get nice floating rotating triangles, if you access it from Firefox stable, you get, understandably, static triangles. But if you access from Firefox nightly, with WebGPU enabled, you get a dark background and the error:
You can probably use "bgra8unorm" where getPreferredCanvasFormat isn't available, that seems to be the preference for at least Blink and WebKit.
Chrome doesn't support rgba8unorm on Mac, probably because Apple seems to have chosen bgra8unorm as their format for their Metal API for some reason, so you'll have to use BRG rather than RGB if you want to support Apple hardware at the moment.
Why is nobody asking the reverse question: How to make operating systems more like browsers??
From the end user's PoV (consider someone who isn't computer savvy) what are the actual objective differences in usability, between the OS and browser?
--
• OS: Apps have their own windows and menu bars.
• Browser: Multiple apps run in a single window, and have no menu bar.
-
• OS: Need to download and "install" apps before you can use them.
• Browser: Just type the app's "name".
-
• OS: Need to make sure apps are compatible with your OS and hardware. Need to keep apps updated. Need to delete apps when out of local storage space.
• Browser: Nope.
-
• Browser: Lets you share links with people to show them exactly what you're seeing in an app (YouTube, HN, Reddit)
• OS: Nope.
--
SO. Instead of constantly reinventing the wheels that have been perfected by operating systems for centuries, and then machete'ing through the resulting struggles of power and politics between the OS and browser,
WHY NOT REMOVE THOSE HURDLES FROM THE OS?
It makes sense: native apps need to be developed for Windows, macOS, Android, iOS, and maybe Linux. Web apps need to be developed once. Android apps will work on Android, ChromeOS, Linux (after some setup), and Windows, but I doubt Apple is going to add an Android runtime to their platform any time soon.
App stores are on every major platform and custom URIs for sharing app state and views are implemented on phones already. Most people seem to run their desktop applications either full screen or nearly full screen. Pin the Windows task bar to the top of the screen and you've basically got yourself a tab bar. I don't know about macOS, but Android and Windows will start clearing caches and temporary files automatically under storage pressure. Sandboxing applications is available on all platforms as well.
I don't want every website to become a native application, though. I don't trust most websites enough to download native code from them. Let's not go back to the ActiveX/Java applet days where you needed to download some scary code for every website you wanted to visit.
I don't see why I would benefit from WebGPU support, I think I'll leave it disabled by default. It's probably one of those technologies that'll be useful for platforms with overbearing control (i.e. how game streaming on iOS is made possible). Maybe some small itch.io games will make use of it so I don't need to download Some Guy(TM)'s native executable every time I want to try a small experimental game.
https://threejs.org/examples/?q=webgpu