Web前端發(fā)展及應(yīng)用

1、web前端的發(fā)展及應(yīng)用一、 簡(jiǎn)單明了的早期時(shí)代這個(gè)也稱(chēng)為web 1.0時(shí)代，非常適合創(chuàng)業(yè)型不分前后端，經(jīng)常3-5個(gè)人就可以搞定所有的開(kāi)發(fā)，基本上是服務(wù)端給什么，瀏覽器就展現(xiàn)什么（由web server層控制）好處：簡(jiǎn)單明了，本地起一個(gè)Tomcat 或者Apache 就能開(kāi)發(fā)了，只要業(yè)務(wù)不太復(fù)雜就都還好。弊端：但業(yè)務(wù)太多了，變得復(fù)雜了，server越來(lái)越多，開(kāi)發(fā)人員增多時(shí)，就會(huì)遇到以下的一些問(wèn)題1. Service 越來(lái)越多，調(diào)用關(guān)系變復(fù)雜，前端搭建本地環(huán)境不再是一件簡(jiǎn)單的事。2. Jsp 等代碼的可維護(hù)性越來(lái)越差。jsp: 非常強(qiáng)大，可以?xún)?nèi)嵌Java代碼。這種強(qiáng)大使得前后端的職責(zé)不清晰，jsp

2、就變成了一個(gè)灰色地帶，經(jīng)常會(huì)出現(xiàn)為了趕項(xiàng)目等各種緊急的需求，會(huì)在jsp里糅雜了大量業(yè)務(wù)代碼，這種積攢到一定程度，往往會(huì)打來(lái)大量的維護(hù)成本。二后端為主的MVC時(shí)代為了降低復(fù)雜度，以后端為出發(fā)點(diǎn)，有了web server層的框架升級(jí)，這就是后端的MVC時(shí)代。從上面的圖可以看出來(lái)代碼的維護(hù)性得到了明顯的好轉(zhuǎn)，MVC是個(gè)非常好的協(xié)作模式，從框架層面讓開(kāi)發(fā)者懂得什么是代碼，應(yīng)該寫(xiě)在什么地方，這使得模板里寫(xiě)不了Java代碼，但功能看起來(lái)變?nèi)趿?，正是這種限制使得了前后端分工更清晰，但任然會(huì)有問(wèn)題存在：1. 前端開(kāi)發(fā)重度依賴(lài)開(kāi)發(fā)環(huán)境這種框架下，前后協(xié)作有兩種模式：一種是前端寫(xiě)demo，寫(xiě)好后讓后端去套模板。好

3、處：很明顯，demo可以本地開(kāi)發(fā)，很高效，不足是還要后端套模板，有可能會(huì)套錯(cuò)，而且還要前端確定，來(lái)回溝通調(diào)整的成本較大。另一種協(xié)作的模式是前端負(fù)責(zé)瀏覽器的所有開(kāi)發(fā)和服務(wù)器端的view層模板開(kāi)發(fā)，支付寶是這種模式。好處：UI相關(guān)的代碼都是前端去寫(xiě)就好，后端不用太關(guān)注，弊端：前端開(kāi)發(fā)嚴(yán)重綁定后端的環(huán)境，環(huán)境成為影響前端開(kāi)發(fā)效率的重要因素。2. 前后端職責(zé)依舊糾纏不清Velocity模板還是挺強(qiáng)大的，變量 邏輯，宏等特性，依舊可以通過(guò)拿到上下文變量來(lái)實(shí)現(xiàn)各種業(yè)務(wù)邏輯。這樣只要前端弱勢(shì)一點(diǎn)，往往會(huì)被后端要求拿到的上下層寫(xiě)出不少業(yè)務(wù)代碼，還有一個(gè)灰色地帶是controller，頁(yè)面路由等功能應(yīng)該前端最關(guān)

4、注的，但是由后端來(lái)實(shí)現(xiàn)了。三 Ajax 的SPA時(shí)代2005年Ajax正式提出，加上CDN開(kāi)始大量用靜態(tài)資源儲(chǔ)存，于是就出現(xiàn)了javascriptd的SPA時(shí)代。特點(diǎn)：這種模式下，前后端的分工就非常清晰了，前后端的關(guān)鍵協(xié)作點(diǎn)是Ajax接口，看起開(kāi)很好，但回頭看看，這與jsp時(shí)代區(qū)別不大。復(fù)雜程度從服務(wù)端的jsp里移到了瀏覽器得到JavaScript，瀏覽器變得復(fù)雜，類(lèi)似Spring MVC ，這個(gè)時(shí)代開(kāi)始出現(xiàn)瀏覽器端的分層架構(gòu)：對(duì)于SPA，有幾個(gè)重要的挑戰(zhàn)1 前后端接口的約定：如果后端的接口一趟糊涂，后端的業(yè)務(wù)模型不夠穩(wěn)定，那這樣前端開(kāi)發(fā)會(huì)很痛苦。2 前端開(kāi)發(fā)的復(fù)雜度調(diào)控：SPA應(yīng)用大多數(shù)以功

5、能交互型為主，JavaScript代碼過(guò)十萬(wàn)行很正常。大量js代碼的組織與view層的綁定等，都不是容易的事情。四前端為主的MV*時(shí)代為了降低前端開(kāi)發(fā)的復(fù)雜度，例如：好處：1. 前后端職責(zé)很清晰： 前端在瀏覽器端工作，后端在服務(wù)端工作。2. 前端開(kāi)發(fā)的復(fù)雜問(wèn)題可控： 前端代碼很重，但合理的分層，讓前端代碼各司其職。3. 部署相對(duì)獨(dú)立： 產(chǎn)品可以快速改進(jìn)。不足：4. 代碼不能復(fù)用，例如后端依舊需要對(duì)數(shù)據(jù)做出各種校驗(yàn)。5. SPA不能滿足所有需求，依舊存在大量頁(yè)面應(yīng)用。五Node帶來(lái)的全棧時(shí)代 前端為主的MV*模式解決了很多很多問(wèn)題，但依舊不足，然后Node.js興起了，JavaScript開(kāi)始有

6、能力運(yùn)行在服務(wù)端，這就研發(fā)了一種新的模式：在這種情況下，前后端職責(zé)很清晰。對(duì)前端來(lái)說(shuō)，兩個(gè)UI層各司其職：1，F(xiàn)ront-end UI layer 處理瀏覽器層的展現(xiàn)邏輯。通過(guò)CSS渲染樣式，通過(guò)JavaScript添加交互功能，HTML的生成也可以放在這層，具體看應(yīng)用場(chǎng)景。2，Back-end UI layre 處理路由，模板，數(shù)據(jù)獲取等。通過(guò)路由，前端可以自主把控URL Design，這樣無(wú)論是單頁(yè)面還是多頁(yè)面應(yīng)用，前端都可以自由調(diào)控，后端也可以擺脫對(duì)展現(xiàn)的強(qiáng)關(guān)注，可以專(zhuān)心于業(yè)務(wù)邏輯的開(kāi)發(fā)。與JSP比較，全棧模式看起來(lái)是一種回歸，也的確是一種原始的開(kāi)發(fā)模式的回歸，不過(guò)是一種螺旋上升的回歸。