4 ms·
I still do not get the point of Htmx of doing the templating in the server side. Maybe it is just me. Can anybody explain it better why mixing templates in the
by jordiburgos 1mo ago
I still do not get the point of Htmx of doing the templating in the server side. Maybe it is just me.
Can anybody explain it better why mixing templates in the backed and HTML in the frontend opposite to keep all the HTML + templates in the browser and only return JSON from the server.
- mkrd 1mo agoWhen sending json data, the browser has to run javascript to parse incoming data, keep track of it, and assemble the UI based on that data. One of the hardest parts of webdev is to synchronize server and frontend state, so there is a lot of things that can go wrong here, you are essentially maintaining the same state in two locations. With htmx, there is no frontend state. The html always just reflects the state of the server passively, meaning it cannot go out of sync. When you do something on the frontend and submit some request, the server will update its state and replace the frontend html to reflect that exactly. Here is an example. Traditional react app: Submit new todo item, append to some reactive js list, update frontend list, send new item to server. Here, you have to ensure that both sides did exactly the same thing, and if either side errors, you have to backtrack. Htmx app: Submit new todo item, send request to server, server stores it into its database, renders new list based on new database state, client replaces the list. Here, the server has the complete authority, and the frontend merely reflects that. If something fails, the server returns the old list plus an error. This is a tradeoff in efficiency, but the hope is that eliminating frontend state management is worth it.