as an ex frontend developer. this looks like a great library. i'm sure people won't understand, why this exists i.e JS fatigue. reason, being the current libraries don't solve all problems. till you've libraries that have good cpu performance, no build steps, great syntax. people will keep spinning out JS libraries. anyways great big-up to the author.
Solid – A declarative JavaScript library for building user interfaces
111–120 of 178 posts
Re: Solid – A declarative JavaScript library for building user interfaces
#112Here is an introductory summary of SolidJS: https://dev.to/ryansolid/introducing-the-solidjs-ui-library-...
My 2c of insight: I found Svelte's docs & examples greatly sweetened the on-boarding.
While I presume writing specs is a boring collateral, a friendly / bitesized / WISYWYG documentation would make a world of difference for the enthusiastic but less-than-ninjas of us.
The smarter kids can catch up faster, and some might not bother, already do react/vue. I personally found with Svelte a way tamer learning curve.
Re: Solid – A declarative JavaScript library for building user interfaces
#113Earlier quoted context omitted.
Exactly. Think of is as the classic compiled vs. interpreted languages debated. One is clearly faster than the other but the slower one may have different advantages.
Ahead-of-time vs Just-in-time is a more accurate description. In this case, there's no evidence that precompiling is faster in theory -- let alone in practice. In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests). This is the BEST possible case for precompiling too. In the real world, JITs take a long time to warm…
> In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests).
I mean I agree with most of your post, but I'm not sure I would necessarily make that highlighted claim from the benchmark results. I mean the +- seems to be pretty run dependent for most libraries on there. And while I agree that the differences in performance is neglible, there is one. Solid is clearly faster in most tests even if by a small amount. Anyone interested you can look at: https://krausest.github.io/js-framework-benchmark/current.ht... And then isolate Solid and Inferno and then do a comparison against one library. It will color highlight the degree of certainty the difference is between the libraries in terms of significance of the results.
Re: Solid – A declarative JavaScript library for building user interfaces
#114[deleted]
Re: Solid – A declarative JavaScript library for building user interfaces
#115Earlier quoted context omitted.
It's my understanding that regardless of the complexity of your custom JSON data at some point while parsing the tree you have a line that says "if obj is of this type, then render this component for this node", all Svelte/Solid etc need to know is that this is the line where a Component is being assigned to a variable that is going to be rendered in the template. Or are you saying you want a layout rendered from JSO…
Consider the following pseudo-code: list2 = bubble_sort(list1) render(list2) Now suppose the user deletes one item in list1. The question is now: Will the update trigger a new bubble sort? Will the update do something smarter, like just delete the DOM element?
There's usually no render function to call in these types of frameworks as far as I understand (my experience being a little Svelte).
I imagine in your scenario the psuedo code to achieve what you want would be written.
list2 = bubble_sort(list1)
removeItem = () => delete list2[random index]
...
Re: Solid – A declarative JavaScript library for building user interfaces
#116Earlier quoted context omitted.
Exactly. Think of is as the classic compiled vs. interpreted languages debated. One is clearly faster than the other but the slower one may have different advantages.
Ahead-of-time vs Just-in-time is a more accurate description. In this case, there's no evidence that precompiling is faster in theory -- let alone in practice. In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests). This is the BEST possible case for precompiling too. In the real world, JITs take a long time to warm…
> In this case, there's no evidence that precompiling is faster in theory -- let alone in practice.
It’s absolutely not because it requires far greater effort computationally. The benefit has nothing to do with performance but instead simplified state management.
I know people desire certain frameworks due to how they perform state management. I have never really understood that motivation myself though because managing state is incredibly simple. Here is a basic outline of how simple it is:
1) realize there are exactly two facets to every component: data, interface.
2) all components should be stored in common locations. A single object stores component data and a common DOM node for storing component interfaces.
3) pick a component facet to update, either data or interface, and never update the other. The other should be automatically updated by your application logic (reflection).
4) store your data on each change. That could be dumping it into local storage. In my current app I send the data to a local node instance to write into a file so that state can shared across browsers in real time.
5) be able to restore state. On a fresh page, or even page refresh, simply grab the stored data and rebuild the component interfaces from it.
My current application is a peer to peer Windows like GUI that works in the browser and exposes the file system (local device and remote devices) in Windows Explorer like interfaces. Managing state is the least challenging part of this. The slowest executing part are long polling operations against large file system trees (it’s about as slow in the native OS interface)
Re: Solid – A declarative JavaScript library for building user interfaces
#117Earlier quoted context omitted.
Consider the following pseudo-code: list2 = bubble_sort(list1) render(list2) Now suppose the user deletes one item in list1. The question is now: Will the update trigger a new bubble sort? Will the update do something smarter, like just delete the DOM element?
There's usually no render function to call in these types of frameworks as far as I understand (my experience being a little Svelte). I imagine in your scenario the psuedo code to achieve what you want would be written. list2 = bubble_sort(list1) removeItem = () => delete list2[random index] ... The compiler will see a change to the list2 variable anywhere that removeItem is called and annotate the code to make the a…
Correct. The idea is that the derived state only updates when the underlying state updates. And the mapping to the DOM is just derived from that derived state. So list updates.. triggers bubble sort, triggers DOM reconciliation. The difference with Svelte is it sees it and the compiler writes the reactive code in the background. In Solid you just write the reactive code yourself.. ie.. `setState` etc. But it more or less works similarly.
It's like Svelte without abstracting the update mechanism. Which makes it a little more to get into at first but very similar to a library like React. The difference from React is that Solid knows exactly what you are updating so it doesn't bother with the other stuff.
Re: Solid – A declarative JavaScript library for building user interfaces
#118Is it possible to use Solid with just plain JavaScript/TypeScript (like using createElement with React)?
I generally find those far more readable than JSX (and is one of the reasons I think SwiftUI and Flutter code looks nicer than React).
Re: Solid – A declarative JavaScript library for building user interfaces
#119Here is an introductory summary of SolidJS: https://dev.to/ryansolid/introducing-the-solidjs-ui-library-...
My 2c of insight: I found Svelte's docs & examples greatly sweetened the on-boarding. While I presume writing specs is a boring collateral, a friendly / bitesized / WISYWYG documentation would make a world of difference for the enthusiastic but less-than-ninjas of us. The smarter kids can catch up faster, and some might not bother, already do react/vue. I personally found with Svelte a way tamer learning curve.
I agree. I would love to do more. The truth is there is just so much to do. It's hard to find a balance between writing cleaner docs and say solving Async Hydration with Suspended Components. I had the luxury early on to prioritize the latter which is why Solid is so feature rich given how much of it needed to be researched and built from scratch. I always knew it would catch up with me. But that's a good problem to have.
Re: Solid – A declarative JavaScript library for building user interfaces
#120Earlier quoted context omitted.
I actually think this is extremely important. One downside of these compilation-driven frameworks is that they would, I assume, make it much more difficult to track with exactly how your code manifests at runtime, and would therefore make it harder to debug. Even setting that aside, I'm a strong believer that "frameworks" (contrasted with "libraries") have a responsibility to bring their own tooling, because existing…
It's easier to just open up and debug than say VDOM views since you can see your dynamic expression (what's not updating) and just drop a breakpoint. The template structure flattens so you don't have this issue of nested children and what you are debugging is the actual DOM nodes. It feels more like debugging jQuery. But it is no replacement for good dev tools.
I guess what I meant is that VDOM views (at least pure-functional ones like React) can have a much clearer separation between the view logic and the state logic. I don't have to understand how the VDOM works because it's never entwined with my code that might have a bug in it: I'm just creating a data structure and handing it off. If there's a bug, it's in the creation of that data structure, which is 100% my own code. That hard barrier exists even at runtime. Solid seems like it deeply entwines the two in a way that's very clever and has performance advantages, but would also, I expect, come with a cost.