There's not that much boilerplate actually. Much less than in Vulkan. WebGPU abstracts away memory management, synchronization and image transitions, which make up for a lot of boilerplate code in Vulkan (and easy to get wrong). The WebGPU hello world code is not that much longer than equivalent OpenGL 3.x code, however it is a more strict API and in some cases requires a redesign of a renderer. For example, you can't update uniforms in the middle of a render pass, you have to create a large buffer and use dynamic offsets to move inside that buffer. In OpenGL the driver did that for you transparently.

Whereas in most middleware you can say "here is my scene, do your best", and only dig deeper if it needs some help to do its best.

As traditionally in all Khronos APIs, the step from "I managed a rotating cube with gourad shading", to loading a game scene with PBR material, is a gigantic step full hunting for libraries and trying to put them together, somehow.

It is no surprise that even with WebGL, most people end up picking ThreeJS or BabylonJS, after getting their first triangle.

Khronos APIs aren't meant to be middleware. They are meant to offer a thin low level abstraction for different vendors, upon which you can create middleware which offers higher level abstractions. Most famously in Vulkan, where each part of the spec is built almost for a specific vendor. Image transitions in Vulkan were mostly designed for AMD, NVidia doesn't require image transitions in Vulkan code at all. Renderpass APIs were developed mostly for tiled (usually mobile) renderers which can optimize when they know which render targets will be written to ahead of time.

Of course they aren't meant to be middleware.

Yet. Middleware renders the "portability"[0] of Khronos APIs a moot point, by having the best 3D API for each platform hardware, while at the same time exposing a more developer friendly infrastructure.

[0] - Anyone that was used Khronos APIs in anger across multiple OS and GPGPUs, knows the painful way of multiple code paths due to extensions, driver and hardware workarounds.

WebGPU is a lot simpler to use than Vulkan. The programming model is much closer to Metal than Vulkan or D3D12.

Easy and simple are not the same, and one still needs to go hunting for libraries to do basic stuff like loading textures, in good old Khronos tradition.

No other 3D API has code for loading textures either though. That stuff belongs in separate utility libraries.

Which are shipped by the same companies as the 3D APIs, on the same OS SDK, where are the Khronos utility libraries?

The attempt to create an OpenGL SDK repository was a joke, and the best Vulkan SDK can offer is a tool to avoid loading all the layers by hand, as it reached the same extension spaghetti as any Khronos API.

I'm not going to defend Khronos, IMHO they are the definition of the "designed by committee" philosophy. But a simple internet search yields:

https://www.khronos.org/ktx/documentation/libktx/index.html

But for cross-platform code it makes more sense anyway to use an independent cross-platform image loader library, instead of depending on the platform-specific utility APIs provided by D3DX or MetalKit.

That was just an example of a library, we can carry on with fonts, scene management, 3D math, .....

I did my thesis porting a particle engine from NeXTSTEP into Windows 98, and was big into OpenGL for a couple of years, went through the Longs Peak drama, eventually my focus switched to other 3D APIs by the GL 3.x timeframe.