> The server just returns HTML (not JSON, actual HTML)

Thats the thing I don't like. I don't want parts of the structure of my page coming from the backend server. I just want that to send data, as JSON and for the front end to handle that into whatever structure it deems suitable.

That way all of the front end code is in one place.

▲

wvbdmp 3 days ago | parent | next [-]

But the front end code is in one place, and that place is the server. It is true, though, that the experience greatly benefits the easier it is to manage and return partials from backend code. Some frameworks make it harder than others.

▲

aembleton 3 days ago | parent [-]

I'd rather have the often loaded static html running on a server that is optimised for that job, or served from a cache close to the user. The backend can then just serve up the dynamic content and be optimised for that job.

	▲	yawaramin 16 hours ago \| parent [-]
		The 'often loaded' static html won't help if the 'often loaded' JS bundle is re-deployed (eg, when the devs make a 'small' change) and the cache is invalidated. In that case all the users will be forced to reload the giant JS bundle over and over again, as opposed to just reloading a single resource on a single page like they would with the htmx approach.

▲

turtlebits 3 days ago | parent | prev [-]

In the simplest web server, the server returns HTML. Having the backend return JSON is where you're adding complexity. Your front end code won't even work without some base HTML.

▲

aembleton 3 days ago | parent [-]

Having the html stored both on a static html site that can be cached and in the code base of a backend server is more complex to me than keeping these concerns separate.

	▲	yawaramin 16 hours ago \| parent [-]
		That's why you just have the HTML in the backend server codebase...which can also make sure it's cached properly with HTTP caching techniques like last modification time, ETag, and so on.