13 ms·

The Disadvantages of Single Page Applications (2014)

209 points by deegles 11y ago

holofernes 11y ago
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.
- joverholt 11y ago
  Agree. The few SPA sites I use annoy the heck out of me. garmin connect is one that I use, and when I view an activity and want to go back, I need to wait .5 or 1 second as the page loads. Sure, I have a nice empty list to look at as it loads, which just annoys me more. I don't know if this is a fault of SPAs, or just poor app design because there seems to be no caching. The delay is just log enough to annoy me.
- lftl 11y ago
  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 11y ago
    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.
- qu4z-2 11y ago
  Funnily enough, even for GMail I use their "legacy" HTML+URLs+POST requests interface. It's honestly a breath of fresh air (although the styling is a bit dated). But it's lovely to be able to open multiple compose windows in new tabs by just middle-clicking the "Compose Mail" link. Then again, I realise the more explicit workflow is a matter of preference (eg it won't autosave drafts unless you hit "Save draft", and I like that, but others might not).
- aaronem 11y ago
  Having had experience with both, I'm a lot happier implementing Ajax form submissions than POST-redirect-GET. Sometimes a form submission has a lot of state around it. Sometimes its result has a major effect on the state of the application of which it's a part. Sometimes you end up implementing half of the ideas involved in the SPA architecture, badly, a couple of years before it becomes a "thing" in the web dev community at large, because that's the only way to produce a halfway decent UX for your tens of thousands of users, and you know this because you've tried all the ways that revolve around POST-redirect-GET and none of them has worked well enough to be going on with. Of course you're welcome to be as anti-SPA as you please. But those of us who've welcomed the concept with all the fervor of a relieved garrison generally have our reasons for so doing.
Justsignedup 11y ago
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 11y ago
  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 11y ago
    > even googlebot I would assume that's one of the more capable crawlers though; not the average, and surely not the lower bound.
    - tomjen3 11y ago
      It is also the only one that it makes sense to care about, from a business perspective.
augustl 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.
      - spoiler 11y ago
        I believe that some things shouldn't be SPAs (but, unfortunately are). Some of our clients[1] use SPAs for regular websites (which just makes me eyeroll). A good example for a SPA would be something like a webmail client, a word processor, or a chat. A bad example of it would be a blog, or a product website; these are much more suited for MPW I'm conflicted wheteher these would benefit from a SPA or not: discussion boards, web shops and the like. I can see them benefiting from SPA, but I can also see some disadvantages. I guess they'd be more suited for a "hybrid solution" (MPW with some AJAX and/or WebSockets). [1]: I work for a hosting company, so our clients are usually web developers (or sometimes they hire web developers).
buckbova 11y ago
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.
- Hakeashar 11y ago
  I'd say that ~98% (statistic pulled out of the thin air) of Single Page Applications are - in fact - Single Page Websites in your terminology. At least that's what I usually see when various companies are using Angular (or Ember, or React-with-routing, or any other library/framework) to power their web applications. Honorable mention for the application that you probably have in mind can go towards (IMO) React UI Builder which was posted to HN a few days ago (https://github.com/ipselon/react-ui-builder https://github.com/ipselon/react-ui-builder).
- chubot 11y ago
  What are some examples of applications that succeed in this? The only one I can think of that is successful is Google Maps. Though lately I seem have all sorts of problems navigating it, so maybe it's no longer a success. "Feeling like you're no longer in a browser" isn't really a customer goal or a product goal. It could be a means to an end, depending on the application, but I don't see that many people executing it effectively. The more common case by far seems to be people who want too much control, without realizing that they are actually degrading the experience (i.e. by messing up navigation, hyperlinks, copy-paste, accessibility, latency, etc.)
- Sanddancer 11y ago
  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 11y ago
    Because a web based application doesn't need installation, it's cross platform and accessible by everybody.
bmir-alum-007 11y ago
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.
vilmosi 11y ago
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 11y ago
  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 11y ago
    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 11y ago
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)
chrisco255 11y ago
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 11y ago
  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 11y ago
    Yes, you get forward button support.
gesman 11y ago
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 11y ago
  User tracking? Seems easy enough to me: https://github.com/kendagriff/backbone.analytics/blob/master/backbone.analytics.js 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.
mc808 11y ago
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 11y ago
  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.
stevedomin 11y ago
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
    - 11y ago
StillBored 11y ago
I've always assumed that if you need a back button, your application wasn't really a good candidate for a SPA anyway...
- renke1 11y ago
  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.
jeanettehead17 11y ago
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.
fizzbatter 11y ago
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 11y ago
  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).
BuckRogers 11y ago
"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.
vlunkr 11y ago
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.
zkhalique 11y ago
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 11y ago
  Link doesn't work for me on iOS. I just get a blank page?
  - EGreg 11y ago
    Which of the links?
  - zkhalique 11y ago
    Try now, it should be working!
elchief 11y ago
If you want a desktop application, you should build a desktop application.
henvic 11y ago
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 11y ago
  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.
freyr 11y ago
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 11y ago
  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.
mandeepj 11y ago
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
ChicagoDave 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.
sulam 11y ago
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).
puppetmaster3 11y ago
I agree w/ people that say SPA can do SEO and is an improvement and in that and everything else.
justin_d 11y ago
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.
dandare 11y ago
ITT: SPAs have few to zero disadvantages.

209 points by deegles 11y ago

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.

joverholt 11y ago
Agree. The few SPA sites I use annoy the heck out of me. garmin connect is one that I use, and when I view an activity and want to go back, I need to wait .5 or 1 second as the page loads. Sure, I have a nice empty list to look at as it loads, which just annoys me more. I don't know if this is a fault of SPAs, or just poor app design because there seems to be no caching. The delay is just log enough to annoy me.
lftl 11y ago
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 11y ago
  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.
qu4z-2 11y ago
Funnily enough, even for GMail I use their "legacy" HTML+URLs+POST requests interface. It's honestly a breath of fresh air (although the styling is a bit dated). But it's lovely to be able to open multiple compose windows in new tabs by just middle-clicking the "Compose Mail" link. Then again, I realise the more explicit workflow is a matter of preference (eg it won't autosave drafts unless you hit "Save draft", and I like that, but others might not).
aaronem 11y ago
Having had experience with both, I'm a lot happier implementing Ajax form submissions than POST-redirect-GET. Sometimes a form submission has a lot of state around it. Sometimes its result has a major effect on the state of the application of which it's a part. Sometimes you end up implementing half of the ideas involved in the SPA architecture, badly, a couple of years before it becomes a "thing" in the web dev community at large, because that's the only way to produce a halfway decent UX for your tens of thousands of users, and you know this because you've tried all the ways that revolve around POST-redirect-GET and none of them has worked well enough to be going on with. Of course you're welcome to be as anti-SPA as you please. But those of us who've welcomed the concept with all the fervor of a relieved garrison generally have our reasons for so doing.

Justsignedup 11y ago

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 11y ago
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 11y ago
  > even googlebot I would assume that's one of the more capable crawlers though; not the average, and surely not the lower bound.
  - tomjen3 11y ago
    It is also the only one that it makes sense to care about, from a business perspective.

augustl 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.
    - spoiler 11y ago
      I believe that some things shouldn't be SPAs (but, unfortunately are). Some of our clients[1] use SPAs for regular websites (which just makes me eyeroll). A good example for a SPA would be something like a webmail client, a word processor, or a chat. A bad example of it would be a blog, or a product website; these are much more suited for MPW I'm conflicted wheteher these would benefit from a SPA or not: discussion boards, web shops and the like. I can see them benefiting from SPA, but I can also see some disadvantages. I guess they'd be more suited for a "hybrid solution" (MPW with some AJAX and/or WebSockets). [1]: I work for a hosting company, so our clients are usually web developers (or sometimes they hire web developers).

buckbova 11y ago

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.

Hakeashar 11y ago
I'd say that ~98% (statistic pulled out of the thin air) of Single Page Applications are - in fact - Single Page Websites in your terminology. At least that's what I usually see when various companies are using Angular (or Ember, or React-with-routing, or any other library/framework) to power their web applications. Honorable mention for the application that you probably have in mind can go towards (IMO) React UI Builder which was posted to HN a few days ago (https://github.com/ipselon/react-ui-builder https://github.com/ipselon/react-ui-builder).
chubot 11y ago
What are some examples of applications that succeed in this? The only one I can think of that is successful is Google Maps. Though lately I seem have all sorts of problems navigating it, so maybe it's no longer a success. "Feeling like you're no longer in a browser" isn't really a customer goal or a product goal. It could be a means to an end, depending on the application, but I don't see that many people executing it effectively. The more common case by far seems to be people who want too much control, without realizing that they are actually degrading the experience (i.e. by messing up navigation, hyperlinks, copy-paste, accessibility, latency, etc.)
Sanddancer 11y ago
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 11y ago
  Because a web based application doesn't need installation, it's cross platform and accessible by everybody.

bmir-alum-007 11y ago

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.

vilmosi 11y ago

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

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)

chrisco255 11y ago

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 11y ago
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 11y ago
  Yes, you get forward button support.

gesman 11y ago

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 11y ago
User tracking? Seems easy enough to me: https://github.com/kendagriff/backbone.analytics/blob/master/backbone.analytics.js 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.

mc808 11y ago

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

stevedomin 11y ago

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

StillBored 11y ago

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

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

jeanettehead17 11y ago

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.

fizzbatter 11y ago

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

BuckRogers 11y ago

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

vlunkr 11y ago

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.

zkhalique 11y ago

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 11y ago
Link doesn't work for me on iOS. I just get a blank page?
- EGreg 11y ago
  Which of the links?
- zkhalique 11y ago
  Try now, it should be working!

elchief 11y ago

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

henvic 11y ago

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

freyr 11y ago

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

mandeepj 11y ago

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

ChicagoDave 11y ago

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

sulam 11y ago

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

puppetmaster3 11y ago

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

justin_d 11y ago

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.

dandare 11y ago

ITT: SPAs have few to zero disadvantages.