No one cares of complexity if it’s hidden behind a reasonable interface. RDBMS and the async coroutine module in your language runtime are the examples of insane complexity done right. Most of these frameworks contain a very reasonable interface, at least compared to r-nonsense. So glad that people start to awaken from this fever dream.
But that is exactly the issue with React imo.
In React needless complexity isn't hidden away, its front and center.
Frameworks like Svelte do a far better job hiding and managing actual complexity.
This question seems misaligned(?). The idea is that it's easier to work with and harder to fail when complexity is hidden beyond a good interface. The complexity of a good UI framework's interface is low by definition. React exposes way too many moving parts and has way too many breakable rules to be called good. All UI frameworks may be as complex as they want, the interface is what matters for an end-developer.
Svelte's interface is basically "I will re-execute top-level statements starting with $:".
Vue's interface is "I bound your data to html, feel free to update it, but beware of []-nuances".
React's interface is "You have to use state and effect wrappers, but don't effect in non-effect blocks (and read what an effect is!), also always make copies of everything, and we can run your code twice, and if you if (), then make sure you don't if () in an inappropriate place, anyway, imagine you're in a pure functional language, but you aren't really, so do that by hand and don't mess it up, we warned you".
Out of React, Vue & Svelte I much prefer Svelte's approach since its the closest you can get to vanilla javascript. But I suppose we're getting pretty off topic at this point.
When I want to do two tabs on a UI that share state (but provide two wildly different views on it), how does one do that in Svelte?
Just add all the components, hide / show the tabs with styling when one or the other should be visible, and accept that state updates will be firing to attempt to re-render invisible components in the other tab?
(This isn't a criticism; I'm trying to wrap my head around the pros and cons of Svelte vs. React. React's approach would be that only one or the other tab renders, so you don't burn cycles updating state on the invisible tab because it doesn't exist in the DOM).
It's React who taught a whole new generation of developers that invisible can be re-rendered (also that generating vdom nodes is called "render" for some reason).
First, invisible things, both d-none or v-hidden, usually don't even have any sort of a graphical context to re-render themselves in, and when they do, it just gets invalidated. Sizing nuances apply to v-hidden, but if you chose it over d-none, it's reasonably consequential.
Second, you don't have to worry about it at all, unless it's quadratic+ for some reason or is covered by performance requirements as unacceptable.
I was thinking more about all the computation to decide what the properties should be of hidden elements, not the actual render state as in "pixels on a screen." (It is unfortunate that React kind of disrupted the terminology around this!).
IIUC unless I'm missing something, if I'm using Vue to drive, say, a list of thirty elements on the page from a JavaScript array somewhere, then when I update the array I'm still going to want to do all the text slicing, splicing, element creation, &c even if the entire list of thirty elements is hidden (and this won't be as expensive as it'd be if the list were visible - cost deferred until the object is actually visible and needs layout and render - but the JavaScript to set up its state is still running). Whereas in React, the fact the component that's parent to the list isn't in the DOM at all means the update logic for the list state wouldn't fire at all, no matter how many change events occurred.
(I'm sure you can do something similar in Vue, by detaching listeners when a given element is hidden).
Vue uses a similar (well, now ubiquitous) vdom technology, which can be used directly instead of templates, which simply transpile to it. I think this idea (afaiu) that vue has to do more work than react due to hierarchy etc isn’t correct. If there’s no dom bound to data.a[b].c, then nothing happens. If you think that vue templates still have to be regenerated, resliced and so on, then that also happens only once and results in a function which can be called to “render” vdom. https://codedamn.com/news/vuejs/exploring-vuejs-compiler-tem...
Sorry if I got you wrong. But it’s not the first time I think I see these wrong ideas about how “React is better”. I blame React itself, cause not only it redefined the terms, but also pushed this vague “compared to a regular detergent” agenda everywhere. It’s much less of a library than of pure religious movement with strawmen and fallacies.
Svelte will work here the same way that React does. If a component/element isn't mounted it will not render or update.
Where Svelte has an advantage is that:
1. A lot of stuff is built in, but extendable/replaceable. Styling, animations, basic state management, ...
2. It's update model makes it easier to use vanilla libraries without the need for any react-x wrappers.
3. The update model is also easier to use in general. The amount of stale closures and referential equality issues I have to fight every time I do something in react is insane.
Of what commercial use are the funny, animating widgets?
At this point frameworks like React exist just to generate employment for software developers, like the Federal reserve exists for economists.
I've had enough experience with 10-person teams trying to synchronize code for a large UI to think otherwise.
Trying to do that with "just HTML, CSS & JS" either dooms the project or ends up with the team implementing their own flavor of React (or something else) to standardized complicated state update in a modular fashion that allows sharing code.
Not everyone needs React, but when you do, it's nice not to have to reinvent the wheel.
Facebook is one. So is Google Cloud's dashboard. Basically anything where a single UI will be serving multiple separable concerns (that could be handed to multiple separate teams in a large org).
Because it is cool to hate on React on hn. Write something in Rust and watch everyone swoon, but mention anything that uses React and the comments will be filled with people hating all over it. As is the way on hn.
You're right about the disproportionate hate for React, but your information about Rust is out of date. These days it's 50-50 whether you'll get a lot of love or hate for a Rust project, and several of the top-upvoted Rust posts of the past year are disenchanted ones.
