前后端的技術(shù)已經(jīng)發(fā)展了很多年了耐齐，但是我們有很多問題或者很多思考的高度依舊是在圍繞工程打轉(zhuǎn)笤成，比如實(shí)現(xiàn)某個(gè)效果的頁(yè)面羡蛾。我嘗試站在時(shí)間的長(zhǎng)河邊漓帅，去思考一下前端和后端技術(shù)發(fā)展的方向問題，并給出一些未來前端的發(fā)展方向。
一忙干、網(wǎng)站發(fā)展簡(jiǎn)史及語(yǔ)言職責(zé)
讓我們回顧一下網(wǎng)站開發(fā)的一些歷史：
- 靜態(tài)網(wǎng)頁(yè) (html)
- 動(dòng)態(tài)網(wǎng)頁(yè)（php, jsp）
- 前端技術(shù)產(chǎn)生(applet, javascript)
從上面這段歷史屯伞，我們能看整個(gè)網(wǎng)站的開發(fā)核心是html，后端和前端技術(shù)均是為了豐富html而逐步發(fā)展起來的豪直。下面我們來看看各種web相關(guān)的語(yǔ)言所負(fù)責(zé)的職責(zé)：
| 名稱 | 職責(zé) | 備注 |
|---|---|---|
| html | 負(fù)責(zé)web頁(yè)面的結(jié)構(gòu) | 因?yàn)樵撛颍?lt;font>,<color>等標(biāo)簽逐步退出歷史舞臺(tái) |
| css | 負(fù)責(zé)web頁(yè)面的樣式 | |
| js | 負(fù)責(zé)web頁(yè)面的交互 | |
| 后端(java,php,node等) | 負(fù)責(zé)頁(yè)面的數(shù)據(jù) |
從這個(gè)職責(zé)表中，我們可以看出每種語(yǔ)言各司其職珠移，整個(gè)系統(tǒng)運(yùn)轉(zhuǎn)很完美弓乙。但是細(xì)究?jī)?nèi)容，我們會(huì)發(fā)現(xiàn)有一件事件是在前后端發(fā)展史上一直爭(zhēng)斗不休的問題钧惧，是一個(gè)繞不過去的問題: data -> html暇韧，一般我們也稱之為渲染。渲染問題是一個(gè)較復(fù)雜的問題浓瞪，而且涉及到整個(gè)web中的各種語(yǔ)言懈玻，是矛盾的集中產(chǎn)生地，針對(duì)渲染的問題乾颁，目前有三種解決方案：
| 方案 | 代表技術(shù) | 描述 | 優(yōu)點(diǎn) | 缺點(diǎn) |
|---|---|---|---|---|
| 后端負(fù)責(zé)渲染 | php, jsp等 | 由后端將數(shù)據(jù)等生成html涂乌，js僅負(fù)責(zé)頁(yè)面交互 | 1.技術(shù)成熟2.邏輯簡(jiǎn)單，數(shù)據(jù)直接通過內(nèi)存?zhèn)鬟f3.利于爬蟲 | 1.前端需要了解后端語(yǔ)言英岭，對(duì)前端極不友好2.代碼耦合緊密湾盒，不易維護(hù)3.消耗服務(wù)器資源 |
| 第三方負(fù)責(zé)渲染 | smarty, twig等 | 在后端與前端之間引入第三方模板系統(tǒng)，來解決渲染問題 | 1. 前后端解耦 2.對(duì)爬蟲友好3.邏輯簡(jiǎn)單 | 1.前后端都需要再學(xué)習(xí)一門模板語(yǔ)言2.消耗服務(wù)器資源 |
| 前端負(fù)責(zé)渲染 | vue, react,angular等 | 后端所有的數(shù)據(jù)都通過接口來傳遞诅妹，js拿到數(shù)據(jù)后負(fù)責(zé)渲染罚勾，將數(shù)據(jù)生成為html | 1.前后端開發(fā)簡(jiǎn)單 2.服務(wù)器壓力降低3.代碼拆分，解耦 | 1.對(duì)爬蟲不友好 2.數(shù)據(jù)傳遞很復(fù)雜3.技術(shù)不成熟4.渲染成為前端開發(fā)的主要矛盾 |
此處吭狡，我無(wú)意討論哪種方式好或者哪種不好尖殃。各種模式均有其適用的場(chǎng)景和環(huán)境，因此划煮，我們可以根據(jù)實(shí)際情況來選擇送丰。但本質(zhì)上我還是想說的事情是：渲染是前后端模式中的一個(gè)核心問題：既然html代表頁(yè)面的結(jié)構(gòu)，那么頁(yè)面結(jié)構(gòu)到底是由data決定還是由樣式和交互來決定般此？
二蚪战、vue等框架的核心問題
2.1 前端框架發(fā)展歷程
下面，我們來看看前端框架的發(fā)展歷程
- javascript 原生js
- 工具集：jquery
- mvc框架: BackboneJs, EmberJs等
- mvvm框架：vue等
2.2 框架設(shè)計(jì)的思路
正愁戆茫框架設(shè)計(jì)時(shí)應(yīng)該是針對(duì)某一類問題邀桑，找到這類問題的主線，通過各種設(shè)計(jì)模式和代碼復(fù)用科乎，解決主線壁畸；當(dāng)我們解決了主線時(shí)，之前的支線會(huì)成為主要矛盾，然后重復(fù)上述過程捏萍。
那么太抓，我們來看一下，早期前端開發(fā)的主要矛盾：
1令杈、jquery時(shí)代走敌。
頁(yè)面由后端渲染生成，js的主要的開發(fā)問題為: 給dom/頁(yè)面加上偵聽事件逗噩，等待事件發(fā)生掉丽，處理事件（主要有ajax, dom操作等）。
2异雁、 vue捶障。
- 整個(gè)頁(yè)面在第一次請(qǐng)求后，被vue接管纲刀。
- vue根據(jù)url或用戶操作项炼，獲取數(shù)據(jù)，渲染為html示绊。
- vue加上偵聽事件锭部，等待事件發(fā)生，處理事件面褐。
所以空免，我們從vue可以看出，vue極大地解決了之前jquery時(shí)代中所遇見的dom操作盆耽，事件綁定的問題蹋砚，使得vue比jquery在處理此類事件時(shí)，要便利很多摄杂。但是與此同時(shí)坝咐，也給前端帶來了新的工作——渲染。
渲染這項(xiàng)工作是極為復(fù)雜的析恢，后端曾經(jīng)花了極大的精力來解決該問題墨坚。但是，當(dāng)渲染被前端接手后映挂，前端并沒有認(rèn)真去考慮如何來解決該問題泽篮，它逐步變成一個(gè)大麻煩，在不斷侵蝕前端工程師的美好年華柑船。
三帽撑、渲染的解決之道
3.1 后端框架的一般過程
- 用戶通過瀏覽器發(fā)送請(qǐng)求給服務(wù)器
- 服務(wù)器會(huì)將請(qǐng)求通過路由分發(fā)到某一個(gè)controller/Action。
- Controller/Atcion通過Model從數(shù)據(jù)庫(kù)中獲取數(shù)據(jù)鞍时。
- 通過View來渲染數(shù)據(jù)亏拉。
- 最后Controller/Action將渲染后的數(shù)據(jù)返回給用戶
3.2 前端渲染時(shí)的邏輯結(jié)構(gòu)
有vue之后扣蜻，我們來看一下整體的邏輯結(jié)構(gòu)圖：
- 用戶先獲取帶有vuejs的基本頁(yè)面，整個(gè)頁(yè)面被vue接管.
- 用戶的操作被controller接管
- controller通過http等獲取數(shù)據(jù)
- 通過view來渲染數(shù)據(jù)及塘，最終呈現(xiàn)給用戶莽使。
- controller保持偵聽事件，等待特定事件發(fā)生笙僚。
我們可以看見芳肌，與后端渲染時(shí)，基本是同一個(gè)圖形肋层，唯一的不同就是把數(shù)據(jù)庫(kù)連接換成http連接庇勃，而vue是沒有Model的。
vue框架是有controller, viewModel(data)槽驶，view的，但是vue框架少了最重要的一層Model層鸳兽，而Model層正是整個(gè)系統(tǒng)中的業(yè)務(wù)邏輯聚集地掂铐，導(dǎo)致我們不得不把業(yè)務(wù)邏輯散亂地放置于Controller中。雖然vuex能部分地解決問題揍异，但是并沒有從根源上來解決全陨。因此，要解決渲染的問題衷掷，Model層或者說數(shù)據(jù)層是極為重要的一層辱姨。
具體的解決方法和實(shí)現(xiàn)下一次再討論。
