瀉藥
1.這壹系列文章寫得很好。
註意，熟悉我的同誌應該知道，我很少給出“很好”的評價。
2.這壹系列文章及其背後的實踐，重新確立了淘寶前端工程水平的領先地位。
在這段時間之前，至少從外部來看，淘寶已經落後於狼系統和企鵝系統。
3.這壹系列文章及其背後的實踐也證明了nodejs不僅在工具鏈中，而且在前端的架構層面上的重要性。
註意，這壹系列文章的思路其實並不新鮮，但我認為在淘寶的規模和非常成熟的產品上實施這樣的改變，是有象征意義的。
4.在具體細節上還有很大的提升空間，在本系列第四篇《前端分離的思考與實踐(四)》中為XSS辯護還存在壹些傳統問題。這方面，我在參加杭州JS的時候和淘寶同學herman有過交流，細節不在本期討論。因為這是局部問題，對整體結構影響不大。
5.註意，上面的評價都是關於架構，或者說思想。實施效果好不好，我相信他們自己的說法。但由於中途框架本身並沒有看到具體的文檔和代碼，其開發目的主要是為了滿足淘寶的需求，因此無法判斷其或其具體組件是否具有普遍意義上的適用性和優秀性。
徐飛的回答(19票):
早上看到何老出來，忍不住寫了壹篇文章，談談蘇寧這樣的公司在這方面的考慮。
這兩年壹直在思考如何改進前端系統的開發方式，最基本的壹點就是前後臺分離。說到前後端的分離，也有壹個誤區，就是只以瀏覽器為界，把這兩部分的代碼分開。但其實做這個東西的初衷是為了解決開發模式的問題，也就是把前後方開發者的職責分開。
這種分離方法對於不同類型的幅材產品是不同的。對於Web應用來說，因為它與服務器的交互基本上是AJAX或者WebSocket接口，所以這種分離是很自然的。整個前端基本都是靜態的HTML模板，JavaScript模塊，CSS以及相關的靜態資源，但是對於網購產品，它的做法就不壹樣了。
# #展示主要產品。
網購商品的展示需求很重要。加載了很多圖片等資源，但是相對操作很少。基本上只有搜索商品、添加購物車、結算等環節。傳統上，這樣的產品大多是這樣的工作流程:
與壹個高保真的圖進行交互，在前端剪切圖，生成靜態HTML並顯示效果，然後，註意，他不是自己做的，而是交給另壹組開發人員轉換成服務器模板，比如freemarker或者velocity，或者smarty。為什麽要這麽做？因為這類產品註重首屏的優化，是首屏而不是首頁，也就是說對於首屏來說，鏈接要盡量少。比如不能先加載客戶端模板，然後AJAX a數據，再渲染。這樣的性能肯定不如服務器生成HTML然後壹次性請求加載。
這個過程肯定有問題。比如開發者B在模板設置的過程中發現原來的靜態HTML部分有問題怎麽辦？眾所周知，壹個既熟悉HTML和CSS，又能寫業務邏輯的前端開發者是稀缺的，所以大多數情況下，這兩方面的技能是不壹樣的。如果是簡單的頁面問題，開發者可能會自己解決。他解決不了怎麽辦？
如果B自己不改，把自己做成了服務器模板的代碼還給前端人員A，A就啟動不了，因為已經是服務器模板了，A手裏沒有環境。改了之後不知道對不對，沒法預覽。那麽，如果B把問題告訴A，A修改了他的原始版本，然後交給B呢？這時候B又有麻煩了。他想比較兩次修訂，並合並他以前的修訂。
所以，無論怎樣，都有很多麻煩在裏面。
中途想用這個產品解決什麽問題？既然因為後端在用服務器端的模板，前端人員無法預覽模板，那我能不能找壹個兩邊都可以用的模板？妳可以在服務器端渲染，我也可以在客戶端預覽？服務器和瀏覽器可以同時運行什麽語言？只有JavaScript。
於是，大家去nodejs探索了壹個普通的JavaScript模板庫，也可以在瀏覽器中渲染，在nodejs中輸出為HTML。這個時候，原來負責集成模板和邏輯的人轉到nodejs，是不是解決了這個問題？
想象壹下這個場景有多美:前端決定壹個模板是服務器渲染還是客戶端渲染。當顯示第壹個屏幕時，會在nodejs中生成HTML。當它不是第壹個屏幕時，AJAX用於在瀏覽器中渲染和顯示它。
從技術角度來說，這很好，但是也帶來了壹些工程上的其他問題，就是對熟練的JavaScript開發人員的需求大大增加了。對於阿裏這樣的公司來說，前端有幾百人，其他公司只能仰望，所以他當然可以放手，但是對於蘇寧來說，前端少部分人我們就麻煩了。如果我們也引入這樣的方案，我們將面臨大量Java開發者轉化為JavaScript開發者的問題，這在短期內肯定是無法解決的，所以反過來又會增加前端的壓力。所以暫時不能用阿裏這樣的方案，只能先想辦法提升人員水平再看情況。
在服務器中引入nodejs還有其他好處，比如請求合並等。這也可以通過其他方式靈活解決，比如增加壹個與現有後端同構的特殊Web服務器，在那裏做這些事情。
# #展示具有平衡商業邏輯的產品。
對於其他場景來說，也有類似的問題，比如支付產品，沒有那麽重，但不是Web應用，面臨著另壹種前後分離的情況。在這個場景中，前端生成DOM操作類的靜態HTML和JavaScript，業務開發人員負責編寫後端，還有壹部分業務邏輯的JS。
這裏有什麽問題？是jQuery代碼導致的協作問題。例如:
$(".okBtn”)。單擊(function() { $。ajax(url，數據)。success(function(result){ $(“somarea”)。html(_。模板(" tpl "，結果))；});});
因為前端人員稀缺，他不可能幫妳寫業務邏輯，所以業務人員要寫$。ajax部分在裏面。然後，在獲得數據後，我們還要處理接口部分。
很多場景下，處理接口遠不是放個模板上去就能完成的，業務開發人員覺得很煩。這麽小的問題，反復去找前端的人很麻煩，自己做也要花很多時間，所以都很郁悶。
這也是壹種前後分離，但分割線不在瀏覽器，而在是否寫業務邏輯。這種情況的解決方案是加強JavaScript代碼的規劃。現在前端做MV*的框架那麽多，不考慮Angular之類的重量級。我們來看看骨幹。解決了什麽問題？
很多人說，雖然脊梁骨小，但根本不解決問題。這句話有壹定道理，但前提是妳自己的JavaScript代碼分層已經做好了。如果做得不好，可以幫妳解決分層的問題。
剛才那段代碼有什麽問題？而是責任不明確。壹個函數只能做壹件事，就是* * *知識，但是由於回調等方式，無意中破壞了函數的簡單性和完整性。讓我們試著把它拆開。
為什麽壹個後端開發者往往不敢寫前端代碼？是因為JavaScript語言嗎？其實不是的。當我們編寫業務邏輯時，我們只使用JavaScript的壹小部分。對於這個子集來說，它沒有太大的學習難度。最麻煩的就是DOM，BOM等東西。對於壹個後端開發人員來說，要求他在掌握服務器端代碼編寫的同時學習這些東西，真的不容易，還是省點他的麻煩吧。
現在我們的出發點是把這段代碼拆分成兩個不同的人，壹個操作DOM，壹個只寫邏輯，從來不操作DOM。前端代碼反匯編為前端維護，後端代碼反匯編為業務開發者。
最老的道:
js
$(".okBtn”)。click(function() { b1(數據))；});函數a1(結果){ $("someArea ")。html(_。模板(" tpl "，結果))；}
bjs
函數b1(數據){ $。ajax(url，數據)。成功(a 1)；}
現在大家都安靜了嗎？
如果這樣做了，AB雙方還要做很多約定，也就是說這個過程還是壹個螺旋鏈。比如A先寫click事件的綁定，然後想起這裏要調用壹個請求，就去B寫b1方法。B在寫b1的時候，突然想到要調用壹個接口呈現方法a1，然後就來A寫了，來回折騰的挺厲害。
況且有壹天A想在另壹個地方調用b1，但是因為b1的回調已經寫死了，笨辦法就是在a1中判斷是什麽原因引起的點擊，然後分別調用不同的回調。如果情況比較復雜，這個代碼寫出來的時候真的看不懂。
如下所示:
js
var type = 0；$(".okBtn”)。click(function(){ type = 1；b1(數據)；});$(".okBtn1 ")。click(function(){ type = 2；b1(數據)；});函數a1(結果){ if(type 1){ $(" somarea ")。html(_。模板(" tpl "，結果))；} else if (type2) { //...} type = 0；}
bjs
函數b1(數據){ $。ajax(url，數據)。成功(a 1)；}
稍微好壹點的方法是直接在b1中返回這個請求的承諾，讓調用方決定怎麽做。
如下所示:
js
$(".okBtn”)。單擊(function() { b1(數據))。success(function(result){ $(“somarea”)。html(_。模板(" tpl "，結果))；});});$(".okBtn1 ")。單擊(function() { b1(數據))。成功(函數(結果){ //...});});
bjs
函數b1(數據){ return $。ajax(url，數據)；}
如果想統壹處理返回的數據，在b1中很容易用promise重新打包返回的數據，但是這樣壹來，在a.js中，直接調用就不是成功，而是然後。
註意這樣的代碼還是有問題的，比如大量的全局函數，不是模塊化的，容易沖突。另外，有些* * *數據是沒有地方緩存的，比如壹個場景:
界面上有M和N兩個塊，其中M初始加載加載數據，N在初始時間不加載，而是在點擊壹個按鈕時加載，M和N各有壹個列表，數據來自同壹個服務器請求。
現在有壹個問題。N加載的時候，它的數據是怎麽來的？老辦法肯定是加載N，同時再次請求數據，然後渲染到N。
從壹個角度來說，如果我們不再次請求，N的這個數據應該從哪裏來？從另壹個角度來說，如果重新請求，發現數據和之前的有變化，要不要和M同步，怎麽同步？
我們來看壹個類似於Backbone的框架。它能提供什麽機制？或者說如果不使用，我們自己怎麽把這壹層包裝的更好？
首先，構建壹個數據模型並在其上添加數據緩存:
define("model "，[]，function() { var Model = { data: null，queryData : function(param，from cache){ var defer = q . defer()；if(from cache | | this . data){ defer . resolve(this . data)；} else { var self = thisthis.ajax(url，param)。success(函數(結果){ self.data = resultdefer.resolve(結果)；});} return defer.promise} };退貨模式；});
這樣，我們緩存了模型上的數據。如果我們在調用時添加fromCache參數，我們將從緩存中讀取它，否則我們將請求壹個新的。為了在兩種情況下保持調用者的界面壹致，整個函數被封裝為對後續調用的承諾。這裏的模型定義為singleton，假設它是全局唯壹的，可以根據需要調整為可實例化的。
此時，視圖層將封裝DOM和事件之間的關系:
define("view "，["model"]，function(Model){ function View(element){ this . element = element；this.element.selector("。okBtn”)。click(function(){ var self = this；var fromCache = trueModel.queryData({}，false)。then(function(result){ self . render data(result)；});});} view . prototype = { render data:function(data){ this . element . selector(" somarea ")。html(_。模板(" tpl "，結果))；} };});
此時，在多個視圖實例的情況下，也可以更好地利用數據。
這樣前端寫這個視圖，後端寫模型，可以做這樣的分工。
這只是壹個很簡單的方式，復雜場景下還有很多不足，這裏就不展開了。更復雜的場景類似於Web應用的方式，後面我會專門寫壹篇文章來展開。
# #摘要
我們來回顧壹下前端分離的問題，就是將前端和業務開發人員的職責分開。這個方案怎麽定，要根據團隊情況來定。比如阿裏前端強大，人多。他的前端會被推回去占據中層。像蘇寧這樣的公司，前端很弱，很多場景下只能放棄中間層，否則戰線太寬，只能處處被動。
同壹個中途島在不同情況下是否被占領，是考驗前端架構師的問題。
對於阿裏的這種做法，我們會繼續觀察，尋找並創造合適的時機出手。
Rank的回答(4票):
簡單說壹下自己的看法。
前端不再是“單純”在kissy上工作，但可以認為向後擴展架構是前端的壹種進步。這個前端架構將重新定義阿裏的前端工程師工作，很多互聯網公司都比阿裏領先壹步。
這個想法和阿裏很多前端沒有接觸後端(比如模板)有很大關系。使用NodeJS作為中間層可以解決當前的問題，這是壹個不局限於解決當前問題的長期解決方案。
能否解決取決於細節，不是新奇，而是過渡。比如NodeJS和原始數據的交互如何過渡，灰度如何過渡，工作量如何過渡等等。
平臺化和接口化(後端數據接口是和服務壹起存在的)的思想讓亞馬遜受益匪淺，現在大公司後端平臺化和接口化的趨勢很明顯。
平臺化需要更多更快的應用層開發和選擇，NodeJS就是很好的壹個。雖然NodeJS還存在壹些問題，但是從信息方面和我們自己的應用經驗來看，已經逐漸成為後端WebApplication的壹個不錯的選擇方案。
總的來說是壹種趨勢。
Hex的回答(1票):
我覺得這就是所謂的大前端開發模式。模式確實是壹個好的模式，但是在實際操作中，與後端工程師的溝通協調也會遇到很多問題。
我做過的幾個項目都是采用這種大前端開發模式，前端由Transformers框架和+CodeIgniter組成，真正做到了前後端的隔離，大大提高了項目的可維護性。
鄧欣欣的回答(1票):
上周去杭州玩，和以前的阿裏同事做了壹些技術交流。我發現阿裏前端今年在流程改進上下了很大功夫；題主說的中途島應該是UDC團隊做的。應該說，這個想法並不是很新鮮。國外有ebay向nodejs轉型的案例，國內之前也有百度音樂移動端的案例；
但是對於阿裏的前端來說，意義真的很大，解決了合作過程中的壹個很大的問題:之前阿裏的前端只寫靜態demo，為開發寫了壹套模板，開發對html了解不多，省去了壹個標簽，然後找前端調試，這是必須的，但這是壹個沒什麽技術含量的事情；中途可以很好的解決這種蛋疼，但是請不要以為前端就會是後端。無非就是以前瀏覽器用ajax請求接口，現在用node bo發布，壹個命令就能搞定，真的很方便。
Dip:數據接口平臺，定義業務線前後臺數據格式的內部公共平臺。基於json-schema，好像還能給妳提供mock接口；
Uitest:前端持續集成平臺；之前我邊做邊吐槽這個東西。好像是剛上線的，和jenkis壹樣。提交或發布代碼時，我會先幫妳運行壹個測試用例。目前通用測試庫很少。
Trace:我覺得叫監控平臺，很久以前就有了。用於監控各業務線頁面的運行狀態，收集各種用戶數據，如分辨率、UA等。
在我看來def和dip會在阿裏前端發揮更大的作用，uitest功能壹般。阿裏前端不註重代碼質量，測試用例只會寫在幾個直接影響交易的重要業務線。
許文敏的回答(0票):
的確，從職責上區分前後端的分離才是王道，nodejs將成為前端工程師的基本功。
獵人豆豆的回答(0票):
不要把簡單的問題復雜化。對於淘寶這種規模的公司，最好權衡壹下風險和收益再做決定。我們是技術的使用者，不要被技術牽著鼻子走。
羅的回答(2票):
前端的大牛們都已經說了，我換個角度說。
這麽說吧，為什麽阿裏的前端比其他公司走得更遠？就是因為他們有很多前端，有很多前端大牛不用寫很多業務邏輯。大牛的作用就是折騰。阿裏的前端工程師水平在自己的野外實踐中已經跟上了後端。
但是這個架構所謂的分離，實際上是把很多前端不需要做的事情攬到自己手裏，增加前端架構師的KPI，讓前端做更多的事情，這樣周報就好寫了。因為nodejs和前端都是js，學習成本不高，但是對壹個技術員的要求比以前高。
但是，他們團隊有很多HC，也有很多錢。。所以像我這樣的產品線只有壹兩個前端。妳這樣玩下去，跟不上，那就玩完了。
所以技術選擇和架構還是以自己團隊的能力和招聘為準。