Remix.run Logo
coneonthefloor 12 hours ago

> What seems wasteful to me is to have the server spend CPU cycles rendering data into JSON, only to have the front-end decode from JSON into internal JS representation, then back into HTML (which is then decoded back into an internal browser representation before being painted on the screen). Seems better to just render it into HTML on the server side, if you know what it's going to look like.

Well put. I think the main issue is that we have a generation of "front end engineers" who have only ever worked with javascript apps. They have no experience of how easy it is to write html and send it via a server. The same html works now, worked 20 years ago, and will work 20 years from now.

tdeck 11 hours ago | parent | next [-]

This is why many websites (even ones light on interactive functionality) now display a progress bar after loading the website. It's a big step backward for user experience and I even see it on blogs.

javcasas 11 hours ago | parent | prev [-]

Your average veteran "front end engineer" has implemented las month half a dozen features that almost impossible to do server-side only, "just send the HTML, dude".

Progressive enhancement, forms with fields depending on other fields, real time updates, automated retries when the backend is down, advanced date selectors, maps with any kind of interactivity.

Any of the above is an order of magnitude harder to do backend-only vs backend API + any frontend.

cenamus 11 hours ago | parent [-]

Who says you can't use any JS when doing server side rendering?

And why would you even want progressive enhancement if you can just send the proper full version right away, without waiting for MBs of JS to "hydrate" and "enhance" the page

javcasas 10 hours ago | parent [-]

You know, you went direct for the "bait" case, while ignoring all the others.

Progressive enhancement is often done to mask the fact that fetching the data takes an unacceptable amount of time, otherwise no effort would be done to mask it.

Your plan is to take that same unacceptable time, and add the server side render-to-html time on top of it, and that will improve it via...