单页应用程序:优点和缺点 [英] Single Page Application: advantages and disadvantages
问题描述
我已经阅读了 SPA 及其优势.我发现他们中的大多数都没有说服力.有 3 个优点引起了我的怀疑.
I've read about SPA and it advantages. I find most of them unconvincing. There are 3 advantages that arouse my doubts.
问题: 你能作为 SPA 的倡导者证明我对前三个陈述的看法是错误的吗?
=== ADVANTAGES ===
1.SPA 非常适合响应迅速的网站:
服务端渲染很难实现所有的中间状态 - 小视图状态不能很好地映射到 URL.
Server-side rendering is hard to implement for all the intermediate states - small view states do not map well to URLs.
单页应用的特点是能够重绘任何部分无需服务器往返即可检索 HTML.这个是通过将数据与数据的表示分离来实现的有一个处理数据的模型层和一个读取数据的视图层来自模型.
Single page apps are distinguished by their ability to redraw any part of the UI without requiring a server roundtrip to retrieve HTML. This is achieved by separating the data from the presentation of data by having a model layer that handles data and a view layer that reads from the models.
为非 SPA 保留模型层有什么问题?SPA 是客户端唯一与 MVC 兼容的架构吗?
2.使用 SPA，我们不需要对服务器使用额外的查询来下载页面.
哈，用户在访问您的网站时可以下载多少页面?二三?相反，出现了另一个安全问题，您需要将登录页面、管理页面等分成单独的页面.反过来，它与 SPA 架构发生冲突.
3.可能还有其他优势吗?不要听到其他任何消息..
=== DISADVANTAGES ===
- 客户端必须启用 javascript.
- 该站点只有一个入口点.
- 安全.
P.S. 我参与过 SPA 和非 SPA 项目.我问这些问题是因为我需要加深我的理解.无意伤害SPA支持者.不要让我多读一点关于 SPA 的内容.我只是想听听您对此的看法.
P.S. I've worked on SPA and non-SPA projects. And I'm asking those questions because I need to deepen my understanding. No mean to harm SPA supporters. Don't ask me to read a bit more about SPA. I just want to hear your considerations about that.
推荐答案
让我们看看最受欢迎的 SPA 网站之一，GMail.
Let's look at one of the most popular SPA sites, GMail.
1.SPA 非常适合响应迅速的网站:
服务器端渲染不像以前那么难，使用简单的技术，比如在 URL 中保留 #hash，或者最近 HTML5 pushState.通过这种方法，Web 应用程序的确切状态被嵌入到页面 URL 中.在 GMail 中，每次打开邮件时都会在 URL 中添加一个特殊的哈希标签.如果复制并粘贴到其他浏览器窗口可以打开完全相同的邮件(前提是它们可以进行身份验证).这种方法直接映射到更传统的查询字符串，区别仅在于执行.使用 HTML5 pushState()，您可以消除 #hash 并使用完全经典的 URL，这些 URL 可以在第一次请求时在服务器上解析，然后在后续请求中通过 ajax 加载.
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，我们不需要对服务器使用额外的查询来下载页面.
用户在访问我的网站时下载的页面数??当他/她打开他/她的邮件帐户时，他/她实际上阅读了多少邮件.我一口气读了> 50.现在邮件的结构几乎相同.如果您将使用服务器端渲染方案，则服务器将在每个请求(典型情况)上渲染它.- 安全问题 - 您应该/不应该为完全取决于您网站结构的管理员/登录保留单独的页面，例如 paytm.com 也制作网站 SPA 并不意味着您打开所有端点用户 我的意思是我在我的 spa 网站上使用表单身份验证.- 在可能最常用的 SPA 框架 Angular JS 中，开发人员可以从网站加载整个 html 寺庙，以便可以根据用户身份验证级别来完成.为所有身份验证类型预加载 html 不是 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 用户中，也只能看到他拥有的适当权利.你不必一次注入所有东西.加载 diff html 模板和 javascript async 也是 SPA 的有效部分.
我能想到的优点是:
- 渲染 html 显然需要一些资源，现在访问您网站的每个用户都在这样做.不仅渲染主要逻辑现在在客户端而不是服务器端完成.
- 日期时间问题 - 我只是给客户端 UTC 时间是一种预设格式，甚至不关心我让 javascript 处理它的时区.这对于我必须根据从用户 IP 得出的位置来猜测时区的地方来说是一个很大的优势.
- 对我来说状态在 SPA 中得到更好的维护，因为一旦你设置了一个变量，你就知道它会在那里.这给人一种开发应用程序而不是网页的感觉.这通常对制作 foodpanda、flipkart、amazon 等网站有很大帮助.因为如果您不使用客户端状态，您将使用昂贵的会话.
- 网站肯定是非常敏感的 - 我会举一个极端的例子来尝试在非 SPA 网站上制作一个计算器(我知道这很奇怪).
评论更新
似乎没有人提到套接字和长轮询.如果您从另一个客户端注销说移动应用程序，那么您的浏览器也应该退出.如果不使用SPA，则必须重新创建每次有重定向时的套接字连接.这也应该处理数据中的任何更新，例如通知、个人资料更新等
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
另一种观点:除了您的网站，您的项目是否会涉及本地移动应用程序?如果是，您很可能会成为从服务器(即 JSON)向本机应用程序提供原始数据并执行客户端处理来呈现它，对吗?所以有了这个断言，你已经在做客户端渲染模型了.现在的问题变成，为什么不应该为网站版本使用相同的模型你的项目?有点没脑子.那么问题就变成了您是否只想为了 SEO 优势而呈现服务器端页面，以及可共享/可收藏的 URL 的便利
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
这篇关于单页应用程序:优点和缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
