Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebGPU Fundamentals

webgpufundamentals.org

Post reply on HN
Print view View original

201–210 of 211 posts

Re: WebGPU Fundamentals

#201

Post by account42 »

IlliOnato wrote: post #139
2h wrote: post #95

Earlier quoted context omitted.

> 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.

Hmm, RGamma describes reality: it is a fact that web browsers don't purely browse The Web, has been for decades now, and there is zero indication this is going to change. You seem to demand that people ignore this reality, because you don't like it. This is not helpful. I don't like this reality either, but despite that I find your statement also factually incorrect: "native applications have existed for decades, no…

> Of course there are reasons, otherwise people/companies won't do it, and users won't use bloated browser that give them no benefits.

The reason is of course control. Things running in the browser gives Google control. That's why they push for everything running there. Want to compete with Google? Tough luck, no tracking for you while they give themselves IDs built into the browser. Do something Google doesn't like? Maybe your site isn't "safe" enough according to Google and won't be shown to users. Invested in your webapp but want to integrate something novel? Guess who gets to decide if you can?

Re: WebGPU Fundamentals

#202

Post by account42 »

meekaaku wrote: post #187
RGamma wrote: post #153

Earlier quoted context omitted.

I wish it wasn't true either. Seeing a semi-technical acquaintance use in-browser software for daily productive work hurts my programmer's soul. It's alright for some light things, like vacation planning, but remote desktop or an IDE... Then there's that other scourge of Electron-like apps with gigantic memory budgets and all. I have resigned to throwing more hardware at it when I can't guarantee a lighter replacemen…

I think I would rather have a bloated (but reasonably fast and featureful) browser, than clog my computer with native apps for every app out there. Most of the apps doesnt need much power anyway. I really dont want to see a repeat of phone apps for every company I interact with.

Most "apps" including "webapps" shouldn't be interactive programs to begin with but a web of documents you can explore using a tool made to your specifications and noone elses.

Re: WebGPU Fundamentals

#203

Post by account42 »

IlliOnato wrote: post #141
2h wrote: post #96

Earlier quoted context omitted.

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.

Whatever features browsers have, it does not prevent you from writing native tools. But browsers don't limit themselves to serving your needs only, and they are not in the business of promoting your approach to computing among their users. Why would they?

But it does prevent the browser from excelling at their original purpose: To browse the web.

One example of many: Backspace no longer taking your to the previous page because that conflicts with usage in web apps.

Re: WebGPU Fundamentals

#204

Post by account42 »

Cloudef wrote: post #102
mpldr wrote: post #19

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.

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.

Re: WebGPU Fundamentals

#205

Post by account42 »

mpalmer wrote: post #109
mpldr wrote: post #19

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.

In the age of app stores and notarized binaries, anything that makes the browser non-trivially more competitive with native apps is defensible.

And you think your webapp is safe from those kinds of requirements? Not when one company runs the show.

Re: WebGPU Fundamentals

#206

Post by account42 »

ReptileMan wrote: post #51
mpldr wrote: post #19

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.

The more of this features in the browsers - the sooner the stranglehold of the app stores could be broken

Or you will just find yourself in the domain of a new lord.

Re: WebGPU Fundamentals

#208

Post by Cloudef »

account42 wrote: post #204
Cloudef wrote: post #102

Earlier quoted context omitted.

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.

Yes until it doesn't or vulkan implementation is considered as second class citizen. Been there seen that. The other thing is that webgpu is slightly higher-level so you do not have to go into extremes with memory handling and synchronization as in vulkan. So unless you absolutely need to squeeze everything out, webgpu gives nice balance.

Re: WebGPU Fundamentals

#209

Post by MikeSchurman »

chefandy wrote: post #194
MikeSchurman wrote: post #105

Earlier quoted context omitted.

I'm not sure if these are examples of dropped support, but I run into issues on websites that prevent me from doing something I really need to do: - I could not unsubscribe from amazon prime yesterday using firefox. The page where you select the option was not rendering correctly. It was white for half the page vertically and the link/button I need to press was absent. - about 6 months ago I could not sign into apple…

In my experience, problems like that are almost always a matter of cookie/cache sticking around when it shouldn't or plugin interference. The only sites I ever have have blocking trouble with in FF are shitty web interfaces for local device configuration, old automatically generated webpages like from MS Access or some other super old enterprise abomination. I worked on a team of web developers that generally develop…

Yeah that could possibly be it. If I run into again I could try clearing caches. And also wanted to mention that since firefox is what I use daily, of course I will mainly see issues there.

If I used chrome daily perhaps I would see the opposite (broken on chrome, works on firefox).

I get the same feel from DuckDuckGo. I use it, till it doesn't work, then switch to google when it doesn't. Of course google would perform better, as I only use it for the cases where DDG fails.

Re: WebGPU Fundamentals

#210

Post by zx8080 »

kajaktum wrote: post #177
zx8080 wrote: post #175

Earlier quoted context omitted.

It's sad that there are specific browser-oriented websites (and development processes, obviously) instead of the standards-oriented ones. (Sure, it's Chrome-oriented ones. We've seen similar previously with IE, by the way.) We have standards for the web. Real ones: the docs, which are discussed and approved in the industry. We have them for a long time! So if some browser does not comply to the standards, it's really…

Having a standard is not even possible technically when you have 1 player that is too good. Due to Hyrum’s Law, any small divergence from the spec will be observed and relied on. Why would you work against the spec which is nebulous, when you could be testing against 99% of what your user use?

> ...when you have 1 player that is too good.

It's not too good. It's just wealthiest. Because it holds ads market monopoly. Because it happens to be the popular search engine at the same time.

But it's not the best. Firefox is on par (I know they get some (most?) payments from Alphabet). And people were using Firefox/Netscape browser long before Google existed.

Post reply on HN