4 ms·

> Nope. It very much is not. Because an SPA doesn't start working until it's done 5-10 server round trips, the slowest part of any website interaction. Regular-

> Nope. It very much is not. Because an SPA doesn't start working until it's done 5-10 server round trips, the slowest part of any website interaction. Regular-backend-framework-served websites are functional after 1 server round trip. Incorrect. A server-side-rendered SPA will be just as functional as the regular-backend-framework-served website, that is functional after 1 server round trip, as in the html is served to the client. This is the big problem with people who don't know how SPAs should be done. And you keep on circling the problems that should be blamed on poorly written applications and bad design choices, not SPAs as a paradigm. The rest of your arguments seems to be based on the fact that you do not know how properly written SPAs are supposed to function, ergo the rest of your arguments is invalid, sorry.

candiodari 8y ago
Server rendering: Request Reply (maybe some images come next, but the site is functional. Ie. showing actual useful data, also images, css, ... are simply common between both app types. Both can be inlined if you want to avoid the cost) SPA: html reply request javascript reply request javascript dependencies reply request the actual useful data the site intends to show reply (note that these requests NEED to happen even when cached, also SPAs are of course less cacheable than server rendering) That's 4x slower minimum. In practice, unless you implement pipelining in your api (ie. fat chance) the request javascript dependencies and request useful data steps really have to happen 5x or 10x. This will turn what is already a disaster into a global catastrophe. Also it doesn't matter what the best developers do, for the reputation of actual types of apps. It matters what the average (ie. very bad) developers do.
- mercer 8y ago
  Not to mention parsing the javascript, and then generating the HTML and/or DOM tree. Sure, you can do SSR first, but then you're still doing SSR for the first load anyways.

candiodari 8y ago

Server rendering: Request Reply (maybe some images come next, but the site is functional. Ie. showing actual useful data, also images, css, ... are simply common between both app types. Both can be inlined if you want to avoid the cost) SPA: html reply request javascript reply request javascript dependencies reply request the actual useful data the site intends to show reply (note that these requests NEED to happen even when cached, also SPAs are of course less cacheable than server rendering) That's 4x slower minimum. In practice, unless you implement pipelining in your api (ie. fat chance) the request javascript dependencies and request useful data steps really have to happen 5x or 10x. This will turn what is already a disaster into a global catastrophe. Also it doesn't matter what the best developers do, for the reputation of actual types of apps. It matters what the average (ie. very bad) developers do.

mercer 8y ago
Not to mention parsing the javascript, and then generating the HTML and/or DOM tree. Sure, you can do SSR first, but then you're still doing SSR for the first load anyways.