8 ms·

The problem is that most SPAs today are cargo-culting. They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut

The problem is that most SPAs today are cargo-culting. They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut is on your Apple computer), at the same time break browser history, and at the same time make you wait for any single interaction you're doing (show spinning wheel for 6 seconds before opening a confirmation modal) The ideal solution is a) minimize server roundtrips (<100ms) and b) reload parts of the site via AJAX where it makes sense. No need to shovel 7MB of JavaScript to the user.

bastawhiz 9y ago
> They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut is on your Apple computer), at the same time break browser history, and at the same time make you wait for any single interaction you're doing (show spinning wheel for 6 seconds before opening a confirmation modal) I am not defending SPAs, but the points you've made are not indicative of SPAs, they're indicative of bad software. This problem existed before SPAs were a thing. Remember ASP.Net pages where the whole page is wrapped in a giant <form> and you couldn't use the back button most of the time? This problem also doesn't exist with properly built SPAs (e.g., by using <a> for links, using the history API correctly, and designing a sensible UX). And certainly, if your app is sending 7MB of JavaScript over the wire and it's not a video game, something is very wrong--SPA or not.
- reaperducer 9y ago
  I think SPAs get a bad reputation partially because they're trendy. Which means that inexperienced programmers flock to them and make them awful. I recently re-wrote an SPA from a previous dev into a regular set of query/response web pages. The SPA was 2,143K. The new set is 78K. A big part of that savings was because javascript is verboten for this project due to client hardware constraints. Yes, the previous dev was not the best in the world, but IME SPAs are always heavier than their response/query counterparts.
  - RussianCow 9y ago
    > SPAs are always heavier than their response/query counterparts Heavier by what metric? Initial load size? Sure. But the static assets will be cached after the first page load, after which an SPA should definitely be faster than a traditional server-side web app given that a) less data is sent over the wire for each page load (you don't need to re-send headers/footers, JSON is usually smaller than HTML, you can implement intelligent caching strategies, etc), and b) only a part of the page is re-rendered, rather than the entire thing every time. So "heavier" really depends on what you're optimizing for.
    - reaperducer 9y ago
      > Heavier by what metric? I measure by the amount of data sent to the client to accomplish a task. I keep a very close eye on this because it's part of my POP (proof of performance) reports each month. Don't forget that plain query/response caches many static assets, too.
      - RussianCow 9y ago
        Sure, but what about responsiveness and other metrics? Reducing the absolute amount of data sent over the wire may be what you are optimizing for, but it's not by any means the absolute metric of performance. Personally, as a user, for many web apps I would rather see a longer initial page load but have all subsequent actions appear instantaneous (a la Gmail), than spread the load times out across every action. My point isn't that SPAs are better than traditional web apps or anything like that, just that these decisions depend entirely on what you are optimizing for and what your priorities are. If initial page load time is your priority, then an SPA may not be the way to go; however, if your goal is to maximize responsiveness or interactivity, then the extra 2MB of JS will likely pay off.
  - neosavvy 9y ago
    Not trying to defend inexperienced programmers but I've seen plenty of 20+ year senior programmers contribute poorly to SPAs. They refuse to learn the best practices / new patterns because "they have 20+ years experience". I have been caught in the middle between some younger programmers and some elder folks for the body of the past 3 years and the bottom line is this: Learn the suggested best practices, or just don't build apps like this. The OP's original thoughts on simplicity do ring true, but pushing for better UX is actually a reason to redo something. There are plenty of legacy systems out there with frustrated users, and the "complexity" can be simplified if effort is invested to accomplish those goals.
- fenwick67 9y ago
  > I am not defending SPAs, but the points you've made are not indicative of SPAs, they're indicative of bad software. When it's a bug that happens on Facebook, which has millions and millions of dollars spent on their web UI and on developing whole entire frameworks for them, you can't wave it away as an application problem anymore.
- lemoncucumber 9y ago
  I agree that correctly written SPAs shouldn't break middle/ctrl click, but browsers make it harder than it should be. A few years ago I was implementing a SPA. I carefully made every clickable element that takes you to a new permalinkable "page" an <a> tag with the correct href for that permalink, and then set up some click handlers to intercept the user clicking the link and do an AJAX call instead of a full page load. Unfortunately some browsers would still send a click event for a middle or ctrl-click, which meant that if I wanted to avoid breaking that I had to write extra code to check if it was a middle click or ctrl-click and not call preventDefault if so. My recollection is that Chrome got it right but Safari and/or Firefox had the behavior I'm describing. Browsers should make it easy for apps to do the right thing, not make it harder.
deleted 9y ago
[deleted]
amsheehan 9y ago
It sounds like your experience with SPA's is the exception, not the rule. I have never built a product or website using Angular or React that performs as poorly as you describe. - Routing modules in all the major frameworks interact directly with the history APIs, and are fast as f*. - There are only a handful of locations in the US where you can expect sub 100ms server round trips, usually they're around 300ms, but lets call that negligible. The real time spent waiting is usually if you're executing some complex database query over large data sets. This has nothing to do with SPA's vs Monoliths. Even so, it sounds like you just experienced bad code if you're waiting 6 seconds for a modal to open. Also...React with React DOM is only 10kb larger than jquery, and when gzipped it's only 37kb.
- craig1f 9y ago
  I was going to say the same thing you said. Angular/React routing, if done correctly, don't have those problems at all. If you let the SPA framework do your page-changing for you, open-in-tab and history still works. If you do amateur stuff like, you bind a button to a function, and the function does an document.location.href update, then you're going to have some weirdness. My biggest problem with SPA the last time I did it (a year ago) was optimizing it for search engine crawling.
  - amsheehan 9y ago
    Google's crawler at some point last year started indexing a really large mostly text based AngularJS app I built: https://www.fwdeveryone.com https://www.fwdeveryone.com Even if it didn't, headless chrome makes it really easy to pre-render content for web crawlers.
- TheRealDunkirk 9y ago
  One of my biggest problems in writing data-heavy web applications is that browsers seem to be really lousy at handling the data. In fact I have 2 applications in this boat. My queries run fast (couple/few hundred ms), but displaying 10's of MB of data, over 10's of thousands of rows of data, has been brutal for a browser. Trying various standard JS table widgets only made the problem worse, but I've discovered ag-grid (a paid JS table widget) which made this tolerable. It takes about 6 seconds to render my big page of data (which is actually on-par with a WinForms version of the system I wrote, using DevExpress). It sounds like you have the opposite problem, and I'm wondering how you display "large data sets" from "complex database queries" in sub-second renders in a browser. Incremental loading (like a news feed) won't really work here, because my users need to be able to sort and filter and rearrange the data as a whole. I guess I could "chunk" the data to be able to see it sooner, but it's still going to hold up the browser until it finishes. I've been looking for a better way for a long time.
mfrye0 9y ago
I agree with the others. Those are signs of bad software dev, not SPAs in particular. It's relatively easy now to break up the 7MB bundle into chunks and load on demand. So you get the benefit of both the fast, small initial load while other stuff loads in the background. Then I'm not sure what you're referring to on links and waiting for single interactions... With SPAs it's actually easier with the History API to create deeply nested stateful apps via the url / links. The confirmation modal, maybe your backend API sucks? Idk what your talking about with a 6s delay. On top of that, a pure SPA means you have a static website, which means you can host the whole app off something like S3. We save so much money by hosting our stuff statically.
xmlninja 9y ago
and with serviceworkers also breaking the refresh button :D
- arrty88 9y ago
  And intercepting URLs meant for the API server
intrasight 9y ago
I see no way that a properly built SPA could perform worse than a properly built server-rendered app form a network bandwidth perspective. JSON is always smaller than HTML.
heavenlyblue 9y ago
Let us all give some credit to LastPass, which manages to tick all of the points you're making here. More importantly, at the same time being a simple browser plugin.
sibeliuss 9y ago
In much modern software this is no longer an issue.
emodendroket 9y ago
> They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut is on your Apple computer), at the same time break browser history, and at the same time make you wait for any single interaction you're doing (show spinning wheel for 6 seconds before opening a confirmation modal) > [...] > No need to shovel 7MB of JavaScript to the user. Well that's exactly the problem. Someone thinks they don't need all the "dead weight" of something like angular that solves every one of these problems and instead they do a half-assed version where it's all broken.
chrismorgan 9y ago
> minimize server roundtrips (<100ms) Not possible, because the speed of light is too low. I live in Australia. Servers tend to be in America. That hundred milliseconds has just been blown in latency, along with another hundred or two, depending on where in the US the servers happen to be. Take something like FastMail. Our servers are in the US, our team is mostly in AU. FastMail couldn’t be fast for us and many of our customers without being crafted in the SPA style—and even customers in the US benefit from its latency-compensation techniques, which reduce at least 50ms of delay (plus further page load, so call it 100ms at a minimum, but probably more like 250ms) to zero. Please don’t blame navigation-breaking on the SPA style of app; blame it on developer ignorance and occasionally laziness, with perhaps a side of unfortunate browser APIs (onclick is a poor event for this sort of thing for various reasons). And I assure you, simple JavaScript-enhanced pages manage to have at least as much problem with such links as SPAs do.

bastawhiz 9y ago

> They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut is on your Apple computer), at the same time break browser history, and at the same time make you wait for any single interaction you're doing (show spinning wheel for 6 seconds before opening a confirmation modal) I am not defending SPAs, but the points you've made are not indicative of SPAs, they're indicative of bad software. This problem existed before SPAs were a thing. Remember ASP.Net pages where the whole page is wrapped in a giant <form> and you couldn't use the back button most of the time? This problem also doesn't exist with properly built SPAs (e.g., by using <a> for links, using the history API correctly, and designing a sensible UX). And certainly, if your app is sending 7MB of JavaScript over the wire and it's not a video game, something is very wrong--SPA or not.

reaperducer 9y ago
I think SPAs get a bad reputation partially because they're trendy. Which means that inexperienced programmers flock to them and make them awful. I recently re-wrote an SPA from a previous dev into a regular set of query/response web pages. The SPA was 2,143K. The new set is 78K. A big part of that savings was because javascript is verboten for this project due to client hardware constraints. Yes, the previous dev was not the best in the world, but IME SPAs are always heavier than their response/query counterparts.
- RussianCow 9y ago
  > SPAs are always heavier than their response/query counterparts Heavier by what metric? Initial load size? Sure. But the static assets will be cached after the first page load, after which an SPA should definitely be faster than a traditional server-side web app given that a) less data is sent over the wire for each page load (you don't need to re-send headers/footers, JSON is usually smaller than HTML, you can implement intelligent caching strategies, etc), and b) only a part of the page is re-rendered, rather than the entire thing every time. So "heavier" really depends on what you're optimizing for.
  - reaperducer 9y ago
    > Heavier by what metric? I measure by the amount of data sent to the client to accomplish a task. I keep a very close eye on this because it's part of my POP (proof of performance) reports each month. Don't forget that plain query/response caches many static assets, too.
    - RussianCow 9y ago
      Sure, but what about responsiveness and other metrics? Reducing the absolute amount of data sent over the wire may be what you are optimizing for, but it's not by any means the absolute metric of performance. Personally, as a user, for many web apps I would rather see a longer initial page load but have all subsequent actions appear instantaneous (a la Gmail), than spread the load times out across every action. My point isn't that SPAs are better than traditional web apps or anything like that, just that these decisions depend entirely on what you are optimizing for and what your priorities are. If initial page load time is your priority, then an SPA may not be the way to go; however, if your goal is to maximize responsiveness or interactivity, then the extra 2MB of JS will likely pay off.
- neosavvy 9y ago
  Not trying to defend inexperienced programmers but I've seen plenty of 20+ year senior programmers contribute poorly to SPAs. They refuse to learn the best practices / new patterns because "they have 20+ years experience". I have been caught in the middle between some younger programmers and some elder folks for the body of the past 3 years and the bottom line is this: Learn the suggested best practices, or just don't build apps like this. The OP's original thoughts on simplicity do ring true, but pushing for better UX is actually a reason to redo something. There are plenty of legacy systems out there with frustrated users, and the "complexity" can be simplified if effort is invested to accomplish those goals.
fenwick67 9y ago
> I am not defending SPAs, but the points you've made are not indicative of SPAs, they're indicative of bad software. When it's a bug that happens on Facebook, which has millions and millions of dollars spent on their web UI and on developing whole entire frameworks for them, you can't wave it away as an application problem anymore.
lemoncucumber 9y ago
I agree that correctly written SPAs shouldn't break middle/ctrl click, but browsers make it harder than it should be. A few years ago I was implementing a SPA. I carefully made every clickable element that takes you to a new permalinkable "page" an <a> tag with the correct href for that permalink, and then set up some click handlers to intercept the user clicking the link and do an AJAX call instead of a full page load. Unfortunately some browsers would still send a click event for a middle or ctrl-click, which meant that if I wanted to avoid breaking that I had to write extra code to check if it was a middle click or ctrl-click and not call preventDefault if so. My recollection is that Chrome got it right but Safari and/or Firefox had the behavior I'm describing. Browsers should make it easy for apps to do the right thing, not make it harder.

deleted 9y ago

[deleted]

amsheehan 9y ago

It sounds like your experience with SPA's is the exception, not the rule. I have never built a product or website using Angular or React that performs as poorly as you describe. - Routing modules in all the major frameworks interact directly with the history APIs, and are fast as f*. - There are only a handful of locations in the US where you can expect sub 100ms server round trips, usually they're around 300ms, but lets call that negligible. The real time spent waiting is usually if you're executing some complex database query over large data sets. This has nothing to do with SPA's vs Monoliths. Even so, it sounds like you just experienced bad code if you're waiting 6 seconds for a modal to open. Also...React with React DOM is only 10kb larger than jquery, and when gzipped it's only 37kb.

craig1f 9y ago
I was going to say the same thing you said. Angular/React routing, if done correctly, don't have those problems at all. If you let the SPA framework do your page-changing for you, open-in-tab and history still works. If you do amateur stuff like, you bind a button to a function, and the function does an document.location.href update, then you're going to have some weirdness. My biggest problem with SPA the last time I did it (a year ago) was optimizing it for search engine crawling.
- amsheehan 9y ago
  Google's crawler at some point last year started indexing a really large mostly text based AngularJS app I built: https://www.fwdeveryone.com https://www.fwdeveryone.com Even if it didn't, headless chrome makes it really easy to pre-render content for web crawlers.
TheRealDunkirk 9y ago
One of my biggest problems in writing data-heavy web applications is that browsers seem to be really lousy at handling the data. In fact I have 2 applications in this boat. My queries run fast (couple/few hundred ms), but displaying 10's of MB of data, over 10's of thousands of rows of data, has been brutal for a browser. Trying various standard JS table widgets only made the problem worse, but I've discovered ag-grid (a paid JS table widget) which made this tolerable. It takes about 6 seconds to render my big page of data (which is actually on-par with a WinForms version of the system I wrote, using DevExpress). It sounds like you have the opposite problem, and I'm wondering how you display "large data sets" from "complex database queries" in sub-second renders in a browser. Incremental loading (like a news feed) won't really work here, because my users need to be able to sort and filter and rearrange the data as a whole. I guess I could "chunk" the data to be able to see it sooner, but it's still going to hold up the browser until it finishes. I've been looking for a better way for a long time.

mfrye0 9y ago

I agree with the others. Those are signs of bad software dev, not SPAs in particular. It's relatively easy now to break up the 7MB bundle into chunks and load on demand. So you get the benefit of both the fast, small initial load while other stuff loads in the background. Then I'm not sure what you're referring to on links and waiting for single interactions... With SPAs it's actually easier with the History API to create deeply nested stateful apps via the url / links. The confirmation modal, maybe your backend API sucks? Idk what your talking about with a 6s delay. On top of that, a pure SPA means you have a static website, which means you can host the whole app off something like S3. We save so much money by hosting our stuff statically.

xmlninja 9y ago

and with serviceworkers also breaking the refresh button :D

arrty88 9y ago
And intercepting URLs meant for the API server

intrasight 9y ago

I see no way that a properly built SPA could perform worse than a properly built server-rendered app form a network bandwidth perspective. JSON is always smaller than HTML.

heavenlyblue 9y ago

Let us all give some credit to LastPass, which manages to tick all of the points you're making here. More importantly, at the same time being a simple browser plugin.

sibeliuss 9y ago

In much modern software this is no longer an issue.

emodendroket 9y ago

chrismorgan 9y ago

> minimize server roundtrips (<100ms) Not possible, because the speed of light is too low. I live in Australia. Servers tend to be in America. That hundred milliseconds has just been blown in latency, along with another hundred or two, depending on where in the US the servers happen to be. Take something like FastMail. Our servers are in the US, our team is mostly in AU. FastMail couldn’t be fast for us and many of our customers without being crafted in the SPA style—and even customers in the US benefit from its latency-compensation techniques, which reduce at least 50ms of delay (plus further page load, so call it 100ms at a minimum, but probably more like 250ms) to zero. Please don’t blame navigation-breaking on the SPA style of app; blame it on developer ignorance and occasionally laziness, with perhaps a side of unfortunate browser APIs (onclick is a poor event for this sort of thing for various reasons). And I assure you, simple JavaScript-enhanced pages manage to have at least as much problem with such links as SPAs do.