为什么使用Nuxt.js？
Why Nuxt.js？
Nuxt.js利用Vue.js开发SSR应用的一站式解决方案，是一个基于Vue.js的通用应用框架。
服务端渲染
首先我们讲清楚服务端渲染（SSR） 与 静态站点生成（SSG） 的区别。我们可以在浏览器里直接输出Vue的组件，然后利用其js来生成和操作用户端展示的DOM，这就是SPA的传统思路。而SSR中我们将组件在服务端直接渲染成HTML字符串然后将其发送到浏览器，然后通过某种方式“激活（hydrate）”这些静态的HTML字符串，形成完全交互式的客户端应用程序。
这篇用三体人的脱水来描述这个过程，非常有趣，如何理解SSR的hydrate过程
然后，我们需要对自己的业务场景发出以下两个灵魂拷问：
-
我们真的需要搜索引擎优化（SEO）吗？
-
我们真的需要更短的首屏加载时间吗？
什么是SEO？众所周知，搜索引擎是通过网络爬虫来实现信息收集的，而这些爬虫在爬取网站内容的同时通常不会执行网站的任何脚本，这也就意味着如果依赖于客户端脚本进行内容渲染，则搜索引擎爬虫得到的内容中基本什么有用的信息都没有。而服务端渲染的页面返回的是已经执行了js脚本的HTML文本，因此搜索引擎爬虫能够获取到相对完整的信息，从而提高搜索引擎对网站的匹配精确度。
什么是首屏？首屏加载时间又是什么？当我们打开一个网页，看到的第一眼显示内容就是首屏，而如果我们滚动鼠标后页面滑动，新出现的内容就不能称为首屏了。首屏优化做的好的网站，在打开的第一时间就可以发现首屏的内容基本加载完全。而如果我们快速滑动页面，会发现首屏以外剩下的部分可能还在加载过程中。首屏加载时间指的就是从开始加载到浏览器显示首屏内容所需的时间，这个时间通常不应超过3s，不过需要视网络环境而定。首屏加载速度更快，最终用户体验更好，用户的滞留时间更长，用户转化率更高。
那么为什么我们要说这两个是灵魂拷问呢？因为SSR并不是绝对的好，我们需要注意SSR带来的以下几个问题：
-
后端需要解析HTML，增大访问压力
-
最终产品与移动端体验有明显差异
-
不能在服务端渲染期间直接操作DOM，使用document、window等对象
-
由于代码在服务端和客户端都需要跑，某些代码操作需要区分运行环境
-
注意不能打包只在服务端运行的外部扩展库，否则构建后文件体积过大
Nuxt.js，你都做了什么？
Nuxt.js相当于一个Vue项目结合了一个node.js server项目。这里的node.js提供的服务起带来两个作用：
-
node.js 能够执行javascript，因此在服务端代替浏览器进行页面渲染
-
作为静态文件服务器，将渲染完成的页面返回给用户
Nuxt.js官网为开发者提供了三个选择它的理由：
-
enjoyable：预设了Vue.js开发SSR应用所需要的几乎一切配置，让任何使用Vue.js进行开发的程序员都能在短时间内掌握开发SSR应用的能力，让开发过程根据enjoyable
-
Performant：Nuxt.js尽可能利用Vue与Node.js进行协同的最佳实践来提高代码性能
-
Modular：模块化结构，而且不同于常规的前端组件化，Nuxt.js提供的模块同时考虑了客户端和服务端。
