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

《Web前端發(fā)展及應(yīng)用》由會(huì)員分享，可在線閱讀，更多相關(guān)《Web前端發(fā)展及應(yīng)用（6頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、 web 前端的發(fā)展及應(yīng)用 一、 簡(jiǎn)單明了的早期時(shí)代 這個(gè)也稱為 web 1.0 時(shí)代，非常適合創(chuàng)業(yè)型不分前后端，經(jīng)常 3-5 個(gè)人就可以搞定所有的開 發(fā)，基本上是服務(wù)端給什么，瀏覽器就展現(xiàn)什么（由 web server 層控制） 好處： 簡(jiǎn)單明了，本地起一個(gè) Tomcat 或者 Apache 就能開發(fā)了， 只要業(yè)務(wù)不太復(fù)雜就都還

2、好。 弊端： 但業(yè)務(wù)太多了，變得復(fù)雜了， server 越來越多，開發(fā)人員增多時(shí)，就會(huì)遇到以下的一些問題 1. Service 越來越多，調(diào)用關(guān)系變復(fù)雜，前端搭建本地環(huán)境不再是一件簡(jiǎn)單的事。 2. Jsp 等代碼的可維護(hù)性越來越差。 jsp:  非常強(qiáng)大，可以內(nèi)嵌 Java代碼。這種強(qiáng)大使得前后端的職責(zé)不清晰，  jsp 就變 成了一個(gè)灰色地帶，經(jīng)常會(huì)出現(xiàn)為了趕項(xiàng)目等各種緊急的需求，會(huì)在  jsp  里糅雜了 大量業(yè)務(wù)代碼，這種積攢到一定程度，往往會(huì)打來大量的維護(hù)成本。

3、 二．后端為主的 MVC 時(shí)代 為了降低復(fù)雜度，以后端為出發(fā)點(diǎn)，有了 web server 層的框架升級(jí)，這就是后端的 MVC 時(shí) 代。 從上面的圖可以看出來代碼的維護(hù)性得到了明顯的好轉(zhuǎn)， MVC 是個(gè)非常好的協(xié)作模式，從

4、 框架層面讓開發(fā)者懂得什么是代碼，應(yīng)該寫在什么地方，這使得模板里寫不了 Java 代碼， 但功能看起來變?nèi)趿?，正是這種限制使得了前后端分工更清晰，但任然會(huì)有問題存在： 1. 前端開發(fā)重度依賴開發(fā)環(huán)境 這種框架下， 前后協(xié)作有兩種模式： 一種是前端寫 demo，寫好后讓后端去套模板。 好處：很明顯， demo 可以本地開發(fā)，很高效，不足是還要后端套模板，有可能會(huì)套錯(cuò)，而且還要前端確定，來回溝通調(diào)整的成本較大。 另一種協(xié)作的模式是前端負(fù)責(zé)瀏覽器的所有開發(fā)和服務(wù)器端的 view 層模板開發(fā)，支付寶是這種模式。 好處： UI 相關(guān)的代碼都是前端

5、去寫就好，后端不用太關(guān)注， 弊端：前端開發(fā)嚴(yán)重綁定后端的環(huán)境，環(huán)境成為影響前端開發(fā)效率的重要因素。 2. 前后端職責(zé)依舊糾纏不清 Velocity 模板還是挺強(qiáng)大的， 變量 邏輯，宏等特性， 依舊可以通過拿到上下文變量來實(shí)現(xiàn)各種業(yè)務(wù)邏輯。 這樣只要前端弱勢(shì)一點(diǎn)， 往往會(huì)被后端要求拿到的上下層寫 出不少業(yè)務(wù)代碼，還有一個(gè)灰色地帶是 controller ，頁(yè)面路由等功能應(yīng)該前端最關(guān)注的，但是由后端來實(shí)現(xiàn)了。 三 Ajax 的 SPA時(shí)代 2005 年 Ajax 正式提出，加上 CDN 開始大量用靜態(tài)資源儲(chǔ)存，于是就出現(xiàn)了 javascriptd

6、 的 SPA時(shí)代。 特點(diǎn)：這種模式下， 前后端的分工就非常清晰了， 前后端的關(guān)鍵協(xié)作點(diǎn)是 Ajax 接口，看起開 很好，但回頭看看，這與 jsp 時(shí)代區(qū)別不大。復(fù)雜程度從服務(wù)端的 jsp 里移到了瀏覽器得到 JavaScript，瀏覽器變得復(fù)雜，類似 Spring MVC ，這個(gè)時(shí)代開始出現(xiàn)瀏覽器端的分層架構(gòu)： 對(duì)于 SPA，有幾個(gè)重要的挑戰(zhàn) 1． 前后端接口的約定： 如果后

7、端的接口一趟糊涂，后端的業(yè)務(wù)模型不夠穩(wěn)定，那這樣前端開發(fā)會(huì)很痛苦。 2． 前端開發(fā)的復(fù)雜度調(diào)控： SPA應(yīng)用大多數(shù)以功能交互型為主， JavaScript 代碼過十萬行很正常。 大量 js 代碼的組織與 view 層的綁定等，都不是容易的事情。 四．前端為主的 MV* 時(shí)代 為了降低前端開發(fā)的復(fù)雜度，例如：

8、 好處： 1. 前后端職責(zé)很清晰： 前端在瀏覽器端工作，后端在服務(wù)端工作。 2. 前端開發(fā)的復(fù)雜問題可控： 前端代碼很重，但合理的分層，讓前端代碼各司其職。 3. 部署相對(duì)獨(dú)立： 產(chǎn)品可以快速改進(jìn)。 不足： 4. 代碼不能復(fù)用，例如后端依舊需要對(duì)數(shù)據(jù)做出各種校驗(yàn)。 5. SPA不能滿足所有需求，依舊存在大量頁(yè)面應(yīng)用。 五． Node 帶來的全棧時(shí)代 前端

9、為主的 MV* 模式解決了很多很多問題，但依舊不足，然后 Node.js 興起了， JavaScript 開始有能力運(yùn)行在服務(wù)端，這就研發(fā)了一種新的模式： 在這種情況下，前后端職責(zé)很清晰。對(duì)前端來說，兩個(gè) UI 層各司其職： 1，F(xiàn)ront-end UI layer 處理瀏覽器層的展現(xiàn)邏輯。通過 C

10、SS渲染樣式，通過 JavaScript添加 交互功能， HTML 的生成也可以放在這層，具體看應(yīng)用場(chǎng)景。 2，Back-end UI layre 處理路由，模板，數(shù)據(jù)獲取等。通過路由，前端可以自主把控 URL Design，這樣無論是單頁(yè)面還是多頁(yè)面應(yīng)用，前端都可以自由調(diào)控，后端也可以擺脫對(duì)展現(xiàn)的強(qiáng)關(guān)注，可以專心于業(yè)務(wù)邏輯的開發(fā)。 與 JSP比較，全棧模式看起來是一種回歸，也的確是一種原始的開發(fā)模式的回歸，不過是一種螺旋上升的回歸。 Node 全棧時(shí)代面臨的挑戰(zhàn)： 1 需要前端對(duì)服務(wù)端編程有更進(jìn)一步的認(rèn)識(shí) 2 Node 層與 Java層的高效通信。 Node 模式下，都在服務(wù)器端 3 對(duì)部署，運(yùn)維層面的熟練，需要更多知識(shí)點(diǎn)和實(shí)操經(jīng)驗(yàn)。