
Solid – The Best JavaScript UI Library You’ve Never Heard Of - ryansolid
https://medium.com/@ryansolid/solid-the-best-javascript-ui-library-youve-never-heard-of-297b22848ac1
======
mac_was
"The last thing anyone is looking for is another JavaScript UI
Library/Framework. It’s beyond fatigue from the crippling weight of constant
decision making and chasing Unicorns. It’s just gotten so easy to make
something. Web Components are responsible for a new “framework” every other
day it seems like. So why even bother?" \- almost stopped reading on the first
paragraph, but there was a nice table with comparison so gave it a try.

~~~
ryansolid
Thanks for sticking with it. I sometimes feel I'm the worst at self promotion.
It is too conflicting with the realist in me.

------
tracker1
Really like and appreciate the approach... the biggest thing keeping me with
react is @material-ui/core, which is in my opinion hands down the best set of
components and theming I've used for web development in over two decades.

For the most part, imho any new paradigm almost needs something like bootstrap
and/or a material design library as a starting point. Bootstrap likely easier
to work towards for a starting point.

~~~
ryansolid
This is great feedback. Using premade Component Libraries like that is not
something I have with my professional experience so it wasn't something I was
thinking about much. It would definitely take some doing to create a library
like that. But it definitely seems like a good way to showcase practical
usage.

I guess one of the reasons I'm so intent in fully supporting Web Components is
so that it is easy to package up Components like that and it opens up the wide
variety of options available regardless of framework.

~~~
tracker1
Absolutely... A good place to start might be one of the react bootstrap
component libraries... they effectively re-use the CSS classes, but provide
actual components instead of bootstrap's JS controls (originally jQuery
extensions, but think they are changing direction).

It would take a bit more thought/planning for something closer to material-
ui's packages (or something else for that matter). I really like material
design myself, but know a lot of people don't care for it.

In any case, I hope the project does gain traction. If I do something
completely green, will definitely be keeping it in mind.

------
emerongi
So what's the key difference vs React?

When it comes to VDOM, as far as I know, that's just the implementation chosen
in react-dom, not something that is inherent to React.

~~~
ryansolid
Key difference is there is no VDOM. Instead of doing multiple passes over a
tree top-down on scheduled update cycles to render a virtual DOM
representation and then diffing and patching against a real DOM. Solid
compiles it's JSX down to optimized real DOM instructions. Then through
basically event subscriptions it triggers updates based only on dependencies
of data that has changed to update specific nodes.

While ReactDOM is just an implementation of the VDOM, Solid uses a completely
different change management approach than React which is why it's API can look
like React Hooks but not be subject to the Hook Rules. Although its more the
other way around in that React Hooks is influenced by fine grained libraries
that have existed for over a decade now.

Historically this approach suffered greatly on initialization but
precompilation of the JSX mitigates this. Which just leaves this approaches
strength which is partial updates to handle the rest. In so the approach
differs from a lot of previous precompiled work since the update cycle is more
optimized.

EDIT: I see meant more that React itself isn't married to the VDOM. That is
true-ish. It still is based on Partitioned Top Down evaluation. So even if it
wasn't using a VDOM it would attack things a similar way. Solid is using fine
grained evaluation through an Synchronous Reactive Programming graph. It just
fundamentally works very differently on how it handles changes.

~~~
treyhuffine
Very interesting approach, I'm excited to try it out. The performance is
pretty undeniable.

------
alok-g
Any comparison data on scalability to orders of magnitude larger number of
rows? Say a million?

~~~
ryansolid
I never got past 30,000. I'm sure there are applications where it could have
meaning but I started noticing completely different performance trends.
Certain ways of writing the code would work better at 30,000 but be slower at
500. Ultimately it seemed fruitless as increasing amount of effort is spent in
the DOM. The amount the JS matters is so small. On one hand even 10k is too
many rows as you'd likely use windowing.

Instead I've been going the other way. Using less rows but using Chrome to
throttle CPU. This lets you focus must more on what can be done in the JS.

~~~
alok-g
I would like to understand your message better. Can you share more about this
variation in the way of writing code in this situation?

I am personally not a fan of this trend of browser libraries falling apart
beyond a few tens of thousand items. Native apps scale well to such numbers of
items and stay performant, albeit there would be a freeze for a while. Excel
and Matlab come to mind as examples. I have given millions of items to both
for real use cases.

~~~
ryansolid
I was playing with using timeouts and request animation frame, along with
storing certain internal objects in Maps vs Objects.

All I meant was that the time the browser spends on rendering/layout/GC trumps
an implementation code consideration. Optimized handwritten JS has the issue
before even considering libraries. People attempt to come up with smarter
solutions rather than actually just rendering a million rows. Playing with
timeouts and asynchronous rendering the view in parts is an approach.
Windowing is another, by which I mean setting a viewport essentially(ie only
render what's in view). But currently these sit in userland since there are
tradeoffs.

I've seen libraries try to offload to WebWorkers but every attempt I've seen
so far in that vein is slower than just optimal main thread code. I know the
WASM crowd is looking into that.

Also things like Time Slicing in React Fiber are trying to bring this to the
library level. And Solid's primitives can be used to similar effect but these
approaches aren't generalized yet. It's one of the areas I see Solid's model
having an advantage.

~~~
alok-g
This is helpful for me to follow the details. Thanks!

