Hacker News Reader

Comment by danielvaughn | Hacker News Reader

Why though? WebGL is already getting left behind for WebGPU.

That doesn’t matter at all, I’m talking about investment. Why continue to develop the older API while a new one is already underway? Sorry I just think it’s a waste of time and resources. What is WebGL 2 going to give us that WebGPU isn’t promising to deliver?

They are not mutually exclusive, and organization can invest in developing both. WebGL also has the advantage that it’s immediately useful (lots of sites already using it).

Something that works now and will continue to work for years without changing any code.

To turn this on its head, if I'm creating a new product now, why invest time into an API where by the time the product would be ready with WebGL, instead I chose WebGPU, so now have the risks:

  -  The API is still years away from mainstream.
  -  Doesn't solve anything for my use case that wouldn't be solved with WebGL.
  -  Is too buggy to use on most configurations.
  -  Isn't supported by X hardware or Y OS.
  -  Has security issues that make browsers disable it for years.
  -  The code has to be regularly updated/maintained/fixed when browsers update.
  -  Performance could be lower for low end systems.
  -  Even if everything worked, it's a lot more work to do everything (e.g. VULKAN).
  -  To beat webGL, you have to optimise specifically for mobile/desktop/amd/nvidia/etc
  -  The documentation is poor.
  -  It's impossible to hire an expert in webGPU.
  -  It's very expensive to test every combination of GPU/OS/driver so you have no confidence it is working correctly.

Most rendering code should abstract to many APIs anyway, so not starting with a webgl version would be quite insane.

I'm not talking about today though, my concern is more around future investment. The web has to be backwards compatible, meaning that years from now, browser vendors will be tasked with supporting WebGL 1, WebGL 2, and WebGPU. Given that browsers are already the most complex programs in the world, is the benefit of WebGL 2 so great that it's worth it?

Luckily that cost is fairly small, due to how bad GL drivers were on Windows ages ago Google initiated the LibAngle project that abstracted the GLES parts needed for WebGL(1&2) onto DirectX. With much of the heavy lifting done for API support the code was then adopted as an abstraction for other low-level APIs, so iirc the recent WebGL 2 implementation that now bought us to this stage is also dependent on a fork of that lib that targets Metal. (And yes, it brings us a monoculture implementation but I'd rather have that than dozens of broken mainline OpenGL drivers from Intel, AMD and Nvidia).

It's "mature". So it's well understood, documented, used in libraries, has guides all over the place and relatively few bugs.

It unlocks a number of nice to haves over WebGL 1 which improve usability, quality and performance. As Safari was the last stand out developers can now rely on these things being there.

It's here now. WebGPU has been on the horizon for many years, and probably will be for several more before you can actually expect it to work on users browsers. Presuming we don't end up with a repeat of WebGL 2 on Safari.

It's simpler. Much like DX12, WebGPU is intended to be lower level and have better control over hardware. Which makes it more complex and harder to use Vs WebGL.

It has plenty of community knowledge from OpenGL ES peeps, which makes it quite easy to find examples that can be used.

For anyone actually building this style of content today, this is huge news.

The WebGPU spec itself is not yet confirmed AFAIK. Thus no browser has a stable support.

Right…but OpenGL is being replaced across the industry by modern rendering APIs like Vulkan etc. Isn’t WebGL 2 still based on OpenGL?

So?

Web technologies lag behind desktop technologies for good reasons.

WebGL 2 is based on OpenGL ES 3, which brings it to rough feature parity with a fairly common baseline for GPU APIs that dates back to 2007-2008-ish, the OpenGL 3 / DirectX 10 feature set. This is a pretty good feature set.

The way I see it, browsers are already API-bloated. I just don’t see the justification for further developing a graphics API when another one based on more modern standards is already underway. It’s not like it’s a small effort.

If it took 10 years to achieve widespread webgl 2 support it could take another 10 for webgpu. People want to make web applications today, not plan them for the future.

WebGL 2 was fully developed five years ago. What happened now was Safari finally exposed support, and reused a lot of implementation effort done by Google in the form of ANGLE (which Safari was already using, just not exposing WebGL 2). This was not a from-scratch implementation and development of a new API, it was a collaboration and adoption of an existing API shipped in all other major browsers for years.

The Metal ANGLE backend work done by Apple was a large chunk of work, but a lot of it needed to be done anyway to continue to support WebGL at all on Apple platforms given Apple's deprecation of OpenGL.

> OpenGL is being replaced across the industry by modern rendering APIs like Vulkan etc.

Not always true though.

The target hardware is different between the game industry and the web industry.

Games focus on delivering best graphics with the latest hardware, whereas websites should care about the compatibility first.

Even though modern web browsers auto update, it does not update the underlying hardware. That is, many non-latest smartphones that do not support Vulkan won't support WebGPU neither. We need to wait for years to safely use WebGPU.

WebGPU: https://en.wikipedia.org/wiki/WebGPU

> WebGPU is the working name for a future web standard and JavaScript API for accelerated graphics and compute, aiming to provide "modern 3D graphics and computation capabilities". It is developed by the W3C GPU for the Web Community Group with engineers from Apple, Mozilla, Microsoft, Google, and others. [1]

Reply on news.ycombinator.com