After working on a pretty massive SPA for our company dashboard, I've kind of been turned off to the idea. Unless you have a really good reason, like data is live updating all the time with some sort of socket connection, it's probably not worth it. There is so much state you have to keep track of, which is just asking for obscure bugs. It's a relief to work on traditional sites where a page refresh gives you clean slate each time. With the framework we used we also had to duplicate lots of server logic, like model fields and validators. It's a bad pattern. The future is either in something like Meteor, where back and front end can share code, or in traditional multi-page sites.
The Disadvantages of Single Page Applications (2014)
31–40 of 105 posts
Re: The Disadvantages of Single Page Applications (2014)
#32As 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…
Looks good. What kind of design patterns are you using to achieve this?
Re: The Disadvantages of Single Page Applications (2014)
#33This reads like a very good list of things to implement in your SPA.
Having said that, you should also be supporting simply rendering the pages on the first request, and progressively enhance it, rather than a blank thing that then goes and fetches all the JS and render itself. The HTML/CSS should arrive and render as soon as possible. His reference to twitter's 2012 writeup is good.
Having said that, take a look at this:
http://platform.qbix.com/guide/pages
In our framework, we've always supported the concept of Pages and Tools (components to put on the pages). We handle all the swapping of CSS/JS, loading what you need only on demand, caching (even in the phonegap bundle!), retaining tools you still need while pages get replaced (instead of re-constructing them expensively from scratch every time). And of course removing event listeners for tools and pages which have been unloaded.
Ideally, all your pages should be cacheable to the point of being static, with dynamic content being populated by JS.
Also there is a security implication with CSRF. If you use a nonce in the session to prevent CSRF then this nonce has to be delivered to the client, either with the first page rendering, or -- if the page is cached -- on subsequent requests.
The point is ... it takes a long time to build all the supporting technology. We've done it. But it took us years!
You can check out an SPA here on desktop, tablet or mobile:
Re: The Disadvantages of Single Page Applications (2014)
#34As 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…
Any idea why on https://gocardless.com/merchants/new, when the Email Address input has focus, Cmd+Left arrow do not navigate to the previous page? Once the input no longer has focus, I'm allowed to use the shortcut again.
Re: The Disadvantages of Single Page Applications (2014)
#35As 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…
More details about SEO would be helpful, considering that's probably the MOST important aspect of going all SPA or not.
Are you doing some escape fragment/headless browser for googlebots?
Re: The Disadvantages of Single Page Applications (2014)
#36As 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…
If you really wanted you could use the HTML5 history API, with a fallback to #hashtags.
Re: The Disadvantages of Single Page Applications (2014)
#37I think this article is overly negative, some of the cases are not _always_ a disadvantage. Take "fast back" as an example. If your app is interactive and updates live, the "back" page can already be up and running with the latest data, instead of first loading a cached version and then having it update with JS later. Also, personally I'm not so sure users care about things like the "stop" button working. And "fast b…
Why would users not care about the stop button working? If something in the browser is not loading, I want to hit stop so I can wait a while before trying again.
What would a stop button in Word be like? It really depends on the type of webapp and experience you are trying to create.
Re: The Disadvantages of Single Page Applications (2014)
#38Earlier quoted context omitted.
Why would users not care about the stop button working? If something in the browser is not loading, I want to hit stop so I can wait a while before trying again.
What would a stop button in Word be like? It really depends on the type of webapp and experience you are trying to create.
Ah, but see, the stop button, back and forward, scrolling down, etc. are how the web worked. And best practice has always been, "don't break the web". Now... people break things. We went from having a consistent UI experience in the browser to everyone just making stuff up. Not good.
Re: The Disadvantages of Single Page Applications (2014)
#39As 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…
>Since gocardless.com is entirely static, we're able to deploy and serve static HTML
Source - https://gocardless.com/blog/how-we-built-the-new-gocardless....
May be this is why your site is so fast. SPA apps are not entirely static.
Re: The Disadvantages of Single Page Applications (2014)
#40Finally some love for the anti-SPA crowd. Subjective here, but there's something nice about Post Redirect Get and Plain Ol' Hyperlinks from a User Experience. Whenever I interact with a regular web application, I am relieved. Not every "forms over data" or ecommerce experience has to be Gmail. Even in mobile.. SPA just isn't that much nicer. Also, I think maintaining these SPAs is ridiculously more difficult. I don't…
From a development standpoint there are a lot of things I prefer from the old Post Redirect Get workflow. The biggest thing I don't miss is modeling complex data in a form. SPAs let me sidestep this because it's JSON, which is much richer for modeling data than a plain form, going both ways. If form JSON (https://darobin.github.io/formic/specs/json/) was widespread I'd probably drop almost all my SPA usage immediately.