Solidjs – JavaScript UI Library

I suggested one such idea (a diffing version of innerHTML) years ago to Mozilla. Ironically, the React team was against it and it fizzled out. In more ironic twists of events, someone eventually wrote a JS implementation of it: https://github.com/tbranyen/diffhtml/tree/master/packages/di... and nowadays people are talking about HTML-based rendering engines again, making this idea somewhat relevant once more.

To be fair to standards bodies, they have done some work. Element.append now exists to make hyperscripts a bit more straightforward, and a lot of reactivity semantics can be implemented on top of Proxy.

The DOM used to be slow, incredibly slow, but that was a very long time ago when JavaScript only executed as an interpreted language. The DOM has been insanely fast even since before React was born. Using micro-benchmarks you can see that DOM access, when not using query selectors, tops out at around 45 million ops/s in Chrome and between 700 million to 4 or 5 billion ops/s in Firefox depending upon your CPU and ram. That is fast. No higher level framework will improve upon that.

Back in the day when the DOM was slow the primary performance limitation was accessing everything through a single bottleneck, the document object. To solve for this the concept of document fragments was invented. These aren't used anymore because the DOM is insanely fast and modern implementations (popular frameworks) are so incredibly slow. You aren't going to achieve a technology solution to a people problem.

The first big misconception of DOM performance is the difference between DOM interaction and visual rendering. Visual rendering is fast now because its offloaded to the GPU but its still far slower than accessing and modifying the DOM. As an example set an element to display:none and then perform what ever DOM modifications you want to it. Those changes have no visual rendering, are still DOM manipulation, and are insanely fast. You can measure this with a microbenchmark tool.

The second big misconception of DOM performance is how to access the DOM. The fastest means of access are the old static DOM methods, like: getElementById and getElementsByClassName. Query selectors will always impose a huge performance penalty when there are standard methods to do the same job and a minor performance boost when there aren't. The querySelectorAll method compounds that performance penalty. The performance penalty is present due to string parsing of the selector as necessary to convert that into something vaguely equivalent to the static methods, which is a step on each operation the static methods do not require. The minor performance to access things, such as by attribute, is achieved because there isn't a single static method equivalent and more steps must be taken compared to the parsed string result of the selector, but that performance boost is exceedingly minor (16x at most).

Usually developers prefer slower means of access to the DOM due to preferential bias to declarative approaches to programming. There isn't a performance tool to fix developer bias.

If you want both performance and less intimidating approaches to DOM access you can create aliases that solves for code reuse with more friendly names, but you will still need to understand the concept of a tree model.

Hey Solid's reactive system uses Signals which are different than streams but work in similar use cases. Streams are slightly more oriented to transformation than synchronization. Most stream libraries could be used with Solid with a bit of an adapter on the end to connect to the templates as they are a good tool for managing global state.

All that being said. If you are happy with Mithril stick with it. It sounds like it's done everything you needed. I have a lot of respect for it's minimalist approach and its author is one of the most insightful and helpful people I've come across since getting into JavaScript frameworks.

If you are interested in trying something different. Check out our tutorials on the site and see how you feel about it. It is a little bit different type of framework.

See also: https://github.com/inrupt/solid-ui-react, and the `https://github.com/inrupt/solid-client-*-js` names under Inrupt. (I helped build most of them!)

I can already imagine the naming discussions if we were to build a Solid library for Solidjs. "Solid-ui-solidjs"? "Solid-client-solidjs-js"? Oh boy. We're currently using React for most things, but I could imagine switching to this if it takes off... that's going to make following conversations very confusing, haha.

Now that I say that and I've clicked around, I wonder which is canonical: "Solidjs", "SolidJS", or "Solid.js"? I've seen it all three ways.

Reading this I'm reminded of knockoutjs, which the author of SolidJS cites as an influence. I remember at one point, years ago, trying to figure out why it was so much faster than AngularJS. Two things seemed to be going on: 1) It was only updating the parts of the DOM it needed to 2) To do this it seemed to 'automagically' be inferring dependencies.

I wondered how they did this second thing and guessed that it was parsing the JS code I was writing somehow. Either that or flooding the observables with values and making note of how changes trickle down. It turned out that it was doing neither of those things but frankly I didn't understand how it worked even when it was explained to me. Might be a good time to revisit and satiate my curiosity and take another look at it.