4 ms·

The problem is that badly developed SPAs are a lot worse, heavier, slower, and more irritating than badly developed request-response "webapps". And God help you

The problem is that badly developed SPAs are a lot worse, heavier, slower, and more irritating than badly developed request-response "webapps". And God help you if you need accessibility. They also have the same sort of problems that Flash used to have. And there, too, you can say, that it was possible to write better apps in flash than the best you can write in HTML. It really was. There were a few really nice examples. But ... it wasn't happening. Vast majority of flash apps sucked beyond belief. Same is true for SPAs. > Absolutely not. When done right, the performance is on-par with a regular backend-framework-served website. 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. This is the big problem I have with SPA developers. In order to save on server round trips you make more of them. Logic at the client side. That's the theory. But they actually need more roundtrips in almost all cases, and many more during startup. So they start slower, they run slower. So I have 2 very big problems with SPAs: 1) the "flash problem": the website owners have "more control". And they invariably use it to create heavy, slow "beautiful" monstrosities that border on unusable. 2) even if written well, they are a lot slower. First at startup, and also once running. Server round trip are the overriding cost and SPAs actually do more of them. The actual amount of data in a request, as long as it's less than, say 20kb or so, doesn't actually matter.

bestest 8y ago
> 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.

bestest 8y ago

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