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".
But then, if I'd had a choice to work with next.js or pile of cow crap, I'd prefer crap.
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).
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.
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).
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.
AFAICT, Svelte doesn't have a vdom? Maybe I'm just missing it.
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.
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.