Yeah, it's almost like hand-written DOM code. Of course it has some of the needed machine-generated parts for variables, etc, but basically it is easy to understand. I think it can be improved though.
Solid was inspired by Surplus. I think Surplus's output is incredibly nice, essentially like human written after compile:
I actually learned about this template compilation concept from Surplus, and it makes so much sense seeing Surplus output (that's how I always explain the concept to people, even for Solid, because it makes sense to people who write DOM code the same way manually, the code is very similar to regular hand-written DOM code).
I believe Solid's output got more complicated for two reasons:
due to the performance improvements it implements
The fact that Solid's dom-expressions hooks allow for any reactive fine-grained library to be used for the reactive backing of the JSX templates, so the output has to be generic.
Solid JSX is just one flavor, and it happens to use Solid's own reactive primitives, but any primitives other libraries can be hooked in.
So, I knew Solid was the next step already having Surplus in mind, but Surplus really helped nail the concept with it's ultra simple output.
@ryansolid
If the output was friendlier, people could also more easily learn how to write imperative code from it. For example, instead of using particular JSX-only APIs like insert, what would the output look like if we wrote the imperative equivalent by hand using only the documented reactive APIs? Would it be possible to do this, while keeping performance?
Also, can we make the dom-expressions hooks be compile time instead if runtime, so that we can also make the output cleaner that way? In that case, default output would be solid specific and as simple as possible.
Yeah, you're right that I can just look up the functions to see what they do. I think that seeing them inlined in Surplus output was what really made it magical, as if I'd written that code already (thinking of the JSX mapped directly to the DOM code). Functions are good for code re-use to minimize size of course.
Would removing the generic nature of dom-expressions' ability to cater to any reactive framework make Solid's specific output simpler?
Sorry if this is off-topic, but it seems like a Rust implementation might also enable (down the road) a port of dom-expressions to native app components, as an alternative to React Native. Has that been considered yet?
Would there be any interest in extending dom-expressions to server as a wrapper around native component solutions such as Tabris?
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.
The short answer is no. You'd bloat out component size significantly. There is runtime code here specific to handling the loose nature of JavaScript. There is normalization that needs to happen. The helpers are written to reduce closures.
I'm unsure what you mean by compile time vs runtime here. Dom Expressions internals are all replaced by Solid's by the time the output is bundled by Solid. The build I do before it is published to NPM makes everything Solid specific.
So other than perhaps more readable variable names this already where it should be.
I see yeah, code re-use through functions is the way to go. What I'm curious about, but I think the answer is no, is if you removed dom-expressions and had only specific functions directly in solid-js and no moduleName option for the Babel preset for example, would it make any difference? Would it be effectively identical to what dom-expressions already requires anyway? Or is there something you would remove if it were solid-specific and not allowing anyone else to hook in?
Some compiler options that I don't use. But almost nothing on the runtime side. The core file that I use to compile it to the specific libraries is tuned to Solid's API to the point that it basically just disappears in Solid's build step. That isn't true 100% for the others but I mean it's like an extra function wrapper etc..
Dom Expressions almost expects the runtime to be overridden for those custom cases like say MobX supporting class components. It provides a differenct createComponent function. I'd never do anything to compromise Solid's size or performance. The most awkward thing might be some redirection of shared Hydration state with the libraries being separate but I think I have that dialed pretty nice as well. Maybe the way I shadow imports. Like I expose them automatically through solid-js/web when they exist in solid-js but in the end bundled program again that all disappears.
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.
Yeah, it's almost like hand-written DOM code. Of course it has some of the needed machine-generated parts for variables, etc, but basically it is easy to understand. I think it can be improved though.
Solid was inspired by Surplus. I think Surplus's output is incredibly nice, essentially like human written after compile:
github.com/adamhaile/surplus
I actually learned about this template compilation concept from Surplus, and it makes so much sense seeing Surplus output (that's how I always explain the concept to people, even for Solid, because it makes sense to people who write DOM code the same way manually, the code is very similar to regular hand-written DOM code).
I believe Solid's output got more complicated for two reasons:
So, I knew Solid was the next step already having Surplus in mind, but Surplus really helped nail the concept with it's ultra simple output.
@ryansolid If the output was friendlier, people could also more easily learn how to write imperative code from it. For example, instead of using particular JSX-only APIs like
insert, what would the output look like if we wrote the imperative equivalent by hand using only the documented reactive APIs? Would it be possible to do this, while keeping performance?Also, can we make the dom-expressions hooks be compile time instead if runtime, so that we can also make the output cleaner that way? In that case, default output would be solid specific and as simple as possible.
I think imperative code would be longer and thus would take more time to read. Also, you can find insert here: github.com/ryansolid/dom-expressio...
It's pretty straightforward, you really don't want to expand that.
Yeah, you're right that I can just look up the functions to see what they do. I think that seeing them inlined in Surplus output was what really made it magical, as if I'd written that code already (thinking of the JSX mapped directly to the DOM code). Functions are good for code re-use to minimize size of course.
Would removing the generic nature of dom-expressions' ability to cater to any reactive framework make Solid's specific output simpler?
Please don't remove the ability to use dom-expressions with other libraries. Some of us prefer MobX and Ryan's integration mobx-jsx…
github.com/ryansolid/mobx-jsx
I don't think there will be changes to DOM-expressions. If so, there would more likely be a fork into the solid-project.
Some of us have been discussing writing a more optimized transpiler exclusively for DOM expressions' JSX flavor written in rust or Go.
Using Rust (for WASM?) sounds like a great idea.
Sorry if this is off-topic, but it seems like a Rust implementation might also enable (down the road) a port of dom-expressions to native app components, as an alternative to React Native. Has that been considered yet?
Would there be any interest in extending dom-expressions to server as a wrapper around native component solutions such as Tabris?
github.com/eclipsesource/tabris-js
npmjs.com/package/tabris-component
Stuff like that in Rust already exists. Sycamore is an example, and there are some others too.
Sidenote, I started
asdomfor AssemblyScript: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
asccompiler options are required:--exportRuntime--exportTable.The
--explicitStartoption 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
Asdomand pass itswasmImportsto 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
tscorasccompilers, 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.
The short answer is no. You'd bloat out component size significantly. There is runtime code here specific to handling the loose nature of JavaScript. There is normalization that needs to happen. The helpers are written to reduce closures.
I'm unsure what you mean by compile time vs runtime here. Dom Expressions internals are all replaced by Solid's by the time the output is bundled by Solid. The build I do before it is published to NPM makes everything Solid specific.
So other than perhaps more readable variable names this already where it should be.
If the code is gzipped, it should make hardly any difference. But it still bloats the code so reading it takes more time, so I applaud your decision.
I see yeah, code re-use through functions is the way to go. What I'm curious about, but I think the answer is no, is if you removed dom-expressions and had only specific functions directly in solid-js and no
moduleNameoption for the Babel preset for example, would it make any difference? Would it be effectively identical to what dom-expressions already requires anyway? Or is there something you would remove if it were solid-specific and not allowing anyone else to hook in?Some compiler options that I don't use. But almost nothing on the runtime side. The core file that I use to compile it to the specific libraries is tuned to Solid's API to the point that it basically just disappears in Solid's build step. That isn't true 100% for the others but I mean it's like an extra function wrapper etc..
Dom Expressions almost expects the runtime to be overridden for those custom cases like say MobX supporting class components. It provides a differenct
createComponentfunction. I'd never do anything to compromise Solid's size or performance. The most awkward thing might be some redirection of shared Hydration state with the libraries being separate but I think I have that dialed pretty nice as well. Maybe the way I shadow imports. Like I expose them automatically throughsolid-js/webwhen they exist insolid-jsbut in the end bundled program again that all disappears.