• bashlk@programming.dev
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    I really like the quote in this post about how simplicity moves the complexity elsewhere. Personally, I share some of the sentiment that the author has. I have working with React since 2016 and while I will still continue to use it for the foreseeable future, I still see glimpses of something better in other frontend frameworks. Maybe this is an illusion, what I’ve noticed lately is that all framework / library sites make big claims about what they are capable of and the real limitations are only discovered when you actually use them. But a few months ago, I helped out on a Vue project and I can’t help but think that it does many things better.

    • ☆ Yσɠƚԋσʂ ☆OP
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      1 year ago

      I like the concept of React, but I find it’s much more complex than it needs to be. A lot of the complexity comes from the fact that’s not opinionated enough. For example, React is agnostic regarding what causes a render to happen, so now you have to manage the whole lifecycle as the user and decide whether the component should repaint or not.

      There’s a ClojureScript library called Reagent that uses React internally. However, it made the decision to use reactive atoms as the repainting mechanism. Components observe the state of the atom, and when it changes the component repaints. With this strategy you only have to care about the render portion of the lifecycle. To be fair, React hooks now work similarly to that.

      Another approach I found interesting was HTMX where UI is basically treated as a dumb terminal and all the logic happens server side. I do find there is a lot of value in decoupling business logic from rendering by design.

  • DessalinesA
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    2 years ago

    State (and rerenders based on changing state) as usual is the most difficult thing with front end, that react never fully got right.

    It wasn’t until I started doing android dev with compose, that I was able to step outside the react model, and think differently about the correct ways to handle it.

    I’ve been using inferno for many years(which is close to a drop in replacement for react, but more performant), but I’m finally going to rust, and sycamore / perseus for future projects, now that the performance has nearly caught up. I’m done with typescript and javascript 👏

    • ☆ Yσɠƚԋσʂ ☆OP
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      2 years ago

      I find nowadays, htmx is probably a good enough solution for most UIs. It just treats the UI as a dumb terminal that renders content and collects user input. Then all the actual logic moves to the backend.

      Personally, I’m a fan of a reactive model where the UI simply represents the state of the data. I think a lot of the complexity in React comes from the fact that it’s not opinionated regarding when a component should repaint. You have a lifecycle and it’s up to you to decide what to do within it and when.

      But you could just eliminate all but the render part of the lifecycle, and then just have reactive components observe the data and repaint when it changes. It’s a much simpler and more predictable model.

  • fernandu00
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Great text…I’m a total noonthat tried to break into tech using js and react (failed to get a job but this is another story) .but I feel like react gets complicated fast and sometimes I felt unnecessarily complex. I love learning and maybe some day in the future I’ll try another framework like the ones you recommended