一、何為電商

所謂電商，即電子商務，就是指通過使用電子類工具，圍繞著商品交易進行的一系列活動。既然是交易，那就離不開交易的三個過程。

交易的第一個過程，就是商品信息的交換，賣方通過一定的渠道讓商品信息擴散出去，而買方也通過一些方式能夠獲取到這些商品信息。無論是集市上的吆喝，還是店鋪門口的廣告，亦或是當今電商網站的網址，做的事本質上都是一樣的，就是傳達交易的信息。

交易的第二個過程，就是協議的達成，這個階段里買賣雙方通過談判來確定商品的質量、數量和價錢，當然最核心的內容也還是價錢。這個過程在傳統的交易過程中有可能會佔用一些時間用來討價還價，但是放在電子商務里，這個過程一般都比較短暫，甚至由於明碼標價，這個過程都可以省略。

交易的最後一個過程，就是我們交易達成的階段，我們經過上一階段的協商，如果能夠達成一個雙方都認同的結果，那麼接下來就是要進行交換了，這裡大部分是以錢異物，當然也不排除有以物易物的可能。

我們這篇文章，就是要借著電商的發展過程中，結合交易的三部曲，來聊一聊相應前端技術都有了哪些發展。

二、互聯網出現以前

電商的出現會比互聯網來的更早，那個年代雖然已經有了計算機，但對交易過程有更大幫助的卻是出現比較早的電話、傳真等電子工具。電子商務這個事最最核心的東西就是信息的交換，在沒有互聯網的年代，計算機還沒有傳達信息的能力，只能用做計算和存儲數據的介質。

這個年代的電子商務是很有限制的，第一個限制來自於通信的成本，當時電話和傳真都很少民用，費用也比較高，所以電子商務絕大部分是以公對公的形式存在。而第二個限制來自於通信的方式，無論電話還是傳真所做的數據通信都是1對1的，這也就意味著如果你想達成交易，那麼就要先找到交易對手，當時的電子設備並不能對尋找交易夥伴有太大的幫助。

在這個沒有互聯網的時代，web和瀏覽器都還沒出現，web前端也就更不會有了。

三、刀耕火種的年代

1994年中國被批准加入互聯網，經過一年多的研究測試階段，在1995年，中國的互聯網終於走向了民間，這個互聯網發展中的里程碑，也可以算作是電商發展中一個關鍵的時間節點。隨著互聯網出現的還有電子郵件和瀏覽器，這兩種工具的配合，使得電子商務變得成本更低，效果更好。同時也因為互聯網的民用，電子商務的市場獲得了一次爆炸性的增長。當然這個時候的爆炸可能也就是從100人的規模增長到1萬人規模的樣子，和現在的電商市場規模還是沒法比的。

這個年代最重要的事件是瀏覽器的出現，也標誌著web開始發展。在電子商務發展的前期，web技術也只是停留在信息的展示上。更多的公司的網站，也只是用來作為商品信息的載體，然後在網站上放上聯繫方式，線下完成交易。這種初級的電商能夠支持商品交易的第一個過程，也就是商品信息的交換，但最終不能在線完成整個交易過程。無法達成全程電子商務的原因有兩個，一個是業務上的原因，當時的在線交易里存在陌生人間交易的信任問題，是先交錢還是先發貨，是一個很容易進入死循環的話題；第二是技術問題，當時的互聯網技術有限，通過ASP、JSP這類模板語言加上簡單的javascript來做一套完整的交易網站，難度還是比較大的。

這個時代里，也沒有所謂的前端分支，頁面里簡單的js語言也就是用來做一下表單驗證之類的最簡單的事情，當時的開發人員也就隨手寫上了。

四、全程電子商務時代

在全程電子商務時代之前，因為信息的傳達已經沒有問題，當時的物流也發展了很多年，所以想要完成電子商務的整個流程，最大的困難就是我們上一章提到的交易的信用問題。

2003年，阿里巴巴公司發布了一款可以算是電商發展過程中里程碑般的產品——支付寶。這個產品最大的意義就是解決了陌生人間交易的信用問題，支付寶通過把買家付款和賣家收款這兩個事拆分開來，在中間做了一層代理。買家先把錢支付給支付寶，然後賣家發貨，當貨物抵達買家。在這個交易模型下，用戶僅需要信任支付寶就可以完成交易，當然這個信任也不是一下就建立起來的，總會有人擔心，我把錢給了支付寶，他們拿錢跑了怎麼辦。但經過一部分敢於信任的人的嘗試，這個顧慮一點點消失，用戶對支付寶的信任感也一點點增強。信任問題解決以後，整個電商流程就變得順暢了，這樣電子商務就進入了全程電子商務時代，這個時代一直持續到現在。

而隨著交易流程的打通，從技術角度來說，電商系統的需求就變得複雜了，純靠當時像ASP、JSP這些模板語言寫一個交易網站，程序猿們還是很痛苦的。於是，從這個時候開始，在業務的壓迫下，技術也開始進入一個高速發展期。而我們前端的技術分支也開始了從無到有，再到豐富的過程。

當然，我們心裡也要有一個概念，那就是技術是工具，它始終要為業務服務的。每一種技術能夠發展成熟，肯定是它在業務的某個發展時期解決了一些比較重要的問題，這才能讓這種技術得到認可和普及。全程電子商務時代才是前端這個技術分支發展的主要時期，下來我們聊一下這些年電商發展過程中遇到了什麼問題？伴隨著這些問題的解決，前端技術又都發生了什麼樣的變化？

4.1 Ajax的應用

最先要說的就是Ajax的出現，在其出現的時期，這個東西絕對是web開發的一大福音。舉個例子，設想一下如果沒有非同步通信的時候，我們填寫了一個有20個輸入框的表單，又一個個檢查了一遍以後，終於有勇氣點了一下提交按鈕。但是！這時候返回的是一個錯誤頁面，「對不起，您的名字已存在！」。這樣我們就又要去重新填那20個欄位了，我們還要祈禱著第二次就都能填正確。但是ajax出現後，這就大不一樣了，我們可以隨時在當前頁面和後端做一個驗證，來保證只要不是後端出了問題，我們提交過去的值都是合法的。

Ajax這個名稱是2005年才有的，在這之前各家瀏覽器廠商就已經各自用自己的方式實現了非同步通訊的機制，這也就有了另外一個問題，兼容性！每個瀏覽器對Ajax的實現都不一樣，但每一個瀏覽器都有一定的市場份額，這就有點難為程序猿了，尤其當時只把js當做簡單的腳本語言的開發人員來說，一下子多了這麼多的瀏覽器要去兼容，簡直是災難！這個問題的解決是從兩方面來進行的，第一個是在2006年，W3C終於將Ajax納入其標準，這就意味著以後的瀏覽器都要按著統一的方法來實現Ajax。但標準歸標準，等標準全部實現還是需要時間的，為了解決當下的問題，就有人或組織封裝了一些兼容各種Ajax實現的類庫。其中最為有名的就是jQuery，它除了Ajax外，還抹平了其他例如Dom操作等方法的兼容性問題，一度成為最流行的前端類庫。

4.2 前後端的劃分和分離

Ajax的出現，也帶來了另外一個問題，那就是有了Ajax以後，之前用模板語言實現起來的功能變得簡單，之前模板語言實現不了的功能現在也能實現了。這樣就造成越來越多的邏輯轉移到了javascript上，使其變得越來越複雜。

隨著js複雜度的增長，原來的開發模式出現了問題，一個程序猿搞定全站變得越來越不靠譜，因此在這個時候就把網站開發這個職位劃分成了前端和後端兩個職位。但是只劃分了前後端的職責範圍還是遠遠不夠的，我們在原來的開發模式下，前後端的代碼也在一起的。現在既然已經分為前後端兩波人在開發了，維護同一套代碼就變得不那麼方便。項目越複雜，出現你等我，我等你的情況就會越來越多，這樣就拖慢了整體團隊的節奏。所以為了團隊的效率，前後端的代碼也要做分離。

前後端的分離方式分為部分分離和全部分離兩種，部分分離是只把腳本和樣式分離出去，而html模板還留在後端通過jsp，velocity或者freemarker來渲染；另一種就是完全分離，腳本樣式以及模板全都放在前端來維護。

部分分離已經很大程度上解決了前後端開發時的協調問題，開發效率也得到了很大程度的提升。但也得承認，這種方式也還是有問題的。當我們要開發html模板的時候，就需要搭起一整套後端的開發環境，或者是找後端同學來協助。

而完全分離一般有兩種方案，第一種就是使用velocity這種在nodejs和java下都可以編譯的頁面模板，在開發時放到前端項目里，但在發布時，會把模板發布到後端的模板目錄下，這樣，開發時就做到了完全分離。這種方式最大的好處就是線上模板的渲染還是由java來做的，形成的是帶有動態數據的html，比較有利於SEO。但這種方式下，前端的開發環境和發布系統的複雜度都相對較高，單純的前端改動也還是要帶著後端一起發布。

第二種完全分離的方式，就是把純靜態的html模板完全放在前端，數據全部通過RESTful介面來進行交互。這樣前後端就完全分開了，脫離了後端的模板，而這種方式的系統複雜度也會比第一種完全分離的方式低。但這種方案下，所有的頁面數據都是用js渲染的，沒有動態模板，不太利於SEO。這個不足我們可以通過做server render或者給蜘蛛做一套定製頁面來解決。

4.3 分層架構的出現

隨著業務進一步的複雜，我們又開始考慮怎麼讓一個複雜系統變得可維護，這時候就體現出一個網站架構的作用了。因為後端比前端發展的要早，分層架構這個概念在後端的發展過程中就已經有了，我們最常見的就是MVC結構。這個時候前端也發展到一定的程度上了，也是需要分層架構來讓代碼變得更加可維護。

分層設計最大的意義就是解耦，如果我們的系統中的各層之間是鬆散耦合的，當我們要改變其中一個層級的時候，只要保證該層級的介面不變即可，裡面的實現方式可以隨意變動。其他經常提到的優點，比如易維護、易復用、易擴展，其實說的也都是一個意思。在前端的分層方式上，和後端並不太一樣，所以後端的MVC模式並不能完全搬到前端來。前端的分層設計在MVC的基礎上又做了進一步的演進，形成了更適合前端的MVV*等方式的分層，來支持前端的邏輯。

4.4 模塊化來了

分層架構有一定的解耦效果，但是遇到複雜業務，所有的邏輯就分成三大塊顯然也是不夠的，並且基於javascript語言的特性，如果我們沒有對全局變數做管理，變數衝突也是無法避免的。因此我們就有了模塊化的處理方案。

由於前端的發展一直處於百花齊放，百家爭鳴的狀態， 所以在每一種技術或者方案的發展過程中基本都會出現幾個分支。我們的模塊化方案也未能免俗。模塊化中比較有代表性的就是AMD、CMD、CommonJS和es6模塊化這幾種方案。

AMD 是 RequireJS 在推廣過程中的規範化產出，而CMD 是 SeaJS 在推廣過程中的規範化產出，這兩個模塊化方案有些相似，主要的區別是載入和運行的時機不太一樣。這兩種模塊化方案是可以直接在瀏覽器上運行的，但也有個缺點，就是會將模塊化的代碼和業務代碼摻雜在一起，對於強迫症的同學來說，這並不算一個很好的方案。

而隨著nodejs的發展，我們有了對代碼做編譯的能力。這樣原本不能在瀏覽器上運行的模塊化方案，通過編譯處理以後，也能正常在瀏覽器上跑了。這種模塊化方案最具代表性的就是CommonJs的模塊化方案。由於我們是要編譯的，所以大部分處理模塊化的代碼都可以通過編譯的過程追加進去，這樣我們只用關心業務邏輯部分就可以了。當然這種方案也不是完美的，這種提前編譯打包的方案會把所有引用的代碼都打包進去，如果想按需載入就需要再做進一步的處理。總體來說，我還是比較傾向這種模塊化方案。

在模塊化方案中，還有一種被納入標準的ES6模塊化方案，理論上這種模塊化方案也是可以直接運行在瀏覽器上的，但對瀏覽器的版本要求比較高。現在也有一種方案，就是通過babel編譯，把ES6的語法轉換成大部分瀏覽器可以兼容的舊版本js的語法。但這樣的話，ES6的模塊化相對CommonJs也就沒有多大的優勢了。

五、下一個時代

互聯網行業的發展總是會受到技術的限制，有很多想做的事可能因為技術原因不能做。但另一方面，業務也總是在促進技術的發展，如果一個事的價值非常大，那麼技術通常會進化到可以搞定它的狀態。業務和技術的就是這樣一個互相促進，階梯式上升的過程。

電商的下一個時代會是什麼樣，應該沒有人能說的清。但是能看到的像大規模數據的處理、機器學習、智能化推薦和VR展示這些技術已經在路上了，有的也已經有了不錯的進展。而對於前端來說，將來也不排除會在這些領域承擔下一些責任，尤其像VR這種用於展示的技術還是很有想像空間的。

無論下一個時代會是什麼樣，但願我們始終保持一顆好奇心，能以興趣驅動的方式跟上技術變革的潮流。

轉載請註明出處，本文來自慕課網手記，原文地址：http://www.imooc.com/article/18294

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！