4 ms·
This breaks once you need to update parts of the page without reloading everything.
by JaggerJo 3y ago
This breaks once you need to update parts of the page without reloading everything.
- marginalia_nu 3y agoIn that case you can just parse the DOM clientside and insert it into the page.
- loloquwowndueo 3y agoYou can still return html partials from your endpoints and use htmx to swap content without a full reload :)
- JaggerJo 3y agoyes, but then it’s not one request per page
- loloquwowndueo 3y agoOnly if there’s an update - htmx will encourage you to render full html pages but still gives you the ability to do in-place updates which is what most folks think a JS front end with a json Api backend and client side rendering is needed for.
- halfcat 3y agoHTMX can swap multiple DOM elements from a single HTTP response https://htmx.org/extensions/multi-swap/ https://htmx.org/extensions/multi-swap/
- Y-bar 3y agoJS can update the DOM dynamically. Nothing prevents the main response from being served as regular HTML and subsequent XHR request for some parts of a page being JSON or some such data format. In fact I bet that sending server-side rendered HTML is faster than sending a full structured page as JSON which has to be decoded, parsed, and then converted to HTML.
- holoduke 3y agoI run a popular app (native ios and android) and a web version. I find having A single json serving api much easier to maintain. The frontends are isolated projects. The backend is just a simple layer with static data served as json. If you would have static html it means you need to update all static files whenever a ui change is needed. Makes it overly complicated. Caching becomes also a challenge and the so does the performance. Currently just running a few Hetzner instances to serve 50k requests per second. That would be really hard with a server side rendered html.
- Y-bar 3y ago> If you would have static html it means you need to update all static files whenever a ui change is needed. Makes it overly complicated We do use a templating engine and separate CSS files, so no, not at all, all static files does not need updating on every change. > Caching becomes also a challenge and the so does the performance Not at all, not even on black fridays. > That would be really hard with a server side rendered html. Why do you pose that hypothetical when our real-world experience is easy?
- halfcat 3y agoDo you build each interface with different tools (e.g. Swift, Java, and React), or one of the unifying tools (Flutter, React Native, etc)?
- robertoandred 3y agoThen you're stuck with two kinds of templating.
- timeon 3y agoReminds me early AYAX days.
- vidarh 3y agoAround 2005 was the first time I "accelerated" a website by requesting the whole page in the background and swapping out what had changed. We eventually trimmed what was returned a bit, but just getting rid of the page transition was 90% of the work.
- strictfp 3y agoThat's true. But that's only really a concert if you're building an SPA. If you're not, having multiple pages is generally faster than running some js framework to reload parts of the page. Plus that you get the benefit of every state combination having it's own URL. You don't need to write any custom state reconstruction code. This was the original design of REST as applied to the web. It was explicitly designed in such a way that it was forbidden to reload parts of the page. This makes it so that every state has it's own URL and you therefore can link to every state. Deep linking if you wish, for all of the web.
- runeks 3y agoThe is exactly what HTMX does and it works: allow returning a HTML response and statically annotating a part of the DOM to be replaced with that. Granted, this requires JavaScript on the front end, but it's a framework that can be shared between different websites, so you're not writing any custom JavaScript for your site.