1四、VUE服务器渲染

一、HTML的渲染方式

1.1. 浏览器本地渲染

   

 

   这种方式不会被搜索引擎获取内容，因此不利于网站的推广。

   由于浏览器本地渲染是页面js经过发送ajax请求获取后台的json数据，而后生成页面内容。

   爬虫程序抓取页面内容时，并不会执行里面的js，因此也就获取不到服务器端的json数据，所以爬虫程序得不到服务器端的内容。

1.2. 服务器渲染

         服务器渲染（SSR=Server Side Rendering）分为所有渲染和部分渲染。

1.2.1. 所有渲染

 

 

      服务器会渲染一个完整的HTML页面返回给浏览器。因此浏览器显示的内容所有来源于服务器。（这个好像好久好久以前的方式。。）

      这种方式能被爬虫程序爬取到。

      缺点是页面加载会比较慢，由于从后台传输的数据比较大。

      

1.2.2. 部分渲染

         就是后台传递给前台部份内容，其余内容由前端本身建立。

         这种方式缺点仍是没法被爬虫程序完整获取到。

 

 

总结：建议所有渲染。

 

二、Nuxt.js基础知识

 

 

 

 

2.1. 为何要使用nuxt.js

     vue单页面应用渲染是从服务器获取所需js，在客户端将其解析生成html挂载于

id为app的DOM元素上，这样会存在两大问题。

 

1、资源请求量大，形成网站首屏加载缓慢，不利于用户体验。

2、因为页面内容经过js插入，对于内容性网站来讲，搜索引擎没法抓取网站内容，不利于SEO。

Nuxt.js 是一个基于Vue.js的通用应用框架，预设了利用Vue.js开发服务端渲染的应用所须要的各类配置。能够将html在服务端渲染，合成完整的html文件再输出到浏览器。

 

 

最主要的缘由时使用vue-cli搭建的SPA（单页应用）不利于搜索引擎的SEO操做。搜索引擎对SPA的抓取并很差，特别是百度根本无法抓取到SPA的内容页面，因此咱们必须把咱们的应用在服务端渲染成适合搜索引擎抓取的页面，再下载到客户端。

 

Nuxt.js是Vue.js的通用框架，最经常使用的就是用来做SSR（服务器端渲染）。再直白点说，就是Vue.js原来是开发SPA（单页应用）的，可是随着技术的普及，不少人想用Vue开发多页应用，并在服务端完成渲染。这时候就出现了Nuxt.js这个框架，她简化了SSR的开发难度。还能够直接用命令把咱们制做的vue项目生成为静态html。

 

2.2. nuxt.js适用的项目

Nuxt.js适合做新闻、博客、电影、咨询等须要搜索引擎提供流量的项目。

 

2.3. nuxt.js和vue的区别

   1、路由
nuxt按照 pages 文件夹的目录结构自动生成路由
vue需在 src/router/index.js 手动配置路由

2、入口页面
nuxt页面入口为 layouts/default.vue
vue页面入口为 src/App.vue

3、webpack配置
nuxt内置webpack，容许根据服务端需求，在 nuxt.config.js 中的build属性自定义构建webpack的配置，覆盖默认配置
vue关于webpack的配置存放在build文件夹下

 

2.4. 建立nuxt.js工程

一、首先要安装vue-cli插件(安装过的忽略此步)

 

 

二、在须要建立工程的目录下面执行以下指令。

    

 

 

三、把工程导入到WebStorm中

四、执行下面的命令，运行开发模式

Npm  run dev

五、打开浏览器 http://localhost:3000

2.5. nuxt.js目录结构

 

 

 

 

l 页面目录（pages）：放置须要渲染的页面

l components：常规vue组件

l Layouts（全局布局文件）：全局文件，站点使用的公共css等，如错误页面，默认布局等

l Middleware（中间件）：相似于java的aop，权限认证用

l 插件目录（plugins）：放置插件

l 静态文件目录（static）：放置静态文件，该目录下的文件自动被映射到“/”之下。

l Store目录：存放状态信息

l Nuxt.config.js目录：Nuxt.js的配置文件

l Package.json目录：依赖文件

 

 

  

 

 

三、附录（推荐阅读）

 

3.1. 为何如今又流行服务端渲染html？

 

https://www.zhihu.com/question/59578433

貌似几年以前从服务端生成html(如servlet)慢慢开始先后端分离，把一些渲染计算的步骤抛向前端来减轻服务端的压力。可是为啥如今又开始流行在服务端渲染html了呢？如vue全家桶或者react全家桶，都是推荐经过服务端渲染来实现路由的。单纯的是由于Virtual DOM的强大仍是别的什么缘由？

 

回答1：

做者：知乎用户
连接：https://www.zhihu.com/question/59578433/answer/332545815
来源：知乎
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

如今的服务端渲染和过去的服务端渲染彻底是两码事。什么叫“又流行”？说明看问题太浅薄。

之前的服务器渲染，是以“文档”为核心思想。服务器端的逻辑是把HTML, CSS, Javascript看成一个静态文件，对“文档”而言不存在“指令”和“数据”的区别，一切都是数据。因此咱们能够看到服务器渲染，GET就是请求一个文件，而web 1.0时代的诸多服务端框架最基础的组件之一就是文档模版，好比asp, JSP之类，核心设计理念就是HTML文件里放占位符而后由服务端逻辑替换成实际数据后一股脑返回。

如今划重点：Web 2.0时代最大的思想革命本质不是先后端分离，而是把网页看成独立的应用程序（app）。先后端分离只是实现这一新架构的必然结果。对程序而言指令和数据是分离的。HTTP GET拿到的不是渲染后的网页，而是一个由html和Javascript组成的app, 这个app以浏览器为虚拟机。装载和显示数据是app启动以后的运行逻辑。传统上app叫什么？叫Client，也就是前端。因而先后端就这么分离了，浏览器变成了app的运行环境，后端蜕化成了单纯的业务逻辑和数据接口。写Javascript再也不是给网页添特效的小伎俩，而是正经的和写桌面应用程序同样的工程。因而咱们看到了前端工程化，编译（转译），各类MVC/MVVM框架，依赖工具，等等。很新鲜吗？不新鲜，都是传统桌面开发玩剩下的。我很早就说过，前端NodeJS的那堆东西，什么npm，Babel，Webpack，gulp，各个框架的cli... 本质上就是开源社区东拼西凑作一个Visual Studio。

那么如今怎么叫“又流行”服务端渲染了？走老路吗？固然不可能，模版式的服务端编程早就进了垃圾堆。咱们公司的后端实现甚至都不加载HTML模版引擎，进出的数据都是JSON（HTML/Javascript内容怎么办？单独编译，而后部署到S3上）如今的服务器渲染的目的只是为了加速和搜索引擎优化（准确的说是非Google引擎优化，由于Google能够解析Javascript动态网页）。而实现也很简单：拿个浏览器核心跑一下app而后把生成的html存起来给搜索爬虫就好了。与其说是渲染，不如说是“快照”，就像给app截图同样。

历史是螺旋上升的，有类似性但更重要的是进步。

 

 

     回答2：

做者：知乎用户
连接：https://www.zhihu.com/question/59578433/answer/326694511
来源：知乎
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

这要从大概八年前提及，事情是这样的

1 一开始，html 就是后端渲染的。不事后端发现页面中的 js 好麻烦（虽然简单，可是坑多），因而让公司招聘专门写 js 的人，也就是前端
2 前端名义上是程序员，实际上就是在切图（CSS）和作特效(JS)，因此全部程序员中前端工资最低，职位也最低。因此先后端的鄙视链就出现了。
3 nodejs 和前端 mvc 的兴起让前端变得复杂起来，前端发现翻身的机会，因而全力支持这两种技术，形成本不应作成 spa 的网站也成了 spa。慢慢地先后端分离运动从大公司开始兴起，目的就是前端脱离后端的指指点点，独立发展。（表面上是为了「代码分离」，其实是为了「人员分离」，也就是「先后端分家」，前端再也不附属于后端团队）
4 spa 以后发现 seo 问题很大，并且首屏渲染速度贼慢，可是本身选的路再难走也要走下去，因而用 nodejs 在服务端渲染这一条路被当作是一条出路
5 其实这是第二个翻身的机会，若是 nodejs 服务器渲染成为主流，其实就至关于前端把后端的大部分工做给抢了，工资压过普通后端指日可待
6 然而结果是 nodejs 服务端渲染始终是小众，由于后端也没那么脆弱，java php rails 十多年沉淀的技术岂是你说推翻就推翻的，已经运行多年的项目又岂是容你随便用 nodejs 重写的，另外一方面 golang 等技术的兴起也给 nodejs 很多压力。最终只有少部分前端特别强势的团队成功用上了 Node.js 作渲染（好比阿里的一些团队），大部分公司依然是用 PHP 渲染 HTML。
7 因而 nodejs 退一步说好好好我不抢大家的工做，我只作中间层（大部分工做就是渲染页面和调用后台接口），毫不越雷池。后端说算你识相。如今 nodejs 主要搞什么微服务，也是为了抢后端还没注意的市场。

你要看一门技术的发展主要应该看背后的人是谁，应用场景是哪些，最后才是技术细节。

nodejs 的火在中国早就烧过了，之后估计不会大火了，做为前端了解一下仍是不错的，可是若是你是后端的话，看不看都无所谓，nodejs 跟其余后端开发框架差别并不大，单线程异步既是优势也是缺点，你就把它当作一种范式研究就好。

我是一个坚决的『先后端分家』反对者，先后代码能够分离，可是人员绝对不该该分离。先后端撕逼的事情在大公司每天都在发生，全都是由于先后是两个团队，利益不一样。实际上前端推 nodejs 渲染就是在试图从新让先后端合成一体。

可是前端不能明说这件事，由于若是要把先后端部门合并，拆掉的确定是前端部门。

 

合，则至关于自断前程。
不合，则永远无法解决seo和首屏加载慢的问题。
因此前端真的挺矛盾的。

 

JS 也有一个矛盾的地方，凡是浏览器上的框架（Vue React）都说本身能适应「复杂」场景，凡是 Node.js 上的框架（express fastify koa）都说本身是「轻量级」框架。

为啥？由于浏览器是 JS 的主战场，并且无敌手。而服务器上，JS 的经验积累仍是太少了，搞企业级服务，Node.js 是敌不过 Java、PHP 的，没办法，发展得太晚了。因此目前只能搞「轻量级」咯。egg.js 号称是企业级 Node.js 框架，用过的人来评我就不评了。

做者：知乎用户
连接：https://www.zhihu.com/question/59578433/answer/326694511
来源：知乎
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

 

有些大佬提出「大前端」的概念，意思是前端也要会后端，可是咱们心仍是前端的。

这不就是把之前的『先后端一我的作』换了个说法嘛。

反正你如今让后端去学前端，后端确定是不肯意躺这浑水的。只能前端本身想办法咯。

想来想去就只有 Node.js 中间层作 HTML 渲染了。

 

当初是你要分开，分开就分开。
如今又要用kpi，把我唤回来。
可是后端kpi跟你前端kpi是不一样的呀，因此没戏。

 

这些话也就我这种脱离了大厂约束的人敢说，在大厂的人根本不敢说，毕竟跟后端低头不见抬头见的。

 

最后告诉你一个小秘密。因为阿里 nodejs 用得还算多，却招不到人，因此从功利的角度出发，也许你学 nodejs 比学 java 更容易进阿里，毕竟阿里的 java 大神多如云，nodejs 大神却很少。

你说是吧。

 

可是从另一个角度考虑，SEO 不友好的页面我是支持的。

若是你的页面是对 SEO 不友好的，那么百度的重要性就会被削弱。如今是移动互联网时代，你们在手机上几乎不用百度，都是直接点 App 点微信公众号的，SEO 不友好问题不大。首屏速度随着 5G 网络的普及也不会是问题了。

只要能让百度利益受损，我以为 SPA 这事仍是值得作的。服务端渲染仍是直接免了吧，你们都不作 SEO 让百度倒闭就最好咯~（只是个人幻想而已，不要当真，我是百度的脑残黑，黑百度历来不须要理由）

 

感谢你看我说了这么多，不过说到最后，我也没给出啥结论，只是把我观察到的告诉你了。

你要不要学、要不要用服务器渲染HTML，都是须要你本身思考的事情。

仍是那句话，我不喜欢说中庸的观点，我喜欢跟你说一个极端的观点，而后会有人用另外一个极端的观点反驳我，他说服不了我，我也说服不了他，可是最终，你会得出本身的观点。