After going through several Google I/O sessions on advancements in browser UI and animation, I headed over to a different section of web browser evolution: advanced hardware capabilities for performance and/or connectivity.

Introducing WebGPU

WebGPU recently became publicly available in a mainstream browser in the form of Chrome 113, and varying levels of support are underway for other browsers. This is a topic that has interest and support from many different parties and I'm cautiously optimistic it will become widespread in the future. WebGPU is an evolution from WebGL following the precedence of desktop APIs Vulkan/D3D 12/Metals as evolutions from OpenGL.

One major aspect of this evolution was growing beyond just drawing operations, opening up hardware capabilities to non-drawing applications. Today this interest is focused on running machine learning algorithms, but it is more general-purpose than that. (Side question: how does that relate to WebML? Something to look into later.) Today people have shoehorned ML workloads into WebGL by rephrasing computation as drawing operations, with associated limitations and conversion overhead. WebGPU eliminates such pretense.

Another major aspect is elimination of global state. Global state was fine when the focus of OpenGL was to support a single CAD rendering window, but very problematic in today's world of large code modules running in parallel on different tasks.

One distinction between WebGPU and its counterpart desktop APIs is that absolute raw performance does not override everything else. Some performance were left on the table in favor of gaining consensus across partners in standardization, in order to reach better cross-platform compatibility. I found this very interesting and promising for the future.

This presentation had an associated Codelab "Your first WebGPU App" to build a parallelized Conway's Game of Life, no prior GPU experience required. I don't know what I might use WebGPU for, but I'll add this Codelab to my to-do list just to see what WebGPU is like firsthand.

WebAssembly: a new development paradigm for the web

In contrast to the hot-from-the-oven WebGPU, WebAssembly has been around for a while. Letting browsers run code beyond JavaScript. The initial scenarios were to allow legacy C code to be compiled into WebAssembly for high performance browser execution, and that approach has found success. I knew about Google's TensorFlow AI runtime running on WebAssembly, but I hadn't know there were also ports of codebases like OpenCV and FFmpeg. That might be worth looking into later.

With success of C and similar code that manage their own memory, recent attention had turned to supporting managed-memory code efficiently. Beyond JavaScript, that is, since JavaScript is already a language where the runtime manages the memory on behalf of the developer. And when another such runtime is in the WebAssembly box, that meant two different memory managers. At best they are duplicating effort and wasting memory, at worst having two separate reference counting garbage collection systems risk them falling out of sync to cause memory errors. This presentation gave a few examples of the kind of messes we can get into, now resolved with latest WebAssembly evolution putting all memory management under a single system.

One thing thrown out as an aside was a comment "Node.js or other webasm server environments" but no further elaboration in the presentation. WebAssembly on the server? Sure, why not. I don't know all the reasons why people might be interested but I also didn't expect Node.js (JavaScript on the server) to be interesting and I was very wrong. If server-side WebAssembly takes off, I'll cross paths with it soon enough.

Advanced web APIs in real world apps

I watched this presentation because I was curious about latest progress in Project Fugu, Google's effort to bridge the capability gap between web apps and native apps. The magnetometer web API, which I recently played with, was done under this umbrella. As did many other electronics hobbyist friendly technologies like Web Serial and Web USB.

This session didn't cover any capabilities that were personally relevant to me. They were selections from the Project Fugu Showcase, demonstrating capabilities like local file system access, use fonts installed on the system, etc. No hardware related fun this time, oh well. I moved on to a different topic: tools to help debug web apps.