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.

You are right, we have multiple applications, it makes it way easier to maintain them. It would be a nightmare if everything (splash pages, dashboard, blog and any other app you can have) was bundled into a single application, be it SPA or MPA.

Agree, it's all about the user's experience for us, we use whatever tool we feel enable us to build the best UX (without breaking the web).

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

It's kind of a combination between a SPA and a static website.

We generate all the HTML pages so that they can serve as entrypoints, so when you go to https://gocardless.com/features we serve a fully rendered page to the browser, plus we load the rest of the website (that's why it's super snappy after the initial page load).

If you don't have javascript enabled, you'll still get fully rendered page.

While it is very fast, I wouldn't consider that an application but rather a static website. In my view, an application needs to do work, usually dependent on user input. Otherwise, basically every website is an application.

The dashboard looks like a much better example of an SPA.

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.

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.

I was actually referring to the product site itself.

But you're right our dashboards are also SPA.

I just wrote a post condemning the use of SPAs that emulate multi-page websites and basic browser functionality, but you provided an interesting counter-example. In fact, it goes to an extreme by being an "app" with minimal user interaction beyond basic navigation across pages.

It is quite fast, which is nice. One of my concerns about SPAs that emulate MPWs is that you're sacrificing speed for complexity, which generally leads to errors. But by serving up static content and limiting interactivity, you get the speed while keeping complexity manageable.

I'm building a multi page app that has a single page which is extremely complex (it's an image based marketing tool, the complex page is the visual editor) and I'm finding browser extremely finicky in their memory management.

I don't know how making a real single page app could be possible for overly complex applications. More than once I managed to crash the chrome javascript engine in a way that could not be recovered even when reloading the page and nothing short of a task manager kill could restore functionality

we are probably abusing too much canvas (we use fabric.js for image maniulation), but adding and removing the canvas from the dom should be safe enough, as we make sure not to store anything outside the dom itself specifically to avoid leaking resources

everything in memory is attached to data entries or in event handlers and browsers should be able to clean up them when the nodes are removed, except they dont.

In you have code that can reliably reproduce this, you can get a nice check from Chrome's bug bounty, or maybe even find a hacker to help you into pwn2own.

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?

It's pre-rendered on the server with React:

  <div class="site-wrapper"
       data-reactid=".20hl256vta8"
       data-react-checksum="-1018283815">

http://facebook.github.io/react/docs/top-level-api.html#reac...

I can easily find in Google content of angularjs sites I created, and I did nothing for SEO :) google just can execute js and it's enough.

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.

Probably because Cmd+left arrow is the system shortcut for "jump to the start of the current line." You'll see this behaviour when a form input has focus on any site.

Which, in turn, is why Cmd+[ and Cmd+] are by default bound to "Back" and "Forward" in at least Safari, Firefox, and Chrome.

OHhh that's true. I've been curious why stuff like this breaks for months now. I use OSX at work, Ubuntu/Windows at home, and jumping between this many OSs I sometimes forget about the system bindings if I'm not in an IDE. Thanks!

No idea why that's the case but I'll mention it to our front-end team

Wow! Very snappy.

    > customers in the UK and the Eurozone

Feel like this should be on the landing page though.

If I click on "learn more" then "find out the basics" and then click back, popup window stays on top.

If you really wanted you could use the HTML5 history API, with a fallback to #hashtags.

Better than falling back to #!hashbang / document fragment navigation - situation allowing - is falling back to a full web page load. (There is even tech allowing for graceful fallback to full form submissions in lieu of AJAX'd form submissions.)

Only ancient browsers fail to support the HTML5 History API. Currently, that is around 10% of the web. Your customers are likely to have a newer browser than IE 9 if they have a budget for technology at all.

http://caniuse.com/#feat=history

★ The problem with embracing the hash for navigation is that you are now committed to running JS on your root FOREVER to detect those URLs - or old bookmarks & links & social media posts will break ★

It would be extra nice if it had a fallback to work without Javascript (menus...).

The site is lightning fast! Very nice.

Looks good. What kind of design patterns are you using to achieve this?

Not sure what you mean by design pattern? It's a SPA, built with React, and pre-rendered.

You can check the source code here: https://github.com/gocardless/splash-pages