It's not a criticism. I'm just pointing it out. For good or bad, it is what it is. There are two sides to it. For anyone familiar with system theory, this was the inevitable end game of the web.

However, the web also has a terrible bloat/legacy issue it refuses to deal with. So sooner or later, a new minimal platform will grow from within it, the way the web started in the 90s as the then humble browser. And the web will be replaced.

I think we've already seen the first shoots from that nascent new system: https://webassembly.org/. And this hilarious talk will continued to be viewed by future generations for marking the 2013 inflection point: https://www.destroyallsoftware.com/talks/the-birth-and-death...

I had great expectations of WASM, and maybe it can evolve into what we're discussing. But as it is, this system is too limited in two crucial ways.

First, it's explicitly designed to be easy to port existing software to. Like C libraries, say. Sounds good right? Well, it's not designed as a platform that arose from the needs of the users, like the web did. But the need of developers porting software, who previously compiled C libraries to JS gibberish and had to deal with garbage collection bottlenecks etc. This seems fairly narrow. WASM has almost no contact surface with the rest of the browser, aside from raw compute. It can't access DOM, or GPU or anything (last I checked).

Second, for reasons of safety, they eliminated jumps from the code. Instead it's structured, like a high-level language. It has an explicit call stack and everything. Which is great, except this is a complete mismatch for all new generation languages like Go, Rust etc. which focus heavily on concurrency, coroutines, generators, async functions etc. Translating code like that to WASM requires workarounds with significant performance penalty.

WASM can access the GPU via middle layers like SDL. I.e. you can write a C program that uses opengl and compile it and as long as you include the right flags etc into `emcc` you will barely need to touch or glue it together on the JS side at all.

All those go through JS as far as I'm aware. Emscripten bridges everything for you, but technically it goes through JS so SDL's calls also go through JS.

You're correct but I don't see why that matters. From your perspective as a C coder you get webgl access without having to write JS, that's what's important. Everything is "mixed together" into asm in the end anyway whether it's glue code in JS or browser side glue code.

I for one am very happy for it. The promise of Java “write once, run anywhere” is mostly realized now. Now all we need is the browser to ship with interpreted language runtimes and language native bindings to DOM, GPU etc.

Its not a criticism that this is neccesary, its a criticism that it is possible to even do this in a browser.

But why is that a criticism? I tried running SD on my computer a few months ago. I spent several hours trying to install the dependencies and eventually gave up. I'm sure it wouldn't have been a big deal for someone familiar with python but for me it was a massive hassle and I eventually failed to make it run at all.

For this one, as long as my browser supports WebGPU (which will be widely supported soon) and I have the system resources, it will run. Barely any technical knowledge needed, doesn't matter what OS or brand of GPU I have. Isn't that really cool? It reduces both technical and knowledge based barriers to entry. Why do people criticize this so strongly?

After seeing the sort of argument you are replying to countless times on HN, I came to a simple conclusion. Some people, esp on HN, just have disdain for anyone who might not be willing to deal with the hubris of running a piece of software, because it invites "lower common denominator", and they don't want to "taint" their hobby by the presence of "normies" in what used to be their exclusive domain.

In a similar vein, you can find plenty of comments on HN faulting the massive proliferation of smartphones among the general population throughout 2010s for "ruining" web, software ecosystems, application paradigms, etc. There are plenty of things one could potentially criticize smartphones for, and some of that criticism indeed has merit. But this specific point about "ruining" things feels almost like a different version of the same argument above - niche things becoming widely adopted by the masses and "ruining" their "cool kids club."

Another similar example from an entirely unrelated domain - comic books and their explosion in popularity after Marvel movies repeatedly killing it in the box office. I don't even like Marvel movies, barely watched any of them, but the elitism around hating things becoming more popular is just silly.

That's a pretty weird conclusion to draw.

The objection (more surprise than objection) is that web browsers are supposed to be sandboxed environments. They are not supposed to be able to do things that negatively impact system performance. It is surprising you can do things involving multi-gb of ram in a web browser. It has nothing to do with what you are using that ram for or if its cool or not.

I dont think anybody has an objection to making it easier to run stable diffusion and i think the only way you could come to that conclusion is intentionally misunterpreting people's comments.

> The objection (more surprise than objection) is that web browsers are supposed to be sandboxed environments. They are not supposed to be able to do things that negatively impact system performance.

I agree with the sandboxing model, but it is orthogonal to WebGPU and impacting system performance. Sandboxing is about making the environment hermetic (for security purposes and such), not about full hardware bandwidth isolation.

First, there is no way for web browsers to have no system performance impact whatsoever. Browsers already use hardware acceleration (which you can disable, thus alleviating your WebGPU concerns as well), your RAM, and your CPU.

Second, afaik WebGPU has limits on how much of your GPU resources it is allowed to use (for the exact purpose of limiting system performance impact).