Almost, that will set the foundation for fully using the DOM APIs. The host bindings proposal mentioned at the end of the article should close the gap.

Minor clarification:

The DOM builtins should be helped by the Reference Types Proposal for WebAssembly. [1]

`The host bindings proposal` is going to help speed up new and getter/setter calls. [2]

1: `Currently the only built-ins that we support this for are mostly limited to the math built-ins. That’s because WebAssembly currently only has support for integers and floats as value types.

That works well for the math functions because they work with numbers, but it doesn’t work out so well for other things like the DOM built-ins. So currently when you want to call one of those functions, you have to go through JavaScript. That’s what wasm-bindgen does for you.

But WebAssembly is getting more flexible types very soon. Experimental support for the current proposal is already landed in Firefox Nightly behind the pref javascript.options.wasm_gc. Once these types are in place, you will be able to call these other built-ins directly from WebAssembly without having to go through JS.`

-- https://github.com/WebAssembly/reference-types

2: `there are still a couple of built-ins where you will need to go through JavaScript. For example, if those built-ins are called as if they were using new or if they’re using a getter or setter. These remaining built-ins will be addressed with the host-bindings proposal.`

-- https://github.com/WebAssembly/host-bindings

(BTW I could be mistaken, just quoting the article)

What is `wasm_gc` all about?

The reason the switch is called that...

"A new proposal has been made to the WebAssembly specification committee a few months ago: to add reference types to the type system. Reference types are a new way to represent a reference to any host values. In a Web environment, this means being capable of playing with JavaScript values within WebAssembly. This is a huge difference with the existing type system, which only contains primitive types: integers represented on 32 or 64 bits, IEEE754 floating-point numbers represented on 32 or 64 bits. This is also a first step for implementing garbage collection (GC) integration within WebAssembly: since these reference values have been allocated on the GC heap in JavaScript, they need to be traced during wasm execution."

https://blog.benj.me/2018/07/04/mozilla-2018-faster-calls-an...

maybe the most important improvement will be direct memory access to the canvas bitmaps for super fast game rendering.

Wouldn't "super fast game rendering" be done by the GPU via WebGL?

For 2D games it's much more convenient to pixel push directly than to deal with vertex buffers, index buffers, shaders... Unfortunately graphics cards are not optimized for that scenario.

Convenient, but "super fast"?

And though it's a matter of opinion, I disagree. The GPU is easier for me to use for things like screen-space shading, alpha blending, sprite transformations and distortions, and it all performs much faster than the equivalent CPU render code.

A lot of game logic also runs on the CPU

canvas bitmaps are only useful for rendering though.

Assuming that also implies access to typed arrays in general, then applications that involve number crunching become a lot more feasible in JS too.

Huh? We've had typed arrays in JS for years. I think they originally went in to support WebGL, but you can use them for other stuff too.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Direct access to typed arrays from WASM without having to copy them over whole first, or use the memory buffer of the WASM module. You can't really write a "true" generic in-place sort in WASM right now, so to speak, because there is always a copying back and forth step.