6 ms·

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 https://gocardless

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 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 won't allow duplicate requests so not an issue SEO: ✓ Navigation and data loss: ? (no idea how we handle that tbh) Navigation and loading CSS & JS: ✓ we load everything on the first load (~ 880kB) and that's it. I don't think it will ever be worst than MPA Analytics: ✓ Automated functional testing: ✓ our unit + e2e test suites run in about 4 minutes (CI) Our splash pages are open-sourced if you want to have a look at our setup: https://github.com/gocardless/splash-pages https://github.com/gocardless/splash-pages

virtualwhys 11y ago
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.
- buckbova 11y ago
  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/pro/#features https://gocardless.com/features/#dashboard https://gocardless.com/features/#dashboard
  - virtualwhys 11y ago
    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.
  - stevedomin 11y ago
    I was actually referring to the product site itself. But you're right our dashboards are also SPA.
themgt 11y ago
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.
- stevedomin 11y ago
  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).
robbrulinski 11y ago
The site is lightning fast! Very nice.
amelius 11y ago
Looks good. What kind of design patterns are you using to achieve this?
- stevedomin 11y ago
  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 https://github.com/gocardless/splash-pages
arenaninja 11y ago
Any idea why on https://gocardless.com/merchants/new 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.
- stevedomin 11y ago
  No idea why that's the case but I'll mention it to our front-end team
- dfcowell 11y ago
  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.
  - aaronem 11y ago
    Which, in turn, is why Cmd+[ and Cmd+] are by default bound to "Back" and "Forward" in at least Safari, Firefox, and Chrome.
  - arenaninja 11y ago
    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!
fourstar 11y ago
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?
- insin 11y ago
  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#react.rendertostring http://facebook.github.io/react/docs/top-level-api.html#reac...
- EugeneOZ 11y ago
  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.
zkhalique 11y ago
If you really wanted you could use the HTML5 history API, with a fallback to #hashtags.
- alanh 11y ago
  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 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 ★
mandeepj 11y ago
>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.com/ 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.
- stevedomin 11y ago
  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 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.
freyr 11y ago
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.
- LoSboccacc 11y ago
  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.
  - spiffytech 11y ago
    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.
eCa 11y ago
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.
minikomi 11y ago
Wow! Very snappy. > customers in the UK and the Eurozone Feel like this should be on the landing page though.
mobiuscog 11y ago
It would be extra nice if it had a fallback to work without Javascript (menus...).
monort 11y ago
If I click on "learn more" then "find out the basics" and then click back, popup window stays on top.

virtualwhys 11y ago

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.

buckbova 11y ago
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/pro/#features https://gocardless.com/features/#dashboard https://gocardless.com/features/#dashboard
- virtualwhys 11y ago
  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.
- stevedomin 11y ago
  I was actually referring to the product site itself. But you're right our dashboards are also SPA.

themgt 11y ago

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.

stevedomin 11y ago
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).

robbrulinski 11y ago

The site is lightning fast! Very nice.

amelius 11y ago

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

stevedomin 11y ago
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 https://github.com/gocardless/splash-pages

arenaninja 11y ago

Any idea why on https://gocardless.com/merchants/new 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.

stevedomin 11y ago
No idea why that's the case but I'll mention it to our front-end team
dfcowell 11y ago
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.
- aaronem 11y ago
  Which, in turn, is why Cmd+[ and Cmd+] are by default bound to "Back" and "Forward" in at least Safari, Firefox, and Chrome.
- arenaninja 11y ago
  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!

fourstar 11y ago

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?

insin 11y ago
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#react.rendertostring http://facebook.github.io/react/docs/top-level-api.html#reac...
EugeneOZ 11y ago
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.

zkhalique 11y ago

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

alanh 11y ago
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 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 ★

mandeepj 11y ago

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

stevedomin 11y ago
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 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.

freyr 11y ago

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.

LoSboccacc 11y ago
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.
- spiffytech 11y ago
  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.

eCa 11y ago

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.

minikomi 11y ago

Wow! Very snappy. > customers in the UK and the Eurozone Feel like this should be on the landing page though.

mobiuscog 11y ago

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

monort 11y ago

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