前段時間我針對手頭上的專案前端配置進行了反思以及總結並且寫了兩篇文章: webpack傳統後端渲染的專案前端配置, webpack配置之前後端不分離, 很顯然這些配置能滿足一時的需求, 但是也有不足. 今天繼續總結, 這裡應該不涉及到具體後端語言, 只對前端配置進行描述. 畢竟配置工程師(逃
靜態資源管理
傳統後端主導的專案中對靜態資源很少處理, 畢竟後端主要還是處理業務邏輯, 但是這樣一來前端的命門就被後端抓在手裡而且還不受重視, 這就導致這麼一個情況: 前端寫好靜態頁面和css js扔給後端轉換為jsp之類的後端模板. 更大的問題是後端會在頁面中增加很多後端邏輯. 這就弊處. 後端看在頁面寫一段java程式碼處理邏輯方便那就很自然的這樣幹了. 後端寫完邏輯後前端發現自己看不懂了(這裡就需要稍微懂一點後端了), 這裡不能說誰錯了, 只是開發模式很不合理. 我們需要做的是儘量避免這種情況的出現.
對於後端模板我們姑且不算靜態資源. 那麼傳統後端對靜態資源的處理方式就如下圖所示:
很明顯, 靜態資源的處理都在後端. 但是靜態資源的不管呈現還是處理都應該是前端的事情. 甚至極端情況下html檔案也應該是前端的事情, 所以spa(單頁應用)誕生了:
後端不再直接參與前端邏輯和靜態資源的處理, 這樣當然有好處: 前後端算是完全分離了, 頁面由前端渲染, 但是弊處也相當明顯: seo的問題, 首次載入速度... 等等. 再者前端無法控制後端的介面質量, 導致分工倒是分了, 但是專案進度反而是慢了, 老專案也不可能進行完全的分離, 我認為操作性很強的web應用(注意是應用)完全可以直接spa, 好處也毋庸置疑. 但是對於一些展示性的網站, 比如知乎, 簡書等卻不一定非得這樣(知乎的問題後面會提到, 不完全是react).
對於上面的情況, 我們可能有個更好的開發模式, 也是我目前在用的, 如下圖所示:
看起來似乎第二個沒有明顯不一樣. 但是我們要知道, 對於很多列表展示類的網頁可能後端渲染很方便很多, 對於單頁應用來說多入口的webpack配置可能是不常用的. 但是如果是後端渲染的網頁, 每個模板我們都需要提供一個介面: 就是之前我寫的文章, 有興趣可以回頭看看. 後端通過讀取資源表來獲取靜態資源, 也就是說後端基本不需要跟靜態資源打交道了. 更有趣的是我們可以在任意頁面引用任意框架, 對於某個操作性很強的頁面來說, 我們完全可以使用vue, react ng等. 或者使用某個元件.
關於seo
其實seo我也不瞭解, 但是姑妄說之. 我們首先來看兩個網站: 掘金和知乎, 在baidu和google下的搜尋表現:
知乎在google:
掘金在google:
知乎在baidu:
掘金在baidu:
上面我們可以看到, 二者其實還是有點差距的吧, 當然也有可能是掘金沒太關注這方面.
但是通過開發者工具其實我們可以看到二者分別用了react和vue, 那麼二者差異到底在哪呢? 我們分別禁用兩個網站的js(此處無圖), 掘金一片空白, 知乎至少可以正常渲染.
掘金完全是前端渲染, 知乎做到這一點也很簡單就是後端渲染一遍前端再渲染一遍(貌似是多餘的), 但是我認為這是值得的, 後端不需要寫介面, 把需要渲染的資料作為INITIAL_STATE 賦值給window, 知乎點贊之類的操作都是框架進行處理的.
其實蠻建議掘金也這樣處理得, 掘金網頁端訪問並不是很爽.
總結
上面不涉及具體程式碼以及配置, 但是思路在那裡, 不管後端是什麼, 我們前端可以都寫的很爽, 同樣, 前後端分離不是說什麼都是給前端幹, 完全可以協調工作量.
最後有問題可以加群討論以及歡迎關注我的公眾號:
