Solid is such an amazing reactive declarative tool for composing and manipulating DOM with simple reactive declarative templates! By far the best c...
For further actions, you may consider blocking this person and/or reporting abuse
What I like the best about SolidJS is that its output is predictable. You don't get that with most transpiled libraries.
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.
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.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.
Every once in a while I go look at the progress in the lume repository. My one gripe is the fact that docs feel somewhat bare, and I have difficulty figuring out how to go beyond simple examples. Of course, authoring a library like that is no mean feat, and docs are always difficult to write. But do wish I had a better way of learning the library.
Commenting because
🙂
Hey, thanks for the feedback. I am slowly working on docs. Initially I spent more time on the JSDoc parser (because everything else didn't fit my need), and now I am focusing more on content.
But also, if you have any questions, you can also come directly to me. :)
What particular areas do you get blocked on? I can focus on documenting those parts next.
Also wish I had more hands! I'm also working on github.com/lume/glas (port of Three.js to AssemblyScript), and now also github.com/lume/asdom (DOM bindings for AssemblyScript). Eventually this will come together into custom elements written in AssemblyScript (hence running as WebAssembly with access to DOM and WebGL for max speed).
I'm not sure right now... Generally though, I can't feel that I "know" what to reach for when I want something, if I don't know everything that's in my toolbox. It's also basically my first foray into 3d, so 🤷.
Is glas meant to replace solid in lume? Or replace lume itself? I know you have lot's of projects, but I don't understand how they all fit together.
I'll definitely take you up on that. I'll see you on discord 😄.
Yeah, i can see how already having 3D knowledge (f.e. knowing how Three.js works) would help.
Currently the custom elements use Three.js underneath for the WebGL rendering. Glas will replace the underlying Three.js as the lower level WebGL rendering mechanism, while the custom elements on top will remain the same. Essentially, if you're only using the HTML elements, you shouldn't notice a difference, only the WebGL rendering mechanism that is abstracted underneath will change. You would only notice any difference if you are reaching inside of the elements to grab the Three.js instances to do something custom that is not supported by the element interfaces yet. For example, if you were to access
element.three, that gives you the Three.js object that the element manipulates, and that part will change to be glas objects. TLDR: If you stick to LUME element attributes and properties (except for.three, which I may not document) then you'll not notice anything.I'm sold on Solid Js, but how do include CSS and JS dependencies (example: getmdl.io/started/index.html) in dev and production build?
I have only found instructions on using Tailwindcss, which is not what I want to work with.