客户端渲染有哪些坑？

从别的角度出发，客户端渲染有很多其他名字比如前端渲染、前端异步、前端 MVC。 今天的 Web 稍有交互的站点都会做一套前端渲染，从早期的 Backbone，AngularJS 1.0， 到现在的流行的 Vue，React。基于这些技术做 MVVM 的同时甚至可以完成服务器端渲染。 但浏览器的客户端渲染（也就是前端 MVC）仍然存在不少限制，这些限制都是前端渲染绕不过的问题。

概述

一个支持客户端渲染的技术架构应当包括这些内容：

• 首屏渲染。服务器端渲染首屏，或者客户端根据当前 URL 渲染对应的页面。
• 前端路由。点击链接时改变页面的 URL，返回/前进时渲染对应页面。
• 异步渲染。在不发生整页重新载入的情况下更新页面内容。

下文中，我们用 同步渲染 指代浏览器直接载入 HTML 及其中的资源；用 异步渲染 指通过 DOM API 去动态插入元素和资源。

共享同一个后端服务

结论：异步打开的所有 URL 都必须在同一服务器，或者这些服务器都知道所有 URL 对应的页面信息。

场景：打开页面A -> 跳转到页面 B -> 刷新 -> 返回到页面 A。考虑如何渲染页面 A？

对于传统的同步渲染，构成 Web 站点的页面之间不需共享任何信息，一个链接就足够了。 但对于一部打开的页面，没有对方页面的信息就意味着无法异步渲染。

在同构渲染流行之前，通常的实现是让服务器对所有页面都返回同样的内容：框架页面。 前端路由会根据页面 URL （最初还是使用 hash 部分）从这个框架页面渲染出真正的页面。 因此那个框架页面知道所有可能的页面如何渲染。

显然上述实现搜索引擎不友好，首屏时间延迟。同构渲染技术使得服务器可以直接渲染用户请求的那个页面，而不需要先在客户端启动 MVC 框架。但即使是同构渲染，仍然要求一个服务器知道所有可能会异步打开的页面。

这一限制从某个角度上理解是反 Web 的。Web 是开放互联的同时服务器之间完全独立，正是这一点让 Web 变得 Scalable。客户端渲染让一组页面对应同一个后端服务，它们组成一个前端 App。

脚本要符合异步风格

结论：所有页面的脚本都必须无副作用、不依赖