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，都是須要你本身思考的事情。

仍是那句話，我不喜歡說中庸的觀點，我喜歡跟你說一個極端的觀點，而後會有人用另外一個極端的觀點反駁我，他說服不了我，我也說服不了他，可是最終，你會得出本身的觀點。