DEV Community

Discussion on: A few reasons why I love Solid.js

 
trusktr profile image
Joe Pea

Sidenote, I started asdom for AssemblyScript:

GitHub logo 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 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.

Thread Thread
 
svicalifornia profile image
Shawn Van Ittersum

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.