如何評價真阿當的文章：《2016年前端技術觀察》？
資深Web技術專家曹劉陽：2016年前端技術觀察 - 極客頭條 - CSDN.NET
讓我先登錄一下萬年不用的 CSDN 帳號，看看我的專家頭銜還在不在??其實這種盤點文章就是這樣子，我之前也不是沒被《程序員》約過稿，就好像 @賀師俊 說的一樣，你不寫就只能約別人寫，反正總是要有人寫的。
儘管我的 title 還是 Front End Engineer，但我的實際工作已經變成了一半 Full Stack Engineer 一半 TPM。（TPM = Technical Program Manager，負責驅動技術項目執行而非規劃面向用戶的產品。）我的目標是最終項目的交付，而不是前端不前端的問題。能夠讓擁有相關技術的專家幫忙做，我就讓他們幫忙做。他們不能幫我做，我就讓他們教我做。無論是 iOS、Android 還是伺服器端或者腳本，沒有人做我就要去學會然後做完。不在乎技術上是否完美，夠用就好，關鍵還是項目交付。因此我專註于思考「什麼樣的 trade off 最有效解決問題（如何定義夠用就好）」以及「某人的 motivation 是什麼（如何說服某人幫我做這件事情）」。我在閱讀這篇文章時，更多的是在思考後面一個問題，也就是發生了什麼事情使得阿當要這樣寫。
我看完這篇文章之後的感覺是，他的團隊里主要有兩種人：專門在新技術上挖坑而且挖完填不回去的「高手」，和什麼坑都不能獨立填好的「新手」。這是他不爽各種新技術的原因。再加上伺服器端團隊時不時有高手跑來前端挖坑，他們可能自己能夠填回去但他團隊里的人就是無法把坑填好，所以他非常不喜歡他團隊裡面的人跟風挖新坑。
這底下的問題是什麼？我覺得是團隊招聘和成長的問題。如果團隊能夠招到真正的高手，自己挖的坑自己能填平，那就沒有那麼多問題了。就拿 ES6 來說，坑是非常多的：開發環境要實時編譯，生產環境要打包編譯。兩者都要支持 Source Maps，前者用於瀏覽器中直接調試，後者用於生產環境收集來的錯誤堆棧反編譯。已有的大量 ES5 代碼要能批量轉換為 ES6。如果你團隊里有人挖了 ES6 這個坑然後填不平，各種配套工具都沒有，那當然是有問題的。但為什麼你招不到能夠解決所有這一切問題的人呢？
如果團隊成員能夠成長，他們能夠變得有能力把坑填平，那也不是問題。對於應屆畢業生來說，他們需要在公司提供好的工具和開發環境下工作，這是正常的。對於工作了幾年的人來說，他們想要做工具，而且是越來越複雜的工具，這也是正常的，因為他們認為（以為）這是正確的方向。但他們的能力上限還沒有到那裡，你怎麼辦？在你眼中，他們所謂的學習成長過程就是把你的工具換代，但開了個頭把一切都搞爛了就做不下去，這是你的鍋還是他們的鍋？
團隊招聘和成長問題的再下一層，是 ownership 的問題，也就是誰背鍋的問題。你可以說別人在進行工具換代時把開發環境搞爛了，影響了團隊所有人的工作效率，所以是別人的鍋。但你是團隊 leader，這自然也是你的鍋，你是逃不掉的。你可以說自己是 PM，嘗試甩鍋給 EM (Engineering Manager)，說團隊建設得不好是 EM 的責任。問題是作為 PM 你的責任就是產品要能高效率地交付，做不到的話哪怕產品規劃得再好也是你的鍋。
有鍋就要背。正確的做法是把自己團隊的問題解決了，而不是寫文章跟別人吵架。做 leader 到了一定的級別就應該具備解決人的問題的能力。團隊有問題就要去 debug，找到問題根源後要有能力 bug fix。到了這個級別，需要處理的問題往往不是技術而是人。你的焦點應該是如何讓人能夠有效地解決技術問題，然後把具體技術問題交給他們處理。
P.S. 透過 PM 和 EM 的視覺看到的世界跟工程師看到的世界是不一樣的，因此我沒有像其它答案一樣討論具體的前端技術。我的思維方式已經變成「如果我們認為阿當是個 bug，那我應該如何 debug 背後實際的問題？然後應該如果設計 bug fix 方案？」這篇文章出來以後，我在微博上的第一反應是：『誤人子弟』。
有些人說，要允許不同的聲音嘛。至少人家有說出來的勇氣嘛。這都不是重點。人當然有表達他的看法的權力，但作為一篇對一個領域做年終總結性質的文章來說，這篇文章有太多問題。因為文章太長沒法細說，所以我大概說說為什麼我認為這文章誤人子弟：
1. 阿當的論證模式完全是經驗主義，而不是基於實踐。
我很早就說過，評價一項技術的時候，我遵循一個原則：如果我沒有用過，研究過，親自踩過坑，我不對一個東西妄下判斷。直覺性的判斷可以有，但你經驗再豐富，沒有實踐支撐的直覺判斷也是不足以作為論據的。
舉例來說，對於 CSS 預處理器，阿當提出的種種疑問，全都是基於『假設』而不是實際的實踐反饋：可能會出現這個問題，可能會出現那個問題。然而他沒有提供任何證據表明這些問題是不能解決的。相比之下，@大漠 的回答里對於這些疑問都提供了基於實踐的反饋，並且用實際使用體驗來說明預處理器利大於弊。真正在生產環境里寫 CSS 的前端們心裡自然也知道預處理器的使用率是怎樣一個狀況。
對於 Angular，對於 React，他的批評也一樣極其的流於表面。對於 Angular 講的是 MV* 這種非常虛的東西，對於 React 則是用上手門檻高一筆帶過，甚至說出了『既然jQuery已然可以提供必要的幫助了，那麼還要React幹嘛』這樣的話。仔細看一看，懂的人立刻會發現這些話根本不像是真的用過 Angular 和 React 人總結出來的經驗。
對這兩三年流行起來的技術，並非因為守舊而排斥，而是確實做過思考，結合自己過往的經驗，持很重的懷疑態度。
我們注意一下阿當說的這句話。『做過思考』，『結合自己過往的經驗』。唯獨沒有真正去實踐過。一切判斷的來源都是他當年的經驗。
對一個東西持懷疑態度沒問題，但把這種未經實踐檢驗的懷疑去對經驗不足的新人輸出，一來可能本來觀點就是錯的，二來讓大家覺得『我沒用過，但這東西不對』的思維模式是可取的，是為誤人子弟。
2. 阿當的技術視野早已經脫離業界現狀。
阿當說自己對新東西一向超前，這在他轉產品之前或許是真的。但是轉產品之後他的技術視野幾乎就停滯在了當年的狀態：2016 年了還在拿 Canvas 和 WebGL 說事兒，覺得『沒有什麼新東西』，然而實際上是他真的脫節太久了 - caniuse 這個 API 列表 (http://caniuse.com/#index) 裡面今年新出來的東西很多，然而他一個字都沒有提到。2016 年了還在拿垂直居中的幾種寫法說事兒，然而 flexbox 他一個字都沒有提到。
從純工程的角度來說，作為一篇 2016 年的年終技術盤點，ServiceWorker, WebAssembly 這些可能導致整個平台格局變化的東西，Web Components 規範逐漸落地，HTTP/2 可能帶來的前端資源打包/載入範式的改變，依然一個字都沒有提到。
退一萬步說，『某框架』在 2016 被廣泛在生產環境中使用，入門門檻低，接地氣，又恰好解決了組件化的問題，當老師仍然一個字都沒提到。嗯，這幾乎一定是故意的了。如果不是，只能說當老師的眼界確實閉塞到了一定程度。
作為一篇總結文，讓沒經驗的讀者看完以後產生一種『哎，看來 2016 我也沒錯過什麼』的錯覺，是為誤人子弟。
3. 阿當的部分觀點完全出於事實上的無知和主動的拒絕接收信息。
阿當時至今日依然覺得自己對於『Node 在服務端失敗了』這個判斷是正確的。淘寶天貓那些用 Node 承載著過億日 PV 的工程師們，PayPal、Uber、Netflix 這種將 Node.js 用在核心業務上的公司的工程師們聽到這句話，不知作何感想。
以下視頻需翻牆，請自行判斷。
PayPal: https://www.youtube.com/watch?v=-00ImeLt9ec
Uber: https://www.youtube.com/watch?v=ElI5QtUISWM
Netflix: https://www.youtube.com/watch?v=p74282nDMX8
當老師批駁 Node 的那一段當中那個『某 JavaScript 框架作者』就是我，當年我給他的幾篇博客，他只說了其中一篇，然而他沒說的其他幾篇當中，就有介紹當年將 Node.js 引入 PayPal 的一篇。那是 2013 年的文章；根據視頻里的信息，2015 年底的時候 PayPal 不僅僅還在用 Node.js，而且是將大部分的服務端邏輯都用 Node.js 替換了。他們的團隊有 700 多個 Node 開發，很多是原來寫 Java 的轉過來的。上面的視頻，我也在微博上貼給阿當看過，至於他是沒看見，不想看，還是看了卻故意不提，我就無從得知了。
那麼 2016 年呢？我們可以看看 Node Interactive 2016 的贊助商：Sponsors | Node.js Interactive North America 2016 | Linux Conferences and Linux Events | The Linux Foundation 這裡面有 Google, Microsoft, IBM, Intel... 如果 Node.js 的市場沒有在增長，如果 Node.js 沒有給這些公司帶來商業上的機會，他們是吃飽了撐的來贊助 Node.js 的年會？你是信當老師，還是信 Google / Microsoft / IBM / Intel 的判斷？
罔顧事實，抱著成見，輸出和事實相悖的信息，是為誤人子弟。
4. 狹隘的前端領域意識，引導新人自我設限。
阿當在文章中常常把前端和其他領域對立起來，人為地製造一種領域歸屬意識。比如批評 Less, CoffeeScript, TypeScript 是其他社區對前端的入侵，把研究語言、語法糖歸作是後端才應該感興趣的事情，把研究 Node 的前端看作是不自量力、不守本行的玩票者...
然而在我看來，領域之間的思想交流才恰恰是保證領域能夠保持活力、向前發展的源動力。阿當對於這些事情的反感，歸根結底就是一句話：他覺得這些東西的存在是一些新人不好好打基礎的根本原因，間接導致了他招不到人。然而這裡面的因果關係是否是這樣，非常值得商榷。
你說新人該不該好好打基礎？這簡直就是廢話。阿當的邏輯謬誤在於把他觀察到的一個客觀現象，邏輯跳躍地怪罪到了一些他所看不慣的技術風向頭上。彷彿真的是這些研究新語言、新框架、搞全棧的這幫人害得新人們啥都不會，而自己是憂國憂民的那個人。
新人浮躁的問題，本質不在於新工具的層出不窮，也不在於社區的技術風向，而在於市場招人時候的導向。管你社區宣傳得再火熱，那是給已經基本功紮實的人看的。如果大家招人的時候都注重考察基本功，新人們自然會知道還是得去惡補基本功。如果大家招人的時候忽略基本功只考察新人知道多少名詞，新人自然就會試圖去走對應的捷徑。但是，畢竟事關飯碗的事情，我相信大部分招人的人都不傻。事實上，真正在研究新技術、搞全棧的前端裡面，大部分都是先打好了紮實的基礎才去接觸更高層的東西的，因為不是這樣的根本玩不轉，也找不到工作。
阿當的論調最大的問題就在於，沒有經驗的新人，或者是沒有技術背景的管理人員在看完他的文章之後，就會形成這樣的印象：『前端就應該乖乖守住自己的本行，學好 JavaScript HTML CSS 這些基礎就夠了，追求新技術、搞什麼工程化、全棧的前端是眼高手低、不負責任的。』
注意，雖然阿當的原話並非如此，他也一定會辯解自己並沒有這個意思，但讀完這文章客觀上會不會留下這樣的印象，讀者可以自行判斷。
人一旦給自己潛意識裡劃定了範圍，就很容易找到逃避困難的借口：『這不屬於前端該管的東西，我不用學』。演算法也不用學了，編譯原理也不用學了，數據結構也不用學了，反正這都不是前端的核心競爭力嘛。@月影 的答案里提到他的心疼，心疼的就是這個。而管理層的人看了這樣的文章，也容易對前端的定位形成過於保守的看法。這樣的導向，會影響真正有工程師思維的前端的產出。某當在拚命渲染新技術風向的危害的時候，有沒有考慮過自己的言論可能帶來的危害呢？
打著為行業憂心的旗號，輸出著讓新人自我設限的價值觀，是為誤人子弟。
---
其他諸多邏輯、技術上的細節謬誤，不再一一指出。我本來沒想多費口舌，到頭來還是寫了這麼多。只希望讀了這篇文章被誤導的人能少幾個。
這整篇文章里當然不是所有的觀點都是錯的，但寫文章不是說只要有那麼幾個對的觀點，就可以無視方法論上的問題、無視事實上的謬誤、無視邏輯上的跳躍。如果要下一個結論，那就是這篇文章是一篇非常糟糕的年終總結文。如果這篇文章能夠做到：- 基於實踐經驗和真實數據而不是臆斷來對一門技術的優劣下論斷；
- 真正地結合 2016 年的發展來討論而不是基於脫節的經驗來空談；
- 基於自洽的邏輯做論證而不是跳躍地把兩件事的因果關係聯繫起來然後批判一番；
那麼我第一個鼓掌表示歡迎。
另：我跟阿當確實有過過節，但我早就對這種個人恩怨沒什麼興趣了，這裡也不對他的動機做任何道德判斷，單純只說對文章的評價。另外，我相信程序員雜誌的編輯應該不是刻意搞什麼套路，這篇文章的責編現在應該承受了很大的壓力，希望大家可以理性評論。
又及：一個人的說法不對，就是會被人批評，不會因為他是弱勢他的錯誤就變得可以理解了。尤其是這次是他先利用了雜誌年終長文這樣的話語權去輸出他的看法，大家才不得不出來表達反對的看法。如果他在他自己博客里寫這種東西，我根本看都懶得看。如果有人覺得這件事情是有人抱團站隊要搞政治鬥爭，恕我直言，這種技術爭論裡面能看出政治鬥爭的人，這看世界的眼光是得齷蹉到什麼地步？在地鐵上，手機碼字不容易，我只說幾句，槽點太多，不具體討論。
今年奇舞團有幸與@玉伯團隊做了一次交流，我最大的感慨是，我靠，大家談的都好奇怪，什麼node服務端框架啦、weex啦、前端運維啦，這群「偽前端」又把前端帶歪了吧。
當然，我這是一句玩笑話。實際上我們兩個團隊會討論這些內容是因為無論是支付寶還是360，我們的工作中經常會遇到這些領域的問題。
如果要證明阿當的說法，現在前端的方向有問題，那我們就要看現在前端跑去研究這些「新玩意兒」對於原本的「傳統前端」技術領域有什麼影響？最簡單的辦法是看現在流行的代表性的互聯網產品，看它們的前端如何？自從大廠前端開始玩被阿當否定的這些技術之後，這些年究竟是在進步還是在退步？我相信這不用我再說下去，大家心裡清楚吧？
至於我看到微博有人大約是這麼回復阿當的—我是非常熱愛前端的演算法渣，看到阿當老師寫的文章我就放心了（意思大概是這樣吧，原文記不清了）這種我有點心痛，我想說的是，你既然口口聲聲說自己熱愛前端，就拿行動證明，而不是口頭上說。你連基本的演算法都不願意下苦功學，憑什麼說自己「熱愛」前端？這就像有人說「我愛我女朋友，但我就是捨不得為她花一分錢」一樣充滿矛盾。
咦，還是說了挺多，那我就再多說兩句吧。
我就是賀老@賀師俊引用的在群里評論的兩人之一。
你們看文章要看全，他最後說的那一句也挺中肯的—「我說的也可能全都是錯的。」不謝邀。
評價就免了，槽點太多反而不好下手。但至少比較好的總結了阿當自己的觀點，至少以後要論戰不能以微博140字講不清楚作為理由了。
本來前端圈子裡對阿當（曹劉陽）的觀點已經討論過幾波了，再來一次也無傷大雅。但是這次不太好的一點呢，是從CSDN/程序員這個老牌程序員媒體上發表的，就讓前端圈之外的人誤以為阿當的觀點是前端行業的主流看法或者至少是有很大影響力的意見。這會誤導其他技術人員（包括技術管理層）和非技術人員（如產品、設計）。我為什麼敢說阿當的觀點絕對不是主流，不是憑藉我個人在前端行業的權威地位（自吹一下，反正不上稅），而是這確實是業界共識（具體後面會說）。
坦率說，這個事情呢，我也有微小的責任。因為程序員編輯部其實之前找過我，希望我來寫2016前端技術盤點，我呢太忙了（年底事多，還要參加好多活動），就推說這題目太難。本來我也應該推薦一些其他人來寫，比如 @黃玄 啊。寫技術盤點這種題目非常重要的是技術視野和技術品味，黃玄這方面很好，而且對於2016年的熱點如微信小程序、（被很多人忽視的）PWA等都有很深入的觀察，而且他最近應該也比較空。但是不幸的，因為程序員編輯部的工作人員在微博私信上聯繫的，我現在刷微博比較少，後來就把這個事情忘記了。但我確實也沒想到最後他們會找阿當來寫。畢竟我印象里歷史上程序員雜誌的編輯還是有眼力勁的，比如在2013年年初請 @尤雨溪 撰寫的《開源前端框架縱橫談》，那時小右甚至還沒開始vue的開發（不知道是不是寫了這盤點之後才下決心自己寫一個的）。當時我也還不認識小右，但那文章給我留下了印象，所以現在還記得。
其實那期是前端專刊（《程序員》2013年3月刊：前端-CSDN.NET），我們看下目錄：
開源前端框架縱橫談 by @尤雨溪
Web App和HTML5給Web前端帶來的變化 by 曹劉陽
（我整理時才發現那個時候阿當也寫了一篇，說明當時這篇文章沒給我留下啥印象。）
前端模塊化開發的價值 by @玉伯
前端工程師如何應對移動Web時代的應用開發 by @winter
TypeScript：更好的JavaScript by @高博
CoffeeScript：陰霾天空的一抹藍 by 周亮
ClojureScript：前端世界的Lisp by 胥帝
針對應用程序設計的Web編程語言Dart——《Dart語言程序設計》作者Chris Strom專訪 by 韓國愷
Node.js高實時應用開發 by 謝騁超
Backbone.js在大型單頁面應用中的應用實踐 by @趙望野
為什麼Discourse使用Ember.js by Robin Ward
模塊化高擴展性的前端框架KISSY by @何一鳴（承玉）
行進中開火：YUI3在美團的實踐 by @尚春
CSS預處理器：Sass、LESS和Stylus實踐 by @大漠
一共14篇。【值得收藏的一期嘿】
除去我不認識的周亮、胥帝、老外Robin Ward（Discourse作者），高博老師（著名技術譯者）、謝騁超（pomelo的作者）不算前端圈裡的人，其他9人確定是前端圈內的。韓國愷（應該是google的）、尚春（美團的）我不熟，其他7人我都多少有過交流。其中只有阿當轉行做了產品，其他人就算做了管理不太寫代碼了，但至少還是前端或大前端團隊的技術leader。以我的了解，我認為他們任何一人都不會同意阿當的大部分觀點。
其中有幾位自己就回答過相關問題：
關於「真阿當」對目前流行前端技術的批判，大家有什麼看法？ - 尤雨溪的回答 - 知乎
關於「真阿當」對目前流行前端技術的批判，大家有什麼看法？ - 玉伯的回答 - 知乎
如何看待真阿當每天在微博吵架？ - winter 的回答 - 知乎
畢竟，按照阿當現在的觀點，TS、CoffeeScript、ES6、Angular、React、CSS預處理器、Node.js……都貶低了一遍，你們對照一下其他人當年寫的稿子和現在做的事情，哪能贊同阿當呢？
不幸的是，這次CSDN/程序員在14位過往撰稿人當中偏選了阿當。
而且如果你翻一下阿噹噹初寫的那篇，儘管我們知道當年他就已經很固執了，但其實還沒有現在這麼……走火入魔。
技術更新換代近在眼前，每個前端人都應該對此有危機意識……才不至於在這場新的革命中掉隊。
呵呵。
有些人可能會覺得（包括他自己表達的也是）他是實踐之後才覺得這些東西不好的。但是他到底實踐了多少呢？大部分人可能並不知道阿當是個多麼固執的人。實際上我、winter、 @米粽 、大城小胖 @魏子鈞、@月影 等當初在盛大創新院和阿當做過一段同事。特別是大城小胖、米粽跟他一起做過項目。當時（2010年）要做遊戲大廳基於websocket的伺服器端，所有人都建議他用node.js，一方面node.js已經有很好的websocket庫和socket.io這樣的封裝庫，另一方面我們許多人都非常看好node.js，並且統一到js能方便團隊協作。但是他偏要自己用python擼一個。
所以他一開始就對node.js充滿偏見直至今天。
BTW，所有盛大創新院共事過的前端（包括非前端的，如老趙 @趙劼 ），沒有一個贊同他的。真的是眾人皆醉他獨醒？
再說CSS預處理器。公平的說，許多非常傑出的前端工程師，包括一些今天已經成長為行業領袖的同志，確實當初（2007年到2012年間）也不能接受CSS預處理器。但是到今天還反對的，除了阿當之外，我是真沒遇到過了。當然，我自己很多時候也不用CSS預處理器，比如side project，或樣式部分非常簡單的項目。但是凡是複雜的需要團隊協作的項目，必上CSS預處理器。因為和阿當理解的相反，CSS預處理器的優勢越是複雜項目越是需要團隊協作，越能體現出來。真正的技術團隊leader早晚會通過實踐明白這個道理。只能說阿當從來沒有真正放下成見。
另一方面，也不是說你沒用過就不能評價了。比如我經常沒怎麼用過就評價嘛。但這得建立在非常強大的技術能力、技術視野和技術品味之上的。（忍不住又自吹了。）
阿當在2010年
拒絕：node.js、CSS預處理器
推崇：YUI
我在2010年
推崇：node.js、CSS預處理器
唱衰：YUI
面對完全相反的判斷，馬後炮來說，當年一個工程師應該聽我的建議，還是應該聽阿當的建議？
其實就當年來說，node.js/CSS預處理器，我和阿當都沒怎麼在production里實踐過；YUI，阿當擅長，我從來不用。說起來他還比我多用過一項。但是這三個東西的趨勢，我都預判準確。
當然，我也有判斷失誤的時候，比如2003年我就推崇XForms……現在沒有幾個人知道這東西，不過你們如果去看一下，就會發現，這不是MVVM嘛！咳咳，只能說太超前也不好。
先寫這些吧。（反正自吹的部分已經ok了）
【補充1】
有人問到CoffeeScript。我從來就沒特別看好過CoffeeScript，也沒有鼓動過任何人在production里使用coffee，儘管我還是挺欣賞CoffeeScript的許多設計的。但是請別說我跟阿當在CoffeeScript的看法上一致。畢竟唱衰那麼多東西，怎麼著總能蒙對一兩個吧。
【補充2】
當然，也許阿當只是來吐槽的。但是吐槽的關鍵是要有娛樂效果。比如本問題下 @方應杭 的吐槽姿勢就很好嘛。看來下次阿當再發文章可以找方應杭先翻譯一遍。
【補充3】
有人問我RN的事。我其實對RN無感，但是可以講點事實，就是國內有許多公司早就已經在用了，攜程、58的移動app已經全線上RN了，類似RN的Weex則已經是阿里的技術戰略。我寫這篇文字的時候隨時刷了一下知乎就又看到一篇去哪兒網同志關於RN/Weex在ListView底層技術上的分析（知乎專欄），注意這文章的作者是iOS程序員。實際上許多公司引入RN、Weex的都是本來完全做native開發的移動端團隊，而不是前端團隊。我在多次技術大會上看到RN/Weex的分享的聽眾native和web開發者各佔一半。所以阿當寫的「學了React Native就可以在公司做App開發了？你先問問iOS和Android團隊答不答應……公司定崗的原因，iOS和Android團隊也絕對不會對你友好……」我相信很多人看到都啞然失笑。
當然RN是不是就是移動開發的銀彈？肯定不是嘛，否則阿里就不要自己再搞Weex了嘛。有沒有其他可能？肯定有嘛，比如PWA，我個人其實也是比較偏愛PWA代表的「純」Web技術方向的。所以阿當也不是所有話都完全不對（畢竟連李紅米 http://weibo.com/1960954893/EjEAqfFI9 也只能做到每頁都有錯誤，無法達到每句都有錯誤）。比如他說「閹割版的CSS導致前端技能的受限」、「learn once write anywhere的性價比不（夠）高」、「如果webview的性能問題在未來得到解決」……好像挺一針見血的嘛。
當然，每個人看到的那個部分也不一定一樣，比如本問題有些答案里覺得
「某當老師反對coffeescript和typescript的理由是比較贊成的」
「關於SPA和Web Site基本贊同」
「但是，強調基礎是對的」
「有個觀點是極其贊同的，很多人只會用框架用工具而不注重基本功的修鍊」
「但是我覺得他對node的看法比較中肯」
「除了對Angular 1和微信小程序的評價相對中肯」
「不過全文反覆強調前端要好好擼基礎知識這點我是贊同的」
「關於全棧的批評。我覺得他說的沒錯。」
「最後說自己可能不對，可能有人覺得這句做作，但是我覺得能說出這句話還是很有勇氣的」
……
我先不說這些認知本身是不是對，其實有不同觀點很正常。有些人就不理解為什麼所謂「前端大佬」們就專針對阿當，以至於被一些同學認為「有失風度」、「狗咬狗，一嘴毛」？
我引用在本文里 @ 過的某兩位「前端大佬」對這文章的評價：
唉，這種文章的誤導性就在於把偏見揉雜在正常的觀點中，讓經驗不深的讀者很難分辨。讓假話容易被相信的最佳方法就是把一句假話混在九句真話中說。
這文章煩就煩在又臭又長，沒有中心脈絡，觀點有些沒問題有些有問題，混雜著一堆偏見。
因為是私下對話，未經授權，所以就不貼人名了。得罪人和「一嘴毛」的事情我來就可以了（手動doge），反正我也是這麼認為的。（咦，說好不評價的呢？）
【補充4】
關於YUI。阿當最擅長的事情是緬懷YUI。
我理解YUI給當年雅虎中國系的同學們帶來的從切頁面到真正工程化的前端編程的啟蒙作用，且因為併入淘寶，所以整個阿里系的前端早期都受到YUI的影響。
雅虎當年確實是一面旗幟，出了不少好東西。關鍵還有DC、NZC這樣的名人。但是請不要高估YUI，也不要老是過分吹捧DC、NCZ了。
YUI是比較老牌的庫，但也只是當年眾多JS庫之一，dojo其實比YUI還早一年，而且背後的公司支持比YUI還強大。dojo的問題主要是1.0之前api版本變化太劇烈，當年開發者還沒有經過semver的教育，遠沒有今天對待版本變遷理性，因此dojo流失了大量用戶。但實際上dojo無論代碼實現質量還是api設計都比YUI強多了。YUI對國內開發者有更大影響是因為前述阿里系前端輻射的影響。
其實不光是我唱衰YUI，玉伯、 @田樂 等在2008年底關於js庫未來的一次討論中雖然觀點不一，很多預測也不準，但對YUI都是不看好的。
YUI則帶著濃厚的「官方、團隊」js庫的氣息……讓YUI成為不少開發團隊的選擇。但YUI 2.x緩慢的更新速度，以及對新思想的接納程度，很多時候讓人恨得牙痒痒，太慢了，和其它新生代框架相比，YUI 2.x像是一個步履蹣跚的老年人，讓人很無奈。YUI 3.x目前還處於preview階段，可以將其看成一個全新的JS庫……（但）仔細比較後，YUI 3.x並沒有帶來什麼新東西，更多的只是吸收接納了新生代框架的許多理念。對YUI的前景，就如對Yahoo!的期待的一樣，我相信它會存活著，但也許僅僅就是這樣活著下去。
——玉伯
YUI的api設計不好。作為oo的庫它不好，作為fp的庫它更不好，所以它不會有多好。不過在widget類庫裡面它肯定繼續占重要地位，因為YUI的widget的確兼容性很好。
——田樂
如玉伯所說，YUI3 其實基本上是重寫了，可見YUI2跟其他同時代的庫比有多落後。但是作為一個追趕者僅僅靠吸收別人的理念是沒超過其他競爭者的可能的。因為YUI團隊的技術品味其實不夠。對，我說的就是老是被搬上神壇的NCZ。（DC其實也不怎麼樣，但是YUI3跟他已經沒啥關係了。）
NCZ是個優秀的工程師，但技術品味跟John Resig、Alex Russell之類的比還是差一檔，關鍵是干這行早，樂於佈道，而且是在Yahoo!，有大廠光環。你看他寫的書其實也就那樣（我就從來不推薦），包括最近的Understand ES6。我前一陣幫忙粗審了中譯版兩章還發現了幾個原書的bug（nzakas/understandinges6），技術可靠度與NCZ的名氣不相匹配。說真的，作為新技術介紹類書，NCZ這書未必比阮一峰寫的那本好。阮老師的書還一直在修訂，新版已經都包括SIMD、SharedArrayBuffer這麼新的東西了（我不是說新東西多就好，但既然是介紹新技術，至少都覆蓋到是對的）。
NCZ對於前端/js生態最大的貢獻其實是他離開Yahoo!之後做的。你別看我看似貶低NCZ，那只是針對你們這些把他供上神壇的人講的。一碼歸一碼，eslint足以讓NCZ進入前端名人堂（如果有這樣的名人堂的話）。話說，eslint這東西要求的就是公平對待需求、技術觀點中立，像我這種有鮮明觀點的人就不適合去搞，像NCZ這種比較中庸的正適合。除了eslint在js生態里的重要作用，我特別要說，eslint的開源社區非常好，我提交過的PR因為缺少文檔放了好久，後來有人就給補上文檔合進去了。能建立這樣的和諧社區很大程度上是創始人決定的。所以我相信NCZ最後是真懂了JohnResig當初給YUI的意見的。阿當說什麼「當年John Resig公然嘲笑YUI，zks出面力挺YUI3」，其實根本沒看懂JResig的意思，還認為是嘲笑，嘿。
扯遠了。
當時玉伯他們等一批人其實看好的是 mootools。當然 mootools 小火了一陣之後也沒怎麼樣，不過反正比 YUI 強一頭。
即使說UI組件呢，YUI不僅比不上dojo，也比不上最早從YUI里fork出來的Ext。要深入分析？我反正就拋個結論，你們懷舊的有空可以撿出來看一下，我有點時間還是向前看比較好。
【補充5】
未來幾年內，前端一定將三分天下：其一，是以Ext為代表js庫將傳統頁面的表現形式發揮到極至;其二，Adobe的flash/flex憑著成熟的技術和豐富的經驗，以及不斷創新的熱情，引領著前端的技術走向；其三，微軟的sliverlight憑藉著公司強大的技術團隊和.net體系協同做戰的優勢，奮起直追，很有可能追趕上flash/flex．
感謝阿當自己又提供了一個全部失敗的預言例子。也真難為了。
再說 ES6，它固然提供了更友好的語法糖，可是，這些語法糖真的像很多同學說的那樣，是救世主，能「極大地提高前端開發的工作效率」嗎？……語言層面保守的解決方案是什麼呢？是通過JavaScript框架來封裝語法糖。最著名的例子就是jQuery，jQuery幾乎把原生的DOM方法都給重寫了吧？為一些實用的語法特性封裝個Lang庫，把想要的語法封裝起來嘛，class、extend、map，沒有什麼功能是封裝不出來的吧？其實在Babel出來之前，Lang庫一直是主流的解決方案，並非新鮮事物。
你
給我
用
JS
框架
模擬個
yield
模擬個
Proxy
試試
當哥，我知錯了，奉上我的簡歷，請笑納！
一艘大船，有優秀的舵手，也有幹練的水手，有修船工，也有講演者，有歌舞昇平的乘客，也偶爾失意的歸人。
船越來越大，人越來越多，大家互相扶持，推陳出新。一切生機勃勃欣欣向榮的景象，正在駛向一個美好的未來！
一個下了船的老水手，憑著當年開船的經驗，三番五次隔空喊話，喂，你們的船有問題，基礎不行，零件不好，這船岌岌可危呀！
船上傳來聲音，老東西，不瞎吵吵行嗎？先不說別的 文首的介紹
作者：曹劉陽，網名阿當，資深Web技術專家，必殺技「前端開發、軟體架構和敏捷開發」。
我早已痊癒的尷尬症又犯了好么。。。 必殺技是↓↙←↙↓↘→+A/C 發動么。
實話實說呢，確實有幾句措辭我是認同的或者說呢是『看起來正確』。文章里，批評很激烈，觀點很片面，實踐呢還是基本看不到，我估計根本也沒有。還是高估自己的品味，還是這種眾人傻逼唯我獨醒的感覺，這姿態真是讓人看不下去。
-------
微博有風吹草動了，如果尤大真寫了， 估計這勢頭會比前幾輪更凶，吃瓜群眾站隊也會站的更牢固，讓漲粉來的更猛烈些吧
佩服你們看完的人。
看的很不舒服，有很多自相矛盾，偷換概念的地方和情緒化的私貨。
前端根本就不複雜，前端只是因為不規範所以來回折騰，後端不是簡單，而是穩定。
而作者一來吐槽複雜，二來對規範化的努力卻嗤之以鼻，不知到底想幹嘛。
強調前端複雜時，後端就是
「在MVC框架的幫助下，後端的編碼體驗其實很輕鬆，設計好資料庫和緩存，工作量基本上就完成了一半。然後Controller里的代碼不會很跳躍，專心在邏輯上就可以了」，這只是最小白的後端乾的事好嘛，就跟前端寫個ajax，寫幾個dom交互一個檔次。
感情
「上面我提到的任何一個領域，要用到的知識都是多方位的。比如服務端要掌握的知識除了語言核心語法，還有語言的功能模塊、Web框架、資料庫、緩存、伺服器配置、Linux運維、性能優化，甚至可能還得學消息中間件和網路安全。這是一整套知識體系，而且編程體驗和前端截然不同。」
這些就不是後端了？
這麼比公平么？
一來羨慕後端「在MVC框架的幫助下，後端的編碼體驗其實很輕鬆」
一來又「關於Angular，我是不認同的。Angular是Google服務端團隊折騰的作品，整套代碼組織的思路和服務端的MVC框架如出一轍：URL路由 + Controller + 數據抽象 + 模板引擎。雖然服務端出身的同學會倍感親切，但這真的不是前端代碼最好的組織方式。」組織方式好不好不說，用angular不是讓部分人覺得很輕鬆？
「我之所以不認同，並不是認為React在技術上一定是走錯了路，而是因為React把簡單的事情越搞越複雜」
Angular的組織方式好不好，React的路對不對，我不清楚，但他們把簡單的事情搞複雜，最後是為了讓前端開發更簡單，複雜的事由框架來作，最終能和後端一樣輕鬆。
看到後端人員能用mvc框架的幾個api寫點東西，就認為後端簡單的不得了。
mvc框架，說著就一個名詞，用的就幾個api，真能吃透的有多少？覺得mvc簡單，因為mvc框架把複雜的活都幹完了。
作者很悲觀的覺得，前端越來越水了，基礎越來越不重要。
這本身技術的發展方向，為了效率，就必然要把複雜度封裝（是封裝不是降低），前端的發展方向最終和後端是一致的，強大的框架完成大量複雜的工作，開發人員只是調幾個api寫點業務邏輯。
但是基礎不重要，只是對初級開發人員而言，能用的溜就行了，想進一步提高，基礎只會越來越重要。
最後「另外，別小看jQuery，我認為jQuery仍然非常堅挺，而且仍然有非常大的可能性成為最後贏家——補上組件抽象類和單向數據綁定就可以了。而這些通過jQueryui都不難做到」
我也差不多是這麼想的，不過理由就簡單多了，不過覺得前端如今在亂戰，抽身而出，不摻和，不站隊，等他們出結果了再拿來主義罷了。畢竟時間有限，沒人願意花時間去學，過幾天可能就被淘汰的東西。補充: 我的立場跟文章作者並不一樣, 因而思考問題角度也不一樣, 當然結論很難說認同. 我的回回答當中主要認為是其中的論據是指的思考的, 特別是前端圈外的一些因素添加進去.
有點警覺, 因為過幾天我要在大庭廣眾之下吐槽 React, 我甚至還要吐槽 JavaScript, 幻燈片已經 freeze 了. 現在看來危險很大啊. 只說關於 React 和 CoffeeScript 部分.
React 部分文章里我看到主要是這樣的:
說回到React的問題上。我之所以不認同，並不是認為React在技術上一定是走錯了路，而是因為React把簡單的事情越搞越複雜，現在一提React就是React全家桶，它的野心很大，還想解決Native開發的問題，但經驗告訴我，這很危險，這意味著學習門檻、團隊合作成本、招人成本、人員流失風險。如果React並不能帶來技術普及，只是曇花一現呢？誰來為公司里的那些遺留代碼負責？誰又來為初出茅廬基本功都未紮實的同學浪費的時間負責呢？
React總的來說，不像Angular走錯了路，但因為全家桶的原因門檻越來越高，這不是個好現象，未來有待觀察。個人不是太看好，但確實也沒有更有力的挑戰者。要麼像我一樣堅守jQuery，自己做組件抽象類，配合jQuery的第三方組件工作，等待更有冠軍相的角色出現，代替jQuery成為新工業標準，要麼就小心翼翼用上React好了，我也想不到有什麼別的路可走，當下這階段確實挺邋里尷尬的。
基本上跟我判斷的問題差不太多, React 本身有閃光點, 但是 Redux Babel 一整套的工具鏈玩得已經過火了. 當初我 bet on React 就是為了解決掉模板引擎加 jQuery 開發成本的問題, 但是計算一下全家桶的開發成本, 當然要把公司的業務對單頁面應用的自定義的要求加上, 這個成本恐怕會越來越高. 真的好嗎? 至少在我的場景當中計算, 我認為風險很大.
關於 React Native. 我個人認為它解決的招聘的問題更多, 還有熱更新方面的一些問題. 原先界面開發需要覆蓋多個平台, 意味著多個人, React Native 打頭嘗試了一個人寫界面少量人力 polyfill 平台的可能. 站在不同的角度意味著也不同的結果. 當然新技術的伴隨著風險, 不管賭還是不賭, 都應該注意到風險.
後面還有一段 jQuery 啥啥啥. 需求不一樣, 立場不一樣. 不認同.
然後是 CoffeeScript, 摘錄了其中一些:
說回到CoffeeScript、TypeScript和ES6上。CoffeeScript和TypeScript分別是Ruby和C#社區的產物，它們都覺得JavaScript語法不夠好，想改善它。只是它們倆分別代表了豪放派和嚴謹派，是兩個極端，讓它們倆先打一架好了。
我既不支持CoffeeScript也不支持TypeScript，原因很簡單，我不想多加一層編譯環節，JavaScript語法固然不完美，可是不完美的語言多了，Lua更簡陋，一樣活得好好的。GWT曾經想讓Java語言通過編譯直接解決JavaScript語言的問題，然後呢？然後GWT死了。
CoffeeScript只在剛出來時，我身邊有幾位同學短時間地表示了一下興趣，然後也沒見著他們真的跟進去了。
從2011年CoffeeScript、Less、Node同時進入前端圈推廣開始，到後來的Angular、React Native（React我覺得還是有價值的，但React Native就相當不接地氣了），全都走偏了路。CoffeeScript是Ruby社區從自己的語法習慣出發的。
我剛學前端時候學的就是 CoffeeScript, 語法糖的觀念並不特殊, 面對兩種選擇, 一種需要編譯, 另一種要很多的坑而且需要寫很多代碼, 怎麼選? 我選擇了用機器的開銷減少我消耗的時間. 別人在爭執分號寫不寫的時候, 吐槽 return 分號行為, 或者丟了 return 返回 undefined, 或者寫 _this = this 的時候, 還有很開心地配置 Babel 編譯 `x${x}x` 的時候, 我躲在某個小公司寫著縮進.
直到現在我還認同著 CoffeeScript 當中很多理念, 也嘆氣著某個語言卡位擠掉 CoffeeScript 之後加了那麼多 CoffeeScript 的功能. CoffeeScript 要發布 2.0 我還是每天去會去點 Issue 列表看有沒有打 tag.
站點我的立場, 我已經習慣了一門使用熟練的語言, 你們拆台做什麼. 同時我有理由相信, 讓那些很多習慣了寫花括弧分號的人, 讓他們玩縮進那是強人所難. 換位思考一下, 為什麼有人會嘲笑變革.
另外 Node 的問題, 沒多寫 Node. 但是在我學 Clojure 還有圍觀 Go, Haskell, Elixir 的時候已經很多次被動搖了 Node 並沒有 JavaScript 社區說的那麼成熟, 很了不起沒錯, 但是一些語言和平台有著十幾二十年的經驗, 而 Node 時間相對較短. 有人吐槽 Node, 我已經不覺得奇怪. 總得我希望聽到的是有資深服務端開發經驗的同學來判斷這個事情.
做下總結吧
1.阿當對前端生態，框架更迭快的情況，持悲觀態度。
2.他講的問題確實存在，但是結論卻是基於當前情況得出的。他覺得node是個玩具，但是node在作為自動化腳本的優點也是用一種不得不認的口吻承認的。
我的看法：
1.就事論事，真阿當提出的問題，確實客觀存在
2.我對前端的日新月異持樂觀態度。不同思想和技術方案，在大爆發後，會進行競爭，像目前的三大框架，慢慢形成格局。 而真阿當批判的前端職業的高薪、確認與浮躁，會在格局確定後自然解決。因此我覺得他看到了問題，但是沒看到問題產生的原因。只有框架的格局穩定了，人才才會不斷湧入。因為他們簡化了學習路線，並有更多的前人實踐作為佐證。人才地湧入，會使前端的工資趨於正常，而不是偏高。
3.關於全棧的批評。我覺得他說的沒錯。批評那些半掉的。但是我覺得他的看法，有點保守。node的發展我是看好的。
a.框架是html規範的補充。當html如果變得更現代化的話。前端可能沒有那麼多框架了。
b.前端的劃分，未來將囊括目前後端的模板渲染和路由。
c.更進一步，引用別人說的，未來將只有端工程師和雲工程師。 也就是前端、IOS、安卓，可能技術路線將趨同
d.前端目前其實還是受制於瀏覽器的技術， 所以得看未來chrome內核可以一統天下不
看得我都不想給 《程序員》 寫稿了
當老師招人難，抱怨是可以理解的，不從自身找原因，卻吐槽世風日下，人心不古，這點實在不能為人師表啊。
說點細節，當老師把ES6和CoffeeScript拉在一個平面上說語法糖的事兒，CoffeeScript作為一個方言，噴噴語法糖也就算了，ES6裡面那麼多runtime級的升級，怕不是語法糖那麼簡單。
另外就是CSS預處理這些，SCSS或LESS也就罷了吧，不知道當老師用不用Auto Prefixer這種人畜無害的東西，亦或還是津津樂道「CSS滑動門技術」。昨天參加完 D2 夜場，回家仔細看阿當這篇文章，味同嚼蠟。看微博上還這麼多討論，補充個我的觀點：前端風起雲湧的類庫、框架、工具等，我覺得都是為了兩件事：
一是為了更好地寫代碼，
二是為了寫出更好的代碼。
的確可以繼續用 jQuery 寫代碼，但很多複雜場景下，使用 React 或 Vue 會更簡潔優雅。Redux 等應用框架，是對分層合理性、協作性、可測性、防腐性等基礎軟體工程的架構思考與沉澱總結。這些架構思想，用 jQuery 也需要思考，但是用 jQuery 會讓人更懶于思考這些更本質的東西。
現在前端圈並不是浮躁，而是正像海綿一樣吸收著來自各個領域的優秀思想。從事前端開發的人群正在越來越多，多樣性差異性也越來越大，隨處都還有大量尚未有定論的領域等著牛人探索。比如 Redux 在很多場景下很繁瑣冗餘並不好用，Rx 則比較高冷不夠親民（純個人觀點、剛把玩一天），究竟什麼方案更合適？不光要考慮場景的定義與分類（定義與分類是 UI 領域的兩大難題），還要考慮人員情況（精英型技術團隊、實用型阿當團隊、什麼都做型全棧團隊等等），業務場景不同，團隊人員不同，架構方案就會不同（如果你對前端應用架構非常感興趣，請毫不猶豫聯繫我）。
前端要解決的問題太多了，需要的技術思想也越來越多，能做的技術產品也遍地是機會。多麼好的時代，一切為了更好地寫代碼，一切為了寫出更好的代碼，任何為這兩個目的而努力折騰的人都值得被尊敬！
------ 回復阿當評論中的問題 -------
時間有限，回答幾個問題：
1、複雜業務場景究竟怎樣的問題。這個問題還原下我想表達的：業務場景 + 人員情況，包括事，也包括人。比如 CRM 系統里的客服工作台、類似 Teambition 的項目協作管理、MIS 系統里金融信息圖譜操作、演算法平台里的模型搭建等等，不少系統的複雜度，已經直逼 Photoshop 這種 Client 端軟體。jQuery 或 YUI 等類庫框架，在這類系統里，能解決掉少量通用 UI 組件的問題，但在 UI - FM - VO - Service 整體架構里，YUI3 能解決的問題是很有限的。
2、簡單解釋下 UI - FM - VO - Service 架構思路：UI 是界面組件，目前基於 React Component 能很好實現，antd 把通用組件層實現後，我們內部還有 antd-plus 來實現行業的通用組件。UI 組件層的開發，僅是前端的一小部分工作。FM 是我造的一個詞：Frontend Model，前端模型層，從 URI 到 route component，用戶觸發 action 後，如何與服務端交互，從服務端拿回數據，如何加工耦合成 FM，不同領域的 FM 如何設計，從 FM 如何變成 state，最後才是讓 state connect 回 UI，實現 UI 層的更新。
3、UI -- dispatch action -- ( FM 架構層) -- state -- connect to UI，FM 架構層，是我所在團隊遇到的問題，這一層的代碼，不光是前端在寫，同時 Java 開發也在寫（全棧），如何保障 FM 架構層的代碼合理、不會隨著時間腐化太快，這不是丟給開發一個 jQuery 或 YUI 就能解決的。這時引入 redux 等方案，對 FM 層做合理規約，就非常重要。當然，從實踐來看，redux 也未能很好解決這個老大難的問題，期待高手的進一步加入。
4、回到為什麼會從 KISSY 到 Arale 再到現在的 antd，原因很簡單，就是從社區借力，從關注 UI 層的實現，到更關注前端業務層的實現。這裡的歷史不想多說，任何類庫都有歷史階段性，看清楚，不拘泥。至於為什麼會有 SeaJS，阿當你可以去了解歷史，看看是先有 RequireJS 還會先有 SeaJS，從 CommonJS 社區翻翻當初的各種討論。我很尊敬 James，但不苟同其理念。
5、FM 到服務端，是 VO （View Object）層，或者更大範圍來說是 BFF 層，這一層是否用 Node 實現，與團隊息息相關。拋開團隊情況，我也非常篤定，BFF 層用 Node 來做是最合適，因為 BFF 的消費者就是前端工程師，這一層由同一批人來做，用同一個種語言來寫，是非常高效的。螞蟻金服現在有大量 Node 應用，絕不是僅僅用 Node 來做做工具。
6、Service 層目前是交給 Java 開發團隊，水很深，前端慎入，不多說。
就先寫這些吧。想要更具體的，歡迎來阿里交流。從前，有一個前端基礎不好，被拒了。
Angularjs，react，react native，sass，less，stylus，vue，node，es6，coffee，typescript：怪我咯？dont talk too much，show me the code。前端圈動不動搞個撕逼事件真沒必要參與，對技術一定要有自己的主見，不要道聽途說，更不要隨口評價一個技術，存在即正義，多了解技術適用的場景才是正道。
--------------
前端的圈子是浮躁的，作為過來人，要做的是首先在公司內把前端體系建設好，然後再做一些影響社區的事情，如果一味的抱怨批評，圈子只會變的更浮躁，共勉。
-------------
大前端（跨端JS）不能說是一種趨勢，但是是一種解決問題的方式。但是有一個前提，脫離開這個前題討論問題就變成空談了。架構足夠穩定而且透明，不管是Node，還是NativeJS，都需要有一套成熟的對開發透明的開發體系，有專門的架構組來解決穩定性，工程化，規範和框架。對於開發來說，只關心怎麼寫結構和簡單的數據拼裝以及引用各種通用組件或者業務SDK即可，這樣這個事情才能推進下去，並且有其特定的意義，當然具體也要看公司的業務場景。
瀉藥
你說的這個文兒我就去完全沒看完
好像看到 sass 還是 node 什麼的時候
一看滾動條還辣么長呢就不看了
大致印象還是他老觀點吧
看你怎麼看待了
頂或踩他意義不大
他不代表大家
大家也不能代表他
他覺得有問題，只是他個人看法而已。
新人肯定會去學最流行的東西
理由很簡單
這樣能跟行內老人有差異化競爭的可能
畢竟學新大家都在一個起跑線上
所以沒有新人傻到會被不學新這類調調誤了子弟
比如 reactNative 大部分認為裡頭的樣式代碼是 CSS，其實是么？起碼沒C吧
（還有可笑到認為JSX的X部分用HTML解析器就能完成解析的）
我對其中幾句作一些探討：
Angular為代表的類服務端MVC框架，上來直接分成M、V、C三個層，然後將互相關聯的三塊分到了三個層里去，這麼干最大的壞處是破壞了抽象。而組件化的核心就在於抽象，將相關的屬性方法內聚到一個組件里去，這是符合面向對象的思維模式的。
這個話題其實很有意思，它代表了實現前端組件的兩條實踐路線：
1. 端到端組件
2. 分層之後，只做視圖的組件
什麼是端到端組件呢？意思就是，某個組件，它自己可以去服務端獲取數據，展示自己，對外部（組件實現之外）的通訊被盡量減少，例如，一個選擇地址的下拉框組件，組件自己去查省市信息，外部引用的時候，不給他傳遞什麼信息，只獲取它的選擇結果。
原文意思應該是傾向於這種組件的，在這種模式下，前端部分實際上是這麼一個形態：
A | B | C
---------
後端
組件之間可能還是會有一些組合，但整體上，前端部分是一刀切到底的。
很多人會傾向於這種組件劃分方式，我起初也是這麼想的，後來經過一次大規模實踐之後（11年到12年的時候，不過當時不是JS體系，而是Flex），對這個思路有了一些懷疑。
為什麼呢？初看之下，這麼劃分的組件可以很獨立，每個組件都能把自己跑起來，連同數據環境，業務開發只需簡單集成、轉發數據就行，當時我們就有一個事件中心來轉發各類業務事件。
我們碰到幾個問題：
一、數據模型不共享，可能會導致冗餘載入、臟更新。
這什麼意思呢，假設你把同一個組件，在一個可視區域內引用了多次，這在業務上是很可能的，那每個組件實例都要去查詢相同的數據，這裡，有多少實例，就會發多少同樣的查詢，形成了浪費。
浪費倒是小事，問題在於，既然數據來源是分別獨立的，如果你要修改一個數據，這麼多界面的部分，基本只能靠一個一個手動刷新，而且刷了幾個，就會有幾個新的，其他都是老的。
除非你的組件業務都比較簡單，並且對這種刷新體驗也不排斥，不然這裡面就會有不少問題。
二、組件的嵌套
很多時候，組件是要有嵌套關係的，一嵌套可能就會導致物理結構跟邏輯結構的不一致，比如說，你數據的結構跟視覺結構不是對應的，那就麻煩了。
更麻煩的在於，你各組件的數據存在時序關係，如果還是讓每個組件自己管自己的數據載入，這個事情就更難辦了。
所以，踩到這些坑之後，我開始考慮前端數據模型層的意義。因為我之前的所有工作場景都是重型，也就是說屬於文中提到的那些「後台系統」，但後台系統現在有很多也走向外界，你要在這個領域追求用戶體驗，仍然必須從前端角度去考慮很多問題，純後端開發是很難認識到這些事情的。
所以這個前端數據模型應當是怎樣的，它們跟組件之間應當如何交互，在不同場景下，要添加什麼，砍掉什麼，都是需要慎重考慮的。這也就是我現在更認同第二種方式的原因，也正是我當初對React體系提出的Flux，Redux這些東西不太認同的原因，複雜業務的數據模型層絕對不能面向事件、面向數據變更來設計，而是要首先抽象實體和實體之間的關係，然後才是他們的變化過程。
A | B | C
---------
前端模型層
---------
後端
如果有持續關注我文章的人，可能會發現，在13-15年，我寫了很多組件化方面的思考文章，反而今年基本不提了。因為當時那個時候，有大規模前端組件實施經驗的人比較少，很多東西還不像現在一樣，現在很多人都有這方面實踐經驗了，有了不少認識和嘗試，所以我也逐步把精力轉到複雜應用的數據層設計上了。
組件化的入門門檻還是比較低的，大家從視圖角度去入手，得出的大部分組件劃分都會是比較合適的。數據層則不然，隨著業務形態的不同，不僅僅是搞Backbone的Model（這個反而是最面向業務模型的），Angular的Service（這個最弱，幾乎等於沒有），React體系的Redux（以「對數據的操作」為核心）這類就足以概括的，而是需要根據場景作相當大的修正。
這一塊其實也有很多東西可說，近期考慮展開談談。前端工程師首先是一個工程師啊，難道掌握 CSS，HTML，JS 以外的工具，框架，技術來幫助我解決工程，效率，可維護性的問題，就要被冠以脫離前端圈子，增加圈子交流內耗的帽子了？
那還是不要叫我前端工程師好了。很多國人都有一個臭毛病，就是喜歡脫離實際泛泛而談一些好壞優劣或者所謂技術趨勢之類。
就各種前端開源類庫而言，無外乎都是針對特定環境在簡單性、易用性、靈活性等等方面做出自己的權衡，例如 jquery 易用但是靈活性太強導致代碼容易難以維護，react 可以輕鬆寫出複雜交互的 UI，但是讓你用它搞個表單，絕對讓你煩躁的想吐。種種設計上的矛盾永遠都會存在，所以優劣也僅僅是在特定場景有所體現罷了。
趨勢這種東西也不需要猜，基本上國外流行的差不多過一兩年中國就會流行，國內的技術輸出也不是沒有，只是歷史上的爛尾項目太多，我是不敢拿來做核心業務的。
阿當有一點我以為有道理，就是國內許多所謂的前端其實只會把弄幾個框架而已，原生一點的開發能力幾乎沒有，但是他把鍋摔給各種類庫就是無稽之談了，工作中用不著這些，同時公司也不會培養你提高這方面知識，有多少前端會去主動學習這些東西呢，想必金錢驅動的多數人都不會去學的？
其實把底層的東西掌握好才是搞前端的捷徑，因為只有基礎好了，你才能最快的掌握最新的框架/技術，才能更快的 debug 找到程序問題所在，才能真正的用知識去發揮自己的創造力，而不是像許多人一樣一個小問題都能卡住很久。推薦閱讀：
※好的前端主管是如何帶隊的？
※作為一個前端開發實習生，我這樣做是不是特別不厚道？
※QQ空間的前端技術水平如何？
※有哪些新手程序員不知道的小技巧？
※知乎上有哪些在前端開發領域的高質量回答？
TAG:前端開發 |