Web開發的歷史發展技術演變

簡介： 本文對Web開發的歷史發展的瞭解頗有裨益，推薦給你們。本文嘗試從歷史發展角度，說說各類研發模式的優劣。 1、簡單明快的早期時代，2、後端爲主的 MVC 時代，3、Ajax 帶來的 SPA 時代，4、前端爲主的 MV* 時代，5、Node 帶來的全棧時代

本文對Web開發的歷史發展的瞭解頗有裨益，推薦給你們。

本文嘗試從歷史發展角度，說說各類研發模式的優劣。

1、簡單明快的早期時代

可稱之爲 Web 1.0 時代，很是適合創業型小項目，不分先後端，常常 3-5 人搞定全部開發。頁面由 JSP、PHP 等工程師在服務端生成，瀏覽器負責展示。基本上是服務端給什麼瀏覽器就展示什麼，展示的控制在 Web Server 層。

這種模式的好處是：簡單明快，本地起一個 Tomcat 或 Apache 就能開發，調試什麼的都還好，只要業務不太複雜。

然而業務總會變複雜，這是好事情，不然極可能就意味着創業失敗了。業務的複雜會讓 Service 愈來愈多，參與開發的人員也極可能從幾我的快速擴招到幾十人。在這種狀況下，會遇到一些典型問題：

一、Service 愈來愈多，調用關係變複雜，前端搭建本地環境再也不是一件簡單的事。考慮團隊協做，每每會考慮搭建集中式的開發服務器來解決。這種解決方案對編譯型的後端開發來講也許還好，但對前端開發來講並不友好。天哪，我只是想調整下按鈕樣式，卻要本地開發、代碼上傳、驗證生效等好幾個步驟。也許習慣了也還好，但開發服務器老是不那麼穩定，出問題時每每須要依賴後端開發搞定。看似僅僅是前端開發難以本地化，但這對研發效率的影響其實蠻大。

二、JSP 等代碼的可維護性愈來愈差。JSP 很是強大，能夠內嵌 Java 代碼。這種強大使得先後端的職責不清晰，JSP 變成了一個灰色地帶。常常爲了趕項目，爲了各類緊急需求，會在 JSP 裏揉雜大量業務代碼。積攢到必定階段時，每每會帶來大量維護成本。

這個時期，爲了提升可維護性，能夠經過下面的方式實現前端的組件化：

理論上，若是你們都能按照最佳實踐去書寫代碼，那麼不管是 JSP 仍是 PHP，可維護性都不會差。但可維護性更可能是工程含義，有時候須要經過限制帶來自由，須要某種約定，使得即使是新手也不會寫出太糟糕的代碼。

如何讓先後端分工更合理高效，如何提升代碼的可維護性，在 Web 開發中很重要。下面咱們繼續來看，技術架構的演變如何解決這兩個問題。

2、後端爲主的 MVC 時代
爲了下降複雜度，之後端爲出發點，有了 Web Server 層的架構升級，好比 Structs、Spring MVC 等，這是後端的 MVC 時代。

代碼可維護性獲得明顯好轉，MVC 是個很是好的協做模式，從架構層面讓開發者懂得什麼代碼應該寫在什麼地方。爲了讓 View 層更簡單幹脆，還能夠選擇 Velocity、Freemaker 等模板，使得模板裏寫不了 Java 代碼。看起來是功能變弱了，但正是這種限制使得先後端分工更清晰。然而依舊並非那麼清晰，這個階段的典型問題是：

一、前端開發重度依賴開發環境。這種架構下，先後端協做有兩種模式：一種是前端寫 demo，寫好後，讓後端去套模板。淘寶早期包括如今依舊有大量業務線是這種模式。好處很明顯，demo 能夠本地開發，很高效。不足是還須要後端套模板，有可能套錯，套完後還須要前端肯定，來回溝通調整的成本比較大。另外一種協做模式是前端負責瀏覽器端的全部開發和服務器端的 View 層模板開發，支付寶是這種模式。好處是 UI 相關的代碼都是前端去寫就好，後端不用太關注，不足就是前端開發重度綁定後端環境，環境成爲影響前端開發效率的重要因素。

二、先後端職責依舊糾纏不清。Velocity 模板仍是蠻強大的，變量、邏輯、宏等特性，依舊能夠經過拿到的上下文變量來實現各類業務邏輯。這樣，只要前端弱勢一點，每每就會被後端要求在模板層寫出很多業務代碼。還有一個很大的灰色地帶是 Controller，頁面路由等功能本應該是前端最關注的，但倒是由後端來實現。Controller 自己與 Model 每每也會糾纏不清，看了讓人咬牙的代碼常常會出如今 Controller 層。這些問題不能全歸結於程序員的素養，不然 JSP 就夠了。

常常會有人吐槽 Java，但 Java 在工程化開發方面真的作了大量思考和架構嘗試。Java 蠻符合馬雲的一句話：讓平凡人作非凡事。

3、Ajax 帶來的 SPA 時代
歷史滾滾往前，2004 年 Gmail 像風同樣的女子來到人間，很快 2005 年 Ajax 正式提出，加上 CDN 開始大量用於靜態資源存儲，因而出現了 JavaScript 王者歸來的 SPA （Single Page Application 單頁面應用）時代。

這種模式下，先後端的分工很是清晰，先後端的關鍵協做點是 Ajax 接口。看起來是如此美妙，但回過頭來看看的話，這與 JSP 時代區別不大。複雜度從服務端的 JSP 裏移到了瀏覽器的 JavaScript，瀏覽器端變得很複雜。相似 Spring MVC，這個時代開始出現瀏覽器端的分層架構：

對於 SPA 應用，有幾個很重要的挑戰：

一、先後端接口的約定。若是後端的接口一塌糊塗，若是後端的業務模型不夠穩定，那麼前端開發會很痛苦。這一塊在業界有 API Blueprint 等方案來約定和沉澱接口，在阿里，很多團隊也有相似嘗試，經過接口規則、接口平臺等方式來作。有了和後端一塊兒沉澱的接口規則，還能夠用來模擬數據，使得先後端能夠在約定接口後實現高效並行開發。相信這一塊會越作越好。

二、前端開發的複雜度控制。SPA 應用大多以功能交互型爲主，JavaScript 代碼過十萬行很正常。大量 JS 代碼的組織，與 View 層的綁定等，都不是容易的事情。典型的解決方案是業界的 Backbone，但 Backbone 作的事還頗有限，依舊存在大量空白區域須要挑戰。

SPA 讓前端看到了一絲綠色，但依舊是在荒漠中行走。

4、前端爲主的 MV* 時代
爲了下降前端開發複雜度，除了 Backbone，還有大量框架涌現，好比 EmberJS、KnockoutJS、AngularJS 等等。這些框架總的原則是先按類型分層，好比 Templates、Controllers、Models，而後再在層內作切分，以下圖：

好處很明顯：

一、先後端職責很清晰。前端工做在瀏覽器端，後端工做在服務端。清晰的分工，可讓開發並行，測試數據的模擬不難，前端能夠本地開發。後端則能夠專一於業務邏輯的處理，輸出 RESTful 等接口。

二、前端開發的複雜度可控。前端代碼很重，但合理的分層，讓前端代碼能各司其職。這一塊蠻有意思的，簡單如模板特性的選擇，就有不少不少講究。並不是越強大越好，限制什麼，留下哪些自由，代碼應該如何組織，全部這一切設計，得花一本的厚度去說明。

三、部署相對獨立，產品體驗能夠快速改進。

但依舊有不足之處：

代碼不能複用。好比後端依舊須要對數據作各類校驗，校驗邏輯沒法複用瀏覽器端的代碼。若是能夠複用，那麼後端的數據校驗能夠相對簡單化。
全異步，對 SEO 不利。每每還須要服務端作同步渲染的降級方案。
性能並不是最佳，特別是移動互聯網環境下。
SPA 不能知足全部需求，依舊存在大量多頁面應用。URL Design 須要後端配合，前端沒法徹底掌控。
5、Node 帶來的全棧時代
前端爲主的 MV* 模式解決了不少不少問題，但如上所述，依舊存在很多不足之處。隨着 Node.js 的興起，JavaScript 開始有能力運行在服務端。這意味着能夠有一種新的研發模式：

在這種研發模式下，先後端的職責很清晰。對前端來講，兩個 UI 層各司其職：

一、Front-end UI layer 處理瀏覽器層的展示邏輯。經過 CSS 渲染樣式，經過 JavaScript 添加交互功能，HTML 的生成也能夠放在這層，具體看應用場景。

二、Back-end UI layer 處理路由、模板、數據獲取、cookie 等。經過路由，前端終於能夠自主把控 URL Design，這樣不管是單頁面應用仍是多頁面應用，前端均可以自由調控。後端也終於能夠擺脫對展示的強關注，轉而能夠專心於業務邏輯層的開發。

經過 Node，Web Server 層也是 JavaScript 代碼，這意味着部分代碼可先後複用，須要 SEO 的場景能夠在服務端同步渲染，因爲異步請求太多致使的性能問題也能夠經過服務端來緩解。前一種模式的不足，經過這種模式幾乎都能完美解決掉。

與 JSP 模式相比，全棧模式看起來是一種迴歸，也的確是一種向原始開發模式的迴歸，不過是一種螺旋上升式的迴歸。

基於 Node 的全棧模式，依舊面臨不少挑戰：

須要前端對服務端編程有更進一步的認識。好比 network/tcp、PE 等知識的掌握。
Node 層與 Java 層的高效通訊。Node 模式下，都在服務器端，RESTful HTTP 通訊未必高效，經過 SOAP 等方式通訊更高效。一切須要在驗證中前行。
對部署、運維層面的熟練了解，須要更多知識點和實操經驗。
大量歷史遺留問題如何過渡。這多是最大最大的阻力。
6、小結
回顧歷史老是讓人感慨，展望將來則讓人興奮。上面講到的研發模式，除了最後一種還在探索期，其餘各類在各大公司都已有大量實踐。幾點小結：

模式沒有好壞高下之分，只有合不合適。 Ajax 給前端開發帶來了一次質的飛躍，Node 極可能是第二次。 SoC（關注度分離） 是一條偉大的原則。上面種種模式，都是讓先後端的職責更清晰，分工更合理高效。 還有個原則，讓合適的人作合適的事。好比 Web Server 層的 UI Layer 開發，前端是更合適的人選。