我已经了解了单页应用程序（SPA）及其优点，但我认为其中大部分都不令人信服。有三个优点让我怀疑。
问题：你能够担任SPA的支持者并证明我对前三个陈述是错误的吗？
=== ADVANTAGES ===
=== DISADVANTAGES ===
P.S. 我参与过SPA和非SPA项目的开发。我提出这些问题是因为我想深入了解。并不是要伤害SPA的支持者。请不要要求我阅读更多关于SPA的文章。我只想听听你们对此的考虑。
让我们来看一下最受欢迎的SPA网站之一，GMail。
1. SPA非常适合响应速度非常快的网站：
服务器端渲染不像以前那么困难，采用简单的技术，如在URL中保留“#hash”，或者更近期的HTML5 pushState。采用这种方法，Web应用程序的确切状态嵌入到页面URL中。就像在GMail中，每次打开邮件时，在URL中添加一个特殊的哈希标签。如果将其复制并粘贴到其他浏览器窗口中，可以打开完全相同的邮件（前提是它们可以进行身份验证）。这种方法直接映射到更传统的查询字符串，区别仅在于执行方式。使用HTML5 pushState（），您可以消除#hash并使用完全经典的URL，在第一次请求时可以在服务器上解决，然后在后续请求中通过ajax加载。
2. 使用SPA，我们不需要使用额外的查询向服务器下载页面。
The number of pages a user downloads during their visit to my website is similar to how many emails someone reads when they open their email account. Personally, I read over 50 emails at once and the structure of the emails is almost always the same. If you use a server-side rendering scheme, the server will render it on every request (typical case).我能想到的优点有：
来自评论的更新
似乎没有人提到套接字和长轮询。如果您从另一个客户端（比如移动应用程序）注销，则您的浏览器也应该注销。如果您不使用SPA，则必须在重定向时重新创建套接字连接。这也应该适用于数据更新，例如通知、配置文件更新等。我是一个实用主义者，所以我会尝试从成本和收益的角度来看待这个问题。
需要注意的是，对于我提出的任何不利因素，我都认为它们可以解决。这就是为什么我不把任何事情看作是非黑即白的原因，而是考虑成本和收益。
优点
缺点
同样地，我认识到这些问题都可以通过某种方式解决，只是需要付出一定代价。但是总有一个度，您可能会花费所有时间来解决那些本来可以避免的问题。这又回到了利益和它对您有多么重要的问题。
1. 客户端必须启用JavaScript。 是的，这是SPA明显的缺点。在我的情况下，我知道可以期望我的用户启用JavaScript。如果不能，则无法使用SPA。这就像试图将.NET应用程序部署到未安装.NET Framework的计算机上。
2. 网站只有一个入口点。 我使用SammyJS解决了这个问题。花费2-3天的时间来正确设置路由，人们就可以创建深链接书签，并且你的服务器只需要公开一个终点 - “给我这个应用程序的HTML + CSS + JS”的终点（将其视为预编译应用程序的下载/更新位置）- 而你编写的客户端JavaScript将处理实际进入应用程序的问题。
3. 安全性 这个问题并不是SPA特有的，在“老式”客户端-服务器应用程序（使用超文本链接页面之间的HATEOAS模型）中，您必须以完全相同的方式处理安全性。只是用户发出请求而不是你的JavaScript，并且结果是HTML而不是JSON或某种数据格式。在非SPA应用程序中，您必须在服务器上保护单个页面，而在SPA应用程序中，您必须保护数据端点。（如果您不希望客户端访问所有代码，则还必须将可下载的JavaScript拆分为单独的区域。 我只是将其绑定到基于SammyJS的路由系统中，因此浏览器仅请求客户端知道它应该访问哪些内容（根据用户角色的初始加载），然后这将成为一个非问题。）
单页应用程序（SPA）的主要架构优势之一（很少被提到），在许多情况下是大大减少您的应用程序的“通信量”。如果您正确设计它以在客户端上处理大部分处理过程（毕竟这是整个重点），那么向服务器发出请求的数量（读作“可能破坏用户体验的503错误”）将大大减少。实际上，SPA使得完全离线处理成为可能，在某些情况下非常重要。
如果你做得好，客户端渲染的性能肯定更好，但这并不是建立SPA最有说服力的原因。（毕竟网络速度正在改善）。不要仅基于这个理由去建立SPA。
另一个我发现的主要优势是界面设计的灵活性。一旦我定义了我的API（带有JavaScript的SDK），我就可以完全重写我的前端而对服务器只有一些静态资源文件产生零影响。试着用传统的MVC应用程序做到这一点吧！：）（当您需要考虑API的版本一致性和实时部署时，这变得非常有价值。）
所以，最终结论是：如果您需要离线处理（或至少希望客户端能够在偶尔的服务器故障中生存） - 大大减少自己的硬件成本 - 并且可以使用JavaScript和现代浏览器，则需要SPA。在其他情况下，它更多是一种权衡。
SPA的一个主要缺点是SEO。最近Google和Bing开始通过执行JavaScript来索引基于Ajax的页面，但在许多情况下仍然会将页面索引错误。
在开发SPA时，您将被迫处理SEO问题，可能是通过后渲染整个站点并创建静态HTML快照供爬虫使用。这将需要对适当的基础设施进行坚实的投资。
自从我写下这篇答案以来，我对单页应用程序（即AngularJS 1.x）有了更多的经验 - 所以我有更多的信息可以分享。
在我看来，SPA应用程序的主要缺点是SEO，使它们仅限于“仪表板”类型的应用程序。此外，与传统解决方案相比，缓存会更加困难。例如，在ASP.NET中，缓存非常容易 - 只需打开OutputCaching即可：整个HTML页面将根据URL（或任何其他参数）进行缓存。但是，在SPA中，您需要自己处理缓存（使用一些解决方案，如二级缓存，模板缓存等）。
我认为SPA最适合数据驱动的应用程序。当然，像Gmail这样的应用程序全部围绕数据展开，因此是SPA的一个好选择。
但如果您的页面主要用于显示，例如服务条款页面，那么SPA就完全是杀鸡焉用牛刀了。
我认为最好的方案是在网站中混合使用SPA和静态/MVC风格的页面，具体取决于页面的特定需求。
例如，在我正在构建的一个网站上，用户会首先看到标准的MVC索引页面。但是当他们进入实际应用程序时，就会调用SPA。另一个优点是SPA的加载时间不在主页上，而是在应用程序页面上。SPA加载时间在主页上可能会干扰首次访问网站的用户。
这种情况有点像使用Flash。经过几年的经验积累，由于负载因素，仅使用Flash的网站数量已经接近于零。但作为页面组件，它仍在使用中。
缺点: 技术上，SPA的设计和初始开发是复杂的，可以避免。不使用这个SPA的其他原因可能包括：
除了以上缺点外，其他架构限制还包括导航数据丢失，在浏览器中没有导航历史记录以及使用Selenium进行自动化功能测试的困难。
此链接说明了单页应用程序的优缺点。
2. 使用SPA，我们不需要使用额外的服务器查询下载页面。
虽然我还有很多要学习，但自从我开始了解SPA以来，我就喜欢它们。
这一点可能会产生巨大的差异。
在许多非SPA的Web应用程序中，您会发现它们仍然通过发出ajax请求来检索和添加内容到页面。因此，我认为SPA更进一步考虑：如果使用ajax检索并显示的内容是整个页面？而不仅仅是页面的一小部分呢？
让我举个例子。假设您有两个页面：
考虑您是否在列表页面上。那么您单击产品以查看详细信息。客户端应用程序将触发2个ajax请求：
然后，客户端应用程序将数据插入html模板并显示它。
然后，您返回到列表（没有请求！）并打开另一个产品。这次，只需要一个ajax请求即可获取产品详细信息。html模板将保持不变，因此您无需再次下载。
您可能会说，在非SPA中，当您打开产品详细信息时，只会进行1个请求，在这种情况下我们做了2个。是的。但是从总体上看，您会获得收益，因为在跨多个页面导航时，请求的数量将更少。客户端和服务器之间传输的数据也将更少，因为html模板将被重用。此外，您无需在每个请求中下载所有页面中存在的css、图像和javascript文件。
另外，让我们考虑您的服务器端语言是Java。如果分析我提到的两个请求，其中一个下载数据（您不需要加载任何视图文件并调用视图渲染引擎），而另一个下载静态html模板，因此您可以拥有一个HTTP Web服务器，可以直接检索它，而无需调用Java应用程序服务器，不执行任何计算！
最后，大型公司正在使用SPA：Facebook、GMail、Amazon。他们不开玩笑，他们有最优秀的工程师在研究所有这些。因此，如果您看不到优势，您可以最初信任他们，并希望未来发现它们。
但是，使用良好的SPA设计模式很重要。您可以使用AngularJS等框架。不要尝试在不使用良好设计模式的情况下实现SPA，因为您可能最终会混乱不堪。