Can we please just get the ECMAScript body to backport some of these common features into the core language itself? I can't keep up with all the javascript frameworks of the day :( By the time I finish one feature, ten new frameworks have popped up. I can no longer tell the difference between innovation and anarchy.
Solidjs – JavaScript UI Library
61–70 of 92 posts
Re: Solidjs – JavaScript UI Library
#62Earlier quoted context omitted.
Interesting how does this compare to Mithril? I have yet find anything that is more performant than Mithril. Never heard of solid. How is it?
Interested as well, Mithril seems plenty fast for my use case. One area I believe I read about where VDOM/Mithril is faster is dealing with dynamic list data. E.g. you have a list of items you're rendering (probably keyed in Mithril), and you append a new one, it'll render faster with VDOM then solid because the diff process will be faster than whatever solid is doing.
Solid's diff algorithm generally is faster(or atleast very comparable) than Mithril's. We test very well in list benchmarks like: https://krausest.github.io/js-framework-benchmark/current.ht.... We are also fast at node creation using pre-compilation to prepare the nodes in a way that can be created more efficiently.
Re: Solidjs – JavaScript UI Library
#63ryan, is a cool guy. but I feel like a lot of work they're doing on marko, will be much better than solidjs. solidjs api is non-intuitive, same as the reactive system say compared to svelte. Hooks are already a bad idea in react, for reasons I will not expand on. And having the same concept in solidjs isn't progress at all. Svelte nails reactivity, it's something you don't think about.
Something you don't need to think about until well, you realize reactivity leaves templates and you need to write a store. Or that you have large data and need things to only update piecewise. Or you need to hoist things out into functions. Svelte has done an amazing job with its compiler but there are considerations you need to understand with its reactivity.
Solid does not have Hooks or Hook rules. They look similar but execute more similar to say Svelte. Although Svelte still is about Component re-renders and Solid's reactivity is more granular hence the performance improvement.
This area of DSLs is very superficial for the most part. I think people have preferences and I'm exploring both sides between Marko and Solid but saying things like unintuitive I think mischaracterizes things. Maybe explicit, transparent, transferrable, and composable are better adjectives that apply more to Solid than to Svelte that you can use in the future.
Re: Solidjs – JavaScript UI Library
#64Can we please just get the ECMAScript body to backport some of these common features into the core language itself? I can't keep up with all the javascript frameworks of the day :( By the time I finish one feature, ten new frameworks have popped up. I can no longer tell the difference between innovation and anarchy.
>I can no longer tell the difference between innovation and anarchy
I think this is kind of the thing with innovation. Innovation is anarchy until the point where the innovation is accepted as best practice. And at that point it's not really innovation. It's just best practice.
Re: Solidjs – JavaScript UI Library
#65Earlier quoted context omitted.
That's kind of why the entire virtual DOM concept came about, because it was faster than direct DOM manipulation. Essentially batched updates to the DOM were faster than ad-hoc updates. Now React is 8 years old and browsers have improved a lot since then so I imagine the gains might not be what they used to be. But at the time it was huge.
That perception of the DOM/VDOM situation is and always was false. React was always slower at runtime than a carefully-engineered system designed for performance. As Dan Abramov said a couple of years later https://medium.com/@dan_abramov/youre-missing-the-point-of-r... >, people were missing the point of React: it was never about VDOM; rather, that was a cost that at the time they reckoned had to be paid in order to…
[deleted]
Re: Solidjs – JavaScript UI Library
#66Can we please just get the ECMAScript body to backport some of these common features into the core language itself? I can't keep up with all the javascript frameworks of the day :( By the time I finish one feature, ten new frameworks have popped up. I can no longer tell the difference between innovation and anarchy.
>I can no longer tell the difference between innovation and anarchy I think this is kind of the thing with innovation. Innovation is anarchy until the point where the innovation is accepted as best practice. And at that point it's not really innovation. It's just best practice.
Yeah, but we shouldn't need 15, no, 17, no, 27... different ways to "update the UI when the data changes after an API call". Just one good one -- not necessarily the best, just good enough.
Something a bit more advanced than fetch, not quite as complex as useContext. To the end user, websites haven't really changed all that much since the early AJAX days. Input gets received, ajax happens, shit gets updated. Why has the tooling gotten 1000x more complex?
Re: Solidjs – JavaScript UI Library
#67Earlier quoted context omitted.
Interesting how does this compare to Mithril? I have yet find anything that is more performant than Mithril. Never heard of solid. How is it?
Mithril is reasonably fast, but there are plenty of faster options like Solid, Inferno, Preact, or Svelte. https://krausest.github.io/js-framework-benchmark/current.ht... IMO the best thing about Mithril is that it doesn't have reactivity, much like Imba. This allows you to define state with pure vanilla objects and classes. Also that it includes an HTTP client and router in just 10kB. It's really verbose though comp…
[Mithril.js author here]
FYI, the krausest benchmark is known among framework authors to be not very good (it weighs some aspects much more heavily than others and has been gamed by various toy-ish "frameworks" that aren't all that practical in real life).
With that said, people obviously use React and even Ember (which are on the slower side of the krausest rankings) out in the wild and they're generally fine frameworks: asciinema-style "render-a-huge-grid-at-60fps" is very much a niche use case that 99.9% of people don't have.
I think the most accurate way to describe Mithril.js is that it aims to be a "get-out-of-your-way" sort of tool, in the sense that if things go wonky, you can generally reason about the low level reason as to why that is the case. For example, in Mithril.js, `render` is not just a first-class concept but an explicit API. So if you ever run into an issue where the template doesn't update for whatever reason, you can intuitively infer exactly what to do to unblock yourself. No need to reason about stale closures when debugging useEffect, observable/signal composition, or similarly complicated mental models. Reactivity, specifically, is great for squeezing performance from needle-in-the-haystack sort of updates when you have humongous haystacks, but it does also have caveats: if Svelte ever doesn't update the template for some reason, the mental model required to understand reactivity membership graphs and reactive bindings and where the compiler has jurisdiction and all that jazz are quite a bit more complicated than "ok fine, just slap a render call in this library's event handler".
The thing you said about vanilla objects follows from those principles: as a JS person, you know how objects work so you're never going to run into cognitive dissonance about the semantics of your primitives.
The verbosity thing I think is more a testament to Svelte being terse than anything else. Mithril.js isn't really verbose compared to other frameworks, IMHO.
Re: Solidjs – JavaScript UI Library
#68Can we please just get the ECMAScript body to backport some of these common features into the core language itself? I can't keep up with all the javascript frameworks of the day :( By the time I finish one feature, ten new frameworks have popped up. I can no longer tell the difference between innovation and anarchy.
Congratulations, now every browser (oh wait, there's only 1 real browser) will implement it slightly differently and you'll use a library once again to reconcile all of them. (Also old browsers, browsers implementing the non-final version of the spec)
Re: Solidjs – JavaScript UI Library
#69It will be sad if this UI library makes Tim Berners-Lee's long-term project Solid less visible: "Your data, your choice. Advancing Web standards to empower people." https://solidproject.org/
In the future, people might build UIs for Solid using a (hypothetical) solid-solid or at least combining Solid UI and SolidJS: e.g. https://github.com/solid/solid-ui vs https://github.com/solidjs/solid
At least, if SolidJS is supposed [1] to be a name separate from Solid, why not call the repo solidjs like the org?
Re: Solidjs – JavaScript UI Library
#70Earlier quoted context omitted.
That's kind of why the entire virtual DOM concept came about, because it was faster than direct DOM manipulation. Essentially batched updates to the DOM were faster than ad-hoc updates. Now React is 8 years old and browsers have improved a lot since then so I imagine the gains might not be what they used to be. But at the time it was huge.
Virtual DOM came about since it offered a simplistic top down view = fn(state) model without terrible performance. Other top down renderers were terribly inefficient and this built on that. It was never innately faster than targeted direct DOM manipulation. It was just compared to other approaches that were innately built on diffing as well. And things like reading from the DOM can cause reflows and other terrible pe…
[deleted]