Hacker News Reader

Why does this have to be the baseline architecture when you can render the HTML on the server with the template and data? Why send the data and the JavaScript to parse that data and transform it into HTML in a users browser when you can do it on the server?

For requests after the first, you can still continue to send the rendered HTML to be placed into the document. Here's an example using HTMX: https://htmx.org/examples/lazy-load/

View on HN

If your app is simple enough, go ahead and do that. In nearly every app I've worked on, I eventually need some dynamic piece of content. Like even a date picker, so you really want to call the server every time the use wants to go to the next month?

Why on earth would you drive a date picker from the server? No one is saying to do that. JS is absolutely fine to build custom UI controls. The form the date picker renders in doesn't need to be 100% JS though.

Use JS to patch over things the browser doesn't implement and let it handle the rest.

Ok, at least we agree on something. I think that's fine if your app is simple enough, but the more and more dynamic it gets, at a certain point, I think it makes sense to just render the whole darn thing in JS. At least for the DX.

Reply on news.ycombinator.com