3 ms·
Sounds like HTMX? So far I have failed to understand the attraction of this solution outside of very small personal projects. Front end is not just a presentati
by palmer_fox 3y ago
Sounds like HTMX? So far I have failed to understand the attraction of this solution outside of very small personal projects. Front end is not just a presentational layer - we are rendering _data_, so having business logic on the front end makes perfect sense. I have built many BE template driven websites in the past (early 2000s PHP, then Django) and this approach does not scale well.
What parts of the page do you reload with HTMX when user's state changes? A GET request to retrieve updated page header? Another request to retrieve updated page footer? Another request to reload the dropdown menu below a post? All of which could be rerefencing user's state.
And then do you implement endpoints for literally every partial and propagate state to all these endpoints?
- infamia 3y agoIt doesn't have to work like that. You can fetch the entire body and then let HTMX or whatever hypermedia lib you're using DOM diff the parts that have changed in place.
- otikik 3y agoNo familiarity with HTMX, but familiar with the thing I linked. There, you render the whole page on the server side. The js "picks" which parts it needs to refresh by essentially using specific classes/attributes. It is a very "pedestrian" system, really. The fact that the whole page is sent is what makes "graceful degradation" possible. > Front end is not just a presentational layer I agree that front is not a presentational layer in all projects, but I also think that most web projects out there are CRUD-like, and for a lot of those, front can be just a presentational layer. I'm just saying that the effort of making front more than that and going the Single Page App route needs to be justified by some business reason - even something vague like "we want to leave the door open releasing a mobile app later so we need an API anyway".