为什么 Facebook、Twitter 和 GMail 将所有数据以 JSON 而不是 HTML 的形式呈现给浏览器?
如果您登录 Facebook、Twitter 或 Gmail 并查看源代码,您会注意到一些非常奇怪的情况。您的所有推文和邮件都会呈现为 JSON。没有尖括号。我的猜测是,这些数据都是动态渲染到 DOM 的。如果您检查页面上的任何元素,您将看到大量的 div 和其他 HTML 元素。这些都没有在原始标记中提供。问题是:
- 为什么这 3 个大型网站要花时间来做这件事?
- 只使用 HTML 不是更快吗?
- 由于 JSON 有效负载比 HTML 更小,是为了节省带宽吗?
- 是因为这些网站很大程度上基于 AJAX 吗?我的猜测是前者,但我不知道。我不确定你是否必须在 Google Twitter 或 Facebook 工作才能知道这是为什么,但这三个网站共享这种策略,所以我认为他们有一个共同的目标。这让我觉得这更像是一个普遍的事情。
If you login to Facebook, Twitter or Gmail and view source, you'll notice something very peculiar. All your Tweets and mail are rendered as JSON. There are no angle brackets. My guess is, this data is all dynamically rendered to the DOM. If you inspect any element on the page, you'll see tons of divs and other HTML elements. None of which was served in the original markup. The questions are:
- Why would these 3 huge sites take time out to do this?
- Wouldn't it be faster to just use HTML?
- Is it to save on bandwidth since the JSON payload is smaller to serve than HTML?
- Is it because these sites are heavily based on AJAX? My guess would be the former, but I have no idea. I'm not sure if you have to work for Google Twitter, or Facebook to know why this is, but this tactic is shared between the 3 sites, so I figure they have a common goal in mind. That makes me think it's more of a general thing.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
他们的设计有几个普遍应用的原因:
上面第 2 点中提到的 API 驱动架构和分离允许公司提供多渠道发货,无需过多返工。考虑一下我们是否要为 Android 构建 Twitter 应用程序:
正如您所看到的,此模型为 Google/Twitter 提供了一种无需重写逻辑即可交付到多渠道的方法。这同样适用于移动 WebView 与普通桌面 WebView。我们需要改变的是 UI 层,而不是数据或控制器层。
这就是为什么他们花时间思考设计和架构本身。数据和表示之间的紧密耦合将要求他们重新编写大量代码,以便在多个渠道中交付。这不是关于 JSON 与 HTML 的问题,也不是关于 Web 的问题,而是更多的架构决策,使他们能够将内容交付到多渠道(iOS、Android、第三方应用程序、移动 WebView、桌面视图、桌面应用程序等)。你在他们的 HTML 源代码中看到的是他们在 WebView 通道中策略的体现。
There are several reasons for their design that are commonly applied:
API driven architecture and separation mentioned in point #2 above allow the company to provide multiple channels delivery without too much rework. Consider if we want to build Twitter App for Android:
As you can see, this model provides a way for Google/Twitter to deliver into multi-channels without having to rewrite their logic. The same applies to Mobile WebView vs. normal Desktop WebView. All we need to change is the UI Layer and not the Data or Controller layer.
This is why they are taking time to think about the design and architecture it as such. A tight coupling between the data and presentation would require them to rework a lot of code in order to be delivered in multiple channels. It's not about JSON vs. HTML or just the web but more of an architecture decision that would allow them to deliver their content to multi-channels (iOS, Android, third party App, Mobile WebView, Desktop View, Desktop App, etc). What you see in their HTML source is the manifestation of their strategy in WebView channel.
该技术允许浏览器缓存 HTML(和静态 JavaScript)并仅获取 json 字符串。它确实非常快并且带宽友好。
This technique allows the browser to cache the HTML(and static javascripts) and only fetch a json string. It is quite fast indeed and bandwith friendly.
不,它不会更快。 JSON 在服务器端生成比 HTML 容易得多。据我所知,Twitter 还使用 Mustache 在客户端上呈现这些数据。
因此,您只需提供静态模板(如果缓存正确,它们只需要加载一次)和 JSON 数据,然后让客户端完成所有渲染工作。一个优点是,客户端可以选择他们想要呈现数据的内容和方式,另一个优点是它可以承担服务器上所有繁重的 HTML 生成开销。
No it wouldn't be faster. JSON is a lot easier to generate on the server side than HTML. As far as I know Twitter also uses Mustache for rendering these data on the client.
So you just serve the static templates (if cached properly they only need to be loaded once) and your JSON data and then let the client do all the rendering work. One advantage is, that the client can pick what and how they want to render the data and another that it takes all the heavy HTML generation overhead from the servers.
我的猜测:避免重复 UI 相关代码。
我刚刚看了 Twitter 的源代码,看起来他们想将所有 UI 逻辑保留在 JavaScript 中。这是合理的,因为 Twitter 页面会不断获取新推文,因此他们无论如何都必须用 JavaScript 编写 UI 相关代码。因此,它不是在后端重复相同的代码,而是只是在使用 JavaScript 加载页面时播种初始数据以呈现推文。
缓存参数对我来说没有意义,因为它在任何一种方法中都会以相同的方式工作,因为初始页面请求不可缓存。
My guess: to avoid repeating UI related code.
I just took a look at Twitter's source code, and it seems like they wanted to keep all UI logic in JavaScript. This is reasonable since Twitter page will keep fetching new tweets, so they had to write UI related code in JavaScript anyway. So, rather than repeating the same code in the backend, it is just seeding the initial data to render the tweets at the time of page load with JavaScript.
Caching arguments do not make sense to me, since it will work the same way in either approach since the initial page request is not cacheable.
基本上,这是将表示和数据分离到另一个层次。服务器端有一层仅提供数据。一般来说,JSON 是提供该数据的好方法。现在你可以单独对待如何呈现它。
该 JSON 可以通过 Web 服务传递给任何感兴趣的客户端(Web/桌面/移动/其他 API)。然后客户可以决定如何呈现它。在 Web 上,我们使用大量 JavaScript 来读取和解析此 JSON 并操作屏幕/DOM。
Basically this is a separation of presentation and data taken to another level. There is a layer on the server side which just provides data. In general, JSON is a good way to provide that data. Now how you present it can be treated separately.
This JSON can be delivered via web services to any interested client (Web/Desktop/Mobile/Other API). Then the client can decide how to present it. On Web we use lot of javascripts to read and parse this JSON and manipulate the screen/DOM .