Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Disadvantages of Single Page Applications (2014)

adamsilver.io

Post reply on HN
Print view View original

21–30 of 105 posts

Re: The Disadvantages of Single Page Applications (2014)

#21

Post by kalms »

gesman wrote: post #13

We need more articles like this. SPA is a total b*tch to do user activity tracking and quirks and glitches just never end. SPA rely on browser performance and users with slow connections or weak device - will wait much longer to see anything appearing on the page. My advice - if you sell anything from your site - stay away from SPA.

User tracking? Seems easy enough to me: https://github.com/kendagriff/backbone.analytics/blob/master...

We do mostly SPA's at our agency by now, and they're incredibly stable and easy to maintain. Each to his own, I guess.

Re: The Disadvantages of Single Page Applications (2014)

#22

Post by virtualwhys »

stevedomin wrote: post #15

As with everything, if you're going to do SPA, you should do it well. So far, one of the best SPA website I've seen is https://gocardless.com (disclaimer: I work there). Once loaded it's probably one of the fastest website I've browsed, and it doesn't have any of the drawbacks you mentioned: navigating to a new page is quick: ✓ navigating back is quick: ✓ remembering scroll position: ✓ cancelling navigation: ✗ but we…

Cool site, I just checked out on Android phone, works (as in fits on screen) in landscape mode; otherwise not. As far as SPAs go the initial page load is relatively fast.

Mobile aside, what is really gained in the SPA approach here when you have what is essentially a brochure site? That is, there isn't a lot of content, and it's all static AFAICT, so why not just send the minimal amount of html over the wire and be done with it? Html fragments are already covered for FAQ et al so don't even need to make a round trip to the server.

Anyway, you'd get above checkmarks for free and, if you generate server-side content using a type safe language (Scala, OCaml, Haskell, C#, etc.), for the most part you'd avoid the code salad of client-side typing.

Obviously I have a server-side bias, am curious to see real world use cases where SPAs are a must vs. a trend.

Re: The Disadvantages of Single Page Applications (2014)

#23

Post by buckbova »

virtualwhys wrote: post #22
stevedomin wrote: post #15

As with everything, if you're going to do SPA, you should do it well. So far, one of the best SPA website I've seen is https://gocardless.com (disclaimer: I work there). Once loaded it's probably one of the fastest website I've browsed, and it doesn't have any of the drawbacks you mentioned: navigating to a new page is quick: ✓ navigating back is quick: ✓ remembering scroll position: ✓ cancelling navigation: ✗ but we…

Cool site, I just checked out on Android phone, works (as in fits on screen) in landscape mode; otherwise not. As far as SPAs go the initial page load is relatively fast. Mobile aside, what is really gained in the SPA approach here when you have what is essentially a brochure site? That is, there isn't a lot of content, and it's all static AFAICT, so why not just send the minimal amount of html over the wire and be d…

I don't suspect he was referring to the gocardless product site, but instead the actual dashboard product.

https://gocardless.com/pro/#features

https://gocardless.com/features/#dashboard

Re: The Disadvantages of Single Page Applications (2014)

#24

Post by themgt »

stevedomin wrote: post #15

As with everything, if you're going to do SPA, you should do it well. So far, one of the best SPA website I've seen is https://gocardless.com (disclaimer: I work there). Once loaded it's probably one of the fastest website I've browsed, and it doesn't have any of the drawbacks you mentioned: navigating to a new page is quick: ✓ navigating back is quick: ✓ remembering scroll position: ✓ cancelling navigation: ✗ but we…

Except, I think this is actually somewhat an example of what the author is saying, because when I click around links:

* Support

* Guides

* Login

* Blog

are all outside the SPA, and some appear to be MPA apps. And perhaps once I logged in that would be its own new app as well?

So in that sense, your website in not an SPA, you have an app for getting new signups which is an SPA, and then you have a bunch of other SPA or MPA apps hooked up to that. As the author said, "Websites can still have Rich User Interfaces without cramming the entire site into one document."

I think the point is to find a balance and realize building your entire infrastructure into an SPA will indeed break the web and your user's experience, most likely. Having a mix of SPA/MPA apps that cover the various functionality you need, and using each where appropriate, is a much better use of resources and results in a better UX.

Re: The Disadvantages of Single Page Applications (2014)

#25

Post by BuckRogers »

"Rely on the browser, not Javascript".

The author of this blog is someone I would befriend. It sounds like his work is probably non-cancerous to the eye.

While I've become rather cynical about web, it's telling that everyone is reading this and posting on a "primitive" and "laughable" site (to many web designers you DON'T want working for you), right now. I'd prefer to keep my 1995, primitive, laughable web in place. Maybe they can keep their blink tags.

Re: The Disadvantages of Single Page Applications (2014)

#26

Post by nogridbag »

mc808 wrote: post #14

In a single page application , I would expect the back button to be entirely nonfunctional, or maybe in some cases functioning as "undo" if this behavior is clearly communicated. (I'm not sure where back-button-undo would be better than an undo button within the app, but I wouldn't rule it out. Maybe in a graphics editor where it would be convenient to use the mouse's back button.)

That might be what you expect - but I think you're in the minority :) Most non-technical users will try to click the back button regardless. Is there even an agreeable definition as to what a web site is versus a web application? Is a discussion forum a web site? What about something like Slack?

I would personally categorize an online discussion forum as a web site but something like Slack as a web app. But I would expect the back button to behave similarly between the two.

Re: The Disadvantages of Single Page Applications (2014)

#27

Post by virtualwhys »

buckbova wrote: post #23
virtualwhys wrote: post #22

Earlier quoted context omitted.

Cool site, I just checked out on Android phone, works (as in fits on screen) in landscape mode; otherwise not. As far as SPAs go the initial page load is relatively fast. Mobile aside, what is really gained in the SPA approach here when you have what is essentially a brochure site? That is, there isn't a lot of content, and it's all static AFAICT, so why not just send the minimal amount of html over the wire and be d…

I don't suspect he was referring to the gocardless product site, but instead the actual dashboard product. https://gocardless.com/pro/#features https://gocardless.com/features/#dashboard

That's where I was.

Not seeing any SPA requirement to click "Payment History" and js display a hidden layer.

Anyway, as far as SPA approaches go this site works well, pretty snappy, no FOUC, just pointing out that server-side + javascript for ajax/effects/transitions is also a viable means to creating a positive user experience.

Re: The Disadvantages of Single Page Applications (2014)

#28

Post by bryanrasmussen »

chrisco255 wrote: post #11

Nearly all of these complaints about SPAs have to do with navigation. It's true, when you make a SPA, you need to factor in routing. That's part of the design decision. When you use a SPA framework like Angular, the typical go to is to use Angular UI Router ( https://github.com/angular-ui/ui-router ) to manage your page and state transitions within those pages. By default, you get back button support, it's highly cus…

does it get forward button support as well, the only SPA I know with reasonable support in both directions is GMAIL and that is recent.

Re: The Disadvantages of Single Page Applications (2014)

#29

Post by robbrulinski »

stevedomin wrote: post #15

As with everything, if you're going to do SPA, you should do it well. So far, one of the best SPA website I've seen is https://gocardless.com (disclaimer: I work there). Once loaded it's probably one of the fastest website I've browsed, and it doesn't have any of the drawbacks you mentioned: navigating to a new page is quick: ✓ navigating back is quick: ✓ remembering scroll position: ✓ cancelling navigation: ✗ but we…

The site is lightning fast! Very nice.

Re: The Disadvantages of Single Page Applications (2014)

#30

Post by mattdeboard »

fizzbatter wrote: post #19

I must say i'm constantly surprised by the negativity towards changes in technology by the technology oriented crowd. More specifically, the pure negativity. So many (here included) constantly shout negativity towards these technology concepts (SPA, in this case), and thankfully also citing what they're negative specifically about. What i'm surprised to see though, is that so few focus on improving the tech concept (…

This isn't an anti-change thing. I have personally experienced the annoyance/pain of having to re-implement navigation in JavaScript. Sure, there are routing libraries that try to make this easier, but on the other hand, routing is kinda built in to the platform.

The author of the post made his point pretty clearly:

> [T]he application handles the browsing instead of the browser. Attempting to mimic the browser using Javascript is the root cause of the self-induced issues.

I think you're conflating "single-page applications" with what the author called "rich user interfaces". They're two separate things. A single-page application is defined by the fact it does not let the remote server handle routing. I think you're conflating the two because otherwise your rant doesn't really make sense to me. You asked for fixes, and the blog post comes with one: let the server & the browser handle routing; don't re-invent the wheel (badly).

Post reply on HN