我读过SPA和它的优点。我发现他们中的大多数都没有说服力。有3个优点引起了我的怀疑。

问:你能作为SPA的倡导者,证明我的前三个陈述是错误的吗?

                              === ADVANTAGES ===

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

服务器端呈现很难为所有的中间体实现 状态——小视图状态不能很好地映射到url。 单页应用程序的特点是它们能够重绘任何部分 的UI,而不需要服务器往返检索HTML。这 是通过将数据与数据的表示分开来实现的 拥有处理数据的模型层和读取数据的视图层 从模型中。

为非spa保留模型层有什么问题?SPA是唯一在客户端与MVC兼容的架构吗?

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

哈,用户在访问你的网站时可以下载多少页面?2、3 ?相反,出现了另一个安全问题,你需要把你的登录页面,管理页面等分开到单独的页面。反过来,它又与SPA体系结构冲突。

3.还有其他的优势吗?别再听别人说了。

                            === DISADVANTAGES ===

客户端必须启用javascript。 只有一个入口。 安全。

附注:我做过SPA项目和非SPA项目。我问这些问题是因为我需要加深我的理解。没有伤害七党联盟支持者的意思。不要让我读更多关于SPA的东西。我只是想听听你对此的看法。


当前回答

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

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

优势

更容易的状态跟踪-不需要使用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.

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

其他回答

对于谷歌、亚马逊等公司来说,他们的服务器在24/7模式下以最大容量运行,减少流量意味着真正的金钱——更少的硬件、更少的能源、更少的维护。将cpu使用从服务器转移到客户端是有回报的,spa大放异彩。到目前为止,利大于弊。 所以,SPA与否很大程度上取决于用例。

只是为了提到另一个可能不那么明显(对于web开发人员)的spa用例: 我目前正在寻找一种在嵌入式系统中实现gui的方法,基于浏览器的架构似乎对我很有吸引力。传统上,嵌入式系统中的ui没有太多的可能性——Java、Qt、wx等或适当的商业框架。几年前,Adobe试图通过flash进入市场,但似乎并不成功。

如今,由于“嵌入式系统”与几年前的大型机一样强大,基于浏览器的UI通过REST连接到控制单元是一种可能的解决方案。这样做的好处是,为用户界面提供了大量的工具,而且是免费的。(例如Qt需要20-30美元/销售单位的特许权使用费加上3000-4000美元/开发者)

对于这样的架构,SPA提供了许多优势——例如,桌面应用程序开发人员更熟悉的开发方法,减少服务器访问(通常在汽车行业,UI和系统混乱是分开的硬件,其中系统部分有一个RT操作系统)。

由于唯一的客户端是内置的浏览器,上面提到的js可用性、服务器端日志记录、安全性等缺点都不再重要。

在我的发展过程中,我发现使用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特有的,要么可以通过良好的习惯和开发模式来缓解。

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

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

优势

更容易的状态跟踪-不需要使用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 - SEO的一个主要缺点。直到最近谷歌和Bing才开始通过在爬行过程中执行JavaScript来索引基于ajax的页面,但在许多情况下,页面仍然被错误地索引。

在开发SPA时,您将被迫处理SEO问题,可能是通过后渲染所有站点和创建静态html快照供爬虫使用。这将需要对适当的基础设施进行坚实的投资。

更新19.06.16:

自从前段时间写了这个答案,我在单页应用(即AngularJS 1.x)方面获得了更多的经验——所以我有更多的信息可以分享。

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

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

我仍然需要学习很多,但自从我开始学习SPA,我喜欢他们。

这一点可能会带来巨大的不同。

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

让我来展示一个场景。假设你有两页纸:

带有产品列表的页面 查看特定产品详细信息的页面

考虑你在列表页面。然后点击产品查看详细信息。客户端应用程序将触发2个ajax请求:

获取带有产品详细信息的json对象的请求 获取一个HTML模板的请求,其中将插入产品详细信息

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

然后返回到列表(没有为此做任何请求!)并打开另一个产品。这一次,将只有一个ajax请求来获取产品的详细信息。html模板将是相同的,所以你不需要再次下载。

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.

另外,让我们假设您的服务器端语言是Java。如果你分析我提到的两个请求,一个下载数据(你不需要加载任何视图文件和调用视图渲染引擎),另一个下载和静态html模板,这样你就可以有一个HTTP web服务器,可以直接检索它,而不需要调用Java应用服务器,没有计算!

最后,大公司也在使用SPA: Facebook, GMail,亚马逊。他们不玩,他们有最伟大的工程师研究这些。因此,如果你没有看到它们的优势,你可以一开始就相信它们,并希望在未来的道路上发现它们。

但是使用好的SPA设计模式是很重要的。你可以使用AngularJS这样的框架。不要试图在没有使用好的设计模式的情况下实现SPA,因为您可能会弄得一团糟。