業(yè)務(wù)專線：13711534025
1991 年 8 月，第一個靜態(tài)頁面誕生了，這是由 Tim Berners-Lee 發(fā)布的，想要告訴人們什么是萬維網(wǎng)。從靜態(tài)頁面到 Ajax 技術(shù)，從 Server Side Render 到 React Server Components，歷史的車輪滾滾向前，一個又一個技術(shù)誕生和沉寂。
前言
1994 年，萬維網(wǎng)聯(lián)盟（W3C，World Wide Web Consortium）成立，超文本標記語言（HTML，Hyper Text Markup Language）正式確立為網(wǎng)頁標準語言，我們的旅途從此開始。
本文將沿著時間線，從“ 發(fā)現(xiàn)問題-解決問題”的角度，帶領(lǐng)大家了解 Web 技術(shù)發(fā)展的關(guān)鍵歷程，了解典型技術(shù)的誕生以及技術(shù)更迭的緣由，思考技術(shù)發(fā)展的原因。
Tim Berners-Lee
Tim Berners-Lee（蒂姆·伯納斯·李），英國科學(xué)家，萬維網(wǎng)之父，于 1989 年在歐洲核子研究組織（CERN）正式提出萬維網(wǎng)的設(shè)想。該網(wǎng)絡(luò)最初是 為了滿足世界各地大學(xué)和研究所的科學(xué)家之間對自動信息共享的需求而設(shè)計和開發(fā)的，這也是為什么HTML的頂層聲明是 document，標簽名、文檔對象模型的名稱也是由此而來。
1990 年 12 月，他開發(fā)出了世界上第一個網(wǎng)頁瀏覽器。1993 年 4 月 30 日，歐洲核子研究組織將萬維網(wǎng)軟件置于公共領(lǐng)域，把萬維網(wǎng)推廣到全世界，讓萬維網(wǎng)科技獲得迅速的發(fā)展，深深改變了人類的生活面貌。
他創(chuàng)造了超文本標記語言（HTML），并創(chuàng)建了歷史上第一個網(wǎng)站。當(dāng)然，現(xiàn)在只剩下了由 CERN 恢復(fù)的網(wǎng)站副本：info.cern.ch.
靜態(tài)網(wǎng)頁時代
早期的靜態(tài)網(wǎng)頁，只有最基本的單欄布局，HTML 所支持的標簽也僅有<h1>、<p>、<a>。后來為了豐富網(wǎng)頁的內(nèi)容，<img>、<table>標簽誕生了。
這一階段，Web 服務(wù)器基本上只是一個靜態(tài)資源服務(wù)器，每當(dāng)客戶端瀏覽器發(fā)來訪問請求，它都來者不拒的建立連接，查找 URL 指向的靜態(tài)頁面，再返回給客戶端。
隨著網(wǎng)頁的飛速發(fā)展，人們發(fā)現(xiàn)要 人工實現(xiàn)所有信息的編寫是非常困難的，而且非常耗時。
設(shè)想一下，假如一個頁面有兩塊區(qū)域展示的內(nèi)容是互相獨立的，那么你需要涵蓋所有的可能，需要編寫的頁面數(shù)量是兩塊區(qū)域的內(nèi)容數(shù)量的乘積！
此外，靜態(tài)網(wǎng)站只能夠根據(jù)用戶的請求返回指向的網(wǎng)頁，除了進行超鏈接跳轉(zhuǎn)，沒辦法實現(xiàn)任何交互。
此時，人們想要
網(wǎng)頁能夠動態(tài)顯示
直接使用數(shù)據(jù)庫里的數(shù)據(jù)
網(wǎng)頁實現(xiàn)一些用戶交互
讓頁面更美觀
1994 年，網(wǎng)景公司發(fā)布了 Navigator 瀏覽器，但他們急需一種網(wǎng)頁腳本語言，以使瀏覽器可以與網(wǎng)頁互動。
1995年，網(wǎng)景公司的 Brendan Eich 迫于公司的壓力，只花了十天就設(shè)計了 JS 的最初版本，并命名為 Mocha。后來網(wǎng)景公司為了蹭 Java 的熱度，把 JS 最終改名為 Java。但實際情況是，網(wǎng)景公司和 Sun 公司結(jié)成聯(lián)盟，才更名為 Java。
從此網(wǎng)頁有了一些簡單的用戶交互，比如表單驗證；也 有了一些JS為基礎(chǔ)的動效，如走馬燈。
但是讓網(wǎng)頁真正開始進入動態(tài)網(wǎng)頁時代的卻是以 PHP 為代表的后端網(wǎng)站技術(shù)。
擴展資料：第一次瀏覽器大戰(zhàn)
在網(wǎng)景公司推出 Java 的時候，微軟以 JS 為基礎(chǔ)，編寫了 J 和 VB 作為瀏覽器語言，并在 1995 年的 8 月推出了 IE 1.0。
由于微軟在系統(tǒng)里捆綁瀏覽器，而 90% 的人都在使用 Windows 操作系統(tǒng)，大量用戶被動地選擇了 IE。面對微軟快速搶占瀏覽器份額，網(wǎng)景公司無奈之下只能快速將 Java 向 ECMA 提交標準，制定了 ECMA 標準。
在這段時間，還發(fā)生過一件趣事，IE 4.0 發(fā)布當(dāng)天 Netscape 的員工們發(fā)現(xiàn)公司的草坪上出現(xiàn)了一個大大的 IE 圖標，這明顯是一個挑釁的舉動。作為回應(yīng)，Netscape 把自己的吉祥物 “Mozilla” 放在 IE 的圖標上，并掛上胸牌，寫著 “Netscape 72，Microsoft 18”——在當(dāng)時， IE 的市場份額確實不如 Netscape Navigator。
但這無法解決份額的問題，網(wǎng)景公司最終在第一次瀏覽器大戰(zhàn)中落敗，于 1998 年，被美國在線（AOL）以42億美元收購。
在 1998 年網(wǎng)景公司被收購前，網(wǎng)景公司公開了 Navigator 源代碼，想通過廣大程序員的參與重新獲得市場份額。Navigator 改名為 Mozilla。這也是火狐瀏覽器的由來，也是第二次瀏覽器大戰(zhàn)的伏筆。
CSS
1994 年，Hkon Wium Lie 最初提出了 CSS 的想法。1996 年 12 月，W3C 推出了 CSS 規(guī)范的第一版本。
美觀是所有人的追求。HTML 誕生以來，網(wǎng)頁基本上就是一個簡陋的富文本容器。由于缺少布局和美化手段，早期網(wǎng)頁流行用table標簽進行布局。為了解決網(wǎng)頁“丑”的問題，Hkon Wium Lie 和 Bert Bos 共同起草了 CSS 提案，同期的 W3C 也對這個很感興趣。
早期網(wǎng)頁外觀
早期的 CSS 存在多種版本，在 PSL96 版本你甚至可以在里面使用邏輯表達式。但因為它太容易擴展，瀏覽器廠商那么多，會變得很難統(tǒng)一，最終被放棄。
在眾多提案中，H?kon W Lie 的 CHSS（Cascading HTML Style Sheets）最早提出了 樣式表可疊加的概念。
行尾的百分比表示這條樣式的權(quán)重，最終將根據(jù)權(quán)重計算最終值。圖中將會計算 30pt * 40% + 20pt * 60%作為h2字體大小的最終值。
為了解決 CSS 兼容性的問題，網(wǎng)景公司甚至還將 CSS 用 JS 來編寫。
CSS 從誕生開始就伴隨著大量的 bug，不同瀏覽器表現(xiàn)不同坑害了無數(shù)的程序員。今天我們能用上相對靠譜的 css，不得不說這是一個奇跡。
動態(tài)網(wǎng)頁技術(shù)
1995 年，Rasmus Lerdof 創(chuàng)造的 PHP 開始活躍在各大網(wǎng)站，它讓 Web 可以訪問數(shù)據(jù)庫了，PHP 實現(xiàn)了人們渴望的動態(tài)網(wǎng)頁。
這里的動態(tài)網(wǎng)頁不是指網(wǎng)頁動效，而是指內(nèi)容的動態(tài)展示、豐富的用戶交互。PHP 就像給網(wǎng)絡(luò)世界打開了一扇窗，各種動態(tài)網(wǎng)頁技術(shù)（如 ASP、JSP）雨后春筍般的冒了出來，萬維網(wǎng)也因此開始高速發(fā)展，MVC 模式也開始出現(xiàn)在后端網(wǎng)站技術(shù)中。
動態(tài)網(wǎng)頁技術(shù)解決了以前各種令人無法呼吸的痛，生活總會越來越好的：
可以用數(shù)據(jù)庫作為基礎(chǔ)來展示網(wǎng)頁內(nèi)容
可以實現(xiàn)表單和一些簡單交互
再也不用編寫一大堆靜態(tài)頁面了
PHP 等動態(tài)網(wǎng)頁技術(shù)的原理，大體上都是根據(jù)客戶端的請求，從數(shù)據(jù)庫里獲取相對應(yīng)的數(shù)據(jù)，然后塞到網(wǎng)頁里去，返回給客戶端一個填充好內(nèi)容的網(wǎng)頁。 這個階段也是前后端耦合的。
網(wǎng)頁開發(fā)流程
而當(dāng)一些基礎(chǔ)的需求被滿足之后， 動態(tài)網(wǎng)頁技術(shù)帶來的不足也漸漸暴露出來：
網(wǎng)頁總是刷新。用戶名密碼校驗需要刷新以展示錯誤提示；因下拉選擇器選擇不同而展示的內(nèi)容需要刷新才能展示；每次數(shù)據(jù)交互必然會刷新一次頁面。
網(wǎng)頁和后端邏輯混合。相信老前端們都有過這樣的經(jīng)歷：開發(fā)完HTML后，會把頁面發(fā)給后端修改，加上數(shù)據(jù)注入邏輯；聯(lián)調(diào)或者debug的時候兩個人坐在一塊看，查問題的效率很低。
有大量重復(fù)代碼無法復(fù)用。舉一個典型的例子，論壇。很多時候只有內(nèi)容有變化，菜單、側(cè)邊欄等幾乎不會有改變，但每次請求的時候還是得再將整個網(wǎng)頁傳輸一遍。不僅頁面會刷新，速度慢，還挺耗流量（這個年代上網(wǎng)也是一種奢侈）。
然后 AJAX 站了出來。
AJAX
AJAX，Async Java And XML，于 1998 年開始初步應(yīng)用，2005 年開始普及。AJAX 的廣泛使用，標志著 Web2.0 時代的開啟。這同時也是各大瀏覽器爭鋒的時代。
現(xiàn)在，我們可以通過 AJAX 來動態(tài)獲取數(shù)據(jù)，利用 DOM 操作動態(tài)更新網(wǎng)頁內(nèi)容了。來看看加入了 AJAX 的網(wǎng)頁是怎么工作的：
這個時候前端路由還沒有興起，大多數(shù)情況下還是后端返回一整個頁面，部分內(nèi)容通過 AJAX 進行獲取。
隨著智能手機的出現(xiàn)，APP 開始萌芽。相比起網(wǎng)頁，APP 編寫好之后只需要數(shù)據(jù)接口就能工作；而網(wǎng)頁不僅需要后端寫業(yè)務(wù)邏輯，控制跳轉(zhuǎn)，還要寫一部分接口用于 AJAX 請求。
這個階段前端能做的事情還是很少，還背負著“切圖仔”的綽號。隨著 HTML5 草案的提出，前端能做的交互越來越多，程序員們急需解決以下問題：
后端業(yè)務(wù)代碼和數(shù)據(jù)接口混合，還得兼容 APP 的接口（很多企業(yè)既有 APP 又有網(wǎng)站）
前端的代碼復(fù)雜度急劇增加
能不能讓前端也像 APP 一樣，只需要請求數(shù)據(jù)接口即可展現(xiàn)內(nèi)容呢？
擴展資料：第二次瀏覽器大戰(zhàn)
2004 年 Firefox 發(fā)布，拉開了第二次瀏覽器大戰(zhàn)的序幕。同期市面上誕生的各種新興瀏覽器，如 Safari、Chrome 等，也加入了戰(zhàn)爭。
此前由于 XP 系統(tǒng)實在過于火爆，導(dǎo)致 IE 6 無任何競爭對手，微軟甚至解散了瀏覽器的大部分員工，只留下幾個人象征性地維護順便修補一下 bug。這讓開發(fā)人員非常痛苦。
此時 Firefox 以優(yōu)越于 IE 的性能和非常友好的編程工具，迅速將那些被 IE6 搞得焦頭爛額的網(wǎng)頁開發(fā)人員們，從水火之中救出，導(dǎo)致先讓前端工程師成為忠實的第一批用戶，然后，經(jīng)由這些有經(jīng)驗的開發(fā)人員們推廣到了普通的用戶群體。
基于 webkit 內(nèi)核的 Safari，借助自家產(chǎn)品（iOS、MacOS）的壟斷快速收割移動端和 mac 端市場份額；同樣基于 webkit 內(nèi)核的 Chrome，趁著微軟放松警惕，憑借優(yōu)越于市場上所有瀏覽器的性能，如同中國歷史上的成吉思汗一樣大殺四方，快速擴展市場份額。
微軟知道，自己已經(jīng)失去了最初能稱霸的機會，這次它不想失去，IE 再次開始迭代，各大瀏覽器廠商又開始不顧標準，迭代再次開始，為了統(tǒng)一化標準，W3C 開發(fā)了 HTML5，但是遲遲得不到微軟的認可。在其他瀏覽器紛紛支持 HTML5 后，微軟發(fā)現(xiàn)，自己又成了孤家寡人，份額不斷縮水。
2016 年，Chrome 瀏覽器份額超越 IE，第二次瀏覽器大戰(zhàn)結(jié)束。
瀏覽器大戰(zhàn)極大的推動了技術(shù)進步，正是 Google 研發(fā)出的 V8 引擎極大的提升了 JS 的運行效率，NodeJS 才有機會誕生，前端才能走向全棧。 JS 其實沒有你想象的那么慢。
SPA
2008 年 HTML5 草案提出，各大瀏覽器開啟良性競爭，爭先實現(xiàn) HTML5 功能。由于 HTML5 帶來前端 代碼復(fù)雜度的增加，前端為了尋求良好的可維護性和可復(fù)用性，也不得不參考后端 MVC 進行了設(shè)計和拆分，后來出現(xiàn)了三大前端框架：Vue（2014）、React（2010）、AngularJS（2009）。
單頁應(yīng)用返回一個空白的 HTML，并通過 JS 腳本進行動態(tài)生成內(nèi)容，從此和頁面刷新說拜拜。
后端不再負責(zé)模板渲染，前端和 APP 開始對等，后端的 API 也可以通用化了。 前后端終于得以分離。（PS：最終目標是成為后端）
但 SPA 因為返回的是空 HTML，所有 JS 也被打包為一個文件，需要在一開始就加載完所有的資源，
請求網(wǎng)頁后 白屏?xí)r間比傳統(tǒng)網(wǎng)頁要長
爬蟲爬到的是空白頁面， 沒辦法做 SEO
在業(yè)務(wù)復(fù)雜的情況下， 請求文件很大，渲染非常慢。
這使得前端不得不拆分過于龐大的單頁應(yīng)用，出現(xiàn)了框架的多頁面概念，也出現(xiàn)了多種解決方案。
很多網(wǎng)頁首次加載的時候其實并不需要太多的東西，比如論壇首頁與貼子詳情頁，完全可以將其拆開，用戶在新打開的頁面閱讀反而體驗更好（ 多頁應(yīng)用）。
又比如管理后臺，可以在頁面框架內(nèi)，將每個菜單對應(yīng)的管理頁拆出來 動態(tài)加載（import）。
Server Side Render
Server Side Render，服務(wù)端渲染，簡稱 SSR，又稱服務(wù)端同構(gòu)、直出，一般使用 NodeJS 實現(xiàn)。
這里的服務(wù)端渲染和以前的不一樣，SSR 會利用已經(jīng)“脫水”的首屏數(shù)據(jù)來渲染首屏頁面返回給客戶端，到了瀏覽器再注入瀏覽器事件，并且保留單頁應(yīng)用的能力，對 SEO 非常友好。但學(xué)習(xí)成本高，限制較多。
讓我們看看傳統(tǒng) SPA 和加入了 SSR 的 SPA 在請求上的區(qū)別：
客戶端渲染示意
服務(wù)端渲染示意
傳統(tǒng) SPA 可以更快的返回頁面，請求響應(yīng)時間更短；加載 JS 后才開始渲染，白屏?xí)r間更長，loading 結(jié)束后用戶感知到的相對可交互時間更早。
而 SSR 在接到瀏覽器請求時，先從后端拉取首屏數(shù)據(jù)渲染在頁面內(nèi)才返回，請求響應(yīng)時間更長；因為節(jié)約了一段瀏覽器請求首屏數(shù)據(jù)的時間，白屏?xí)r間更短。由于 JS 異步加載，用戶感知的相對可交互時間變晚。但體驗上 SSR 一般更好。
在極端情況下，用戶眼中傳統(tǒng) SPA 會一直顯示 loading，使用了 SSR 的頁面則會出現(xiàn)“點不動”的情況。
大多數(shù)時候 SSR 體驗會更佳，因為服務(wù)端承擔(dān)了大部分渲染工作，這也導(dǎo)致服務(wù)端負載變高。但在業(yè)務(wù)復(fù)雜的情況下，SSR 首屏請求的接口數(shù)很多，導(dǎo)致返回 HTML 變慢。
歸根結(jié)底，SSR 不能很好的應(yīng)付業(yè)務(wù)復(fù)雜的情況，首屏 要加載的東西還是太多了。所以我們要怎樣讓用戶感知到的白屏?xí)r間變短呢？
減小加載體積
減少接口請求數(shù)
PWA 緩存
分塊渲染
…
說完了 SSR，必須說一下 NodeJS。2010 年 NodeJS 正式立項到現(xiàn)在已經(jīng) 11 個年頭了，NodeJS 的誕生來自于 Ryan Dahl（下圖） 的靈感。他想 以非阻塞的方式做所有事情，用完全異步方式可以處理非常多的請求（高并發(fā)）。
NodeJS 的出現(xiàn)讓前端向全棧的發(fā)展邁出了重大的一步。很多公司開始用 NodeJS 搞 BFF（backend for frontend），我們也開始把 Controller 層放到 NodeJS 來處理，后端只負責(zé)基礎(chǔ)業(yè)務(wù)數(shù)據(jù)。也就是現(xiàn)在的三層架構(gòu)：
這種架構(gòu)在跨端的時候具有良好的適配性，我們可以根據(jù)業(yè)務(wù)需求，為不同端設(shè)計不同的 Controller 和 View，而后臺可以不做變更。這種架構(gòu)省去了很多溝通成本，前端專注頁面的展示，后端專注業(yè)務(wù)邏輯。
當(dāng)然，NodeJS 還可以對后端數(shù)據(jù)進行預(yù)處理，前端根據(jù)自己的需要自己設(shè)計數(shù)據(jù)結(jié)構(gòu)， 頁面開發(fā)與接口調(diào)試形成閉環(huán)，還為后端分擔(dān)了壓力。
擴展資料：第三次瀏覽器大戰(zhàn)
智能手機的飛速發(fā)展，這張圖表現(xiàn)的淋漓盡致。第三次瀏覽器大戰(zhàn)是爭奪移動端市場份額的一戰(zhàn)，也是當(dāng)下正在進行的一戰(zhàn)。
Benedict Evans: “Mobile is eating the world.”（移動設(shè)備正在蠶食世界） “Mobile remakes the Internet.”（移動設(shè)備正在重構(gòu)Internet）
而未來，瀏覽器真正的對手不再是瀏覽器，而是小程序這樣結(jié)合了APP和網(wǎng)頁優(yōu)點的新興技術(shù)。
未來
早在 2009 年，F(xiàn)acebook 的工程師就開發(fā)了 bigPipe，讓 Facebook 頁面打開速度提高了兩倍。bigPipe 使用 分塊渲染的思想，將網(wǎng)頁的渲染變成了一小塊一小塊的，服務(wù)端渲染好一塊頁面就發(fā)送給客戶端。他們直接把木桶拆了，打破了 短板效應(yīng)。
服務(wù)端渲染 VS 流式分塊渲染
時隔 11 年，也就是 2020 年 12 月，React 團隊提出了 React Server Components，算是一個可擴展的前后端融合方案。其理念和 bigPipe 類似，把組件放在服務(wù)端渲染，節(jié)省了從瀏覽器進行數(shù)據(jù)請求的開支，一些運行時也可以不用放到瀏覽器，減小了包大?。ㄈ?markdown 在服務(wù)端渲染好了，也就不再需要把工具庫發(fā)送給瀏覽器了）。React Server Components 的引入，也同步做到了自動的 Code Split。
React Server Components 原理
不同的是 React Server Components 返回的不是 HTML，而是帶有結(jié)構(gòu)和數(shù)據(jù)的自定義類 JSON 數(shù)據(jù)。
這種結(jié)構(gòu)，是對服務(wù)端渲染的核心（結(jié)構(gòu)+數(shù)據(jù)）進行抽象，結(jié)合 React 的工作方式（如 Suspense），平緩的從服務(wù)端過渡到了客戶端，維持了組件狀態(tài)，并且可以更自由的拼裝服務(wù)器組件和客戶端組件。
客戶端組件和服務(wù)端組件混用
關(guān)于拆分這條思路，讓我想到微前端，雖然現(xiàn)在微前端還有很多問題，但微應(yīng)用即服務(wù)也不乏為一條解決之道。未來前端或許會往“小而美”的方向發(fā)展，甚至形成一個以服務(wù)端組件為單位的包管理器，網(wǎng)頁打包大小會越來越小，更多的組件是從網(wǎng)絡(luò)上直接獲取。
此外，我也很期待 Web Components 的發(fā)展，有了原生的支持，0kb runtime 也不是不可能了。合久必分分久必合，現(xiàn)存很多前端框架也可以得到統(tǒng)一了。當(dāng)然現(xiàn)在 Web Components 想要投入使用，首先離不開瀏覽器的支持，而且必須有一個平緩的過渡，此外兼容性也是一個大問題（最后還是苦了程序員們）。
本文首發(fā)公眾號：騰訊技術(shù)工程（ID：Tencent_TEG）
