4 ms·

> The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised. Does it? To me, it see

by least 2y ago

> The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised. Does it? To me, it seems more proof that software development trends are cyclical. It's also just not all that apparent that things like HTMX are all that popular. React is much more popular than any of them, and then JQuery remains even more popular than React, at least in terms of finding it on the web. Working with XHR sending full HTML responses, it's pretty clear to me that there's some major tradeoffs to this approach. The payload sizes are larger and interactivity is dependent on round trips to the server. so you're increasing server load and are increasing payload sizes to save on client side processing. If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results, for example. So you click a column header, then you're sending another request to the server, asking for a new table with the newly sorted rows, it renders it, sends it back to the client, and then replaced the entirety of the table contents with the new contents. and then htmx does some magic to make it behave closer to native HTML (like enabling css transitions on replaced elements, for example). Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data. I'm all for sending plain html from the server. If your views are static and largely unchanging, then sure, by all means, send it over. You don't need a JSON response to render a blog post on the frontend. But as soon as you want any sort of interactivity in your forms or data views, then you probably don't want to make every interaction a round trip to the server and then you're back at having to think about state on the client, at which point objects in JS are just going to facilitate your needs better than html elements.

thunky 2y ago
> If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results > Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data. Only if you're only working with a tiny amount of data... For example, say you have a dataset with 10k records. You're not going to want to send that all to the client so it can sort it locally. Much more efficient to send just the first 100 or whatever results. Then when the user clicks the sort button, ask the backend to re-sort it and give you the first 100 results again. Bonus: those 100 results are already formatted as html table rows and htmx easily slots them right into the correct spot on the page.
- least 2y ago
  It depends on the sort of data you're looking at, but definitely agree that you will need to hit the server sometimes, depending on the number of records you're looking at. Though even 10k row dataset can actually be handled quite easily with modest computers/phones. I'm not saying you should be doing that, but that would have more to do with usability than the client not being able to handle it. But even with a modest 100 rows being retrieved, the payload size of fully rendered HTML is generally going to be substantially larger than JSON. These add up quickly when you're making round trip requests to the server for interactivity, especially if it's something like reordering tables. This is a clear tradeoff and it's why we see trends like this oscillate between client-side and server-side. I think React is seeing the downsides of being entirely client-side, which is why there's so much development into server side components. Conversely, things like HTMX are tackling problems of handling local state, client/server side caching, and well, payload sizes.
  - thunky 2y ago
    That's true but if you're concerned about payload sizes then 10k records is way too much to pre-send, and in general I think it's safer to depend on the server sending a known max size of html than it is to pre-send all the json every time. Unless you're using tailwind or some other variation of inline styles, I don't think a typical formatted <tr> is going to be much bigger than a json record anyway. It might even be smaller if the json includes extra attributes that don't make it out to the html. But I agree that if you know you have a tiny amount of data and you don't want to involve a server then it would be better to do the entire interaction client side. But nothing prevents you from plugging in a small client side lib (not react) and using server-side for everything you can.
  - yawaramin 2y ago
    > the payload size of fully rendered HTML is generally going to be substantially larger than JSON. Substantially larger? No, I don't think so. Maybe slightly larger, but if you are compressing your responses (a best practice), there should not be a significant difference between them. And, while in a theoretical perfect world you send exactly the JSON needed for each response, in real-world conditions JSON APIs are quite often overfetching and making too many calls in the first place. Evidence: just look at any typical React-based webapp accessible to the public. Meanwhile with htmx you can render and send the exact HTML you need for the response, and any overfetching is immediately obvious because it's all shown on the page.

by least 2y ago

thunky 2y ago

> If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results > Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data. Only if you're only working with a tiny amount of data... For example, say you have a dataset with 10k records. You're not going to want to send that all to the client so it can sort it locally. Much more efficient to send just the first 100 or whatever results. Then when the user clicks the sort button, ask the backend to re-sort it and give you the first 100 results again. Bonus: those 100 results are already formatted as html table rows and htmx easily slots them right into the correct spot on the page.

least 2y ago
It depends on the sort of data you're looking at, but definitely agree that you will need to hit the server sometimes, depending on the number of records you're looking at. Though even 10k row dataset can actually be handled quite easily with modest computers/phones. I'm not saying you should be doing that, but that would have more to do with usability than the client not being able to handle it. But even with a modest 100 rows being retrieved, the payload size of fully rendered HTML is generally going to be substantially larger than JSON. These add up quickly when you're making round trip requests to the server for interactivity, especially if it's something like reordering tables. This is a clear tradeoff and it's why we see trends like this oscillate between client-side and server-side. I think React is seeing the downsides of being entirely client-side, which is why there's so much development into server side components. Conversely, things like HTMX are tackling problems of handling local state, client/server side caching, and well, payload sizes.
- thunky 2y ago
  That's true but if you're concerned about payload sizes then 10k records is way too much to pre-send, and in general I think it's safer to depend on the server sending a known max size of html than it is to pre-send all the json every time. Unless you're using tailwind or some other variation of inline styles, I don't think a typical formatted <tr> is going to be much bigger than a json record anyway. It might even be smaller if the json includes extra attributes that don't make it out to the html. But I agree that if you know you have a tiny amount of data and you don't want to involve a server then it would be better to do the entire interaction client side. But nothing prevents you from plugging in a small client side lib (not react) and using server-side for everything you can.
- yawaramin 2y ago
  > the payload size of fully rendered HTML is generally going to be substantially larger than JSON. Substantially larger? No, I don't think so. Maybe slightly larger, but if you are compressing your responses (a best practice), there should not be a significant difference between them. And, while in a theoretical perfect world you send exactly the JSON needed for each response, in real-world conditions JSON APIs are quite often overfetching and making too many calls in the first place. Evidence: just look at any typical React-based webapp accessible to the public. Meanwhile with htmx you can render and send the exact HTML you need for the response, and any overfetching is immediately obvious because it's all shown on the page.