First you should get familiar with AssemblyScript and learn how to run
AssemlyScript code in a browser.
The following asc compiler options are required: --exportRuntime--exportTable.
The --explicitStart option is required only if any of your ES modules use DOM
APIs at their top level (read the comments in the below example).
In your JavaScript code that loads your Wasm module, import Asdom and pass
its wasmImports to your Wasm module's imports. The following snippet assumes
the use of native ES Modules in the browser and a…
Next I'd like to add a JSX transform for AS. It will compile to something like Solid.js does with fine-grained updates of the DOM, but written in AS.
The final experience will be similar to Solid. I will be porting my LUME custom elements for 3D (which use Solid underneath) to AS after that.
In the end, it will be possible to compile this stuff, written in TypeScript, to either JS for existing apps, or to Wasm when that makes sense (using tsc or asc compilers, respectively).
I think compiling to Wasm will make sense for computationally expensive apps like 3D games with physics, transforms, collisions, etc, where the gains from doing that math stuff in Wasm will far outweigh the coat of DOM bindings.
In upcoming Wasm specs, Wasm will be able to interop with DOM much more quickly (essentially like JS), at which point I'm hoping that this infrastructure I'm making ahead of time will be beneficial for regular non-computationally-heavy DOM apps.
I'm betting Wasm, even on MVP with slower bindings, will be a good fit for something like LUME. React-three-fiber or A-frame could benefit too I think.
However, I wonder if 3D games and other visualizations would be best served by DOM elements or by raw pixels in a canvas element. But then we'd compare that to Three.js, WebGL, etc.
For DOM elements driven by WASM, I was thinking more about (very) large dashboards with lots of figures changing constantly, and perhaps certain parts of the display being highlighted and zoomed as needed to direct user attention. That kind of content, while not as demanding as 3D games, could potentially benefit from a faster implementation of Ryan's DOM expressions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sidenote, I started
asdom
for AssemblyScript:lume / asdom
Use DOM APIs in AssemblyScript
asdom
Use DOM APIs in AssemblyScript (TypeScript compiled to WebAssembly).
This allows us to write WebAssembly applications that can manipulate the DOM, and with potential for more speed!
Early Stages!
Work in progress (probably may always be), but right now it's early and many APIs need to be added.
Supported APIs so far
See the outline of supported APIs.
Usage
First you should get familiar with AssemblyScript and learn how to run AssemlyScript code in a browser.
The following
asc
compiler options are required:--exportRuntime
--exportTable
.The
--explicitStart
option is required only if any of your ES modules use DOM APIs at their top level (read the comments in the below example).In your JavaScript code that loads your Wasm module, import
Asdom
and pass itswasmImports
to your Wasm module's imports. The following snippet assumes the use of native ES Modules in the browser and a…Next I'd like to add a JSX transform for AS. It will compile to something like Solid.js does with fine-grained updates of the DOM, but written in AS.
The final experience will be similar to Solid. I will be porting my LUME custom elements for 3D (which use Solid underneath) to AS after that.
In the end, it will be possible to compile this stuff, written in TypeScript, to either JS for existing apps, or to Wasm when that makes sense (using
tsc
orasc
compilers, respectively).I think compiling to Wasm will make sense for computationally expensive apps like 3D games with physics, transforms, collisions, etc, where the gains from doing that math stuff in Wasm will far outweigh the coat of DOM bindings.
In upcoming Wasm specs, Wasm will be able to interop with DOM much more quickly (essentially like JS), at which point I'm hoping that this infrastructure I'm making ahead of time will be beneficial for regular non-computationally-heavy DOM apps.
I'm betting Wasm, even on MVP with slower bindings, will be a good fit for something like LUME. React-three-fiber or A-frame could benefit too I think.
Interesting stuff!
However, I wonder if 3D games and other visualizations would be best served by DOM elements or by raw pixels in a canvas element. But then we'd compare that to Three.js, WebGL, etc.
For DOM elements driven by WASM, I was thinking more about (very) large dashboards with lots of figures changing constantly, and perhaps certain parts of the display being highlighted and zoomed as needed to direct user attention. That kind of content, while not as demanding as 3D games, could potentially benefit from a faster implementation of Ryan's DOM expressions.