215

I've read about SPA and it advantages. I find most of them unconvincing. There are 3 advantages that arouse my doubts.

Question: Can you act as advocate of SPA and prove that I am wrong about first three statements?

                              === ADVANTAGES ===

1. SPA is extremely good for very responsive sites:

Server-side rendering is hard to implement for all the intermediate states - small view states do not map well to URLs.

Single page apps are distinguished by their ability to redraw any part of the UI without requiring a server roundtrip to retrieve HTML. This is achieved by separating the data from the presentation of data by having a model layer that handles data and a view layer that reads from the models.

What is wrong with holding a model layer for non-SPA? Does SPA the only compatible architecture with MVC on client side?

2. With SPA we don't need to use extra queries to the server to download pages.

Hah, and how many pages user can download during visiting your site? Two, three? Instead there appear another security problems and you need to separate your login page, admin page etc into separate pages. In turn it conflicts with SPA architecture.

3.May be any other advantages? Don't hear about any else..

                            === DISADVANTAGES ===
  1. Client must enable javascript.
  2. Only one entry point to the site.
  3. Security.

P.S. I've worked on SPA and non-SPA projects. And I'm asking those questions because I need to deepen my understanding. No mean to harm SPA supporters. Don't ask me to read a bit more about SPA. I just want to hear your considerations about that.

VB_
  • 45,112
  • 42
  • 145
  • 293
  • 1
    2. and 3. are not issues. – Wiktor Zychla Feb 18 '14 at 18:17
  • @WiktorZychla please tell me why. What about the first one? Maybe I miss any advantages? – VB_ Feb 18 '14 at 18:18
  • 1
    I suggest that instead of just reading about SPAs, you could spend some time playing with an actual framework like extjs. The time soent there will pay off and you will be able to answer your own questions. – Wiktor Zychla Feb 18 '14 at 18:22
  • 3
    @WiktorZychla I work on a SPA project. I use JQuery + Backbone. I also have written a JSP site. I can't answer those questions. Can you? – VB_ Feb 18 '14 at 18:24
  • @VolodymirBakhmatiuk: could you then elaborate on these disadvantages? Why is security your concern in SPA context? – Wiktor Zychla Feb 18 '14 at 18:27
  • @WiktorZychla user gets all web content, even content that he hasn't rights to get. It requires aditional server side validations, additional precautions to prevent abuse of authority. – VB_ Feb 18 '14 at 18:35
  • 1
    As to your disadvantages, [JavaScript](http://stackoverflow.com/questions/9478737/browser-statistics-on-javascript-disabled) is rather widely enabled (but as with any dependency it helps to know your users) and security is identical between any approach because the security is managed in the requests. SPA is still HTTP, just without the unneeded "rest of the page" being loaded on each request. – Jason Sperske Feb 18 '14 at 18:39
  • This also applies to nonSPA applications. – Wiktor Zychla Feb 18 '14 at 18:40
  • There is no requirement that your users get "all of the content" with an SPA. The same logic you apply when rendering your HTML you can apply when generating JSON. – Jason Sperske Feb 18 '14 at 18:41
  • @WiktorZychla I mean that in non-SPA applications user can't get page which he hasn't rights to see. – VB_ Feb 18 '14 at 18:42
  • @JasonSperske yes you can separate your login page. But lets imagine that you have many user roles each of them has different pages and rights. Than you won't avoid the situation when one user get the content/js code that belongs to another – VB_ Feb 18 '14 at 18:46
  • @VolodymyrBakhmatiuk: in an SPA application you guard your web apis somehow (tokens, cookies). No unauthorized access is possible. – Wiktor Zychla Feb 18 '14 at 19:19
  • @WiktorZychla what about that fact that all your html is loaded to a user at once – VB_ Feb 18 '14 at 19:46
  • 3
    @VolodymyrBakhmatiuk: that doesn't matter, what user can compromise is the gui not the data because the data is guarded at the server side. – Wiktor Zychla Feb 18 '14 at 21:07
  • 1
    SPA has serious UI/UX disadvantageous: Losing scroll position on navigating back, unable to Autofill Form on navigating back, unable to scrape page with certain tools, unable to open links in new window, Slow initial load times.... – Muhammad Umer Jul 13 '16 at 21:06
  • @MuhammadUmer I can't agree with you. With SPA you can easily keep scroll position or autofill fields. that's even easier since you keep that state on client side – VB_ Jul 14 '16 at 08:40
  • in browser if you're typing and navigate away and come back text will be in input field. normal behavior is to refresh to clear all fields which needs to be implemented on top of autofill. Scroll position isn't easy at all. scroll position is not even based on session but navigation history. you can reach to same page in two tabs and have different scroll positions. Plus since you cant track history outside of your app that makes it impossible to come back to same page/position if user went to other site. – Muhammad Umer Jul 14 '16 at 12:43
  • @MuhammadUmer you can keep everything you want in SPA state. If you can't save smth due code refresh (page reload, close tab and so on) probably you shouldn't. That's strange UX to store scroll position after user close/reopen your site, isn't it? That's sound more like you trying to make SPA behave like native desktop app. If you still want that benefits you may take a look at isomorphic apps which achieve best of two worlds – VB_ Jul 14 '16 at 13:39
  • ?.. not what i said. Two behaviors: Keeping scrollPosition/page based on navigation. Autofill form based on navigation. The Scroll Position is linked with navigation history, you can't simply save position for each page and show it. Instead you need to somehow determine if user navigated back from another view in your app vs directly landed on that page. And this is limited to your app, but in browser you can navigate from bbc.com to msn.com and position on page is reserved. But if you go to msn.com in new tab scroll position is default, to top. – Muhammad Umer Jul 14 '16 at 14:12
  • 6
    What if this question is opinion based? I often wondered why and when should I write an SPA? It'd be helpful if SO allowed Pros n Cons questions as well – Anurag Awasthi Apr 03 '17 at 11:12
  • 1
    This is a very important question facing all site developers. Please vote to re-open. – Greg Gum Nov 13 '17 at 20:16
  • __SPA myths.__ There are two misconceptions about SPA: (1) It's bad for SEO. (2) SSR offers better performance. See the [performance review](https://github.com/winwiz1/crisp-react/blob/master/docs/benchmarks/PERFORMANCE.md#performance) and the [SEO article](https://hackernoon.com/single-page-application-dispelling-seo-myths). I'm the author. – winwiz1 Jan 17 '22 at 04:35

11 Answers11

149

Let's look at one of the most popular SPA sites, GMail.

1. SPA is extremely good for very responsive sites:

Server-side rendering is not as hard as it used to be with simple techniques like keeping a #hash in the URL, or more recently HTML5 pushState. With this approach the exact state of the web app is embedded in the page URL. As in GMail every time you open a mail a special hash tag is added to the URL. If copied and pasted to other browser window can open the exact same mail (provided they can authenticate). This approach maps directly to a more traditional query string, the difference is merely in the execution. With HTML5 pushState() you can eliminate the #hash and use completely classic URLs which can resolve on the server on the first request and then load via ajax on subsequent requests.

2. With SPA we don't need to use extra queries to the server to download pages.

The number of pages user downloads during visit to my web site?? really how many mails some reads when he/she opens his/her mail account. I read >50 at one go. now the structure of the mails is almost the same. if you will use a server side rendering scheme the server would then render it on every request(typical case). - security concern - you should/ should not keep separate pages for the admins/login that entirely depends upon the structure of you site take paytm.com for example also making a web site SPA does not mean that you open all the endpoints for all the users I mean I use forms auth with my spa web site. - in the probably most used SPA framework Angular JS the dev can load the entire html temple from the web site so that can be done depending on the users authentication level. pre loading html for all the auth types isn't SPA.

3. May be any other advantages? Don't hear about any else..

  • these days you can safely assume the client will have javascript enabled browsers.
  • only one entry point of the site. As I mentioned earlier maintenance of state is possible you can have any number of entry points as you want but you should have one for sure.
  • even in an SPA user only see to what he has proper rights. you don't have to inject every thing at once. loading diff html templates and javascript async is also a valid part of SPA.

Advantages that I can think of are:

  1. rendering html obviously takes some resources now every user visiting you site is doing this. also not only rendering major logics are now done client side instead of server side.
  2. date time issues - I just give the client UTC time is a pre set format and don't even care about the time zones I let javascript handle it. this is great advantage to where I had to guess time zones based on location derived from users IP.
  3. to me state is more nicely maintained in an SPA because once you have set a variable you know it will be there. this gives a feel of developing an app rather than a web page. this helps a lot typically in making sites like foodpanda, flipkart, amazon. because if you are not using client side state you are using expensive sessions.
  4. websites surely are extremely responsive - I'll take an extreme example for this try making a calculator in a non SPA website(I know its weird).

Updates from Comments

It doesn't seem like anyone mentioned about sockets and long-polling. If you log out from another client say mobile app, then your browser should also log out. If you don't use SPA, you have to re-create the socket connection every time there is a redirect. This should also work with any updates in data like notifications, profile update etc

An alternate perspective: Aside from your website, will your project involve a native mobile app? If yes, you are most likely going to be feeding raw data to that native app from a server (ie JSON) and doing client-side processing to render it, correct? So with this assertion, you're ALREADY doing a client-side rendering model. Now the question becomes, why shouldn't you use the same model for the website-version of your project? Kind of a no-brainer. Then the question becomes whether you want to render server-side pages only for SEO benefits and convenience of shareable/bookmarkable URLs

Parv Sharma
  • 12,581
  • 4
  • 48
  • 80
  • 4
    Good on you for making this a community Wiki answer :) Also these are great points – Jason Sperske Feb 18 '14 at 18:50
  • @Parv Sharma explain please more widely why maintain state is more comphortable with SPA? – VB_ Feb 18 '14 at 19:13
  • @Parv Sharma It'll be greate if you explain all that on your example (such as calculator).I mean state holding, view rendering, security and so on. And in any case - thanks – VB_ Feb 18 '14 at 19:18
  • state holding - previous callculations etc. view rendering - you can render numbers in diff language based upon users location. security - if i were to make a calculator in which only an admin can do a + then i would have done calculations on server sending numbers so that server can check whether to send the sum or just an unauthorized response – Parv Sharma Feb 18 '14 at 20:06
  • 5
    You cannot easily index pages for SEO optimization with SPA. – Ankit_Shah55 Jul 12 '15 at 20:15
  • 2
    @Ankit_Shah55 This may no longer be true (at least for google, who owns most of the search engine market share anyways). See "Deprecating our AJAX crawling scheme" from Google. My understanding is that you don't have to do anything special for Google to index your SPA anymore. I think you will need to make sure to support pushstate, however, because I don't think google indexes hash fragments. – Kevin Wheeler Dec 23 '15 at 00:04
  • I think an SPA may complicate HTTP status codes in some cases. For instance, if one of your internal links is broken (which of course it shouldn't be), you won't be able to return a 404 since it won't be a new page load. – Kevin Wheeler Dec 23 '15 at 00:31
  • A calculator's state should be updated without a page refresh, yes. That implies using Javascript, but not necessarily a single page app. I worked on a server-rendered app where one page had JS to support adding invoice items, with a total calculated on the fly. (I believe the actual calculation was done server-side via AJAX, using Ruby's `BigDecimal` for more accuracy.) – Nathan Long Nov 28 '16 at 13:35
  • 3
    It doesn't seem like anyone mentioned about sockets and long-polling. If you log out from another client say mobile app, then your browser should also log out. If you don't use SPA, you have to re-create the socket connection every time there is a redirect. This should also work with any updates in data like notifications, profile update etc. – Taku Mar 08 '17 at 09:33
  • An alternate perspective: Aside from your website, will your project involve a native mobile app? If yes, you are most likely going to be feeding raw data to that native app from a server (ie JSON) and doing client-side processing to render it, correct? So with this assertion, you're ALREADY doing a client-side rendering model. Now the question becomes, why shouldn't you use the same model for the website-version of your project? Kind of a no-brainer. Then the question becomes whether you want to render server-side pages only for SEO benefits and convenience of shareable/bookmarkable URLs. – Kalnode Dec 12 '17 at 16:40
  • @KevinWheeler, regarding SEO, there are still some limitation on what Googlebot can do. For example, Googlebot does not understand ES6. Also, the page can end up rendered partially as the bot uses an old Chrome engine. And finally, it takes longer for the page to be indexed if the content has to be rendered. See: https://developers.google.com/search/docs/guides/rendering – Eric Jeker Mar 04 '19 at 06:53
74

I am a pragmatist, so I will try to look at this in terms of costs and benefits.

Note that for any disadvantage I give, I recognize that they are solvable. That's why I don't look at anything as black and white, but rather, costs and benefits.

Advantages

  • Easier state tracking - no need to use cookies, form submission, local storage, session storage, etc. to remember state between 2 page loads.
  • Boiler plate content that is on every page (header, footer, logo, copyright banner, etc.) only loads once per typical browser session.
  • No overhead latency on switching "pages".

Disadvantages

  • Performance monitoring - hands tied: Most browser-level performance monitoring solutions I have seen focus exclusively on page load time only, like time to first byte, time to build DOM, network round trip for the HTML, onload event, etc. Updating the page post-load via AJAX would not be measured. There are solutions which let you instrument your code to record explicit measures, like when clicking a link, start a timer, then end a timer after rendering the AJAX results, and send that feedback. New Relic, for example, supports this functionality. By using a SPA, you have tied yourself to only a few possible tools.
  • Security / penetration testing - hands tied: Automated security scans can have difficulty discovering links when your entire page is built dynamically by a SPA framework. There are probably solutions to this, but again, you've limited yourself.
  • Bundling: It is easy to get into a situation when you are downloading all of the code needed for the entire web site on the initial page load, which can perform terribly for low-bandwidth connections. You can bundle your JavaScript and CSS files to try to load in more natural chunks as you go, but now you need to maintain that mapping and watch for unintended files to get pulled in via unrealized dependencies (just happened to me). Again, solvable, but with a cost.
  • Big bang refactoring: If you want to make a major architectural change, like say, switch from one framework to another, to minimize risk, it's desirable to make incremental changes. That is, start using the new, migrate on some basis, like per-page, per-feature, etc., then drop the old after. With traditional multi-page app, you could switch one page from Angular to React, then switch another page in the next sprint. With a SPA, it's all or nothing. If you want to change, you have to change the entire application in one go.
  • Complexity of navigation: Tooling exists to help maintain navigational context in SPA's, like history.js, Angular 2, most of which rely on either the URL framework (#) or the newer history API. If every page was a separate page, you don't need any of that.
  • Complexity of figuring out code: We naturally think of web sites as pages. A multi-page app usually partitions code by page, which aids maintainability.

Again, I recognize that every one of these problems is solvable, at some cost. But there comes a point where you are spending all your time solving problems which you could have just avoided in the first place. It comes back to the benefits and how important they are to you.

Brandon
  • 9,822
  • 3
  • 27
  • 37
  • 2
    I think this response provides very valid feedback from someone who has actually built a large complex system and experienced the long-term casualties SPA brings (or looks like so) – DanielCuadra Dec 09 '16 at 21:37
  • 4
    What I get from this answer is, avoid SPA if you are doing anything even remotely serious. – IvanP Jan 16 '17 at 10:33
  • I think you gave us a very helpful overview rather just answer . Really pragmatic. – mercury Jun 10 '17 at 03:05
  • 3
    I agree. SPA looked great when we did proof of concept. 3 years down the road now, we have seen every problem mentioned in this answer and we continue to spend a lot of time on trying to solve them. Framework change is no longer an option and we're stuck with a framework that basically stopped development. – Qi Fan Jun 21 '17 at 22:10
  • 1
    I have experienced the last 4 disadvantage points directly. I have built a 10K LOC web app with Angular, Bootstrap & PHP as the primary players with about 5K of Angular JS code. There are some really neat features of Angular but at this point I really wish I had just used a traditional page based approach and I think it would have significantly sped up development of the site. – Zack Macomber Aug 29 '17 at 14:25
  • I agree 100% with Brandon. If you have to read the SPA code done by somebody else, it could be the biggest headache. – Sam Patirage Jul 07 '19 at 02:18
  • @ZackMacomber I'm curious, if you were using PHP, how was it an SPA in the first place? Isn't an SPA meant to be JS-only? – Hashim Aziz Oct 26 '20 at 18:43
  • 1
    @Prometheus I used PHP (via the Slim Framework) only on the backend for the REST API portion of the app. The SPA portion was built with Angular. – Zack Macomber Oct 27 '20 at 12:58
42

Disadvantages

1. Client must enable javascript. Yes, this is a clear disadvantage of SPA. In my case I know that I can expect my users to have JavaScript enabled. If you can't then you can't do a SPA, period. That's like trying to deploy a .NET app to a machine without the .NET Framework installed.

2. Only one entry point to the site. I solve this problem using SammyJS. 2-3 days of work to get your routing properly set up, and people will be able to create deep-link bookmarks into your app that work correctly. Your server will only need to expose one endpoint - the "give me the HTML + CSS + JS for this app" endpoint (think of it as a download/update location for a precompiled application) - and the client-side JavaScript you write will handle the actual entry into the application.

3. Security. This issue is not unique to SPAs, you have to deal with security in exactly the same way when you have an "old-school" client-server app (the HATEOAS model of using Hypertext to link between pages). It's just that the user is making the requests rather than your JavaScript, and that the results are in HTML rather than JSON or some data format. In a non-SPA app you have to secure the individual pages on the server, whereas in a SPA app you have to secure the data endpoints. (And, if you don't want your client to have access to all the code, then you have to split apart the downloadable JavaScript into separate areas as well. I simply tie that into my SammyJS-based routing system so the browser only requests things that the client knows it should have access to, based on an initial load of the user's roles, and then that becomes a non-issue.)

Advantages

  1. A major architectural advantage of a SPA (that rarely gets mentioned) in many cases is the huge reduction in the "chattiness" of your app. If you design it properly to handle most processing on the client (the whole point, after all), then the number of requests to the server (read "possibilities for 503 errors that wreck your user experience") is dramatically reduced. In fact, a SPA makes it possible to do entirely offline processing, which is huge in some situations.

  2. Performance is certainly better with client-side rendering if you do it right, but this is not the most compelling reason to build a SPA. (Network speeds are improving, after all.) Don't make the case for SPA on this basis alone.

  3. Flexibility in your UI design is perhaps the other major advantage that I have found. Once I defined my API (with an SDK in JavaScript), I was able to completely rewrite my front-end with zero impact on the server aside from some static resource files. Try doing that with a traditional MVC app! :) (This becomes valuable when you have live deployments and version consistency of your API to worry about.)

So, bottom line: If you need offline processing (or at least want your clients to be able to survive occasional server outages) - dramatically reducing your own hardware costs - and you can assume JavaScript & modern browsers, then you need a SPA. In other cases it's more of a tradeoff.

GaTechThomas
  • 5,421
  • 5
  • 43
  • 69
Lars Kemmann
  • 5,509
  • 3
  • 35
  • 67
  • 6
    Another advantage is that a SPA can be saved as a bookmark ("Add to home screen") on iOS and have it open in fullscreen mode (assuming you have defined the correct [meta tag](https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html)), making it feel like a native app and not a web page. – Strille Feb 18 '14 at 19:27
  • 9
    3. It is just as easy in traditional MVC app. If you operate with the same data you just need to make changes in the V (view) part of your app. This is usually templates, css and js. – karantan Feb 28 '15 at 09:57
  • Can a SPA version of SO have links to individual questions to share, or what advantages and disadvantages would it bring, for example in terms of SEO (past questions' searchability from a search engine). – sçuçu Apr 27 '16 at 17:15
  • 6
    Most SPA apps I've seen are more chatty than server side apps. Instead of a single request to get data you end up with more requests to the server per page. – Matthew Whited Sep 04 '16 at 09:57
30

One major disadvantage of SPA - SEO. Only recently Google and Bing started indexing Ajax-based pages by executing JavaScript during crawling, and still in many cases pages are being indexed incorrectly.

While developing SPA, you will be forced to handle SEO issues, probably by post-rendering all your site and creating static html snapshots for crawler's use. This will require a solid investment in a proper infrastructures.

Update 19.06.16:

Since writing this answer a while ago, I gain much more experience with Single Page Apps (namely, AngularJS 1.x) - so I have more info to share.

In my opinion, the main disadvantage of SPA applications is SEO, making them limited to kind of "dashboard" apps only. In addition, you are going to have a much harder times with caching, compared to classic solutions. For example, in ASP.NET caching is extreamly easy - just turn on OutputCaching and you are good: the whole HTML page will be cached according to URL (or any other parameters). However, in SPA you will need to handle caching yourself (by using some solutions like second level cache, template caching, etc..).

Saurabh
  • 71,488
  • 40
  • 181
  • 244
Illidan
  • 4,047
  • 3
  • 39
  • 49
  • Is it better SEO to have traffic forwarded to single page vs spread over a couple pages? – SILENT Apr 25 '16 at 15:17
  • @SILENT - not sure, but since all pages on the same domain, I don't think there should be a difference – Illidan May 02 '16 at 04:17
  • I don't understand the SEO argument. Can't you just have the same routes defined in your SPA also defined server-side as well, so search bots can easily crawl your site, and at the same time people get direct URLs to your content. And so, you may have two sets of templates to maintain, big deal. You can try to use universal templating if it's such a concern. – Kalnode Nov 30 '17 at 21:05
  • @MarsAndBack: Not sure which server links you are talking about. If you mean sitemap - then it useless in case of SPA: search engines are not execute JavaScript (at least, this was the state of things a few years ago), they only download and parse HTML. So, even if you prepare sitemap - the page will be not constructed correctly. – Illidan Dec 02 '17 at 07:54
15

I would like to make the case for SPA being best for Data Driven Applications. gmail, of course is all about data and thus a good candidate for a SPA.

But if your page is mostly for display, for example, a terms of service page, then a SPA is completely overkill.

I think the sweet spot is having a site with a mixture of both SPA and static/MVC style pages, depending on the particular page.

For example, on one site I am building, the user lands on a standard MVC index page. But then when they go to the actual application, then it calls up the SPA. Another advantage to this is that the load-time of the SPA is not on the home page, but on the app page. The load time being on the home page could be a distraction to first time site users.

This scenario is a little bit like using Flash. After a few years of experience, the number of Flash only sites dropped to near zero due to the load factor. But as a page component, it is still in use.

Greg Gum
  • 33,478
  • 39
  • 162
  • 233
  • 1
    after many years of web development that is what I can confirm. you should mix both, spa and mvc apps together. you cant have an answer, either nor. I had my entire app as a spa first, figured out that my app is not listed by google correctly. so I moved to mpa and use spa only in needed situations. wordpress is also not spa and a popular framework for good reasons. – Rudolf Schmidt Nov 12 '17 at 21:46
  • 1
    This is my approach as well. I have SPA as the main area for my users to quickly rip through search results be it on a map or dynamic list. Then when looking at details, those open as standard server-rendered pages. My routes work both within the SPA, and as first-load server routes. I have duplicated template code and route code, but I couldn't care less, it's a necessary evil. – Kalnode Nov 30 '17 at 21:08
9

For such companies as google, amazon etc, whose servers are running at max capacity in 24/7-mode, reducing traffic means real money - less hardware, less energy, less maintenance. Shifting CPU-usage from server to client pays off, and SPAs shine. The advantages overweight disadvantages by far. So, SPA or not SPA depends much on the use case.

Just for mentioning another, probably not so obvious (for Web-developers) use case for SPAs: I'm currently looking for a way to implement GUIs in embedded systems and browser-based architecture seems appealing to me. Traditionally there were not many possibilities for UIs in embedded systems - Java, Qt, wx, etc or propriety commercial frameworks. Some years ago Adobe tried to enter the market with flash but seems to be not so successful.

Nowadays, as "embedded systems" are as powerful as mainframes some years ago, a browser-based UI connected to the control unit via REST is a possible solution. The advantage is, the huge palette of tools for UI for no cost. (e.g. Qt require 20-30$ per sold unit on royalty fees plus 3000-4000$ per developer)

For such architecture SPA offers many advantages - e.g. more familiar development-approach for desktop-app developers, reduced server access (often in car-industry the UI and system muddles are separate hardware, where the system-part has an RT OS).

As the only client is the built-in browser, the mentioned disadvantages like JS-availability, server-side logging, security don't count any more.

Valentin H
  • 7,240
  • 12
  • 61
  • 111
3

Disadvantages: Technically, design and initial development of SPA is complex and can be avoided. Other reasons for not using this SPA can be:

  • a) Security: Single Page Application is less secure as compared to traditional pages due to cross site scripting(XSS).
  • b) Memory Leak: Memory leak in JavaScript can even cause powerful Computer to slow down. As traditional websites encourage to navigate among pages, thus any memory leak caused by previous page is almost cleansed leaving less residue behind.
  • c) Client must enable JavaScript to run SPA, but in multi-page application JavaScript can be completely avoided.
  • d) SPA grows to optimal size, cause long waiting time. Eg: Working on Gmail with slower connection.

Apart from above, other architectural limitations are Navigational Data loss, No log of Navigational History in browser and difficulty in Automated Functional Testing with selenium.

This link explain Single Page Application's Advantages and Disadvantages.

Jean-Rémy Revy
  • 5,607
  • 3
  • 39
  • 65
Vish
  • 832
  • 7
  • 21
  • 12
    This is incorrect. a) XSS affects server-generated pages just as readily as documents generated on the client. I would argue moreso, given that there are very simple and effective XSS mitigation solutions on the client. If you don't want to allow XSS, don't interpret user-submitted content as HTML. Any decent programmer can handle this. Navigation is easy using any of the available techniques (pushState, hash routing, etc). AFT for a properly built SPA is exactly the same as any other web application. The summary of your answer is that you do not know how to build for the client. – Jason Miller Feb 24 '15 at 14:30
  • @JasonMiller: Agree. I just realize that summary is not all the context of whole blog. I will makes changes in it. Thank you. – Vish Mar 03 '15 at 11:24
  • 6
    Points a and b are completely invalid. Both have more to do with poor programming than the characteristics of a SPA, and both are perfectly possible with a traditional website; XSS vulnerabilities can affect your site even if you don't write a line of JS. Memory leaks are just as possible server-side as client side. As for point c, anyone who disables Javascript in this day and age is likely to find using the web in general a major problem, this is a non-issue IMHO. – garryp Aug 10 '15 at 15:32
3

2. With SPA we don't need to use extra queries to the server to download pages.

I still have to learn a lot but since I started learn about SPA, I love them.

This particular point may make a huge difference.

In many web apps that are not SPA, you will see that they will still retrieve and add content to the pages making ajax requests. So I think that SPA goes beyond by considering: what if the content that is going to be retrieved and displayed using ajax is the whole page? and not just a small portion of a page?

Let me present an scenario. Consider that you have 2 pages:

  1. a page with list of products
  2. a page to view the details of a specific product

Consider that you are at the list page. Then you click on a product to view the details. The client side app will trigger 2 ajax requests:

  1. a request to get a json object with the product details
  2. a request to get an html template where the product details will be inserted

Then, the client side app will insert the data into the html template and display it.

Then you go back to the list (no request is done for this!) and you open another product. This time, there will be only an ajax request to get the details of the product. The html template is going to be the same so you don't need to download again.

You may say that in a non SPA, when you open the product details, you make only 1 request and in this scenario we did 2. Yes. But you get the gain from an overall perspective, when you navigate across of many pages, the number of requests is going to be lower. And the data that is transferred between the client side and the server is going to be lower too because the html templates are going to be reused. Also, you don't need to download in every requests all those css, images, javascript files that are present in all the pages.

Also, let's consider that you server side language is Java. If you analyze the 2 requests that I mentioned, 1 downloads data (you don't need to load any view file and call the view rendering engine) and the other downloads and static html template so you can have an HTTP web server that can retrieve it directly without having to call the Java application server, no computation is done!

Finally, the big companies are using SPA: Facebook, GMail, Amazon. They don't play, they have the greatest engineers studying all this. So if you don't see the advantages you can initially trust them and hope to discover them down the road.

But is important to use good SPA design patterns. You may use a framework like AngularJS. Don't try to implement an SPA without using good design patterns because you may end up having a mess.

dam_js
  • 39
  • 2
  • 1
    Facebook is not an SPA, actually it's an MPA style app, they're using ReactJS here and there for comments, chat etc. Instagram is a good example for the full SPA page with PWA enabled. Same apply for Amazon, Youtube both are MPA apps. – Peter Húbek Oct 13 '18 at 06:10
1

Try not to consider using a SPA without first defining how you will address security and API stability on the server side. Then you will see some of the true advantages to using a SPA. Specifically, if you use a RESTful server that implements OAUTH 2.0 for security, you will achieve two fundamental separation of concerns that can lower your development and maintenance costs.

  1. This will move the session (and it's security) onto the SPA and relieve your server from all of that overhead.
  2. Your API's become both stable and easily extensible.

Hinted to earlier, but not made explicit; If your goal is to deploy Android & Apple applications, writing a JavaScript SPA that is wrapped by a native call to host the screen in a browser (Android or Apple) eliminates the need to maintain both an Apple code base and an Android code base.

zero298
  • 25,467
  • 10
  • 75
  • 100
Bill Lawrence
  • 11
  • 1
1

I understand this is an older question, but I would like to add another disadvantage of Single Page Applications:

If you build an API that returns results in a data language (such as XML or JSON) rather than a formatting language (like HTML), you are enabling greater application interoperability, for example, in business-to-business (B2B) applications. Such interoperability has great benefits but does allow people to write software to "mine" (or steal) your data. This particular disadvantage is common to all APIs that use a data language, and not to SPAs in general (indeed, an SPA that asks the server for pre-rendered HTML avoids this, but at the expense of poor model/view separation). This risk exposed by this disadvantage can be mitigated by various means, such as request limiting and connection blocking, etc.

magnus
  • 4,031
  • 7
  • 26
  • 48
  • 2
    1.) Not having an API doesn't mean that HTML pages can't be mined. 2.) You can prevent misuse of your API to some extent. 3.) By having an API, you can easily build not only web pages, but also mobile applications on top of it, which in my opinion greatly outweights any disadvantages. – Jan Kalfus May 08 '16 at 07:25
  • 1
    1. I didn't say that non-API prevent data mining. I just said that an API can make data mining easier. 2. That's what my last sentence addressed. 3. There are a lot of advantages to having an API, and I personally prefer an API/SPA combination for most use cases I typically encounter. However, I just wanted to add a single disadvantage to the list (which in retrospect I should have added as a comment rather than a complete answer). – magnus May 08 '16 at 09:11
  • Sorry, but if I haven't misunderstood, you did not, you said that "Such interoperability has great benefits but does allow people to write software to "mine" (or steal) your data.". If I changed your sentence a little bit, I could also say that "Websites allow people to write software to "mine" (or steal) your data." and be correct. Now I'm not saying that your idea is incorrect, I agree with the mining being easier, I'm just saying that it's not what you've written ;) – Jan Kalfus May 08 '16 at 09:22
  • 1
    Agreed. It was not clear enough. Data embedded in HTML is mineable. Data embedded in JSON/XML/etc is also mineable, just easier – magnus May 08 '16 at 09:24
1

In my development I found two distinct advantages for using an SPA. That is not to say that the following can not be achieved in a traditional web app just that I see incremental benefit without introducing additional disadvantages.

  • Potential for less server request as rendering new content isn’t always or even ever an http server request for a new html page. But I say potential because new content could easily require an Ajax call to pull in data but that data could be incrementally lighter than the itself plus markup providing a net benefit.

  • The ability to maintain “State”. In its simplest terms, set a variable on entry to the app and it will be available to other components throughout the user’s experience without passing it around or setting it to a local storage pattern. Intelligently managing this ability however is key to keep the top level scope uncluttered.

Other than requiring JS (which is not a crazy thing to require of web apps) other noted disadvantages are in my opinion either not specific to SPA or can be mitigated through good habits and development patterns.

JOP
  • 89
  • 1
  • 1