了解javascript有必要使用服務端渲染嗎

javascript學習教學專欄介紹是否使用服務端渲染。

前言 

#前陣子有搞了React 服務端渲染的項目，是否應該用這個主要還是看場景吧。

比較適用於大家常說的 SEO 和首屏渲染這些，一般都是 toc 的業務才會需要用到。

同構 

現代框架的服務端渲染和 jsp、php 這些還是有不少區別的。因為 nextjs 和 nuxtjs 這種不只是服務端渲染，它們還是同構框架。

什麼是同構呢？就是一份程式碼既可以跑在瀏覽器端，也可以跑在服務端。這得歸功於 NodeJS 在服務端的流行。

傳統 jsp、php、django 這些服務端渲染框架都是傳回 html 字串，類似於傳統的 MPA 多頁模式。所以切換頁面的時候就會刷新，重新請求 css 和 js 文件，使用者體驗比較差。

而現在流行的前端開發模式都是 SPA 單頁面，基於 H5 的 History 來實現切換頁面無刷新，這樣可以帶來更好的使用者體驗。

所以 nextjs 和 nuxtjs 不僅支援服務端渲染，還支援 SPA，常用的是對首頁進行服務端渲染，其他頁面依然保持 SPA 的無刷新存取模式。

我們這邊就有使用 Django 來寫的頁面，維護起來很痛苦。因為無法說清楚哪些是前端負責的，哪些是後端負責的。所以為了維護這個，前端和後端都去要學習 Python 和 Django，大大提高了維護成本。

實際應用場景的話，我們這裡有幾個場景就比較適合用服務端渲染。

支援Post 請求 

一個是重構的h5 頁面，專案以前是新加坡團隊用Python Django 寫的，所以有些頁面是第三方網站Post 提交表單開啟的。

我們重構後的 H5 頁面都掛在騰訊雲 CDN 上面，不支援用 Post 開啟的。為什麼不改成 Get 呢？因為這是以前他們協定的，然後銀行都是爸爸，他們不會為了我們改協議的。

頁面功能都是比較簡單的，所以為了趕上重構的時間線，當時旁邊的小夥伴用 Express EJS 實作了一版，只支援 ES5 的語法。

後續需求經歷幾次變更，想在原來的頁面上加功能都比較麻煩。例如我想實作 JS Bridge，我只能用 microbundle 把現有的 npm 套件打成一個 umd 文件，然後用 script 標籤引進。

動態渲染標題 

前陣子遇到了另一個需求，我需要為多家銀行實現相同的H5 頁面，功能基本上都是一樣的，但App 頭部需要顯示不同銀行的名字。

在我們 AirPay App 裡面，客戶端在開啟 webview 的時候會去讀取我們 HTML 裡面的 title，將其設定為原生頭部的標題。

如果我在程式碼裡面使用 document.title 的方式動態設定就不會生效，只能透過 JS Bridge 來動態設定頭部。

但這個頁面不只會提供給 AirPay 使用，還會提供給 Shopee 使用，需要相容兩套 JS Bridge，有點兒得不償失。

但如果使用服務端直出的形式，就可以在服務端直接判斷好需要渲染的標題，設定到 HTML 的 title 裡面。這就是另一個適合的業務場景了。

所以在先前專案基礎上新增了 React 服務端渲染的功能，支援用 React 開發同構應用程式。這裡也沒有用 Next，只是一套自己實現的同構。

大致實現思路是用isomorphic-style-loader 和universal-router 來處理樣式和路由的同構，服務端獲取到資料後輸出到window._INITIAL_STATE__ 裡面，在瀏覽器取得這個初始化資料實現資料同構的。

同時也保留了原始的 EJS 模板，都是基於 Express 路由分發的，既可以渲染用 EJS 渲染，也可以用 React 服務端直出。

一期的這個頁面是掛在騰訊雲 CDN 上面的，二期使用了服務端渲染，可以明顯感覺到載入速度變快了很多，畢竟以前還是會展示一個 loading 圖。

在進程守護方面，整個部門的 Node 服務都是用大佬寫的 Node Agent 來做，也經歷了各種大促的考驗。

缺點 

當然了，服務端渲染也不應該被濫用。

例如我們的內部後台管理系統就上了 Nuxt，現在每次本地建置要花10分鐘，非常影響開發效率。

Nuxt 功能還是非常強大的，例如會根據路由動態拆分建置檔案、滑鼠放到 Nuxt-link 路由元件上面就會預先載入 JS 檔案等等。

But the actual benefits are almost zero, because we don’t need SEO, and we don’t need to improve the first screen loading speed.

Almost everyone in the team has tried to use various means to optimize the build, but the effect is not very obvious. It was not until recently that we started to split micro-frontends that we solved this problem.

In addition, server-side rendering is also written differently from client-side rendering, which can easily lead to bugs.

For example, the following code in the Vuex state file:

const date = moment().format('YYYY-MM-DD')
export default () => ({  
date
})

When the page is opened, the time should be displayed today. Even if the page is placed across the sky, it should still be the same day when you open it and refresh it.

But in Nuxt, the displayed date is the date when your service is started. No matter how you refresh it, it will never change.

Because Nuxt will store these data in the store when it is initialized. No matter how it is refreshed later, this file will not be reloaded on the server because the module will be cached by Node, so the date will not be updated. .

But in client-side rendering, since page refresh will cause the browser to reload the JS file, this date will also be recalculated.

Recommended (free): Javascript learning tutorial

以上是了解javascript有必要使用服務端渲染嗎的詳細內容。更多資訊請關注PHP中文網其他相關文章！