
The Disadvantages of Single Page Applications (2014) - deegles
http://adamsilver.io/articles/the-disadvantages-of-single-page-applications/
======
stevedomin
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)

~~~
fourstar
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
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...](http://facebook.github.io/react/docs/top-level-
api.html#react.rendertostring)

------
holofernes
Finally 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 think the SPA juice is worth the squeeze.

~~~
lftl
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/](https://darobin.github.io/formic/specs/json/))
was widespread I'd probably drop almost all my SPA usage immediately.

~~~
holofernes
That is a good point. The hard part of programming is the modeling. And your
point leads to another, easy modeling is why JSON as a format (and its
programming interface, JavaScript) is so appealing. I guess it's a trade off:
complex modeling and state transfer vs. sometimes inscrutable magic asset
loading, client/server programming model, losing the natural behavior of the
web, and all the other criticisms in the article and elsewhere.

------
jeanettehead17
SPA applications frameworks and architecture are so young compared to server
side rendering and still evolving.

Why do they exist? User expectations of the web are increasing and waiting for
server responses from any action isn't really cutting it anymore.

Of course it's harder to maintain state and develop - the patterns haven't
been clearly defined, and SPAs introduce two sources of state (client and
server) which is a hard problem. It's the cost of the demanded user
experience.

Angular ui router, ember data, react flux architecture are all examples of
things that have just started evolving to address these kinds of issues. All
of these are very new and being constantly iterated on and updated. Angular ui
router does a good job of handling things like the back button and managing
the state of your page. Ember data has really powerful client side data state
management, and react flux architecture presents a much needed practice of how
to control the flow of data between server calls and views. HyperMedia APIs
are another evolving technology for maintaining more control between the
client and the server.

------
freyr
One of my favorite SPAs is Trello. It demonstrates a great use case for a
single-page app, a highly-interactive interface based around a single view.

I realize that the "single page" in SPA refers to loading a single HTML page,
but I've generally felt like SPAs work best when they're based around a
primary view.

Once you start building a SPA that emulates a multi-page website, you're
suddenly jumping through hoops that the browser/HTML previously gave you for
free (routing, URL history, back button, etc.). If the main thing you'll get
in return is faster page transitions, it's probably not worth it.

~~~
nstart
Nailed it! This is one of the first things on my checklist for SPAs.

Is it an application?

Does it revolve around a single view that is not just a header toolbar?

Ok. You are now cleared for any other questions to evaluate SPAs. If the
answer to either of those questions is no, just don't use a single page site.

As for answering the question of how much of a primary view makes the SPA
worth it. If data needs to be retained within the view while making requests,
then yes. Examples - spotify, most multi column apps, ERPs etc.

------
ChicagoDave
I completely disagree with the assessment of this article. I've been building
and managing the build of simple to enterprise web applications since the web
was born. I'm familiar with the entire spectrum of development platforms from
old CGI/Perl, ASP, JSP, Cold Fusion, ASP.NET, MVC-platforms (pick one), and
now SPA's using front-end platforms like AngularJS and ReactJS.

The amount of time saved in developing services and front-ends over a server-
based system is so significant as to offset any of the complexities mentioned
here.

The speed of development, the ability to rapidly change requirements, to adapt
to stakeholders wants and needs...all are supported by the service+SPA model.

And tooling is coming in many forms to support this pattern, so it's not going
anywhere.

~~~
voidr
Maybe the MVC frameworks you used weren't the best, I can do everything on the
backend and still have all the advantages that you described.

It's not about where you execute your UI code, It's about how you structure
your application.

I've seen plenty more of SPA's become an unmaintainable spaghetti nightmare
and also seen many non-SPA's work splendidly.

~~~
EugeneOZ
You can't do on the backend everything what SPA can. You simply can't
manipulate views without page reload and if you want to do it by injecting JS
into backend templates, it will be just mimicking of SPA on the server side,
and it's the most ugliest thing what can exist - from the development point of
view.

I support parent comment and I can add: SPA split responsibilities between
server side and frontend. It helps us to build services with APIs, reusable
with different clients (mobile app can use same API with absolutely different
UI), so this split looks like natural evolution. This article is just luddism.

~~~
voidr
I recommend reading my comment again, it's not about what each approach can
and cannot accomplish technically, it's about maintainability.

I can give examples of a lot of things that SPA's can't do, that's not the
point.

I also don't think, you should either build everything on the backend or
everything on the frontend, I consider both approaches to be equally bad.

SPA's do not help split responsibilities, I can easily give the SPA a low
level Data API and start implementing data processing functionalities in the
frontend.

SPA's don't help build services, good frameworks do.

SPA is a religion, cause it states 'Single Page'. What if I want to have an
application with 2 or 3 pages just because it doesn't make any sense
whatsoever to cram everything into 1 page? What if I can render a lot of stuff
on the backend and be 100x more efficient and provide far superior UX?

I had a colleague once who wanted to do everything on the client side, he said
that the SPA is the way to go. He got 6 months to prove his approach is good.
He failed. His application was both slow as hell and nobody on the team could
maintain it. So after he left it took me roughly 2 months to implement what he
had in 1/5th of the code.

~~~
ChicagoDave
I'm sorry, but my take on your comments is that you haven't actually been on
any SPA projects (yet). Having been on several over the past two years, I have
a clear understanding of the trade-offs, benefits, and complexities. I was
very skeptical two years ago, but that skepticism has been mostly eradicated.

Sure, if you have bad programmers, no pattern will save you. But if you want
speed, agility, and separation of concerns, SPA + services is currently the
way to go.

~~~
voidr
I have been on SPA projects and I have made SPA's myself as well.

If you want speed, agility separations of concerns, MVC is the way to go. Most
of the things you said are MVC and SRP, it has nothing to do with SPA, this is
what I have been trying to explain. SPA stands for "Single Page Application",
it doesn't specify anything beyond that, your code could be utter garbage with
everything mangled together, and it's still technically a SPA. MVC on the
other hand does specify how to organize your code.

I think the problem here is the SPA terminology itself and the way it's being
used and marketed.

------
sulam
It's really good to see an article like this. IMO the pendulum has swung too
far towards massive JS "applications" that force you to download MBs of
content to render anything at all. Yes, if caching works things can be fast,
but then you do things like release a new version of your software and I have
to download it all again. I use Asana (and love it), but I hate the fact that
it can literally take a minute to download their web application. Once it's
loaded it's incredibly fast and one of the best web apps I use, but the
performance loading it makes it really, really painful at times. Not to
mention that based on their blog posts they've also found it difficult to
program.

And it's not just Asana, there are some very popular web applications that
have had to make the same decision in order to reduce the time it takes to
load things for their users, especially users who aren't on fast links
(mobile, rural, and places like South America, Africa and Australia).

------
chrisco255
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](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 customizable and configurable and it's not difficult to manage at
all.

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

~~~
thoman23
Yes, you get forward button support.

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

~~~
kalms
User tracking? Seems easy enough to me:
[https://github.com/kendagriff/backbone.analytics/blob/master...](https://github.com/kendagriff/backbone.analytics/blob/master/backbone.analytics.js)

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.

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

------
fizzbatter
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 (SPA). I see so many complaints, but so few fixes. I don't think SPA
is inherently bad, not by a long shot. It's just that, like any young idea it
is far from perfect. But, that's technology! It's how advancement goes.

As technology goes, we tend to take two steps forward one step back. But it's
often for the sake of _progress_. I have a Moto 360 on my wrist as i type
this, but do i consider it amazing? God no, it has some nifty features sure,
but it's massive and i can't even see what the time is without turning it on.

Take that in for a second - i have a watch and i have to turn my wrist and
bring it up to my face to see the damn time. But do i think that it shouldn't
exist? God no. When i got my first "smart" phone it was also awful. If i
followed the (seeming) mantra of these negative people, i'd have been shouting
for no smartphones phones and no smart watches for years before they had a
really solid UX.

I understand a MPA currently offers a more reliable and overall better UX than
SPAs tend to. However, can we please focus on improving this technology
concept rather than screaming for them to not exist anymore? The HTML5 History
API attempts to solve many of the complaints here. It also sounds like we
should use data caching (in our SPAs) so that when a user hits back, they get
a back-like experience. And as far as scroll position goes, that might be
something the History API should provider (if it doesn't already).

Like it or not, JavaScript is here to stay. Usage of it will only increase.
Rather than saying how terrible of a UX it has, please try to think in the
reverse. Even if you aren't going to work on the solutions, this is the exact
type of crowd that will. Cite your concerns and UX improvements - These are
the sort of people you should be helping, to help you :)

/rant

~~~
mattdeboard
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).

~~~
thebfed
This.

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

------
bmir-alum-007
In general, it depends: there are many different use cases where SPA is fine
and others where they are not. It's especially good for long-running consoles
that don't need much navigation (given using the appropriate JS framework
which doesn't leak resources on most browsers). SPA doesn't make much sense
(apart from in-web app search live results searching) for static pages that
need to be SEO crawlable and can be served up fast from static CDNs. Perhaps
the core engineering tradeoff is whether to breaking the stateless RESTful
contract by managing state with session cookies and/or JavaScript, and doing
so in a way that may or may not be sharable to other users, history-friendly,
SEO-friendly, etc.

Ruby's turbolinks is a clever hack and mostly works approach to make nav-based
(browser history- and crawler SEO-compatible) almost as responsive as SPA...
it replaces assets, title, meta and body on-the-fly and updates the url
location with javascript to save a whole page update. It's basically a hybrid
of client+server coordinated fragment caching. There are some gotchas and
workarounds for onLoad() and other JS hooks, but it mostly works pretty well.

------
Justsignedup
Other points of note:

The whole history API exists to help the SPA experience (but others too).

The site still needs to be able to render something like:

www.foo.com/customers/10 even if www.foo.com is a SPA and via clicks can go to
/customers/10\. This may require more server work, so you're not exactly
making life much easier for yourself.

You still need to handle cases where a web crawler comes in without good
javascript and has to index your site.

~~~
tomjen3
Not really - these days even googlebot can and does execute enough javascript
to craw #/customers/10\. Screen readers can do javascript and you can use ARIA
to make it easy to browse for blind people.

~~~
PavlovsCat
> even googlebot

I would assume that's one of the more capable crawlers though; not the
average, and surely not the lower bound.

~~~
tomjen3
It is also the only one that it makes sense to care about, from a business
perspective.

------
buckbova
This seems to be aimed at Single Page Websites and not Applications.

The aim isn't to "mimic the browser using Javascript" but to create an
immersive application that feels like you're no longer in a browser at all.

~~~
Sanddancer
At which point, the question becomes, "why is this a website?" if you're
building an application, usually languages like C#, Objective-C, etc offer far
more powerful tools for making an application.

~~~
adamors
Because a web based application doesn't need installation, it's cross platform
and accessible by everybody.

~~~
jalfresi
Then surely all the effort being put into make browsers not browsers would be
better directed towards solving those goals, without bastardising the web?

I always thought that the SPA crowd would settle on a custom content-type to
handle web apps. That way they aren't hamstrung by the limitations of HTML and
web pages and can really do things right by web apps.

------
augustl
I 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 back" depends on the situation.

Having said that: if these kinds of articles reduce the risk of things like
blogger.com being a SPA, keep writing :)

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

~~~
nkassis
What would a stop button in Word be like? It really depends on the type of
webapp and experience you are trying to create.

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

~~~
augustl
If browsers had hooks for "the page has now finished loading" (to display a
loading indicator while the page loads with XHR etc) and "callback for stop
button click" I'm sure lots of SPAs would put them to good use :)

~~~
JustSomeNobody
So, it is the browser's fault. Nice.

~~~
augustl
If we can agree that SPAs are useful for some type of apps, it's definitely
the browsers lack of APIs fault that the SPA has no way of telling the browser
about these sort of things, yeah.

------
zkhalique
This 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](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:

[http://qbixstaging.com/Groups](http://qbixstaging.com/Groups)

~~~
crgt
Link doesn't work for me on iOS. I just get a blank page?

~~~
zkhalique
Try now, it should be working!

------
mandeepj
All,

If you want detailed guidance on how to build SPA apps in a right way then you
need to check out this guide (called Project Silk) from Microsoft [1]. It
contains lot of insights and all the approaches provided are still applicable
in 2015.

It comes with complete source code.

[1] - [https://msdn.microsoft.com/en-
us/library/hh396380.aspx](https://msdn.microsoft.com/en-
us/library/hh396380.aspx)

------
henvic
Senna.js is a blazing-fast single page application engine that provides
several low-level APIs that allows you to build modern web-based applications
with only ~8KB of JavaScript without any dependency.
[http://sennajs.com/](http://sennajs.com/)

Most of the issues reported by this article are not a problem with it thanks
to its approach.

Disclaimer: I have contributed to the project.

~~~
aaronem
That's nice. The blog example exhibits a lot of the problems identified in
OP's article, especially those around history and scroll position.

Look, I'm all in favor of SPAs; I build them myself. But when I trip over
something that does infinite scrolling, I groan, because I know that if I
should happen, twenty pages in, to slip and left-click a link instead of
right-clicking and "Open in New Tab", I'm going to lose my place and have to
start over from page 1 and spend five minutes wearing out my scroll wheel to
get back to where I was -- either that, or shrug and give up on whatever I was
reading.

There are real problems in the space. They need to be either solved or
avoided. (If you can't get infinite scroll to work right, then don't use
infinite scroll.) Pretending they don't exist and refusing to address them is
just foolishness.

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

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

------
vilmosi
The main disadvantages mentioned in this article relate to the fact that many
SPA today don't replicate the traditional routing mechanism. Which, in my
humble opinion, is the wrong thing to judge it on. You can easily have a
single-page-application on a... Single Page. The actual url can just preserve
the current state of the app, instead of a location.

~~~
freyr
Unfortunately, I have seen SPAs that emulate multi-page websites and the
traditional routing mechanism. I'm even guilty of creating one, and I very
quickly regretted it! It's generally not a good idea.

~~~
vilmosi
Same here. Today, I tend to make sure these days that my projects absolutely
are SPAs beforehand. If someone mentions traditional pages, SPA is out.

------
jimmyislive
How about the fact that in case you use API keys for the back end, the API key
has to appear in the client as well. e.g. If there are third party clients
using your API server and you want to issue keys for them. (They could just as
easily use the one that is used by the main website)

------
dandare
ITT: SPAs have few to zero disadvantages.

------
puppetmaster3
I agree w/ people that say SPA can do SEO and is an improvement and in that
and everything else.

------
justin_d
Some problems with the article.

One you cherry pick SPA attempts, like with Twitter. This is an example of a
company trying to refactor for SPA, not doing SPA from the beginning.

Libraries that help with SPA are maturing. It's easy to implement routing with
backbone for example. You just have to be a good developer and actually learn.

The part that really matters is being a solid dev. Not if you choose SPA or
not.

------
elchief
If you want a desktop application, you should build a desktop application.

------
StillBored
I've always assumed that if you need a back button, your application wasn't
really a good candidate for a SPA anyway...

~~~
renke1
Is that so? – As far as I know on Android the back button was or is an
integral part of most applications and the whole Android UI as a whole – and I
would say a SPA is something that is pretty similar to an Android app.

