2 ms·

What if you're building a highly interactive front end?

JodieBenitez 1y ago
That might be a case where you want a SPA + backend API. But the point is that in many cases you either don't need a highly interactive frontend or the frontend is not that interactive (ie. progressive enhancements work).
- b_e_n_t_o_n 1y ago
  Ime progressive enhancements are brittle and hard to maintain. If your site doesn't need any JS it's fine, but as soon as it needs some interactivity beyond the absolute basics you benefit from having reusable components and automatic change detection / data binding.
  - JodieBenitez 1y ago
    Not true anymore, as tools like unpoly, htmx and the like make it really easy to integrate and maintain with very little dependency and no build step.
    - b_e_n_t_o_n 1y ago
      Those are part of what I'm talking about re. brittle and hard to maintain. Similar to jquery, just server sideZ
      - JodieBenitez 1y ago
        I fail to see the connection with jquery. Anyway brittle and hard to maintain is what we experience now with frontend stacks and codebases with very short lifespan. I can't keep track of components libs du jour that come and go and keep being reinvented with very little value added on each iteration, along with constant api breakage. Brittle, indeed. Meanwhile, Rails and Django have been rock solid.
        b_e_n_t_o_n 1y ago
        Both jquery and htmx style approaches lack the concept of components, data flow, template binding etc. At most you get string templates. You end up manually wiring up dom updates when state changes, and that kind of thing is brittle and is why stuff like React was invented in the first place. React has been very stable throughout its life time. You can run 10yo react code in v19x without issues.
        array_key_first 1y ago
        The reason HTMX lacks the concept of components is because you already have components. Components are backend logic in an SSR application. If we have some component and the associated HTML BS JS, we're good to go. Virtually all backend frameworks have components. Whats the advantage of this? We have one component. When we use react or vue, we now have two. The backend one and the frontend one, and they're not the same component. We can kind of force them to talk together over JSON and an API.
AstroBen 1y ago
"Islands" are really nice for this. The highly interactive pieces are usually only a small part of the app - just mount a component there if it's suitable. You don't need a full blown SPA
- tshaddox 1y ago
  Islands probably have some runtime performance benefits, but the dev experience and build-time complexity is probably just as high or higher than most JavaScript SPA setups.
  - array_key_first 1y ago
    IMO no, because with a SPA everything has to be a SPA, which is incredibly inconvenient. The benefit of the island is only the island has to be a SPA. The rest can be SSR.
marcosdumay 1y ago
Yes, when the thing you are building is a web application, you should use web application tools. When you are building a data browser, you should use web tools.
- b_e_n_t_o_n 1y ago
  It sounds nice in theory but then eventually you wind up needing to implement a feature where you wish you had React et al to implement it. Easier just to start with it from the beginning. Assuming you're a full stack / front end guy of course, or else I get the appeal of html only.

That might be a case where you want a SPA + backend API. But the point is that in many cases you either don't need a highly interactive frontend or the frontend is not that interactive (ie. progressive enhancements work).

b_e_n_t_o_n 1y ago
Ime progressive enhancements are brittle and hard to maintain. If your site doesn't need any JS it's fine, but as soon as it needs some interactivity beyond the absolute basics you benefit from having reusable components and automatic change detection / data binding.
- JodieBenitez 1y ago
  Not true anymore, as tools like unpoly, htmx and the like make it really easy to integrate and maintain with very little dependency and no build step.
  - b_e_n_t_o_n 1y ago
    Those are part of what I'm talking about re. brittle and hard to maintain. Similar to jquery, just server sideZ
    - JodieBenitez 1y ago
      I fail to see the connection with jquery. Anyway brittle and hard to maintain is what we experience now with frontend stacks and codebases with very short lifespan. I can't keep track of components libs du jour that come and go and keep being reinvented with very little value added on each iteration, along with constant api breakage. Brittle, indeed. Meanwhile, Rails and Django have been rock solid.
      - b_e_n_t_o_n 1y ago
        Both jquery and htmx style approaches lack the concept of components, data flow, template binding etc. At most you get string templates. You end up manually wiring up dom updates when state changes, and that kind of thing is brittle and is why stuff like React was invented in the first place. React has been very stable throughout its life time. You can run 10yo react code in v19x without issues.
        array_key_first 1y ago
        The reason HTMX lacks the concept of components is because you already have components. Components are backend logic in an SSR application. If we have some component and the associated HTML BS JS, we're good to go. Virtually all backend frameworks have components. Whats the advantage of this? We have one component. When we use react or vue, we now have two. The backend one and the frontend one, and they're not the same component. We can kind of force them to talk together over JSON and an API.

AstroBen 1y ago

"Islands" are really nice for this. The highly interactive pieces are usually only a small part of the app - just mount a component there if it's suitable. You don't need a full blown SPA

tshaddox 1y ago
Islands probably have some runtime performance benefits, but the dev experience and build-time complexity is probably just as high or higher than most JavaScript SPA setups.
- array_key_first 1y ago
  IMO no, because with a SPA everything has to be a SPA, which is incredibly inconvenient. The benefit of the island is only the island has to be a SPA. The rest can be SSR.

marcosdumay 1y ago

Yes, when the thing you are building is a web application, you should use web application tools. When you are building a data browser, you should use web tools.

b_e_n_t_o_n 1y ago
It sounds nice in theory but then eventually you wind up needing to implement a feature where you wish you had React et al to implement it. Easier just to start with it from the beginning. Assuming you're a full stack / front end guy of course, or else I get the appeal of html only.