Hacker News Reader

Comment by jhp123 | Hacker News Reader

> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded.

but the page is loaded later because you have to wait for the server to perform this work. There is no reduction in total work, probably an absolute increase because some logic is duplicated. If there is a speed improvement it is because the server has more clock cycles available than the client, but this is not always true.

> Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase.

Huh? It takes less code to build a string in a datacenter than it does in a browser?

View on HN

> but the page is loaded later because you have to wait for the server to perform this work. There is no reduction in total work

Removing or shortening round trips absolutely removes work. Sending you a page, letting you parse the JavaScript, execute it to find out the calls to make, sending that to the API, the API decoding it and pulling from the database, rendering the JSON and returning that, you parsing the JSON, executing the JavaScript and modifying the DOM

Pulling from the JSON and rendering the HTML, sending it to you to render

Seems like the latter has less total work.

yes, reducing round trips is very important for web performance. It can be done via a server-side architecture where external resources are sent immediately as prefetch headers, then the page is generated and sent after database calls etc are made. Or via a client-side architecture where API calls needed for initial render are either sent via prefetch headers, or included inline in the HTML response.

If you don't need page interactivity then a pure server-side approach works best because you do not need to send, parse, or execute any page logic. For highly interactive pages you tend to need all the logic to rerender each component on the frontend anyway, so client-side rendering makes sense as a simpler approach without significant performance costs. Isomorphic approaches are more complex and brittle, they tend to hurt time to full page interactivity because of duplicated work, but can be needed for SEO. Reducing overall page weight and complexity and lazy-loading where possible, and getting rid of the damn tracking pixels and assorted third-party gunk, are often more effective directions for optimization than worrying about where HTML is generated.

> There is no reduction in total work, probably an absolute increase because some logic is duplicated

The server is either building a JSON (or some other message format) response, or, it could just build the relevant HTML fragment. In many cases, there is no real increase in actual work on the server.

Conversely, the client side doesn't need to parse JSON and convert it to a DOM fragment.

There's solid reasons for both approaches, depending upon the context.

> no reduction in total work

This does not 100% track with observed client-side performance. Another poster mentioned caching, which obviously reduces total work. I would also add shifting the work via pre-computation as another commonplace way to improve performance.

> It takes less code to build a string in a datacenter than it does in a browser?

The string build in a datacenter might be happening in a warmed-up JIT of some language, on a machine with enough capacity to do this effectively. By contrast, the browser is possibly the slowest CPU under the most outside constraints (throttling due to power, low RAM, multitasking, etc.). It is generally going to be better to do the work in the datacenter if possible.

>but the page is loaded later because you have to wait for the server to perform this work.

Client-side rendering isn't immune to this. The server APIs they hit have to render the response in JSON after hitting the same kinds of backend resources (e.g. DB).

>but the page is loaded later because you have to wait for the server to perform this work.

What is caching?

Caching also works for client side rendering of course (you can usually cache the entire client side app so that the browser doesn't have to hit the network at all to start running client side code).

> you can usually cache the entire client side app so that the browser doesn't have to hit the network at all to start running client side code

This is also true for Web apps that do not have meaningful amounts of client-side code.

> Caching also works for client side rendering

There are obviously a lot of differences in how caching works, but client-side caching is generally strictly worse than doing so on the server. Using the e-commerce example in TFA, every browser has to maintain their own cache of the product information, which may include cache-busting things like prices, promotional blurbs, etc.

The server can maintain a single cache for all users, and can pre-warm the cache before any users ever see the page. Adding fragment caching, which allows parts of a page to be cached, a server-side caching strategy will typically result in less total work being done across the user population, as well as less work done at request time for each visitor.

As with SSR vs CSR in general, I think which is best depends on how much interactivity there is on the page. And also how much can be done entirely on the client side (it is possible to cache data client side too and make the app work entirely offline).

As an extreme example, something like https://www.photopea.com/ would be a nightmare to use if it was server-side rendered. Or consider something like Google Maps. For things like ecommerce that are mainly focussed on presenting information I agree that client side rendering doesn't make a whole lot of sense. But that isn't the whole web.

> how much interactivity there is on the page

Yes, and also how much interactivity is better served by a thick browser-based client than by a round-trip to the datacenter. In practice, many Web applications we encounter daily have relatively low interactivity (where something like Google Maps or the Spotify Web player score as "high"). And then they are implemented using thick frameworks that are frequently slower than a round-trip to a server for re-rendering the entire page was even as far back as 10 or 20 years ago.

Your extreme examples, plus applications like Figma, are absolutely places where I would expect to see thick client-side Javascript. However, most Web applications that we encounter frequently are more like e-commerce, blogs, recipe websites, brochureware sites, landing pages and the like that absolutely are primarily about presenting information. Using thick browser clients is a sub-optimization for most of those Web uses.

> However, most Web applications that we encounter frequently are more like e-commerce, blogs, recipe websites, brochureware sites, landing pages and the like that absolutely are primarily about presenting information. Using thick browser clients is a sub-optimization for most of those Web uses.

I mean sure (although I'd probably make a distinction in the terminology and call those websites as opposed to web applications). I don't see many of those kind of websites using client side rendering though. I think the grey area is sites like Gmail which do have quite a bit of interactivity but would also be workable with SSR. Personally I think they're generally better using CSR. If done badly as the current gmail is then it makes things slow, but if done well (like the older gmail!) then it's faster.

Reply on news.ycombinator.com