Hacker News Reader

Comment by avaer | Hacker News Reader

GLSL. Makes sense as the breezy path, but it seems WebGL2 is a dead evolutionary branch, even if it can be transpiled over.

What are your thoughts on supporting other languages? Or did I miss that in the docs?

View on HN

It isn't a dead end when WebGPU failed at all their graphics performance promises for being better than it in every way.

I was speaking more to the willingness of vendors to support. It's debatable how well WebGL(2)/WebGPU are designed and especially implemented. But it does seem like most evolutionary features, if they make it to browsers at all, would come from the WebGPU path. Not saying the reasons for that are good.

Underrated comment. Our industry is littered with business choices made over technical ones that crippled or otherwise enshittified products.

But the technical is entirely subservient to business concerns, or else what's the point?

Sometimes that's true, like at work.

If you're talking about open source projects or decisions by some consortium, that's not always true...or at least one business is pushing their concerns at the expense of others.

An easily remembered example is what happened (at least from Pieter Hintjens' perspective, as he wrote/complained at length about) between AMQP 0.9.1 and 1.0

What part of WebGPU isn't meeting graphics performance? AFAICT it's only people who continue to treat it like WebGL. It's like C++ programmers complaining Rust is slow and then Rust programmers say "stop using it like C++". If you want perf in a low-level API liek WebGPU you have to work with it using patterns that fit. If you stick to your WebGL patterns then yea, your app will suck.

A simple PBR shader on a mobile device. Anything that is basic graphics without crazy things like 10,000 lights.

Reply on news.ycombinator.com