[runlaszlorun]

I’ve been working on something like that but, and I’m not sure if you’ve used WASM much, but WASM has none of the web APIs so you need to lean on JS to do UI or local storage, etc.

I’ve been fiddling with my own 2D canvas UI, and would like to get WebGL thrown in the mix but that’s a learning curve of it’s own.

The effort to build my own input widgets and intercept click events, etc was actually less then I would have imagined.

I find WebAssembly a fairly odd duck though and highly disappointing. As the quote goes, there’s little actually “web” or “assembly” about it. Performance seems on average no faster than JS- sometimes worse. The driving factor being how and how much you need to serialize/deserialize into its TypedArray memory space. And while you can port legacy codebases over, they then will be using various kludges to use the existing JS API’s instead of the POSIX-style interface they’re likely expecting.

If anything, I have a newfound respect for the performance of current JS engines. And am about to go all in on HTML Custom Elements for the UI. Once I ignored the various features most tutorials talk you through and looked at them as just a class overriding HTMLElement, they made a lot more sense to me.

Just my 20 cents…

—— edited for spelling ——

[apatheticonion]

> but WASM has none of the web APIs so you need to lean on JS to do UI or local storage, etc.

Yeah, haha I am eagerly waiting on these additions. I'm following the spec quite closely and would love it if one day an index.wasm could replace index.html as a web application entry point.

> I find WebAssembly a fairly odd duck though and highly disappointing.

100% agree. It was introduced about 8 years ago and we still can't use it to make a div appear (without heavy JS thunking). The consortium is discussing how to use web assembly in serverless functions and to replace docker - meanwhile in the web world, it's essentially a faster Web Worker.

But hey, I'm still hopeful