web前端動態(tài)網(wǎng)頁開發(fā)主流技術有哪些？

時間：2024-01-14 08:12:01 | 來源：網(wǎng)站運營

時間：2024-01-14 08:12:01 來源：網(wǎng)站運營

web前端動態(tài)網(wǎng)頁開發(fā)主流技術有哪些？：

現(xiàn)今各種框架、工具‘橫行’，到處在講原理和源碼，更有跨端技術需要我們?nèi)ヌ剿鳎绻竟Σ缓?，學什么都是事倍功半，效果很不好，花費時間的同時打擊自信心。此篇文章，為我所計劃的【輕聊前端】系列第（十五）篇，旨在系統(tǒng)地、邏輯性地把原生JavaScript知識分享給大家，幫助各位較為輕松地理清知識體系，更好地理解和記憶，我盡力而為，望不負期待。

前言

前面的文章，我們聊了數(shù)據(jù)，操作數(shù)據(jù)的方法，網(wǎng)頁載體，宿主，交互，工具箱已經(jīng)很豐富。

但是，需要思考一個重要問題，我們一直在討論語言本身，而網(wǎng)頁，首先是用來呈現(xiàn)信息的——“信息從哪來？”

可以在html里寫，但如果這樣，它會一直不變，而且每個人都一樣。

故而，信息“動態(tài)化”，是Web的重要特點之一，毫不夸張地說，它改變和引領了一個時代。

如果你是新手，從手敲代碼輸入內(nèi)容，到從數(shù)據(jù)庫拉取內(nèi)容，是一種突破和跨越，即便老手，仍舊每天在和數(shù)據(jù)打交道，拿到準確無誤的信息依然令人興奮。

網(wǎng)頁只有具備了動態(tài)化的內(nèi)容，才是豐富的，和用戶產(chǎn)生聯(lián)系的。

本文就聊聊前后端通信的發(fā)展歷程。

發(fā)展歷程

CGI（Common Gateway Interface）

CGI，出現(xiàn)于1993年，距今快30年歷史，它定義了Web服務器與外部程序之間的通信接?標準，Web服務器可以通過CGI執(zhí)?外部程序，讓外部程序根據(jù)請求?成動態(tài)內(nèi)容?？梢允褂貌煌木幊陶Z言編寫。

缺點是效率低，編程困難。

ASP/PHP/JSP

它們出現(xiàn)的時間、特點，不盡相同，但較CGI更簡單，效率更高。它們有一個共同點，頁面是由后端處理完之后生成返回給前端，前后端有相當一部分代碼耦合在一起。

通過這些方式同樣能做到內(nèi)容動態(tài)刷新，但有幾個缺點。

（1）刷新時網(wǎng)頁一片空白，影響用戶體驗。

（2）多數(shù)情況下，需要更新的只是網(wǎng)頁中很小一部分，但這種方式會刷新整個頁面，網(wǎng)絡傳輸中傳送了額外的信息，使速度變慢，增加了傳輸負擔。

這種方式已經(jīng)顯得陳舊，雖然仍會有公司，包括大公司，由于歷史原因仍有使用，但不作為討論的重點，知道即可。

“無破壞”刷新、前后端分離

iframe——模擬異步傳輸

什么是異步傳輸？它如何模擬？上面提到了頁面的整體傳輸，一片空白。異步傳輸就是局部更新，iframe可以用來實現(xiàn)局部化。

iframe是一種HTML標記，它會創(chuàng)建包含另外一個文檔的內(nèi)聯(lián)框架，通過iframe框架可以在當前頁面顯示其他頁面的信息。

具體操作，是將iframe的src屬性設置為對另外一個頁面的連接請求，并在當前頁面通過JavaScript動態(tài)更新iframe的內(nèi)容，就可以將服務端的數(shù)據(jù)響應到客戶端，這樣就不會出現(xiàn)主頁面空白，等待刷新的現(xiàn)象，減少了刷新的內(nèi)容，提高了速度。

至此，在當前時間節(jié)點，能被稱為”老歷史“的已經(jīng)回顧完成，接下來的內(nèi)容，才是當下需要學習和掌握的重點。

Ajax——真正的異步交互

在Web發(fā)展歷程中，Ajax具有轉(zhuǎn)折性意義。

2005年，Jesse James Garrett撰寫了一篇文章，“Ajax—A New Approach toWeb Applications”。文中描繪了一個被他稱作Ajax（AsynchronousJavaScript+XML，即異步JavaScript加XML）的方案。

它不是一門獨立的技術，而是使用JavaScript對象——XMLHttpRequest跟XML相結合得出的實現(xiàn)方案。現(xiàn)在我們知道，它不局限于XML，只是名字被保留下來。

Ajax通過異步通信和響應完成頁面的局部刷新，以此改善傳統(tǒng)Web中大量不必要的整頁刷新。

Ajax出現(xiàn)之后，Google就在Google地圖、Google搜索建議、Gmail等投入使用，效果很棒，隨后在全世界逐漸流行開來。

Ajax請求

創(chuàng)建

function requestMethod(type,url,data,contentType){ let XHR = new XMLHttpRequest() XHR.open(type,url,true) XHR.setRequestHeader('Content-type',contentType) XHR.send(data) XHR.onreadystatechange = function(){ if(XHR.readyState == 4 && XHR.status == 200){ // 請求成功返回內(nèi)容 } }}

過程略顯繁瑣，不論是以前還是現(xiàn)在，都會有第三方工具提供更加簡潔和強大的封裝，后面會聊，現(xiàn)在先讓我們深入細節(jié)。

type——請求類型

小tips：請求類型跟JavaScript無關，屬于HTTP協(xié)議的范疇。

常見的有以下幾種：

• get：用于獲取數(shù)據(jù)
• post：用于創(chuàng)建數(shù)據(jù)
• put：用于更新數(shù)據(jù)
• delete：用于刪除數(shù)據(jù)
• options：判定服務器內(nèi)容是否允許客戶端訪問

不常見的有：head、trace、connect、patch，感興趣的可自行了解。

請求類型看起來很豐富，能充分應對各種需求，但你可能在很多項目中只看到get和post，這就是它”靈活“的地方，雖各有用途，但你用或者不用，并沒有強制性，不會被阻止。建議還是應用合適的方法。

url——請求地址

前端發(fā)送請求是向服務端地址發(fā)起的，需要服務端提供。

data——請求傳參

傳參是需要注意的一點，不同的請求方式和后端處理不同的時候，都會不同。

主要有兩種方式，一種是作為查詢字符串（query），另一種放在消息體（body）。查詢通常對應get，消息體通常對應post。

傳輸?shù)臄?shù)據(jù)類型即contentType，常見的有以下三種：

（1）application/x-www-form-urlencoded：原生form表單，放在body，數(shù)據(jù)按照key1=val1&key2=val2的方式進行編碼，key 和 val 都進行了URL轉(zhuǎn)碼。

（2）multipart/form-data：通常表單上傳文件時使用該種方式。

（3）application/json：消息主體是序列化后的JSON字符串。

請求回調(diào)

請求發(fā)出之后，我們需要知道什么時候返回結果，狀態(tài)是什么，內(nèi)容是什么。

成功了是一種處理，失敗又是另一種。怎么判斷呢？——onreadystatechange。

在這個回調(diào)中，有兩個屬性值可用于判斷：readyState 和 status。

readyState代表請求的狀態(tài)，跟結果無關，每當readyState的值發(fā)生變化，都會觸發(fā)readystatechange事件?？梢越璐藱C會檢查readyState的值。一般來說，我們需要關心的readyState值是4，表示數(shù)據(jù)已就緒。為保證跨瀏覽器兼容，onreadystatechange事件處理程序應該在調(diào)用open()之前賦值。

如果readyState值為4，就需要判斷status，它保存著HTTP狀態(tài)碼，當它的值是2xx或3xx，表示請求順利完成，完成后，我們就拿到返回的數(shù)據(jù)進行后續(xù)處理和展示。

還有一些小工具，在某些場景很有用。 - loadstart：接收到第一個字節(jié)時觸發(fā) - progress：獲取響應進度 - error：請求出錯時觸發(fā) - abort：用來取消發(fā)出的請求 - load：成功接收完響應時觸發(fā)，和readyState值為4時類似 - loadend：在通信完成時，且在error、abort或load之后觸發(fā)

請求頭（Request Headers）

每個請求在發(fā)送時都會攜帶請求頭，用于傳遞除數(shù)據(jù)之外的信息。常見的有：請求方法、協(xié)議、接收的數(shù)據(jù)類型、請求來源、緩存策略等，數(shù)量繁多，每種都有其特定的作用，這里不展開。

開發(fā)者需要額外關注的，是自定義的請求頭，通常是前后端約定用于接口鑒權，如果需要，可以使用setRequestHeader()方法。它接收兩個參數(shù)：字段的名稱和值。

為保證請求頭被發(fā)送，須在open()之后、send()之前調(diào)用setRequestHeader()。

狀態(tài)碼

上面提到過狀態(tài)碼，狀態(tài)碼能夠幫助我們判斷請求結果是否可用，如果不可用，發(fā)生了什么類型的異常，從而更合理地進行后續(xù)處理。

主要分類如下：

• 1XX 表示消息
• 2XX 表示成功
• 3XX 表示重定向
• 4XX 表示客戶端錯誤
• 5XX 表示服務端錯誤

這就是為什么說status是2xx或者3xx代表請求順利完成，因為這兩種是沒有出錯且和數(shù)據(jù)相關的。狀態(tài)碼種類同樣繁多，且每個項目規(guī)范不一，酌情使用，這里不再展開。

Ajax為Web發(fā)展立了大功，現(xiàn)在仍占據(jù)主流，但隨著時間推移，它終將會被替代，替代者可能就是下面要登場的這位。

Fetch API

顧名思義，”獲取“。

Fetch API能夠執(zhí)行XMLHttpRequest對象的所有任務，且更容易使用，接口更現(xiàn)代化。

它在使用上和Ajax有很大不同，主要是：

• fetch()暴露在全局，可直接調(diào)用
• XMLHttpRequest可以通過open的第三個參數(shù)選擇是否異步（true為異步，false為同步），F(xiàn)etch必須異步
• 請求完成返回一個Promise，回調(diào)里包含返回對象
• 使用這個對象的屬性和方法獲取資源并進行轉(zhuǎn)換
• 能夠在包括主頁面執(zhí)行線程、模塊和工作線程中使用

看個示例：

fetch(url).then((response)=>{ if(response.status == 200){ response.json().then(data=>{ console.log(data) }) }})看代碼就一目了然，直接調(diào)用fetch，參數(shù)url、響應response、屬性status、方法json()、有用的數(shù)據(jù)data。

其中，方法有多種選擇：blob、formData、json、text。

只使用URL時，fetch()會發(fā)送GET請求，只包含最低限度的請求頭。要進一步配置如何發(fā)送請求，需要傳入可選的第二個參數(shù)——init對象。init中包含但不限于：

• method：請求的類型
• cache：控制瀏覽器和HTTP緩存的交互
• headers：指定請求頭部
• mode：指定請求模式，決定來自跨源請求的響應是否有效
• signal:支持通過AbortController中斷進行中的fetch請求

比如可以像這樣發(fā)送請求：

let payload = JSON.stringify({ name:'idea'})let jsonHeader = { 'Content-Type':'application/json'}fetch('send-json',{ method:'POST', body:payload, headers:jsonHeader})需要注意的是，fetch請求不會幫你判斷狀態(tài)是否真正可用，只要響應完成，就會返回為resolve，所以，要在回調(diào)中用response.status和response.ok來判斷，如果因為服務器沒有響應而導致瀏覽器超時，這樣的失敗會導致reject。

同樣，fetch支持通過AbortController/AbortSignal中斷請求。調(diào)用AbortController. abort()會中斷所有網(wǎng)絡傳輸，適合希望停止傳輸大型負載的情況。中斷進行中的fetch()請求會導致包含錯誤的拒絕。

fetch的大體使用就是這樣，還有很多細節(jié)，可自行查閱。

實時交互

以上介紹的內(nèi)容，在頁面的生命周期，或者響應用戶操作層面足夠了，但有一些情況難以勝任，即實時交互。比如，你發(fā)出一個請求，后端處理結果的時機是不確定的，需要一個過程，這時候該怎么響應呢？

主流方案

有4種主流方案： - 輪詢：客戶端定時發(fā)送請求，就像普通請求一樣。 - 長輪詢：客戶端發(fā)送請求，服務端接收到請求后進行阻塞，并保持連接，當服務端有數(shù)據(jù)需要響應時，使用保持住的連接進行響應，并關閉連接。 - 長連接：和上一種類似，但最后不關閉連接，而是繼續(xù)保持。 - 推送：客戶端與服務端建立連接后，服務端可以直接向客戶端推送數(shù)據(jù)。

這幾種都可以滿足實時更新服務端信息的目的，下面介紹的屬于最后一種。

Web Socket

iframe、AJAX都是基于HTTP協(xié)議進行Web交互。HTTP協(xié)議的工作模式對于構建實時Web應用存在諸多的限制，只能先由客戶端提交請求，服務器端響應請求，并非是由服務器向客戶端進行主動推送。

隨著HTML 5標準的推出，提出了一種新的瀏覽器服務器通信協(xié)議—WebSocket協(xié)議。通過該協(xié)議可以在瀏覽器和服務器之間構建一條全雙工的通信連接，支持服務器端向客戶端主動推送信息，實現(xiàn)實時刷新頁面的功能。

為了使用Web Socket，需要在Web服務器上運行一個程序（也叫Web Socket服務器）。這個程序負責協(xié)調(diào)各方通信，而且啟動后就會不間斷地運行下去。

前端使用示例：

const ws = new WebSocket('ws://localhost:8080')ws.onopen = ()=>{ ws.send()}ws.onmessage = ()=>{}ws.onerror = ()=>{}ws.onclose = ()=>{}以ws開頭的url，是一個表示W(wǎng)eb Socket連接的新協(xié)議，還可以是wss表示安全加密。

創(chuàng)建WebSocket對象后，頁面就會嘗試連接服務器。然后就是使用WebSocket對象的4個事件：onOpen、onMessage、onError、onClose。分別對應”建立連接、收到消息、發(fā)生異常、連接關閉“。

連接成功后，需要向服務器發(fā)送一條消息。發(fā)送消息要使用WebSocket對象的send()方法，這個方法接收純文本內(nèi)容作為參數(shù)。

Web Socket在前端的使用就是這樣，但使用之前要理解兩點。

第一，Web Socket是一種專用手段，比較適合開發(fā)聊天室、大型多人游戲，或者端到端的協(xié)作工具，而不是每一種類型。在適合的場景使用才好。

第二，Web Socket方案做起來可能比較復雜。JavaScript代碼很簡單，服務端代碼不好寫，要對多線程和網(wǎng)絡模型有深刻理解。

到這里，關于前后端數(shù)據(jù)通信基本介紹完了，但是，還有一個角色，雖然跟業(yè)務數(shù)據(jù)無關，也屬于這個范疇。

Beacon API

介紹之前，先聊一個話題——數(shù)據(jù)上報。

一般的請求是用來拉取動態(tài)數(shù)據(jù)的，但還有一類請求，它不是來展示數(shù)據(jù)，而是幫助統(tǒng)計數(shù)據(jù)，什么數(shù)據(jù)呢？跟用戶行為相關的數(shù)據(jù)。這個動作稱為”數(shù)據(jù)上報“。

上報的對象是服務器，至于是自有，還是第三方，看情況定。

過去，解決這個問題有如下幾種方案：

• 發(fā)起一個同步 XMLHttpRequest
• 使用<img>元素
• 創(chuàng)建一個幾秒的 no-op 循環(huán)

一個奇怪的角色出現(xiàn)了，Image對象，你可能會問，這兩者似乎完全不搭，是怎么產(chǎn)生聯(lián)系的。大體有以下幾點：

• 數(shù)據(jù)上報不需要回饋，對頁面沒有、也不應該有實際的展示或者交互影響。
• 方法足夠輕量，性能消耗小。
• 圖片作為替換元素，有src屬性可用來傳遞url
• 兼容性極好

有優(yōu)點也有缺點，它的缺點：

• 請求方式只能是get
• url長度受限
• 響應數(shù)據(jù)類型受限，狀態(tài)處理受限
• 用戶代理會延遲文檔卸載，以完成掛起的圖片加載

既然以上幾種方案都互有優(yōu)劣，有沒有一種結合它們優(yōu)點的方式？

Beacon API就是。

語法如下：

navigator.sendBeacon(url);navigator.sendBeacon(url, data);sendBeacon有兩個參數(shù)：URL和要在請求中發(fā)送的數(shù)據(jù)data。data參數(shù)是可選的，其類型可以是ArrayBufferView、Blob、DOMString 或FormData。如果瀏覽器成功的以隊列形式排列了用于傳遞的請求，則該方法返回“true”，否則返回“false”。

當我們寫了這些代碼，它會嘗試在卸載文檔之前將數(shù)據(jù)發(fā)送到服務器。時機過早可能錯失收集數(shù)據(jù)的機會。所以時機控制很重要，恰恰這是開發(fā)人員難以做到的，API幫我們解決了。

有幾點要說明：

• sendBeacon()并不是只能在頁面生命周期末尾使用，而是任何時候都可以使用。
• 瀏覽器保證在原始頁面已經(jīng)關閉的情況下也會發(fā)送請求。
• 狀態(tài)碼、超時和其他網(wǎng)絡原因造成的失敗是不透明的，不能通過編程方式處理。

嗯，這次真結束了~

工具

通信方法部分聊完了，簡單介紹幾個工具，

第三方封裝的請求Jquery.ajax()、axios。

接口調(diào)試工具mock、postman、apipost、apifox等。

結語

前后通信，接口調(diào)試，是現(xiàn)代Web必有的環(huán)節(jié)，當我們寫好頁面結構和布局，就是它了。

本文需要重點關注的是Ajax、Fetch、其次Websocket，最后Beacon。

文章夠長，希望你有收獲，下篇見。