《Web前端發(fā)展及應用》由會員分享,可在線閱讀,更多相關《Web前端發(fā)展及應用(6頁珍藏版)》請在裝配圖網(wǎng)上搜索。
1、
web 前端的發(fā)展及應用
一、 簡單明了的早期時代
這個也稱為 web 1.0 時代,非常適合創(chuàng)業(yè)型不分前后端,經(jīng)常 3-5 個人就可以搞定所有的開
發(fā),基本上是服務端給什么,瀏覽器就展現(xiàn)什么(由 web server 層控制)
好處:
簡單明了,本地起一個 Tomcat 或者 Apache 就能開發(fā)了, 只要業(yè)務不太復雜就都還
2、好。
弊端:
但業(yè)務太多了,變得復雜了, server 越來越多,開發(fā)人員增多時,就會遇到以下的一些問題
1. Service 越來越多,調(diào)用關系變復雜,前端搭建本地環(huán)境不再是一件簡單的事。
2. Jsp 等代碼的可維護性越來越差。
jsp:
非常強大,可以內(nèi)嵌 Java代碼。這種強大使得前后端的職責不清晰,
jsp 就變
成了一個灰色地帶,經(jīng)常會出現(xiàn)為了趕項目等各種緊急的需求,會在
jsp
里糅雜了
大量業(yè)務代碼,這種積攢到一定程度,往往會打來大量的維護成本。
3、
二.后端為主的 MVC 時代
為了降低復雜度,以后端為出發(fā)點,有了 web server 層的框架升級,這就是后端的 MVC 時
代。
從上面的圖可以看出來代碼的維護性得到了明顯的好轉(zhuǎn), MVC 是個非常好的協(xié)作模式,從
4、
框架層面讓開發(fā)者懂得什么是代碼,應該寫在什么地方,這使得模板里寫不了 Java 代碼,
但功能看起來變?nèi)趿耍沁@種限制使得了前后端分工更清晰,但任然會有問題存在:
1. 前端開發(fā)重度依賴開發(fā)環(huán)境
這種框架下, 前后協(xié)作有兩種模式: 一種是前端寫 demo,寫好后讓后端去套模板。
好處:很明顯, demo 可以本地開發(fā),很高效,不足是還要后端套模板,有可能會套錯,而且還要前端確定,來回溝通調(diào)整的成本較大。
另一種協(xié)作的模式是前端負責瀏覽器的所有開發(fā)和服務器端的 view 層模板開發(fā),支付寶是這種模式。
好處: UI 相關的代碼都是前端
5、去寫就好,后端不用太關注,
弊端:前端開發(fā)嚴重綁定后端的環(huán)境,環(huán)境成為影響前端開發(fā)效率的重要因素。
2. 前后端職責依舊糾纏不清
Velocity 模板還是挺強大的, 變量 邏輯,宏等特性, 依舊可以通過拿到上下文變量來實現(xiàn)各種業(yè)務邏輯。 這樣只要前端弱勢一點, 往往會被后端要求拿到的上下層寫
出不少業(yè)務代碼,還有一個灰色地帶是 controller ,頁面路由等功能應該前端最關注的,但是由后端來實現(xiàn)了。
三 Ajax 的 SPA時代
2005 年 Ajax 正式提出,加上 CDN 開始大量用靜態(tài)資源儲存,于是就出現(xiàn)了 javascriptd
6、 的
SPA時代。
特點:這種模式下, 前后端的分工就非常清晰了, 前后端的關鍵協(xié)作點是 Ajax 接口,看起開
很好,但回頭看看,這與 jsp 時代區(qū)別不大。復雜程度從服務端的 jsp 里移到了瀏覽器得到
JavaScript,瀏覽器變得復雜,類似 Spring MVC ,這個時代開始出現(xiàn)瀏覽器端的分層架構(gòu):
對于 SPA,有幾個重要的挑戰(zhàn)
1. 前后端接口的約定:
如果后
7、端的接口一趟糊涂,后端的業(yè)務模型不夠穩(wěn)定,那這樣前端開發(fā)會很痛苦。
2. 前端開發(fā)的復雜度調(diào)控:
SPA應用大多數(shù)以功能交互型為主, JavaScript 代碼過十萬行很正常。 大量 js 代碼的組織與 view 層的綁定等,都不是容易的事情。
四.前端為主的 MV* 時代
為了降低前端開發(fā)的復雜度,例如:
8、
好處:
1. 前后端職責很清晰:
前端在瀏覽器端工作,后端在服務端工作。
2. 前端開發(fā)的復雜問題可控:
前端代碼很重,但合理的分層,讓前端代碼各司其職。
3. 部署相對獨立:
產(chǎn)品可以快速改進。
不足:
4. 代碼不能復用,例如后端依舊需要對數(shù)據(jù)做出各種校驗。
5. SPA不能滿足所有需求,依舊存在大量頁面應用。
五. Node 帶來的全棧時代
前端
9、為主的 MV* 模式解決了很多很多問題,但依舊不足,然后 Node.js 興起了,
JavaScript 開始有能力運行在服務端,這就研發(fā)了一種新的模式:
在這種情況下,前后端職責很清晰。對前端來說,兩個 UI 層各司其職:
1,F(xiàn)ront-end UI layer 處理瀏覽器層的展現(xiàn)邏輯。通過 C
10、SS渲染樣式,通過 JavaScript添加
交互功能, HTML 的生成也可以放在這層,具體看應用場景。
2,Back-end UI layre 處理路由,模板,數(shù)據(jù)獲取等。通過路由,前端可以自主把控 URL
Design,這樣無論是單頁面還是多頁面應用,前端都可以自由調(diào)控,后端也可以擺脫對展現(xiàn)的強關注,可以專心于業(yè)務邏輯的開發(fā)。
與 JSP比較,全棧模式看起來是一種回歸,也的確是一種原始的開發(fā)模式的回歸,不過是一種螺旋上升的回歸。
Node 全棧時代面臨的挑戰(zhàn):
1 需要前端對服務端編程有更進一步的認識
2 Node 層與 Java層的高效通信。 Node 模式下,都在服務器端
3 對部署,運維層面的熟練,需要更多知識點和實操經(jīng)驗。