- Every click is a full page load, and you still didn't manage to get caching right, so it takes 2 seconds to load.
- When I have multiple tabs open, your badges and notifications fall out of date, because you never poll for updates.
- If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.
- You forgot to update the styles on that rarely-used page, and now it's got half the new CSS and half the old CSS and the point is the header runs halfway down the goddamn content in Times New Roman.
I get it, there are problems with SPAs. But this perfect land of one-page-per-link has real usability problems if it's not implemented properly, and there's a lot of maintenance overhead associated with a sprawling mass of transcluded templates. If we're going to criticize an architecture because it's easy to poorly implement, I don't think "ROCA" or whatever we're calling it has any meaningful benefits over SPAs in the general case.
Since we're talking about poorly implemented features.
Why I hate your SPA:
- If I click on a link, I receive no indication that I actually clicked a link, then 2-10 seconds later the page abruptly loads. Sometimes the page doesn't load at all.
- I cannot tap and hold a link, wait a second for the pop-up menu, and open the link in a new tab because the link isn't actually a link. It's implemented in JavaScript.
- The back and forward buttons don't work as expected because either history isn't maintained or it's shoddy (scrolling should not be a history event).
- The refresh page button don't work as expected because it resets you to the beginning.
. - If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.
Funny that you mention it. Loosing form data on page refresh or clicking "back" button was a problem on the Web until browsers started keeping form state along with page history. Suddenly millions of websites got this new feature without actually doing anything differently. But that was only possible because page transfers were semantic. Frameworks of that time that tried to manage their own form state (like ASP.NET WebForms) didn't have real page transfers, so they didn't get this "upgrade" and currently are significantly worse off in terms of usability.
- If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.
Even when I was coding web pages in Perl in the 90's I wouldn't do that to a user, that's just mean. You don't need a SPA to provide proper error handling that also rebuilds previous state.
. - If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.
This was fixed in browsers years ago when they started keeping form state along with page history. I can refresh this page, go back and forth in history, and this text box will keep my comment. Ironically, websites that tried to be clever about form state management and faked page transfers (like ASP.NET WebForms) didn't benefit from the fixes and currently are significantly worse off in terms of usability than websites that used vanilla forms.
In about 95% of the SPAs I've tried, each click takes even longer than that.
"you never poll for updates"
Yes, because apparently AJAX/AJAJ is completely nonexistent and there's absolutely zero ground between "pure-HTML like it's 1991" and "VueWangulaReact.js single-page monstrosity".
Hell, even a meta-refresh will fix that if you really do want "pure-HTML like it's 1991", though that's certainly inelegant.
- The author is describing hypertext, which is perfectly fine for textual static content, one of the key goals for which the World Wide Web was conceived.
- Server-side generation of HTML seems totally out of place for other use cases: HTML/JS are now the assembly languages of the web and they belong in the browser. Besides a more distributed architecture is just perfect: server and client focus on what they do best.
- Fixing web-apps with broken history buttons and unlinkable urls is important, but to be honest there are fewer and fewer SPAs that are mono-url these days. And it's perfectly fine to have a unlinkable "Delete this Invoice" app button. If it's not real content it should not be a link.
The last bullet is just a straight up error on the part of the developer. The third... isn't real? What browser doesn't save form state?
The first two are fair criticism but they aren't nearly as detrimental to the user experience as the typical single page app antipatterns (no history, no indication of page loading, refresh button is broken, etc).
While it is of course possible to execute any design well or poorly, the observation that a typical single page app is worse than a typical multipage app is certainly valid.
"If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it."
This. I have a very short list of architectural must-haves that I use when evaluating junior dev's code at the start of a project, and not having robust error handling that preserves submitted form information is right up near the top.
It's an annoying design mistake with two input elements, unworkable with five, and just plain cruel beyond that.
I only scanned towards the end, but I was waiting to here what his proper architectural would be. I don't like complaining unless you have alternative you're ready to support.
> If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.
This really shouldn't be a problem for anything other than file inputs. If someone's form is losing submitted information on a validation failure when using an actual HTML submit, then I find it pretty unlikely that they're doing a good job of AJAX submission.
> Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab.
Each screen has its own discrete URL, so you can share links, refresh, bookmark or open in a new tab, just like any other website.
I think the criticism here is misguided. The problem is not with SPA as an architecture, it's with SPA devs not implementing features that end users are accustomed to on a website. They can all be added, it just takes effort.
The biggest valid criticism to SPAs IMHO is the initial site load. There are ways to mitigate (CDNs, progressive loading, compression, etc) but pound-for-pound SPAs probably have longer initial load times on average for the first page than a vanilla HTML site does.
Once it's loaded there's no faster way to traverse a website, IMHO.
Your pages load quickly in Chrome, but not in Safari or Firefox.
The back button normally preserves scroll position. Your site takes me back to the top of the list.
History transitions are especially jarring in Safari. It optimistically restores the viewport state, so at first the page appears to be loaded but doesn't respond to clicking or scrolling. Click events register before the page is repainted, so the user can end up on the wrong page. After that, the list appears to jump to the top.
As other people have mentioned, some ways of opening a new tab work, and others don't.
> Once it's loaded there's no faster way to traverse a website, IMHO.
In my experience, this is almost never true. SPAs are good for some kinds of interaction, but traversing collections of resources is what web browsers are designed to do, and they do it pretty well.
The author's criticism is that people often build SPAs based on theoretical benefits and don't recognize or don't put in the effort to fix the practical shortcomings.
That is an incredible website. It is amazingly responsive and fast, I couldn't tell it was an SPA because of how well it behaves in every possible way, yet it is far too responsive to be anything but an SPA.
Even as someone who cooks a lot, using the site doesn't come naturally to me, my typical shopping method is to go to the store and think up of what I want to cook as I stroll around the outside picking up fresh food. Or I put recipes from blogs into a shared family OneNote section and use that to do more directed shopping.
That said, the links off of the food pages are high quality, with very good info on what to do with each item, so I try and spend some time exploring the resources you've put together!
It's an incredible website! But it still does not work completely "right." For example, the back and forth buttons don't navigate to the correct scroll locations.
This actually illustrates his points. Which is this: the browser(s) ALREADY implement all of those features. It already knows forward and backward and new tabs and link and etc. etc. etc. SPA's completely ignore these and must re-implement everything. This means:
* choppy differences between different SPA
* when new browsers come out with new navigation features, guess what, you have to reimplement them!
* Extra javascript code
* Extra bug opportunities
* What if a user keeps your page open so long that you change JSON? I have seen my wife keep a tab opened for weeks....
I guess this is just my DRY training kicks into overdrive, but reimplementation of well-tested, well-proven patterns really doesn't smell right. Which was his point.
Broken for me. I am middle clicking to open in a new tab and Javascript is forcing it to open on the current page. Additionally, the page is blank except for a background image when Javascript is turned off.
The problem arguably is with SPA as an architecture.
The problem is not that SPA devs are not implementing these features, it's that the devs are responsible for implementing them in the first place. As other people have noted, even though you have gone through great lengths to make your site work as expected, "open in new tab" does not work.
These are browser features, and devs shouldn't have to worry about implementing them.
The biggest things for me are probably the excessive amount of resources used, the long load times, how hard it is to get things "right" (like not breaking the back button) and links taking awhile to load because we have to load your stupid SPA (if they work at all).
SPAs did win out big in one area though. On mobile. Except on mobile they're called "apps". As much as many HNers like to chafe against native mobile development as they yearn for the open standards of the Web, native apps have basically "won". Users love em.
I guess that leaves desktop.
I do wish more people asked "does my Web presence need to be an SPA?" or even "will it benefit significantly from being an SPA?" because I feel like the answer more often than not is "no".
How hard it is to get things right? It's not hard at all. It's builtin with frameworks like Ember or Angular, and for React you got react-router which does things correctly by default. It's just bad programming. I don't even understand why people would make an SPA without a url-router. Doesn't that just make development harder/more anoying?
Why would links take longer to load in a SPA? CSS, Javascript and the like should already be downloaded, there should be much less networking involved.
Also. My SPA's come in at around 120-130kb minified (no gzip). That's about the same as "pure-html" sites which include jquery.
I do agree with your last point though. Pure content sites, or even "mostly"-content sites, is probably better off with backend generated html.
I wouldn't say that mobile apps "won" anything, just that networks and hardware aren't fast enough yet for browser on mobile. Desktop started the same way, and just as most of the desktop apps have moved to the browser, so too will mobile apps. React native, cordova etc are just the early signs of this transition.
One big downside of SPAs the author didn't mention is the chain reaction effect I wrote about last year[1], where if you start to implement one browser-native feature in JS, it breaks other browser-native features, and it begins a chain reaction where you basically implement the whole site in JavaScript, and the result ends up being noticeably worse than if you had just stuck with native browser features from the beginning. It's not necessarily specific to SPAs, but it's definitely a very common problem I see with them.
None of the things described here are inherent to single page apps. Ember (with Ember Data and proper routing), for example, solves most of the issues he brings up (back button not working, failure to link to individual items) by convention.
The downside of Ember (at least the last time I used it, several years ago) is you must do things "the Ember way", which isn't inherently bad, but there's a lot of implicit functionality that "just works" until it doesn't, and can make debugging a painful experience.
Some of this hits home for me. I work on the WAY DEEP backend of one of these 'modern single page apps', so dont really care about the REST apis or UI/UX. I will say our actual website is a nightmare to use and I attribute a lot of it to (A) mgmt demanding bad UI/UX on short timeframes(B) front end folks having the power to write butt loads of JS code to achieve said goals with no thought to system wide architecture / integration. We have so much shit happening each time you click to a different part of webapp, we seem to have hit the messy phase of a codebase where you cant change one part of the site without breaking something else in a totally different section of the codebase.
to be fair though, as with everything there are pros and cons. Once i learned to deal with some of complexities and crazy UI/UX, using our web app is like driving a spaceship and it does work pretty fast considering all the data getting lifted, html getting rendered etc.
Answer: "Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab."
I really hate articles that have a large fixed header at the top, that causes the next few lines of text to be hidden when I hit page down. Something something glass houses and throwing stones.
I half way agree here. Too many things are SPA's that don't need to be. An internal tool used by < 1000 people? Maybe let that stay server side rendered. A cutting edge app that promises a new clean way to bank/farm/hire/cryptowhatever, then please embrace SPA's and PWA's. The reason we have a glut of these SPA's is because we have devs, designers and product not recognizing context. Some things don't need to look or feel cutting edge. The real tragedy here is that I've seen companies burn thousands on SPA's when they could have had one front-end on their API team make it server side rendered.
Most websites get little benefit from using a SPA architecture, and the negative aspects are significant:
- deploy headaches
- the infamous JS fatigue
- debugging (minified code and nested anonymous functions make it painful)
- troubles with content blockers
I guess we'll have to wait a few years until the JS/SPA ecosystem will become more mature and find good solutions to these annoyances. Until then I'd gladly stick with rails, django & friends, both as a developer and as a user.
He makes some good points. There are good reasons and uses of the tech in SPAs, for example, I show previews of documents made with forms by hiding the form and rendering the document, but on a blog app I made where I did the much the same thing I made a button that linked to the article so users could find it easily. The "go back" button didn't work to reopen it though and I suspect search engines wouldn't have known what to do with it.
Most of his argument is negated by using routing and route parameters. Generate a unique ID for all data points and any page can be linked to and will be in the history.
> Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab.
That reminds me: if anyone out there has any advice how to make AppCache play nice with JavaScript-based routing solutions (say, react-router), please let me know.
>>> Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab
All these concerns assume HTML 5 history api doesn't exist. It does and SPAs can do all that.
Stefan identifies common pitfalls or shortcomings of most single page applications such as:
1. Bad performance because of too many operations
2. Breaking browser navigation buttons
3. Not having unique links/anchors to in-page content.
While there are in fact multiple ways of bringing focus and solving these problems the authors suggests that simply ditching SPAs for native toolkits or backend/frontend system is the way to go.
While switching away from SPAs might mitigate the problems listed above - it will also present new problems that developers have to tackle - or simply spend time on.
The main problem here is how hard the problems he describes are to deal with in current frameworks I believe.
He has one thing 100% right - bringing attention to those problems is the right way to go.
Lot of SPAs I have seen also reinvent the desktop. They have their own tabs and dashboards. And they do it badly - no shortcuts, no integration with the file system..
[+] [-] trjordan|8 years ago|reply
- Every click is a full page load, and you still didn't manage to get caching right, so it takes 2 seconds to load.
- When I have multiple tabs open, your badges and notifications fall out of date, because you never poll for updates.
- If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.
- You forgot to update the styles on that rarely-used page, and now it's got half the new CSS and half the old CSS and the point is the header runs halfway down the goddamn content in Times New Roman.
I get it, there are problems with SPAs. But this perfect land of one-page-per-link has real usability problems if it's not implemented properly, and there's a lot of maintenance overhead associated with a sprawling mass of transcluded templates. If we're going to criticize an architecture because it's easy to poorly implement, I don't think "ROCA" or whatever we're calling it has any meaningful benefits over SPAs in the general case.
[+] [-] cpburns2009|8 years ago|reply
Why I hate your SPA:
- If I click on a link, I receive no indication that I actually clicked a link, then 2-10 seconds later the page abruptly loads. Sometimes the page doesn't load at all.
- I cannot tap and hold a link, wait a second for the pop-up menu, and open the link in a new tab because the link isn't actually a link. It's implemented in JavaScript.
- The back and forward buttons don't work as expected because either history isn't maintained or it's shoddy (scrolling should not be a history event).
- The refresh page button don't work as expected because it resets you to the beginning.
[+] [-] romaniv|8 years ago|reply
Funny that you mention it. Loosing form data on page refresh or clicking "back" button was a problem on the Web until browsers started keeping form state along with page history. Suddenly millions of websites got this new feature without actually doing anything differently. But that was only possible because page transfers were semantic. Frameworks of that time that tried to manage their own form state (like ASP.NET WebForms) didn't have real page transfers, so they didn't get this "upgrade" and currently are significantly worse off in terms of usability.
I think there is a lesson here.
[+] [-] tjoff|8 years ago|reply
1. Every click is fetched and rendered faster than your javascript code has had a chance to execute, let alone fetch or render.
2. True, minor headache though compared to the vast improvements in usability.
3. Nope.
4. Nope, this is a bug - something javascript pages most certainly are not immune against.
[+] [-] smhenderson|8 years ago|reply
Even when I was coding web pages in Perl in the 90's I wouldn't do that to a user, that's just mean. You don't need a SPA to provide proper error handling that also rebuilds previous state.
[+] [-] darkstar999|8 years ago|reply
> You forgot to update the styles on that rarely-used page
That's solved with proper css, not SPA.
[+] [-] romaniv|8 years ago|reply
This was fixed in browsers years ago when they started keeping form state along with page history. I can refresh this page, go back and forth in history, and this text box will keep my comment. Ironically, websites that tried to be clever about form state management and faked page transfers (like ASP.NET WebForms) didn't benefit from the fixes and currently are significantly worse off in terms of usability than websites that used vanilla forms.
I think there is a lesson here.
[+] [-] yellowapple|8 years ago|reply
In about 95% of the SPAs I've tried, each click takes even longer than that.
"you never poll for updates"
Yes, because apparently AJAX/AJAJ is completely nonexistent and there's absolutely zero ground between "pure-HTML like it's 1991" and "VueWangulaReact.js single-page monstrosity".
Hell, even a meta-refresh will fix that if you really do want "pure-HTML like it's 1991", though that's certainly inelegant.
[+] [-] ojosilva|8 years ago|reply
- The author is describing hypertext, which is perfectly fine for textual static content, one of the key goals for which the World Wide Web was conceived.
- Server-side generation of HTML seems totally out of place for other use cases: HTML/JS are now the assembly languages of the web and they belong in the browser. Besides a more distributed architecture is just perfect: server and client focus on what they do best.
- Fixing web-apps with broken history buttons and unlinkable urls is important, but to be honest there are fewer and fewer SPAs that are mono-url these days. And it's perfectly fine to have a unlinkable "Delete this Invoice" app button. If it's not real content it should not be a link.
[+] [-] s17n|8 years ago|reply
The first two are fair criticism but they aren't nearly as detrimental to the user experience as the typical single page app antipatterns (no history, no indication of page loading, refresh button is broken, etc).
While it is of course possible to execute any design well or poorly, the observation that a typical single page app is worse than a typical multipage app is certainly valid.
[+] [-] lscharen|8 years ago|reply
This. I have a very short list of architectural must-haves that I use when evaluating junior dev's code at the start of a project, and not having robust error handling that preserves submitted form information is right up near the top.
It's an annoying design mistake with two input elements, unworkable with five, and just plain cruel beyond that.
[+] [-] Pigo|8 years ago|reply
[+] [-] mnarayan01|8 years ago|reply
This really shouldn't be a problem for anything other than file inputs. If someone's form is losing submitted information on a validation failure when using an actual HTML submit, then I find it pretty unlikely that they're doing a good job of AJAX submission.
[+] [-] amelius|8 years ago|reply
How bad is that really if users are aware of it and they can simply reload the page?
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] ordinaryperson|8 years ago|reply
My SPA is different - https://www.seasonalfoodguide.org.
Browser back button works like normal.
Each screen has its own discrete URL, so you can share links, refresh, bookmark or open in a new tab, just like any other website.
I think the criticism here is misguided. The problem is not with SPA as an architecture, it's with SPA devs not implementing features that end users are accustomed to on a website. They can all be added, it just takes effort.
The biggest valid criticism to SPAs IMHO is the initial site load. There are ways to mitigate (CDNs, progressive loading, compression, etc) but pound-for-pound SPAs probably have longer initial load times on average for the first page than a vanilla HTML site does.
Once it's loaded there's no faster way to traverse a website, IMHO.
[+] [-] pseudalopex|8 years ago|reply
The back button normally preserves scroll position. Your site takes me back to the top of the list.
History transitions are especially jarring in Safari. It optimistically restores the viewport state, so at first the page appears to be loaded but doesn't respond to clicking or scrolling. Click events register before the page is repainted, so the user can end up on the wrong page. After that, the list appears to jump to the top.
As other people have mentioned, some ways of opening a new tab work, and others don't.
> Once it's loaded there's no faster way to traverse a website, IMHO.
In my experience, this is almost never true. SPAs are good for some kinds of interaction, but traversing collections of resources is what web browsers are designed to do, and they do it pretty well.
The author's criticism is that people often build SPAs based on theoretical benefits and don't recognize or don't put in the effort to fix the practical shortcomings.
[+] [-] strken|8 years ago|reply
This app is a good example of one of my pet peeves: ctrl-click doesn't reliably open links in a new tab.
[+] [-] com2kid|8 years ago|reply
That is an incredible website. It is amazingly responsive and fast, I couldn't tell it was an SPA because of how well it behaves in every possible way, yet it is far too responsive to be anything but an SPA.
Even as someone who cooks a lot, using the site doesn't come naturally to me, my typical shopping method is to go to the store and think up of what I want to cook as I stroll around the outside picking up fresh food. Or I put recipes from blogs into a shared family OneNote section and use that to do more directed shopping.
That said, the links off of the food pages are high quality, with very good info on what to do with each item, so I try and spend some time exploring the resources you've put together!
[+] [-] magice|8 years ago|reply
This actually illustrates his points. Which is this: the browser(s) ALREADY implement all of those features. It already knows forward and backward and new tabs and link and etc. etc. etc. SPA's completely ignore these and must re-implement everything. This means: * choppy differences between different SPA * when new browsers come out with new navigation features, guess what, you have to reimplement them! * Extra javascript code * Extra bug opportunities * What if a user keeps your page open so long that you change JSON? I have seen my wife keep a tab opened for weeks....
I guess this is just my DRY training kicks into overdrive, but reimplementation of well-tested, well-proven patterns really doesn't smell right. Which was his point.
[+] [-] Washuu|8 years ago|reply
[+] [-] mnarayan01|8 years ago|reply
This, in combination with the fact that developers don't take the extra effort, is exactly what the article is complaining about.
[+] [-] anamexis|8 years ago|reply
The problem is not that SPA devs are not implementing these features, it's that the devs are responsible for implementing them in the first place. As other people have noted, even though you have gone through great lengths to make your site work as expected, "open in new tab" does not work.
These are browser features, and devs shouldn't have to worry about implementing them.
[+] [-] virtualwhys|8 years ago|reply
Only one data point, but 15 seconds to load here. After that, yes, everything is, as advertised, snappy.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] cletus|8 years ago|reply
The biggest things for me are probably the excessive amount of resources used, the long load times, how hard it is to get things "right" (like not breaking the back button) and links taking awhile to load because we have to load your stupid SPA (if they work at all).
SPAs did win out big in one area though. On mobile. Except on mobile they're called "apps". As much as many HNers like to chafe against native mobile development as they yearn for the open standards of the Web, native apps have basically "won". Users love em.
I guess that leaves desktop.
I do wish more people asked "does my Web presence need to be an SPA?" or even "will it benefit significantly from being an SPA?" because I feel like the answer more often than not is "no".
[+] [-] Skinney|8 years ago|reply
Why would links take longer to load in a SPA? CSS, Javascript and the like should already be downloaded, there should be much less networking involved.
Also. My SPA's come in at around 120-130kb minified (no gzip). That's about the same as "pure-html" sites which include jquery.
I do agree with your last point though. Pure content sites, or even "mostly"-content sites, is probably better off with backend generated html.
[+] [-] EGreg|8 years ago|reply
You can wrap your SPA in a native app and thus cache the requests ahead of time. But develop on the web, and use Cordova.
[+] [-] tyrw|8 years ago|reply
[+] [-] sidlls|8 years ago|reply
[+] [-] _sdegutis|8 years ago|reply
[1]: https://sdegutis.com/blog/2016-03-21-why-i-dont-use-clojures...
[+] [-] _m8fo|8 years ago|reply
[+] [-] coldtea|8 years ago|reply
Does it matter though, if they are still all prevalent on single page apps?
[+] [-] mysterydip|8 years ago|reply
[+] [-] sidcool|8 years ago|reply
[+] [-] brootstrap|8 years ago|reply
to be fair though, as with everything there are pros and cons. Once i learned to deal with some of complexities and crazy UI/UX, using our web app is like driving a spaceship and it does work pretty fast considering all the data getting lifted, html getting rendered etc.
[+] [-] tyrw|8 years ago|reply
[+] [-] derekp7|8 years ago|reply
[+] [-] gorpomon|8 years ago|reply
[+] [-] jmartens|8 years ago|reply
[+] [-] paozac|8 years ago|reply
- deploy headaches
- the infamous JS fatigue
- debugging (minified code and nested anonymous functions make it painful)
- troubles with content blockers
I guess we'll have to wait a few years until the JS/SPA ecosystem will become more mature and find good solutions to these annoyances. Until then I'd gladly stick with rails, django & friends, both as a developer and as a user.
[+] [-] twobyfour|8 years ago|reply
[+] [-] darkstar999|8 years ago|reply
[+] [-] oblib|8 years ago|reply
[+] [-] 5trokerac3|8 years ago|reply
[+] [-] vanderZwan|8 years ago|reply
That reminds me: if anyone out there has any advice how to make AppCache play nice with JavaScript-based routing solutions (say, react-router), please let me know.
[+] [-] seanalltogether|8 years ago|reply
Modern users want content delivered to them in a personal, rapid, contextual(stateful) manner
Fight.
[+] [-] vilmosi|8 years ago|reply
All these concerns assume HTML 5 history api doesn't exist. It does and SPAs can do all that.
[+] [-] atanasb|8 years ago|reply
Stefan identifies common pitfalls or shortcomings of most single page applications such as:
1. Bad performance because of too many operations
2. Breaking browser navigation buttons
3. Not having unique links/anchors to in-page content.
While there are in fact multiple ways of bringing focus and solving these problems the authors suggests that simply ditching SPAs for native toolkits or backend/frontend system is the way to go.
While switching away from SPAs might mitigate the problems listed above - it will also present new problems that developers have to tackle - or simply spend time on.
The main problem here is how hard the problems he describes are to deal with in current frameworks I believe. He has one thing 100% right - bringing attention to those problems is the right way to go.
[+] [-] js8|8 years ago|reply