曆史上第一個網頁它長啥樣？？？

每日英文

Two things always to be remembered in life- don't take any decisions when you are angry & dont make any promises when you are happy! 

生活中一定要記住這兩件事:不在生氣時做決定，不在高興時輕許諾言。

每日掏心話

随欲而安的缈茫，虛空的一如既往。人生在世，面對無數的誘惑和磨難，往往不得不在舍與得之間彷徨徘徊。

程式設計技術圈(ID:study_tech)第 1302次推文

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

React Server Components 原理不同的是 React Server Components 傳回的不是 HTML，而是帶有結構和資料的自定義類JSON資料。
這種結構，是對服務端渲染的核心（結構+資料）進行抽象，結合 React 的工作方式（如Suspense），平緩的從服務端過渡到了用戶端，維持了元件狀态，并且可以更自由的拼裝伺服器元件和用戶端元件。
用戶端元件和服務端元件混用關于拆分這條思路，讓我想到微前端，雖然現在微前端還有很多問題，但微應用即服務也不乏為一條解決之道。未來前端或許會往“小而美”的方向發展，甚至形成一個以服務端元件為機關的包管理器，網頁打包大小會越來越小，更多的元件是從網絡上直接擷取。
此外，我也很期待 Web Components 的發展，有了原生的支援，0kb runtime也不是不可能了。合久必分分久必合，現存很多前端架構也可以得到統一了。當然現在 Web Components 想要投入使用，首先離不開浏覽器的支援，而且必須有一個平緩的過渡，此外相容性也是一個大問題（最後還是苦了程式員們）。
結語從 JavaScript 的誕生一路走來，從“發現問題-解決問題”的角度，我們看到了技術發展的原因和必然性。2021年的今天，Web APP 仍然距離原生 APP 體驗有一定的差距。或許以後會出現一個小程式桌面APP，小程式能夠得到統一；或許會在 PWA 的道路上越走越遠；又或者浏覽器開放更多原生系統 API，利用各種加載方式，再模拟 APP 的各種體驗，達到近似 APP 的效果。
每個時代都誕生了許多的技術，大浪淘沙，留下的卻也隻是隻存在于這個時代的王者。技術總是不斷的更疊，重要的不是慌慌張張的追趕技術的腳步，而是去思考技術為什麼這麼如此演變，思考這樣的演變方式的利與弊。如果是你，又會怎麼解決當代技術的問題呢？
歡迎在評論區各抒己見。
你還有什麼想要補充的嗎？
PS：歡迎在留言區留下你的觀點，一起讨論提高。如果今天的文章讓你有新的啟發，歡迎轉發分享給更多人。

版權申明：内容來源網絡，版權歸原創者所有。除非無法确認，我們都會标明作者及出處，如有侵權煩請告知，我們會立即删除并表示歉意。謝謝!


猜你還想看
阿裡、騰訊、百度、華為、京東最新面試題彙集
消息幂等（去重）通用解決方案，真頂！

沒想到《天龍八部》這段，隻有搞IT的才懂

一架無人機就恢複河南災區50km²通信！“翼龍”成功助小鎮通網5小時

嘿，你在看嗎？