为什么使用单页应用

by Stefan Tilkov

斯蒂芬·蒂尔科夫(Stefan Tilkov)

为什么我讨厌您的单页应用 (Why I hate your Single Page App)

Okay, now that I have your attention, let me say that I don’t really hate your single page app. I just find it highly annoying, unless it is one of the very, very few exceptional cases that actually merit being developed in this style. As those are few and far between, it’s a fair assumption yours doesn’t qualify.

好的，现在我引起了您的注意，让我说我并不真的讨厌您的单页面应用程序。 我只是觉得这很烦人，除非它是真正值得以这种风格开发的极少数例外情况之一。 由于两者之间的距离很小，因此可以公平地假设您的资格不符。

Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab. They offer no way to link to something that I look at. (Oh, I know there are exceptions to this rule, but they typically require effort — a lot more than many developers are prepared to invest). They are bloated and slow to load, even though the actual information they display and the interaction they offer is very simple.

也许您的单页面应用程序有所不同，但是我所知道的那些应用程序破坏了我浏览器的大多数功能，例如后退和前进按钮，页面刷新，添加书签，发送链接或在新窗口或标签中打开链接。 它们无法链接到我所查看的内容。 (哦，我知道这条规则有例外，但是它们通常需要努力-比许多开发者准备投资的要多得多)。 尽管它们显示的实际信息和它们提供的交互非常简单，但它们却肿且加载缓慢。

Am I just an old, grumpy guy? Yes, but that’s beside the point. My point is that from an architectural perspective, most single page apps are the result of making the wrong choices and missing important opportunities.

我只是一个脾气暴躁的老家伙吗？ 是的，但这不重要。 我的观点是，从体系结构的角度来看，大多数单页面应用程序都是错误选择和错过重要机会的结果。

My main beef with single page apps, or SPAs for short, is that they’re not “on the web”. In that regard, they are very similar to a SOAP web service. They have a URI, but only for the whole thing, not for all of those valuable things that are inside of it. (Again, I know you can build your SPA differently, but most people don’t.) I believe that if you build a web application, it should have a web UI that merits the name, similarly to a web service that should have something to do with the web.

我主要使用单页应用程序(或简称SPA)的原因是它们不在“网络上”。 在这方面，它们与SOAP Web服务非常相似。 它们具有URI，但仅适用于整个内容，而不适用于其中的所有有价值的内容。 (同样，我知道您可以以不同的方式构建SPA，但大多数人却没有。)我相信，如果您构建一个Web应用程序，它应该具有一个应具有名称的Web UI，类似于应该包含某些内容的Web服务。与网络有关。

If this all seems very abstract to you, think about what makes the web the web. The single most important feature of the web is that you can link to individual things. Every important concept within your application should be a possible entry point. This enables anyone, anywhere, to use it as the target of a link. The fact that a user can move forwards and backwards through the history of the things they have visited is not a bug, it’s an essential feature. It is crucial that each of those targets returns a response quickly, because any overhead you create will have to be paid for multiple times. The back and forward buttons are not supposed to navigate between applications.

如果这一切对您来说都非常抽象，请考虑一下使网络成为网络的原因。 网络上最重要的功能是可以链接到单独的东西。 应用程序中的每个重要概念都应该是一个可能的切入点。 这使任何地方的任何人都可以将其用作链接的目标。 用户可以在访问过的事物的历史记录中前进和后退的事实并不是一个错误，它是必不可少的功能。 这些目标中的每个目标都必须快速返回响应，这一点至关重要，因为您创建的任何间接费用都必须多次支付。 后退和前进按钮不应在应用程序之间导航。

I can almost hear you say: “But I don’t care about the web. I’m building an application, not a website.” To which I say: Go ahead then, build an application, using your desktop’s or mobile operating systems native toolkit, or build an applet, or a Flash or Silverlight application. That’s all fine by me. I don’t even object to you building the same thing using the browser as an application runtime. Just be aware that when you do things this way, your application is on the web just as much as if you had built it as a Java applet. Be aware of what you’re sacrificing.

我几乎可以听到您说：“但是我不在乎网络。 我正在构建一个应用程序，而不是网站。” 我要说的是：然后，使用桌面或移动操作系统的本机工具包构建应用程序，或构建小程序，Flash或Silverlight应用程序。 我很好。 我什至不反对您使用浏览器作为应用程序运行时来构建相同的东西。 请注意，以这种方式执行操作时，您的应用程序就可以在Web上使用，就像您将其构建为Java小程序一样。 请注意您要牺牲的东西。

This is where I believe people’s wrong choices come in. It seems as if for many people, building an SPA has become synonymous with building a modern web application. Anybody who criticizes this architectural approach has obviously not made the move to the modern world. I couldn’t disagree more. People choose an SPA without being aware of the downsides, including such things as frameworks that go out of maintenance, almost unmanageable complexity in client-side code, as well as performance and accessibility issues.

我认为这是人们做出错误选择的地方。对于许多人来说，构建SPA似乎已成为构建现代Web应用程序的代名词。 任何批评这种建筑方法的人显然都没有转向现代世界。 我完全同意。 人们在选择SPA时并没有意识到不利之处，包括诸如维护不力的框架，客户端代码几乎难以管理的复杂性以及性能和可访问性问题。

But more importantly, they miss out on the benefits of not choosing an SPA. They’re not aware of the benefits of the alternative. What is this alternative, then? It is to build a classic web application, including rendering server-side HTML, and use JavaScript only sparingly, to enhance browser functionality where possible. In this architectural approach, it is absolutely clear that the responsibility for actual business logic resides completely on the server. This includes the server-side state machine that governs the transitions between pages. And again, this is not a bug, but a feature: It is what enables a quick change on the server side to take effect immediately, everywhere — including the other kinds of clients that you might end up building in addition to your web UI. Business logic does not belong in the client, unless you like having to redundantly maintain the same logic in every kind of client you support (in addition to maintaining it on the server, of course — remember that you can never trust any client). From a server-side viewpoint, the best architecture you can have is the one you could (and should) have built a decade ago: following REST principles, including stateless communication and identification of resources.

但更重要的是，他们错过了不选择SPA的好处。 他们不知道替代方案的好处。 那么，这是什么选择呢？ 它将构建一个经典的Web应用程序，包括呈现服务器端HTML，并仅少量使用JavaScript，以尽可能增强浏览器功能。 在这种架构方法中，绝对清楚的是，实际业务逻辑的责任完全在服务器上。 这包括控制页面之间过渡的服务器端状态机。 再说一次，这不是错误，而是一个功能：它使服务器端的快速更改可以在任何地方立即生效，包括在Web UI之外可能最终建立的其他类型的客户端。 除非您希望在所支持的每种客户端中冗余维护相同的逻辑，否则业务逻辑不属于客户端(当然，除了在服务器上维护该逻辑外，请记住，您永远不能信任任何客户端)。 从服务器端的角度来看，您可以拥有的最佳架构是您十年前(并且应该)构建的架构：遵循REST原则，包括无状态通信和资源标识。

Some people object to this because they believe that SPA gives you a better architecture. I disagree: With an SPA, your architecture typically is the one suggested by your framework because from a web perspective, your SPA is a single thing the web is concerned with. With a non-SPA approach (which I’m going to call ROCA from now on), the architecture governing your applications is the one of the web itself. Again, the fact that your server takes on the boring task of rendering HTML is an asset, not a burden. I, for one, don’t have a lot of trust in the stability and long-term maintainability of any of the currently existing, client-side JavaScript frameworks.

有些人对此表示反对，因为他们认为SPA可为您提供更好的体系结构。 我不同意：对于SPA，您的体系结构通常是框架建议的体系结构，因为从Web角度来看，SPA是Web与之相关的一件事。 使用非SPA方法(从现在开始，我将其称为ROCA )，控制您的应用程序的体系结构就是Web本身之一。 同样，服务器承担着呈现HTML的枯燥任务的事实是一种资产，而不是负担。 首先，我对任何现有的客户端JavaScript框架的稳定性和长期可维护性都不抱有任何信任。

A fantastic example of the problems created by the SPA approach is parallelization of work. If you have a team of multiple people, or God forbid, multiple teams working on the same SPA, you need to come up with a good way to support this. Instead, you can just have each of those teams build their own web application. Each of those applications can be connected to every other one built at the same time by the same organization (as well as to every other web application residing anywhere, if you want to) — in fact relying on the core strength of the web.

SPA方法产生的问题的一个很好的例子是工作并行化。 如果您有一个由多个人组成的团队，或者上帝禁止，多个团队在同一个SPA上工作，那么您需要想出一种很好的方法来支持这一点。 相反，您可以让每个团队都构建自己的Web应用程序。 这些应用程序中的每一个都可以连接到同一组织在同一时间同时构建的其他每个应用程序(如果需要，也可以连接到位于任何地方的其他所有Web应用程序)，实际上是依靠Web的核心力量。

In terms of accessibility, rendering semantic HTML on the server-side provides an out-of-the-box support. There is only a limited set of things that you can do with HTML, and again this is a feature, not a bug.

在可访问性方面，在服务器端呈现语义HTML提供了开箱即用的支持。 您可以使用HTML进行有限的操作，这又是一项功能，而不是错误。

You can address some of those problems within an SPA, too. But it takes effort. With the ROCA approach, you have a well-known, extremely mature, proven architecture to rely on.

您也可以在SPA中解决其中一些问题。 但这需要努力。 使用ROCA方法，您将拥有一个众所周知的，极其成熟且经过验证的架构。

Of course, this does not at all suggest you do not use JavaScript and Ajax. I am completely aware that you cannot build a modern user interface without JavaScript to enable some in-page modification. But that is an optional enhancement, not the driving factor of your architecture. (Even from a REST perspective, using JavaScript is perfectly fine: It is actually mentioned as an optional constraint in the REST dissertation as “code on demand”. But its intended purpose is to serve as a means to extend the browser to support content it does not support natively.) In almost every case I’m aware of, your SPA has zero benefit for the user, and there are only positive sides to embracing browser features instead. You might believe there are benefits for the developer, but first of all, you should put those behind the interest of the user, and secondly, they’re mostly make-believe, especially in the long run.

当然，这根本不表示您不使用JavaScript和Ajax。 我完全知道，如果没有JavaScript来启用某些页内修改，就无法构建现代的用户界面。 但这是可选的增强功能，而不是体系结构的驱动因素。 (即使从REST的角度来看，使用JavaScript也很好：实际上，它在REST论文中作为“按需代码”作为可选约束被提及。但是其预期目的是用作扩展浏览器以支持其内容的一种手段。在我所知的几乎每种情况下，您的SPA对用户来说都是零收益，而采用浏览器功能只是积极方面。 您可能会相信对开发人员有好处，但是首先，您应该将这些利益置于用户的兴趣后面，其次，它们大多是虚构的，尤其是从长远来看。

So build your SPAs, I don’t mind, as long as I don’t have to use them. Just be aware of what it is you’re giving up.

因此，我不介意建立您的SPA，只要我不必使用它们即可。 只是要知道您要放弃什么。

翻译自: https://www.freecodecamp.org/news/why-i-hate-your-single-page-app-f08bb4ff9134/

为什么使用单页应用