4 ms·

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

by 1GZ0 2y ago

CafeRacer 2y ago
Vue, Svetle, etc. is roughly same level of shit complexity as react; htmx is interesting actually.
- 1GZ0 2y ago
  Agree completely, but if you "need" that level of complexity, I'd rather be working with Vue or Svelte.
  - CafeRacer 2y ago
    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.
    - 1GZ0 2y ago
      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.
      - shadowgovt 2y ago
        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).
        wruza 2y ago
        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.
        shadowgovt 2y ago
        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).
        wruza 2y ago
        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-template-compilation 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.
  - Capricorn2481 2y ago
    Vue vs React is splitting hairs, honestly. DX wise they feel the same, whereas JQuery and Vue are worlds apart.
    - recursive 2y ago
      Not to me. React's insistence on immutability can be difficult to work around.
- wruza 2y ago
  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.
  - 1GZ0 2y ago
    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.
    - CafeRacer 2y ago
      How is Svetle complexity is different and why is JS-vanilla-like Svetle complexity is better than React-like complexity?
      - wruza 2y ago
        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".

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

by 1GZ0 2y ago

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

CafeRacer 2y ago

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

1GZ0 2y ago
Agree completely, but if you "need" that level of complexity, I'd rather be working with Vue or Svelte.
- CafeRacer 2y ago
  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.
  - 1GZ0 2y ago
    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.
    - shadowgovt 2y ago
      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).
      - wruza 2y ago
        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.
        shadowgovt 2y ago
        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).
        wruza 2y ago
        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-template-compilation 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.
- Capricorn2481 2y ago
  Vue vs React is splitting hairs, honestly. DX wise they feel the same, whereas JQuery and Vue are worlds apart.
  - recursive 2y ago
    Not to me. React's insistence on immutability can be difficult to work around.
wruza 2y ago
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.
- 1GZ0 2y ago
  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.
  - CafeRacer 2y ago
    How is Svetle complexity is different and why is JS-vanilla-like Svetle complexity is better than React-like complexity?
    - wruza 2y ago
      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".