4 ms·

Solid – The Best JavaScript UI Library You’ve Never Heard Of

43 points by ryansolid 8y ago

mac_was 8y ago
"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 8y ago
  Thanks for sticking with it. I sometimes feel I'm the worst at self promotion. It is too conflicting with the realist in me.
emerongi 8y ago
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 8y ago
  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 8y ago
    Very interesting approach, I'm excited to try it out. The performance is pretty undeniable.
alok-g 8y ago
Any comparison data on scalability to orders of magnitude larger number of rows? Say a million?
- ryansolid 8y ago
  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 8y ago
    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 8y ago
      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.
tracker1 8y ago
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 8y ago
  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 8y ago
    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.

43 points by ryansolid 8y ago

"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 8y ago
Thanks for sticking with it. I sometimes feel I'm the worst at self promotion. It is too conflicting with the realist in me.

emerongi 8y ago

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 8y ago
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 8y ago
  Very interesting approach, I'm excited to try it out. The performance is pretty undeniable.

alok-g 8y ago

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

ryansolid 8y ago
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 8y ago
  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 8y ago
    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.

tracker1 8y ago

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 8y ago
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 8y ago
  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.