一遍膜、何為電商

所謂電商碗硬，即電子商務(wù)，就是指通過使用電子類工具瓢颅，圍繞著商品交易進行的一系列活動恩尾。既然是交易，那就離不開交易的三個過程挽懦。

交易的第一個過程翰意，就是商品信息的交換，賣方通過一定的渠道讓商品信息擴散出去信柿，而買方也通過一些方式能夠獲取到這些商品信息冀偶。無論是集市上的吆喝，還是店鋪門口的廣告渔嚷，亦或是當(dāng)今電商網(wǎng)站的網(wǎng)址进鸠，做的事本質(zhì)上都是一樣的，就是傳達交易的信息形病。

交易的第二個過程客年，就是協(xié)議的達成，這個階段里買賣雙方通過談判來確定商品的質(zhì)量漠吻、數(shù)量和價錢量瓜，當(dāng)然最核心的內(nèi)容也還是價錢。這個過程在傳統(tǒng)的交易過程中有可能會占用一些時間用來討價還價途乃，但是放在電子商務(wù)里绍傲，這個過程一般都比較短暫，甚至由于明碼標(biāo)價欺劳，這個過程都可以省略唧取。

交易的最后一個過程铅鲤，就是我們交易達成的階段，我們經(jīng)過上一階段的協(xié)商枫弟，如果能夠達成一個雙方都認同的結(jié)果邢享，那么接下來就是要進行交換了，這里大部分是以錢異物淡诗，當(dāng)然也不排除有以物易物的可能骇塘。

我們這篇文章，就是要借著電商的發(fā)展過程中韩容，結(jié)合交易的三部曲款违，來聊一聊相應(yīng)前端技術(shù)都有了哪些發(fā)展。

二群凶、互聯(lián)網(wǎng)出現(xiàn)以前

電商的出現(xiàn)會比互聯(lián)網(wǎng)來的更早插爹，那個年代雖然已經(jīng)有了計算機，但對交易過程有更大幫助的卻是出現(xiàn)比較早的電話请梢、傳真等電子工具赠尾。電子商務(wù)這個事最最核心的東西就是信息的交換，在沒有互聯(lián)網(wǎng)的年代毅弧，計算機還沒有傳達信息的能力气嫁，只能用做計算和存儲數(shù)據(jù)的介質(zhì)。

這個年代的電子商務(wù)是很有限制的够坐，第一個限制來自于通信的成本寸宵，當(dāng)時電話和傳真都很少民用，費用也比較高元咙，所以電子商務(wù)絕大部分是以公對公的形式存在梯影。而第二個限制來自于通信的方式，無論電話還是傳真所做的數(shù)據(jù)通信都是1對1的蛾坯，這也就意味著如果你想達成交易光酣，那么就要先找到交易對手，當(dāng)時的電子設(shè)備并不能對尋找交易伙伴有太大的幫助脉课。

在這個沒有互聯(lián)網(wǎng)的時代救军，web和瀏覽器都還沒出現(xiàn)，web前端也就更不會有了倘零。

三唱遭、刀耕火種的年代

1994年中國被批準加入互聯(lián)網(wǎng)，經(jīng)過一年多的研究測試階段呈驶，在1995年拷泽，中國的互聯(lián)網(wǎng)終于走向了民間，這個互聯(lián)網(wǎng)發(fā)展中的里程碑，也可以算作是電商發(fā)展中一個關(guān)鍵的時間節(jié)點司致。隨著互聯(lián)網(wǎng)出現(xiàn)的還有電子郵件和瀏覽器拆吆，這兩種工具的配合，使得電子商務(wù)變得成本更低脂矫，效果更好枣耀。同時也因為互聯(lián)網(wǎng)的民用，電子商務(wù)的市場獲得了一次爆炸性的增長庭再。當(dāng)然這個時候的爆炸可能也就是從100人的規(guī)模增長到1萬人規(guī)模的樣子捞奕，和現(xiàn)在的電商市場規(guī)模還是沒法比的。

這個年代最重要的事件是瀏覽器的出現(xiàn)拄轻，也標(biāo)志著web開始發(fā)展颅围。在電子商務(wù)發(fā)展的前期，web技術(shù)也只是停留在信息的展示上恨搓。更多的公司的網(wǎng)站院促，也只是用來作為商品信息的載體，然后在網(wǎng)站上放上聯(lián)系方式奶卓，線下完成交易一疯。這種初級的電商能夠支持商品交易的第一個過程，也就是商品信息的交換夺姑，但最終不能在線完成整個交易過程。無法達成全程電子商務(wù)的原因有兩個掌猛，一個是業(yè)務(wù)上的原因盏浙，當(dāng)時的在線交易里存在陌生人間交易的信任問題，是先交錢還是先發(fā)貨荔茬，是一個很容易進入死循環(huán)的話題废膘；第二是技術(shù)問題，當(dāng)時的互聯(lián)網(wǎng)技術(shù)有限慕蔚，通過ASP丐黄、JSP這類模板語言加上簡單的javascript來做一套完整的交易網(wǎng)站，難度還是比較大的孔飒。

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

四、全程電子商務(wù)時代

在全程電子商務(wù)時代之前鸠匀，因為信息的傳達已經(jīng)沒有問題蕉斜，當(dāng)時的物流也發(fā)展了很多年，所以想要完成電子商務(wù)的整個流程，最大的困難就是我們上一章提到的交易的信用問題宅此。

2003年机错，阿里巴巴公司發(fā)布了一款可以算是電商發(fā)展過程中里程碑般的產(chǎn)品——支付寶。這個產(chǎn)品最大的意義就是解決了陌生人間交易的信用問題父腕，支付寶通過把買家付款和賣家收款這兩個事拆分開來弱匪，在中間做了一層代理。買家先把錢支付給支付寶侣诵，然后賣家發(fā)貨痢法，當(dāng)貨物抵達買家。在這個交易模型下杜顺，用戶僅需要信任支付寶就可以完成交易财搁，當(dāng)然這個信任也不是一下就建立起來的，總會有人擔(dān)心躬络，我把錢給了支付寶尖奔，他們拿錢跑了怎么辦。但經(jīng)過一部分敢于信任的人的嘗試穷当，這個顧慮一點點消失提茁，用戶對支付寶的信任感也一點點增強。信任問題解決以后馁菜，整個電商流程就變得順暢了茴扁，這樣電子商務(wù)就進入了全程電子商務(wù)時代，這個時代一直持續(xù)到現(xiàn)在汪疮。

而隨著交易流程的打通峭火，從技術(shù)角度來說，電商系統(tǒng)的需求就變得復(fù)雜了智嚷，純靠當(dāng)時像ASP卖丸、JSP這些模板語言寫一個交易網(wǎng)站，程序猿們還是很痛苦的盏道。于是稍浆，從這個時候開始，在業(yè)務(wù)的壓迫下猜嘱，技術(shù)也開始進入一個高速發(fā)展期衅枫。而我們前端的技術(shù)分支也開始了從無到有，再到豐富的過程泉坐。

當(dāng)然为鳄，我們心里也要有一個概念，那就是技術(shù)是工具腕让，它始終要為業(yè)務(wù)服務(wù)的孤钦。每一種技術(shù)能夠發(fā)展成熟歧斟，肯定是它在業(yè)務(wù)的某個發(fā)展時期解決了一些比較重要的問題，這才能讓這種技術(shù)得到認可和普及偏形。全程電子商務(wù)時代才是前端這個技術(shù)分支發(fā)展的主要時期静袖，下來我們聊一下這些年電商發(fā)展過程中遇到了什么問題？伴隨著這些問題的解決俊扭，前端技術(shù)又都發(fā)生了什么樣的變化队橙？

4.1 Ajax的應(yīng)用

最先要說的就是Ajax的出現(xiàn)，在其出現(xiàn)的時期萨惑，這個東西絕對是web開發(fā)的一大福音捐康。舉個例子，設(shè)想一下如果沒有異步通信的時候庸蔼，我們填寫了一個有20個輸入框的表單解总，又一個個檢查了一遍以后，終于有勇氣點了一下提交按鈕姐仅。但是花枫！這時候返回的是一個錯誤頁面，“對不起掏膏，您的名字已存在劳翰！”。這樣我們就又要去重新填那20個字段了馒疹，我們還要祈禱著第二次就都能填正確佳簸。但是ajax出現(xiàn)后，這就大不一樣了颖变，我們可以隨時在當(dāng)前頁面和后端做一個驗證溺蕉，來保證只要不是后端出了問題，我們提交過去的值都是合法的悼做。

Ajax這個名稱是2005年才有的，在這之前各家瀏覽器廠商就已經(jīng)各自用自己的方式實現(xiàn)了異步通訊的機制哗魂，這也就有了另外一個問題肛走，兼容性！每個瀏覽器對Ajax的實現(xiàn)都不一樣录别，但每一個瀏覽器都有一定的市場份額朽色，這就有點難為程序猿了，尤其當(dāng)時只把js當(dāng)做簡單的腳本語言的開發(fā)人員來說组题，一下子多了這么多的瀏覽器要去兼容葫男，簡直是災(zāi)難！這個問題的解決是從兩方面來進行的崔列，第一個是在2006年梢褐，W3C終于將Ajax納入其標(biāo)準旺遮，這就意味著以后的瀏覽器都要按著統(tǒng)一的方法來實現(xiàn)Ajax。但標(biāo)準歸標(biāo)準盈咳，等標(biāo)準全部實現(xiàn)還是需要時間的耿眉，為了解決當(dāng)下的問題，就有人或組織封裝了一些兼容各種Ajax實現(xiàn)的類庫鱼响。其中最為有名的就是jQuery鸣剪，它除了Ajax外，還抹平了其他例如Dom操作等方法的兼容性問題丈积，一度成為最流行的前端類庫筐骇。

4.2 前后端的劃分和分離

Ajax的出現(xiàn)，也帶來了另外一個問題江滨，那就是有了Ajax以后铛纬，之前用模板語言實現(xiàn)起來的功能變得簡單，之前模板語言實現(xiàn)不了的功能現(xiàn)在也能實現(xiàn)了牙寞。這樣就造成越來越多的邏輯轉(zhuǎn)移到了javascript上饺鹃，使其變得越來越復(fù)雜。

隨著js復(fù)雜度的增長间雀，原來的開發(fā)模式出現(xiàn)了問題悔详，一個程序猿搞定全站變得越來越不靠譜，因此在這個時候就把網(wǎng)站開發(fā)這個職位劃分成了前端和后端兩個職位惹挟。但是只劃分了前后端的職責(zé)范圍還是遠遠不夠的茄螃，我們在原來的開發(fā)模式下，前后端的代碼也在一起的×猓現(xiàn)在既然已經(jīng)分為前后端兩波人在開發(fā)了归苍，維護同一套代碼就變得不那么方便。項目越復(fù)雜运怖，出現(xiàn)你等我拼弃，我等你的情況就會越來越多，這樣就拖慢了整體團隊的節(jié)奏摇展。所以為了團隊的效率吻氧，前后端的代碼也要做分離。

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

部分分離已經(jīng)很大程度上解決了前后端開發(fā)時的協(xié)調(diào)問題垄懂，開發(fā)效率也得到了很大程度的提升骑晶。但也得承認痛垛，這種方式也還是有問題的。當(dāng)我們要開發(fā)html模板的時候透罢，就需要搭起一整套后端的開發(fā)環(huán)境榜晦，或者是找后端同學(xué)來協(xié)助。

而完全分離一般有兩種方案羽圃，第一種就是使用velocity這種在nodejs和java下都可以編譯的頁面模板乾胶，在開發(fā)時放到前端項目里，但在發(fā)布時朽寞，會把模板發(fā)布到后端的模板目錄下识窿，這樣，開發(fā)時就做到了完全分離脑融。這種方式最大的好處就是線上模板的渲染還是由java來做的喻频，形成的是帶有動態(tài)數(shù)據(jù)的html，比較有利于SEO肘迎。但這種方式下甥温，前端的開發(fā)環(huán)境和發(fā)布系統(tǒng)的復(fù)雜度都相對較高，單純的前端改動也還是要帶著后端一起發(fā)布妓布。

第二種完全分離的方式姻蚓，就是把純靜態(tài)的html模板完全放在前端，數(shù)據(jù)全部通過RESTful接口來進行交互匣沼。這樣前后端就完全分開了狰挡，脫離了后端的模板，而這種方式的系統(tǒng)復(fù)雜度也會比第一種完全分離的方式低释涛。但這種方案下加叁，所有的頁面數(shù)據(jù)都是用js渲染的，沒有動態(tài)模板唇撬，不太利于SEO它匕。這個不足我們可以通過做server render或者給蜘蛛做一套定制頁面來解決。

4.3 分層架構(gòu)的出現(xiàn)

隨著業(yè)務(wù)進一步的復(fù)雜窖认，我們又開始考慮怎么讓一個復(fù)雜系統(tǒng)變得可維護超凳，這時候就體現(xiàn)出一個網(wǎng)站架構(gòu)的作用了。因為后端比前端發(fā)展的要早耀态，分層架構(gòu)這個概念在后端的發(fā)展過程中就已經(jīng)有了，我們最常見的就是MVC結(jié)構(gòu)暂雹。這個時候前端也發(fā)展到一定的程度上了首装，也是需要分層架構(gòu)來讓代碼變得更加可維護。

分層設(shè)計最大的意義就是解耦杭跪，如果我們的系統(tǒng)中的各層之間是松散耦合的仙逻，當(dāng)我們要改變其中一個層級的時候驰吓，只要保證該層級的接口不變即可，里面的實現(xiàn)方式可以隨意變動系奉。其他經(jīng)常提到的優(yōu)點檬贰，比如易維護、易復(fù)用缺亮、易擴展翁涤，其實說的也都是一個意思。在前端的分層方式上萌踱，和后端并不太一樣葵礼，所以后端的MVC模式并不能完全搬到前端來。前端的分層設(shè)計在MVC的基礎(chǔ)上又做了進一步的演進并鸵，形成了更適合前端的MVV*等方式的分層鸳粉，來支持前端的邏輯。

4.4 模塊化來了

分層架構(gòu)有一定的解耦效果园担，但是遇到復(fù)雜業(yè)務(wù)届谈，所有的邏輯就分成三大塊顯然也是不夠的，并且基于javascript語言的特性弯汰，如果我們沒有對全局變量做管理艰山，變量沖突也是無法避免的。因此我們就有了模塊化的處理方案蝙泼。

由于前端的發(fā)展一直處于百花齊放程剥，百家爭鳴的狀態(tài)， 所以在每一種技術(shù)或者方案的發(fā)展過程中基本都會出現(xiàn)幾個分支汤踏。我們的模塊化方案也未能免俗织鲸。模塊化中比較有代表性的就是AMD、CMD溪胶、CommonJS和es6模塊化這幾種方案搂擦。

AMD 是 RequireJS 在推廣過程中的規(guī)范化產(chǎn)出，而CMD 是 SeaJS 在推廣過程中的規(guī)范化產(chǎn)出哗脖，這兩個模塊化方案有些相似瀑踢，主要的區(qū)別是加載和運行的時機不太一樣。這兩種模塊化方案是可以直接在瀏覽器上運行的才避，但也有個缺點橱夭，就是會將模塊化的代碼和業(yè)務(wù)代碼摻雜在一起，對于強迫癥的同學(xué)來說桑逝，這并不算一個很好的方案棘劣。

而隨著nodejs的發(fā)展，我們有了對代碼做編譯的能力楞遏。這樣原本不能在瀏覽器上運行的模塊化方案茬暇，通過編譯處理以后首昔，也能正常在瀏覽器上跑了揭糕。這種模塊化方案最具代表性的就是CommonJs的模塊化方案耳奕。由于我們是要編譯的栽渴，所以大部分處理模塊化的代碼都可以通過編譯的過程追加進去逼龟，這樣我們只用關(guān)心業(yè)務(wù)邏輯部分就可以了昂勒。當(dāng)然這種方案也不是完美的脊框，這種提前編譯打包的方案會把所有引用的代碼都打包進去侣监，如果想按需加載就需要再做進一步的處理萨咳⊥欤總體來說巨税，我還是比較傾向這種模塊化方案。

在模塊化方案中粉臊，還有一種被納入標(biāo)準的ES6模塊化方案草添，理論上這種模塊化方案也是可以直接運行在瀏覽器上的，但對瀏覽器的版本要求比較高《笾伲現(xiàn)在也有一種方案远寸，就是通過babel編譯，把ES6的語法轉(zhuǎn)換成大部分瀏覽器可以兼容的舊版本js的語法屠凶。但這樣的話驰后，ES6的模塊化相對CommonJs也就沒有多大的優(yōu)勢了。

五矗愧、下一個時代

互聯(lián)網(wǎng)行業(yè)的發(fā)展總是會受到技術(shù)的限制灶芝，有很多想做的事可能因為技術(shù)原因不能做。但另一方面唉韭，業(yè)務(wù)也總是在促進技術(shù)的發(fā)展夜涕，如果一個事的價值非常大，那么技術(shù)通常會進化到可以搞定它的狀態(tài)属愤。業(yè)務(wù)和技術(shù)的就是這樣一個互相促進女器，階梯式上升的過程。

電商的下一個時代會是什么樣住诸，應(yīng)該沒有人能說的清驾胆。但是能看到的像大規(guī)模數(shù)據(jù)的處理、機器學(xué)習(xí)贱呐、智能化推薦和VR展示這些技術(shù)已經(jīng)在路上了丧诺，有的也已經(jīng)有了不錯的進展。而對于前端來說奄薇，將來也不排除會在這些領(lǐng)域承擔(dān)下一些責(zé)任锅必，尤其像VR這種用于展示的技術(shù)還是很有想象空間的。

無論下一個時代會是什么樣，但愿我們始終保持一顆好奇心搞隐，能以興趣驅(qū)動的方式跟上技術(shù)變革的潮流。