4 ms·

This approach introduces a lot more pain from experience: "From experience" — that's the thing. "YOUR" experience. As a JS DEV I've experienced a lot of good a

This approach introduces a lot more pain from experience: "From experience" — that's the thing. "YOUR" experience. As a JS DEV I've experienced a lot of good and bad examples. When things are done right, SPAs are a pleasure to work with and a pleasure to use. 1. Having to maintain and upgrade SPA type frameworks is hell and you have to do that sometimes (think Angular upgrade hell). Can't afford to start again every 5 years. That is true. But that is also true for the backend frameworks too. All major upgrades introduce breaking changes. That's not SPA specific. And a properly written SPA (or any other application) is very upgradable. 2. The performance, and the article actually states it, is shitty at the best of times. All it takes is one client running mandatory IE11 on Citrix and you lose a customer. Absolutely not. When done right, the performance is on-par with a regular backend-framework-served website. 3. Most of the complexity is hard complexity that has to be there to process rules. Rules are way more complex than you want to run on a client in some cases. This is too ambiguous to comment on. Butter is buttery? 4. They are incredibly difficult to test. Go try testing a big SPA with selenium for example. Absolutely not true. They are a blast to test. Once again, when done right. 5. Security boundaries are terribly difficult to enforce when half of your application isn't inside your control. Having done desktop development for a number of years, the worst turds I've seen are in that space and the SPA brings them all to the web which is one of the most hacked up evolutionary disasters we have ever created. Really our responsibility as engineers, architects, developers is to give the user the best experience and that means the fastest and most reliable one. SPAs are neither. KISS is a mentality we should be using and I can build a better user experience without SPAs. That is your opinion. You can build a better user experience without SPAs, I can build a better user experience with SPAs. Who's right then? The comments you wrote are applicable to ANY application (not just SPAs) when it's not done right. But it looks like it's somewhat of a trend here to blame everything on badly developed SPAs.

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

candiodari 8y ago

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.