Hacker News Reader

Comment by indentit | Hacker News Reader

> Another area where you can lean a lot more heavily on HTML is API responses

Please no - it is so much nicer and easier when using a website with poor UI/filtering capabilities/whatever, to look at the network requests tab from devtools in the browser and get json output which you can work with however you want locally versus getting html and having to remove the presentation fluff from it only to discover it doesn't include the fields you want anyway because it is assuming it should only be used for the specific table UI... Plus these days internet while out and about isn't necessarily fast, and wasting bandwidth for UI which could be defined once in JS and cached is annoying

View on HN

> only to discover it doesn't include the fields you want anyway because it is assuming it should only be used for the specific table UI

It sounds like you're complaining that a server isn't shipping bits that it knows the client isn't going to use?

> wasting bandwidth for UI which could be defined once in JS and cached is annoying

How much smaller is the data encoded as JSON than the same data encoded as an HTML table? Particularly if compression is enabled?

ETA: And even more so, if the JSON has fields which the client is just throwing away anyway?

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.

The main advantage of using JSON would be to allow non-HTML-based clients to use the same API endpoints. But with everyone using electron these days, that's less of an issue.

> How much smaller is the data encoded as JSON than the same data encoded as an HTML table? Particularly if compression is enabled?

Well, as many things in life, it depends. If the cells are just text, there is no much difference. But, if the cells are components (for example, popover things or custom buttons that redirect to other parts of the site), the difference of not shipping all those components per cell and rendering them on the frontend starts to become noticeable.

How lucky then that WebComponents exist, and we don't actually have to ship the whole DOM for each cell...

So a backend-focused team that minimizes frontend is going to start fiddling with the DOM and shipping web components.

Sure, tell me more. I always enjoy a cool story.

Eh, I don't really think the frontend/backend distinction in webdev should exist. Your react components still get served from a backend too (even if they are static html).

> 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.

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.

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.

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

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...

The server rarely has to render/build the html. It will do it once and then cache it. 99% of websites don’t have real time data. They are just boring webpages.

As someone else who does this, I think we're a pretty small audience. People shouldn't be building web apps with our reverse engineering experience in mind.

Reply on news.ycombinator.com