我知道这是一个老问题，但我想补充单页应用程序的另一个缺点:

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.

让我们来看看最流行的SPA网站之一，GMail。

1. SPA非常适合响应性非常强的网站:

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. 使用SPA，我们不需要对服务器使用额外的查询来下载页面。

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.还有其他的优势吗?别再听别人说了。

现在，您可以放心地假设客户机将拥有支持javascript的浏览器。 网站只有一个入口。正如我之前提到的，状态维护是可能的，你可以有任意数量的入口点，但你应该有一个确定的入口点。 即使在SPA用户只看到他有适当的权利。你不需要一次注射所有的东西。加载不同的html模板和javascript async也是一个有效的SPA的一部分。

我能想到的优点是:

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

来自评论的更新

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

如果没有首先定义如何在服务器端解决安全性和API稳定性问题，就不要考虑使用SPA。然后，您将看到使用SPA的一些真正优点。具体来说，如果您使用实现OAUTH 2.0的rest式服务器来实现安全性，那么您将实现两个基本的关注点分离，从而降低开发和维护成本。

这将把会话(以及它的安全性)转移到SPA上，从而减轻服务器的所有开销。 您的API变得既稳定又易于扩展。

前面曾暗示过，但未明确;如果您的目标是部署Android和Apple应用程序，那么编写一个JavaScript SPA，它由本地调用包装，以在浏览器(Android或Apple)中托管屏幕，从而消除了同时维护Apple代码库和Android代码库的需要。

我是一个实用主义者，所以我会试着从成本和收益的角度来看待这件事。

请注意，对于我给出的任何缺点，我都认识到它们是可以解决的。这就是为什么我不把任何事情看得非黑即白，而是成本和收益。

优势

更容易的状态跟踪-不需要使用cookie，表单提交，本地存储，会话存储等来记住2个页面加载之间的状态。 每个页面(页眉、页脚、logo、版权横幅等)上的样板内容在每次典型的浏览器会话中只加载一次。 切换“页面”时没有开销延迟。

缺点

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.

我再次承认，这些问题中的每一个都是可以解决的，只是需要付出一定的代价。 但总有一天，你把所有的时间都花在了解决问题上，而这些问题本来是可以避免的。这又回到了益处以及它们对你的重要性上。

在我的发展过程中，我发现使用SPA有两个明显的优势。这并不是说在传统的web应用程序中不能实现以下功能，只是我看到了增量收益而不会引入额外的缺点。

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.

在我看来，除了需要JS之外(这对web应用程序来说并不是一件疯狂的事情)，其他的缺点要么不是SPA特有的，要么可以通过良好的习惯和开发模式来缓解。

缺点

1. 客户端必须启用javascript。是的，这是SPA的一个明显的缺点。在我的例子中，我知道我可以期望我的用户启用JavaScript。如果你不能，那么你就不能做SPA，就这样。这就像试图将。net应用程序部署到一台没有安装。net框架的机器上。

2. 只有一个入口。我用SammyJS解决了这个问题。2-3天的工作，让你的路由正确设置，人们将能够创建深度链接书签到你的应用程序，并正常工作。你的服务器只需要公开一个端点——“给我这个应用程序的HTML + CSS + JS”端点(把它想象成预编译应用程序的下载/更新位置)——而你编写的客户端JavaScript将处理进入应用程序的实际入口。

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

优势

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

因此，底线是:如果您需要脱机处理(或者至少希望您的客户端能够在偶尔的服务器中断中存活)—极大地降低您自己的硬件成本—并且您可以假设JavaScript和现代浏览器，那么您需要一个SPA。在其他情况下，这更像是一种权衡。