4 ms·

Why is this so easy to read compared to React? https://github.com/HeyPuter/puter/blob/master/src/UI/PuterDialog.js https://github.com/HeyPuter/puter/blob/master

• ashishb 3y ago
  The JSX syntax makes React hard to read due to multiple layers of nesting. IMHO, Vue is superior for both maintainability and readability than React. Especially because CSS, JS anda HTML are largely in separate blocks of the same file.
  • benatkin 3y ago
    You can see this in that Flutter didn't copy JSX and its usability seems better. Not that I'm confident Flutter is worth the trade-offs.
    • pmarreck 3y ago
      narrator: It's not.
    • mightyham 3y ago
      I'm confused about what you mean by this. There's nothing about Flutter's API that encourages less nesting, In fact, it's the exact opposite. Plenty of layout and styling that takes a number of nested widgets in Flutter can be achieved using a single div in React.
  • CharlieDigital 3y ago
    I can understand some of the benefits of JSX, but compared to Vue SFC's, it's a mess to read. React CSS modules feel so unwieldy compared to Vue SFC's inline `scoped` CSS. Vue's approach to templating using `v-for` and `v-if` means that you won't end up with a big block of logic mixed in with the template (you can still do it, but Vue's nature steers you away from it).
  • noduerme 3y ago
    Arguably they should all be in external files. HTML in one, CSS in another, and Javascript to load and cache them without any embedded strings. That's how I prefer to write. For one thing, it lets me choose which things I want to cache and which I don't. I can compile from SCSS and deploy without changing any JS or HTML files. Usually my rollups are just the JS.
• jahewson 3y ago
  Because it’s trivial?
• pcloadletter_ 3y ago
  That's a pretty small component and I think folks would find a comparable React component also pretty easy to read. Conversely: https://github.com/HeyPuter/puter/blob/master/src/UI/UIDesktop.js https://github.com/HeyPuter/puter/blob/master/src/UI/UIDeskt...
  • ent101 3y ago
    I'm sorry XD
    • pcloadletter_ 3y ago
      Ha, I am not criticizing your work at all. It's nothing short of jaw-dropping.
• divbzero 3y ago
  I guess “React makes sense for more complex UIs” is not hard-and-fast rule. jQuery, apparently, is more than enough for clean working frontend code.
  • omeid2 3y ago
    It is not about complex UI per se, it is about complex state. With jQuery, the State is duplicated in the DOM instead of mirrored and is very hard to keep in sync.
    • FpUser 3y ago
      >"State is duplicated in the DOM instead of mirrored" And the difference between duplicated and mirrored is ...
      • deleted 3y ago
        [deleted]
      • omeid2 3y ago
        Fair question. Mirrored means when you update state, your changes are reflected in the DOM, automagically. Duplicated means when you change state, you also have to make the changes to the DOM, yourself.
        • divbzero 3y ago
          Clear (mostly one-way) data binding is definitely one of React’s strengths. It appears that Puter handles templating with a pattern like: let h = `` h += `<div>${exampleContent}</div>` h += `<div>${moreExampleContent}</div>` $(targetEl).append(h) And handles events in the traditional way: $(targetEl).on('click', function () { /* do stuff */ }); Searching for “React” or “jQuery” in this thread, there are several other conversations with thoughtful comments about pros and cons. One curious tidbit that I learned is that Visual Studio Code doesn’t use a framework either and, like Puter, updates the DOM directly.
• blackoil 3y ago
  This component has no state, no data fetch or transitions. It doesn't even have any dynamic part.
• raggi 3y ago
  Despite being asynchronous it contains a single linear schedule and two callbacks. The obvious outcome is two layered constructors, and a single top level API object with two custom events. You couldn't describe what was going on in an equivalent functional construction of a react version unless you first head off on a diatribe about signals/hooks/state-management-disaster-du-jour, the choice of use of which would have implications to both the event handlers in some way - though they likely couldn't be in-place here, they'd have to be passed down from parent context in a giant dance of inversion of control. At runtime the outcome would likely get parsed twice (once for shadow, once for insertion) if not more times under certain compositions. Here the jquery is almost incidental, and could be quickly replaced by something else - for example want to swap out htmx here, well, just add the markers to the DOM, delete the jquery lines and you're done. You'd probably need to spend at least an hour figuring out if you could fit something independent and platform-native into your react code base, hell I've seen people burn weeks on it.
• deleted 3y ago
  [deleted]