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 (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)
Except, I think this is actually somewhat an example of what the author is saying, because when I click around links:
* Support
* Guides
* Login
* Blog
are all outside the SPA, and some appear to be MPA apps. And perhaps once I logged in that would be its own new app as well?
So in that sense, your website in not an SPA, you have an app for getting new signups which is an SPA, and then you have a bunch of other SPA or MPA apps hooked up to that. As the author said, "Websites can still have Rich User Interfaces without cramming the entire site into one document."
I think the point is to find a balance and realize building your entire infrastructure into an SPA will indeed break the web and your user's experience, most likely. Having a mix of SPA/MPA apps that cover the various functionality you need, and using each where appropriate, is a much better use of resources and results in a better UX.
You are right, we have multiple applications, it makes it way easier to maintain them. It would be a nightmare if everything (splash pages, dashboard, blog and any other app you can have) was bundled into a single application, be it SPA or MPA.
Agree, it's all about the user's experience for us, we use whatever tool we feel enable us to build the best UX (without breaking the web).
It's kind of a combination between a SPA and a static website.
We generate all the HTML pages so that they can serve as entrypoints, so when you go to https://gocardless.com/features we serve a fully rendered page to the browser, plus we load the rest of the website (that's why it's super snappy after the initial page load).
If you don't have javascript enabled, you'll still get fully rendered page.
While it is very fast, I wouldn't consider that an application but rather a static website. In my view, an application needs to do work, usually dependent on user input. Otherwise, basically every website is an application.
The dashboard looks like a much better example of an SPA.
Cool site, I just checked out on Android phone, works (as in fits on screen) in landscape mode; otherwise not. As far as SPAs go the initial page load is relatively fast.
Mobile aside, what is really gained in the SPA approach here when you have what is essentially a brochure site? That is, there isn't a lot of content, and it's all static AFAICT, so why not just send the minimal amount of html over the wire and be done with it? Html fragments are already covered for FAQ et al so don't even need to make a round trip to the server.
Anyway, you'd get above checkmarks for free and, if you generate server-side content using a type safe language (Scala, OCaml, Haskell, C#, etc.), for the most part you'd avoid the code salad of client-side typing.
Obviously I have a server-side bias, am curious to see real world use cases where SPAs are a must vs. a trend.
Not seeing any SPA requirement to click "Payment History" and js display a hidden layer.
Anyway, as far as SPA approaches go this site works well, pretty snappy, no FOUC, just pointing out that server-side + javascript for ajax/effects/transitions is also a viable means to creating a positive user experience.
I just wrote a post condemning the use of SPAs that emulate multi-page websites and basic browser functionality, but you provided an interesting counter-example. In fact, it goes to an extreme by being an "app" with minimal user interaction beyond basic navigation across pages.
It is quite fast, which is nice. One of my concerns about SPAs that emulate MPWs is that you're sacrificing speed for complexity, which generally leads to errors. But by serving up static content and limiting interactivity, you get the speed while keeping complexity manageable.
I'm building a multi page app that has a single page which is extremely complex (it's an image based marketing tool, the complex page is the visual editor) and I'm finding browser extremely finicky in their memory management.
I don't know how making a real single page app could be possible for overly complex applications. More than once I managed to crash the chrome javascript engine in a way that could not be recovered even when reloading the page and nothing short of a task manager kill could restore functionality
we are probably abusing too much canvas (we use fabric.js for image maniulation), but adding and removing the canvas from the dom should be safe enough, as we make sure not to store anything outside the dom itself specifically to avoid leaking resources
everything in memory is attached to data entries or in event handlers and browsers should be able to clean up them when the nodes are removed, except they dont.
In you have code that can reliably reproduce this, you can get a nice check from Chrome's bug bounty, or maybe even find a hacker to help you into pwn2own.
Any idea why on https://gocardless.com/merchants/new, when the Email Address input has focus, Cmd+Left arrow do not navigate to the previous page? Once the input no longer has focus, I'm allowed to use the shortcut again.
Probably because Cmd+left arrow is the system shortcut for "jump to the start of the current line." You'll see this behaviour when a form input has focus on any site.
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!
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.
★ 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 ★
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.
From a development standpoint there are a lot of things I prefer from the old Post Redirect Get workflow. The biggest thing I don't miss is modeling complex data in a form. SPAs let me sidestep this because it's JSON, which is much richer for modeling data than a plain form, going both ways. If form JSON (https://darobin.github.io/formic/specs/json/) was widespread I'd probably drop almost all my SPA usage immediately.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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) 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.
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.
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 :)
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).
In all fairness, I thought early smartphones were pretty silly, and my opinion hasn't much changed.
I also find people touting "progress" don't realise that a lot of the time they just mean "change". I mean, sure, if a new way of doing things is demonstrably better, by all means let's use it. But a lot of the time you're just swapping one (well-understood) set of tradeoffs and considerations for a new, less understood set, because "That's what we're doing now".
For all that a lot of technical people like to make fun of the fashion industry, we definitely have our own as well.
(Not to take away from people trying different approaches. I'm all for trying alternate paths from 'best practice'. You don't want to get stuck on a local maximum. That said, there is a chunk of our industry that seems to congregate around whatever technology or approach has been recently discovered to be feasible)
Well, i sort of disagree. I agree that all progress isn't positive, but the problem is you can't really know that in the current timeframe. "progress" very often contains one (or more) steps back for every step forward. In the future, after the concept as matured, we will know if it is positive or not. But that is exactly how this works.
Sure, we can only use well tested, well understood, and well functioning concepts - but we already do that. What you are experiencing is bleeding edge, and we do not do bleeding edge where it really matters. Eg, good luck finding Nasa pulling this crap haha. In places where it is far less important, where you as a company/person have decided to use a product that is newer (probably for the sake of not being old, stale, and "safe"), then you have clearly chosen to accept the tradeoffs.
That's a fair point. I mean, I try to avoid rushing onto "the new thing" just because (although I'm certainly guilty of it at times), but I guess I forget that the ratio of articles posted to HN isn't representative of what people are actually doing, because the well-understood methods are, well, understood, so they don't generate a flood of articles.
Personally, I've yet to see a real solid case for SPAs. I know that may be confused for negativity towards the SPA technology, but I always found it to be a technology looking for a problem.
Again, in my experience, SPAs break the web 99% of the time. The times that they don't (e.g. Gmail), I still don't see what an SPA brings to the table that a simple MPA didn't. Yeah Gmail is nice, but it's no where near as good as a decent desktop or mobile mail app. And its miles away from a good, well structured MPA. SPAs just seem to sit in this no-mans land for me, and I'm not sure that more technology is the answer.
It's like Flash. When Flash came out I used to be a Flash developer for a while. But I had an epiphany as to why Flash development was so hard. It was the entire concept of the timeline, something that is at the core of Flash. A timeline is a sequence of keyed steps over time. The problem with this is that it make interactivity next to impossible; you were constantly fighting against the core purpose of Flash (play items in sequence over time). How do you handle users interrupting this sequence with their constant demands for interactivity? The answer was to throw the entire timeline concept out the window and generate all objects, items and stuff using code. That way you could handle arbritary interactions from the user. Well, I'm sure you can imagine how ridiculous that got over time. Frameworks and libraries and hacks and workarounds and generally just a big fat mess because Flash devs were constantly trying use Flash for something it was never designed to do in the first place.
For me, personally, SPAs and the related technology bear some of the similar hallmarks. Some developers want to use Web Browsers to write the equivalent of desktop apps. But browsers and the web in particular do not have the same interaction patterns as desktop apps (or mobile). But that is absolutely fine! The web is something else, it is its own thing.
But thats just me. By all means go for it! You are right that progress in technology is a good thing. I'm just wary of misdirected technological gains, like smart-jars, digital credit cards and smart smoke alarms that require internet connections.
To sum up; I wouldn't say it's negativity, it's more that some people are just not convinced by the concept at its core.
I worked on a project that implemented a SPA with its own tab-based browsing, including nested iframes for some tabs(!). I worked on another projected that implemented a SPA with its own windowing system, because the lead dev thought browser tabs would be too cluttered and users might not know how to use them. (Considering his browser had something like 100 tabs open and he never cleaned them up or opened the existing tabs, I think there was a bit of personal experience colouring his view.)
I think the general issue is that there are existing solutions that avoid the downsides associated with this approach, so this seems like re-inventing the wheel. Yes, needless negativity should be avoided, but so should breathless enthusiasm without due diligence.
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.
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.
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.
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.
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).
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.)
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.
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.
I disagree. What would Google Docs look like as a typical post back driven app? A giant text area with markup? No collaboration? No history of changes? No live spellckeck? Are you suggesting we go back to a pre-ajax web? No thanks.
I was developing clunky web applications with way too many text areas, buttons, tables, and pages pre-ajax. I'm much happier with the state of the web now.
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 :)
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.
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.
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).
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 :)
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.
Word also doesn't generally lock up when it can't access the network, and sit there spinning though. (Although I'm sure that feature is on the road-map).
I feel like a lot of the people making SPAs just haven't used a dodgy internet connection in five years or more.
IT would probably be like the time when everyone used Flash to create web apps and reproduced the browser functionality like back and stop, confusing users and breaking the web.
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.
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:
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.
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/
Most of the issues reported by this article are not a problem with it thanks to its approach.
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.
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.)
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.
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.
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.
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)
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.
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.
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