Comment by Illniyar | Hacker News Reader

Comment by Illniyar | Hacker News Reader

There are a few issues with these:

1) "Server-side rendering can be faster" - the information in this part quietly ignores the fact that:

  * even if you have server-side rendering, you are still going to load external javascript/css files

  * browsers optimize multiple resource loading by opening multiple concurrent connections and reusing connections

  * you can and should use cdn (hence actually lowering the 'theoretical' minimum time)

  * browsers cache excessively - and you can make them cache even for longer

  * the fact that rendering on the server-side takes a lot of cpu and hence increases response time dramatically the more requests are made

6) while reloading the page when the code changes is a good idea, hot updating javascript is a really bad idea - beyond the fact that it's terribly hard, will most likely result in memory leaks in the end and as far as I know no one is doing it, it'll be extremely hard to maintain or debug.

The rest of the principles are quite true, informative and should be practiced more often (assuming you actually have the time to engage in these kind of improvements as opposed to making more features).

Just to nuance your 1) points about server side rendering, with pro-points :

• you only need html and css loaded to show content to your user, and js loads while the user is watching content, js has some time to be ready on first interaction.

• still feels slower than showing stuff with only html+css

• for pages content that changes a lot, if you rely on cdn for html pages, you need to update content with js on page load and you either ends up with a splash wait-while-we-are-loading or a blinking christmas tree.

• if your html is small enough, the cache checking round-trip is not that faster than loading content, while a JS rendering will need cache round trip AND data loading round trip. You can eliminate some html round trip with cache expiration, but at the expense of reliable deployments.

• still, JS rendering/update can be slower than server side CPU, especially on mobile devices.

There is a very simple way to get both maximum cache (without cache round trip, I.E. the ETag or Older-then) and reliable deployments - use version identifiers on the url and no expiration cache.

The only thing that the browser should always load is your base html, and have a single linked js/css that is concatenated and compressed, whose url changes every deployment - most web frameworks already have a way of doing it (Rails, Django etc...).

This is not entirely true, I believe:

1. With server-side rendering browser can get HTML and display it before other resources are downloaded, parsed and executed (for JS).

2. In pre HTTP/2 world resource requests can be expensive, since browsers limit the number of outstanding requests.

3. Some users still use slow phones with slow and laggy network connection. Server-side rendering can improve experience for them a lot.

You can send a pre rendered HTML shell with text content, when using server side rendering with something like React, quite quickly. I think this gives users a very nice experience especially compared to staring at a blank page!

Reply on news.ycombinator.com