8 ms·

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

> 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.
  - jrs95 9y ago
    As a relatively junior developer, my advice would be “learn the best practices, or don’t write code at all”... But we’ll see if I’m actually following my own advice 15 years from now. Hopefully I’m not on the wrong side of the Dunning-Krueger effect
    - neosavvy 9y ago
      Sometimes I find myself fighting the framework and someone inevitably shows me the best practice and I see how it would have just worked had I done more reading. Good luck out there.
    - at-fates-hands 9y ago
      > But we’ll see if I’m actually following my own advice 15 years from now. The one thing I've learned after doing this for 5 years is you probably won't be needing to follow best practices in the next 3 months. I've been in my current role about three years. Most of my 2015 was building an Angular 1.X transactional app. By the time it was released, I was told to start learning HapiJS and EmberJS because we were transitioning as a group to that. Then 8 months later and several smaller apps, I was told we're going back to AngularJS and Angular 2.0 transitional. So I had to almost completely relearn that. Then after one huge disaster trying to integrate it into our services, we gave it up and spent the rest of 2016 moving that app to ReactJS. I then spent most of last year jumping around (because now all these apps we built needed supporting) between those three frameworks (Angular, React and Hapi). Now there's talk of moving to VueJS but there is a loud push to just stick with one (Angular or React) and be done with this. My point here is you may want to learn best practices, but how fast my org was changing, and building things quite literally on the fly, you just don't have time. Sure, in my own private projects, I learn best practices and use them myself. For our customers and "the business"? No time man, no matter if it will us time or not. Getting something shipped that's working is far more important.
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.

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.
- jrs95 9y ago
  As a relatively junior developer, my advice would be “learn the best practices, or don’t write code at all”... But we’ll see if I’m actually following my own advice 15 years from now. Hopefully I’m not on the wrong side of the Dunning-Krueger effect
  - neosavvy 9y ago
    Sometimes I find myself fighting the framework and someone inevitably shows me the best practice and I see how it would have just worked had I done more reading. Good luck out there.
  - at-fates-hands 9y ago
    > But we’ll see if I’m actually following my own advice 15 years from now. The one thing I've learned after doing this for 5 years is you probably won't be needing to follow best practices in the next 3 months. I've been in my current role about three years. Most of my 2015 was building an Angular 1.X transactional app. By the time it was released, I was told to start learning HapiJS and EmberJS because we were transitioning as a group to that. Then 8 months later and several smaller apps, I was told we're going back to AngularJS and Angular 2.0 transitional. So I had to almost completely relearn that. Then after one huge disaster trying to integrate it into our services, we gave it up and spent the rest of 2016 moving that app to ReactJS. I then spent most of last year jumping around (because now all these apps we built needed supporting) between those three frameworks (Angular, React and Hapi). Now there's talk of moving to VueJS but there is a loud push to just stick with one (Angular or React) and be done with this. My point here is you may want to learn best practices, but how fast my org was changing, and building things quite literally on the fly, you just don't have time. Sure, in my own private projects, I learn best practices and use them myself. For our customers and "the business"? No time man, no matter if it will us time or not. Getting something shipped that's working is far more important.

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.