认识SPA
最早单页面的应用无从知晓，在2004年，google的Gmail就使用了单页面。到了2010年，随着Backbone的问世之后，此概念才慢慢热了起来。
随着后来React、Angular、Vue的兴起，单页面应用才成了前端圈里人人皆知的架构模式。
接下来将通过对比传统页面应用和单页面应用来说明SPA具体是什么。
传统的页面应用
早期web应用的前后端交互模式是这样的，每个html作为一个功能元件，通过刷新、超链接、表单提交等方式，将页面组织起来后给用户提供交互。
后期很多流行的框架都是基于此模式进行设计的，比如 Ruby on Rails，Spring MVC，Express 等等
传统的web应用中，浏览器只是作为展示层，路由、服务调用、页面跳转都是服务端来处理的。也就是MVC的架构都是放在后端的，只有V这一层，将页面通过网络发送到浏览器端，渲染给用户。
传统的模式具有以下特点：
- 重服务端：浏览器只作为展示层，将MVC全置于后端，加重了服务端的体量，开发中主要以后端为主。
- 频繁刷新：页面展示依赖于不同的功能元件，所以必须依靠刷新页面，或者跳转路由来实现功能块的切换，这种方式严重耗费资源，同时用户体验很差。
单页面应用
和传统应用相比较，单页面应用就是将MVC个架构搬到了前端来实现
- 控制器：将处理路由的功能放在前端，当浏览器的路由发生变化时，由控制器来响应其变化，指向其对应的处理逻辑（组件），最终将页面展现给用户。
- 视图：这一层就是功能元件，也就是单个的组件，当路由发生变化的时候由组件来处理，只处理变化的那部分，最后组织成页面。
- 数据层：单页面应用有自己的数据层定义，简化了后端服务的复杂度，后端只要提供公共的数据接口即可，而数据层会对数据服务API进行进一步的封装，然后提供数据给视图层。
如此看来单页面应用很像移动客户端，后端的精力就是提供高质量的、可复用的Rest API服务。
单页面应用的出现依然存在着争议性，我们该如何看待他的两面性呢？
单页面应用的优势：
- 无刷新体验：没有了令人诟病的页面频繁刷新，同时节约浏览器资源，路由响应比较及时，提升了用户的体验。
- 共享组件：前端组件化是将独立完整的功能模块封装到一个组件中，代码结构更加规范，便于代码维护，同时模块化后的组件可以在不同的场景中进行复用，极大地加快了迭代开发的速度。这也是为什么主流的前端框架都提倡组件化编程的原因。
- 共享API：给后端减负，前端加码的好处就是，前端能有一点口粮吃了（开玩笑，前端那么牛怎么能没饭吃呢？），前端担起家务的事，后端就可以安心地处理业务逻辑了，于是才能写出高质量并可共享的API，供自己或者其他的合作伙伴使用。一个优秀的产品背后，一定有一群出色的前端（小生脸皮太厚）。
单页面应用的劣势：
- 抬高了前端门槛：SPA模式的流行，引领了前端技术的飞速发展，与此同时对前端人员在学习和使用上的能力就有了更高的要求，同时工作量也增加了，前端想活的更好就要付出的更多，所以不要再以为前端就是切切图，画画页面这么简单。too young, too naive。
- 首次加载大量资源：既然只有一个页面显示，那许多功能元件（组件）所依赖的静态资源就需要在初次时进行加载，加载时间相对比较长。
- 不利于SEO：单页面应用，数据都是在前端进行渲染的，所以就影响了SEO。