单页应用程序：优点和缺点[关闭]

我已经读过SPA及其优势。我发现其中大多数令人信服。有3个优点引起了我的怀疑。

问题： 您可以担任SPA的拥护者，并证明我对前三个陈述有误吗？

                              === ADVANTAGES ===

1. SPA对于响应速度很快的网站非常有用：

对于所有中间状态，很难实现服务器端呈现-小视图状态无法很好地映射到URL。

单页应用程序的特点是能够重绘UI的任何部分，而无需服务器往返来检索HTML。这是通过具有处理数据的模型层和从模型读取的视图层将数据与数据表示分离开来的。

为非SPA保留模型层有什么问题？SPA是否是客户端上唯一与MVC兼容的体系结构？

2.使用SPA，我们不需要对服务器使用额外的查询来下载页面。

嗯，在访问您的网站期间用户可以下载多少页？二三？而是出现了另一个安全问题，您需要将登录页面，管理页面等分成单独的页面。反过来，它与SPA架构冲突。

3.可能还有其他优势吗？什么都没听到

                            === DISADVANTAGES ===

1. 客户端必须启用javascript。
2. 该站点只有一个入口点。
3. 安全。

PS我曾经从事过SPA和非SPA项目。我问这些问题是因为我需要加深理解。无意伤害SPA支持者。不要让我多读一些有关SPA的文章。我只想听听您对此的考虑。

让我们看一下最受欢迎的SPA网站之一，GMail。

1. SPA对于响应速度很快的网站非常有用：

服务器端呈现的难度不像使用简单技术（例如在URL中保留#hash或最近在HTML5中pushState保留）那样困难。通过这种方法，Web应用程序的确切状态将嵌入到页面URL中。与每次打开邮件一样，在GMail中，一个特殊的哈希标记将添加到URL。如果复制并粘贴到其他浏览器窗口，则可以打开完全相同的邮件（前提是它们可以进行身份​​验证）。这种方法直接映射到更传统的查询字符串，区别仅在于执行。使用HTML5 pushState（），您可以消除#hash和使用完全经典的URL，它们可以在第一个请求上在服务器上解析，然后在后续请求上通过ajax加载。

2.使用SPA，我们不需要对服务器使用额外的查询来下载页面。

用户访问我的网站时下载的页面数？当他/她打开他/她的邮件帐户时，实际上阅读了多少邮件。我一口气读了> 50。现在邮件的结构几乎相同。如果您将使用服务器端渲染方案，则服务器将在每个请求（典型情况）下对其进行渲染。-安全问题-您应该/不应为完全取决于您网站结构的管理员/登录页面保留单独的页面，例如以paytm.com为例，制作网站SPA并不意味着您要为所有网站打开所有端点。用户，我的意思是我在spa网站上使用表单身份验证。-在可能最常用的SPA框架Angular JS中，开发人员可以从网站上加载整个html模板，因此可以根据用户身份验证级别来完成。为所有身份验证类型预加载html是“

3.可能还有其他优势吗？什么都没听到

• 这些天，您可以放心地假设客户端将具有启用了javascript的浏览器。
• 网站的一个入口。正如我之前提到的，状态维护是可能的，您可以根据需要拥有任意数量的入口点，但是应该确定有一个。
• 即使在SPA用户中，也只能看到他具有适当的权限。您不必一次注入所有东西。加载差异html模板和javascript异步也是SPA的有效部分。

我能想到的优点是：

1. 现在，每个访问您网站的用户都在执行html渲染，因此显然需要一些资源。现在，不仅渲染主要逻辑都在客户端而不是服务器端完成。
2. 日期时间问题-我只是给客户提供UTC时间是一种预设格式，甚至不在乎我让JavaScript处理的时区。这对于我不得不根据用户IP派生的位置来猜测时区是一个很大的优势。
3. 对我来说，状态可以更好地保存在SPA中，因为一旦设置了变量，便知道该变量将在那里。这给人一种开发应用而不是网页的感觉。这通常对制作类似foodpanda，flipkart，亚马逊之类的网站有很大帮助。因为如果您不使用客户端状态，那么您将使用昂贵的会话。
4. 网站肯定是非常敏感的-我将举一个极端的例子，尝试在非SPA网站上制作一个计算器（我知道这很奇怪）。

评论更新

似乎没有人提到套接字和长轮询。如果您从另一个客户端（例如移动应用程序）注销，则您的浏览器也应该注销。如果不使用SPA，则每次重定向时都必须重新创建套接字连接。这也应该与通知，个人资料更新等数据中的任何更新一起使用

另一种观点：除了您的网站之外，您的项目是否还会涉及本机移动应用程序？如果是，那么您很可能将从服务器（即JSON）向该本地应用程序馈送原始数据，并进行客户端处理以呈现它，对吗？因此，有了这个断言，您已经在做一个客户端渲染模型。现在的问题变成了，为什么您的项目的网站版本不使用相同的模型？毫无疑问。然后，问题就变成了是否仅出于SEO好处和可共享/可标记URL的便利性而呈现服务器端页面

我是一个实用主义者，所以我将尝试从成本和收益方面进行研究。

请注意，对于我给的任何缺点，我都知道它们是可以解决的。这就是为什么我不看黑白事物，而是看成本和收益的原因。

优点

• 状态跟踪更容易-无需使用Cookie，表单提交，本地存储，会话存储等即可记住2个页面加载之间的状态。
• 每个页面（页眉，页脚，徽标，版权标语等）上的样板内容在每个典型的浏览器会话中仅加载一次。
• 切换“页面”时没有开销延迟。

缺点

• 性能监视-双手牵着手：我见过的大多数浏览器级性能监视解决方案都只专注于页面加载时间，例如到第一个字节的时间，构建DOM的时间，HTML的网络往返，onload事件等。更新页面通过AJAX进行的后加载不会被测量。有一些解决方案可让您检测代码以记录明确的度量，例如单击链接，启动计时器，然后在呈现AJAX结果之后结束计时器，然后发送该反馈。例如，New Relic支持此功能。通过使用SPA，您已将自己与少数几种可能的工具绑定在一起。
• 安全/渗透测试-束手无策：当您的整个页面由SPA框架动态构建时，自动安全扫描可能很难发现链接。可能有解决方案，但同样，您已经受到限制。
• 捆绑：当您在初始页面加载时下载整个网站所需的所有代码时，很容易陷入这种情况，这对于低带宽连接可能表现得非常糟糕。您可以将JavaScript和CSS文件捆绑在一起，以尝试在加载时更自然地进行加载，但是现在您需要维护该映射，并注意意外的文件会通过未实现的依赖项被拉入（这只是我的事）。同样，可解决，但要付出代价。
• 爆炸式重构：如果要进行重大的架构更改，例如从一个框架切换到另一个框架，以最大程度地降低风险，则最好进行增量更改。也就是说，开始使用新的，并在某些基础上进行迁移，例如每页，每功能等，然后将旧的丢弃。使用传统的多页面应用程序，您可以将页面从Angular切换到React，然后在下一个sprint中切换另一页面。有了SPA，一切皆有或没有。如果要更改，则必须一次性更改整个应用程序。
• 导航的复杂性：存在工具来帮助维护SPA中的导航上下文，例如history.js，Angular 2，其中大多数依赖于URL框架（＃）或更新的历史记录API。如果每个页面都是单独的页面，则不需要任何页面。
• 弄清楚代码的复杂性：我们自然将网站视为页面。多页面应用程序通常按页面划分代码，这有助于维护。

我再次意识到，这些问题中的每一个都是可以解决的，需要付出一定的代价。但是到了某个时刻，您将花费所有时间来解决本来可以避免的问题。回到收益以及它们对您的重要性。

缺点

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的路由系统中，因此浏览器仅请求根据用户角色的初始负载，客户知道它应该有权访问的内容，

优点

1. 在许多情况下，SPA（主要是很少提及）的主要架构优势是可大幅降低应用程序的“简洁”。如果您正确地设计它来处理客户端上的大多数处理（毕竟，这很重要），那么对服务器的请求数（请参阅“破坏503错误的可能性破坏用户体验”）。事实上，SPA能够做到完全离线处理，这是巨大的在某些情况下。

2. 如果做得正确，客户端渲染的性能当然会更好，但这不是构建SPA的最引人注目的原因。（毕竟，网络速度正在提高。）不要仅以此为依据来考虑SPA。

3. UI设计的灵活性也许是我发现的另一个主要优点。定义了API（使用JavaScript中的SDK）后，除了一些静态资源文件之外，我还能够完全重写前端，并且对服务器的影响为零。尝试使用传统的MVC应用程序做到这一点！：）（当您需要实时部署和需要担心API的版本一致性时，这将非常有用。）

因此，最重要的是：如果您需要脱机处理（或至少希望您的客户端能够在偶尔的服务器中断中幸免于难）-大大降低了自己的硬件成本-并且可以使用JavaScript和现代浏览器，则需要SPA。在其他情况下，这更像是一个权衡。

SPA的一大缺点-SEO。直到最近，Google和Bing才开始在抓取过程中执行JavaScript，从而为基于Ajax的页面建立索引，但在许多情况下，页面仍被错误地索引。

在开发SPA时，您可能会被迫处理SEO问题，方法可能是后期渲染所有网站并创建静态html快照供爬网程序使用。这将需要在适当的基础架构上进行大量投资。

更新19.06.16：

自从前一段时间编写此答案以来，我在Single Page Apps（即AngularJS 1.x）上获得了更多的经验-因此，我有更多的信息要分享。

在我看来，SPA应用程序的主要缺点是SEO，这使它们仅限于某种“仪表板”应用程序。此外，与经典解决方案相比，您将在缓存方面遇到更多困难。例如，在ASP.NET中，缓存非常简单-只需打开OutputCaching，您就可以了：整个HTML页面将根据URL（或任何其他参数）进行缓存。但是，在SPA中，您需要自己处理缓存（通过使用某些解决方案，例如二级缓存，模板缓存等）。

我想证明SPA最适合数据驱动的应用程序。gmail当然是关于数据的，因此非常适合使用SPA。

但是，如果您的页面主要用于显示（例如，服务条款页面），那么SPA完全是多余的。

我认为，最吸引人的地方是同时包含SPA和静态/ MVC样式页面的网站，具体取决于特定页面。

例如，在我正在构建的一个站点上，用户登陆到标准的MVC索引页面。但是，当他们转到实际应用程序时，它将调用SPA。这样做的另一个好处是，SPA的加载时间不在主页上，而是在应用程序页面上。主页上的加载时间可能会干扰初次访问站点的用户。

这种情况有点像使用Flash。经过几年的经验，由于负载因素，仅Flash站点的数量下降到接近零。但是作为页面组件，它仍在使用中。

对于Google，Amazon等公司（其服务器以24/7模式以最大容量运行），减少流量就意味着真正的钱-更少的硬件，更少的能源，更少的维护。将CPU使用率从服务器转移到客户端会带来回报，并且SPA会发光。优点到目前为止不利于缺点。因此，SPA还是不SPA很大程度上取决于用例。

只是提到了SPA的另一个（对于Web开发人员而言）可能不太明显的用例：我目前正在寻找一种在嵌入式系统和基于浏览器的体系结构中实现GUI的方法对我来说很有吸引力。传统上，嵌入式系统中的UI没有很多可能性-Java，Qt，wx等或专有的商业框架。几年前，Adobe试图通过Flash进入市场，但似乎并不那么成功。

如今，由于几年前“嵌入式系统”与大型机一样强大，因此通过REST连接到控制单元的基于浏览器的UI是一种可行的解决方案。优点是，免费提供了大量用于UI的工具。（例如，Qt要求每售出单位收取20-30美元的专利使用费，再加上每位开发人员3000-4000美元）

对于这样的体系结构，SPA提供了许多优势-例如，更熟悉的桌面应用开发人员开发方法，减少的服务器访问权限（通常在汽车行业中，UI和系统混乱是单独的硬件，其中系统部分具有RT OS）。

由于唯一的客户端是内置浏览器，因此所提到的诸如JS可用性，服务器端日志记录，安全性等缺点不再重要。

2.使用SPA，我们不需要对服务器使用额外的查询来下载页面。

我仍然需要学习很多东西，但是自从我开始学习SPA以来，我就喜欢它们。

这一点很重要。

在许多不是SPA的Web应用程序中，您将看到它们仍将检索并向发出Ajax请求的页面添加内容。因此，我认为SPA不仅要考虑：如果要使用ajax检索和显示的内容是整个页面，该怎么办？而不只是页面的一小部分？

让我提出一个方案。考虑您有2页：

1. 包含产品列表的页面
2. 查看特定产品详细信息的页面

考虑您在列表页面上。然后单击产品以查看详细信息。客户端应用将触发2个Ajax请求：

1. 获取带有产品详细信息的json对象的请求
2. 请求获取将在其中插入产品详细信息的html模板的请求

然后，客户端应用程序会将数据插入html模板并显示。

然后，您返回列表（对此没有任何请求！），然后打开另一个产品。这次，只有ajax请求可以获取产品的详细信息。html模板将是相同的，因此您无需再次下载。

您可能会说，在非SPA中，当您打开产品详细信息时，您仅发出1个请求，在这种情况下，我们提出了2个请求。是。但是从总体上看，当您浏览许多页面时，请求数量将减少。而且在客户端和服务器之间传输的数据也将减少，因为html模板将被重用。另外，您无需在每个请求中都下载所有页面中存在的所有这些CSS，图像和javascript文件。

另外，让我们考虑一下您的服务器端语言是Java。如果您分析了我提到的2个请求，则1个将下载数据（无需加载任何视图文件并调用视图呈现引擎），而其他将下载数据和静态html模板，因此您可以拥有一个HTTP Web服务器来检索它无需调用Java应用程序服务器即可直接进行，无需任何计算！

最后，大公司正在使用SPA：Facebook，GMail，Amazon。他们不玩游戏，他们拥有最出色的工程师来研究所有这一切。因此，如果您看不到优势，则可以一开始就信任它们，并希望一路发现它们。

但是使用良好的SPA设计模式很重要。您可以使用类似AngularJS的框架。不要尝试在不使用良好设计模式的情况下实施SPA，因为这样可能会导致混乱。

缺点：从技术上讲，SPA的设计和初期开发很复杂，可以避免。不使用此SPA的其他原因可能是：

• a）安全性：由于跨站点脚本（XSS），与传统页面相比，单页面应用程序的安全性较低。
• b）内存泄漏：JavaScript中的内存泄漏甚至可能导致功能强大的计算机速度变慢。由于传统网站鼓励在页面之间导航，因此几乎清除了由前一页引起的任何内存泄漏，从而减少了残留。
• c）客户端必须启用JavaScript才能运行SPA，但是在多页应用程序中可以完全避免使用JavaScript。
• d）SPA增长到最佳大小，导致较长的等待时间。例如：在连接速度较慢的Gmail上工作。

除上述之外，其他体系结构限制包括导航数据丢失，浏览器中没有导航历史记录以及使用硒进行自动功能测试的困难。

此链接说明了单页应用程序的优缺点。

在我的开发中，我发现使用SPA有两个明显的优势。这并不是说在传统的Web应用程序中无法实现以下目的，只是我看到了不断增加的好处而没有引入其他缺点。

• 呈现新内容的服务器请求减少的可能性并不总是，甚至不是HTTP服务器对新html页面的请求。但是我说有潜力，因为新内容可能很容易需要Ajax调用来提取数据，但是该数据可能比其本身加标记的增量要轻，从而带来了净收益。

• 维持“状态”的能力。用最简单的话说，就是在进入应用程序时设置一个变量，在整个用户体验期间，其他组件都可以使用该变量，而无需传递变量或将其设置为本地存储模式。但是，智能管理此功能是保持顶级范围整洁的关键。

在我看来，除了需要JS（这对Web应用程序而言不是疯狂的事情）外，其他一些明显的缺点不是特定于SPA的，或者可以通过良好的习惯和开发模式来缓解。

在不首先定义如何在服务器端解决安全性和API稳定性的情况下，请不要考虑使用SPA。然后，您将看到使用SPA的一些真正优势。具体来说，如果您使用实现OAUTH 2.0的RESTful服务器以实现安全性，则将实现两个基本的关注点分离，从而可以降低开发和维护成本。

1. 这会将会话（及其安全性）移到SPA上，并减轻服务器的所有开销。
2. 您的API既稳定又易于扩展。

提示较早，但未明确；如果您的目标是部署Android和Apple应用程序，则编写一个由本地调用包装的JavaScript SPA，以便在浏览器（Android或Apple）中托管屏幕，从而无需同时维护Apple代码库和Android代码库。

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

如果构建的API以数据语言（例如XML或JSON）而不是格式语言（例如HTML）返回结果，则可以实现更大的应用程序互操作性，例如在企业对企业（B2B）应用程序中。这种互操作性具有很大的好处，但是确实允许人们编写软件来“挖掘”（或窃取）您的数据。对于所有使用数据语言的API来说，这个特殊的缺点是普遍存在的，而不是通常对于SPA而言（通常，SPA要求服务器提供预渲染的HTML可以避免这种情况，但这是以不良的模型/视图分离为代价的）。可以通过各种方式（例如，请求限制和连接阻塞等）来减轻此缺点带来的风险。