> And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item

> And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place. Nothing stops a dev from providing both a server-side render and an API endpoint, for those that don't want the JS soup. In fact, such a design is not uncommon, and it's fairly straightforward to write a backend interface that both the server-side rendered endpoint handler and the API endpoint handler can use. > HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloaded once (and we can send the initial data with it), and then it can become interactive from there. e.g. if the data needs to be reloaded we can make a small JSON request instead of reloading the whole page and re-rendering it. The "smart" thing to do depends on what your requirements are. For minimal latency, server-side rendering tends to fare much better, as it requires only one round trip to fetch all the necessary information to render the page contents.