3 ms·
> 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 se
by aembleton 10mo ago
> 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.
- turtlebits 10mo agoIn 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 10mo agoHaving 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 10mo agoThat'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.
- wvbdmp 10mo agoBut 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 10mo agoI'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 10mo agoThe '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.