Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Oh idk let me think.. off the top of my head: - Vue - Svelte - Solid - Qwik - Alpine - Lit Or better yet HTMX


Vue, Svetle, etc. is roughly same level of shit complexity as react; htmx is interesting actually.


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.


How is Svetle complexity is different and why is JS-vanilla-like Svetle complexity is better than React-like 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".


Agree completely, but if you "need" that level of complexity, I'd rather be working with Vue or Svelte.


Idk, does the same thing, but aestetically looks different. I guess I'm bigger fan of JSX than whatever Svelte approach is named.

But then, if I'd had a choice to work with next.js or pile of cow crap, I'd prefer crap.


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.


Thank you for that. My apologies; said "Vue" meant "Svelte."

AFAICT, Svelte doesn't have a vdom? Maybe I'm just missing it.


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.


Vue vs React is splitting hairs, honestly. DX wise they feel the same, whereas JQuery and Vue are worlds apart.


Not to me. React's insistence on immutability can be difficult to work around.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: