參加第11屆D2前端技術論壇，你有什麼收穫？
http://d2forum.alibaba-inc.com/
2016年12月17日在東方威尼斯國際大酒店舉辦。參加第十屆D2前端技術論壇，你有什麼收穫？ http://www.zhihu.com/question/38637676
沒參與這次的 D2, 但是看到 @馬天翼 的回答，有感而發。
最近一兩年我去過的技術會議不超過 3 個，去的動機基本上是面基。在我還沒真正入行(但是已經寫了幾年代碼)的時候，我很喜歡跑到廣州參加各種各樣的技術會議，是因為我喜歡跟和我一樣在做技術的人在一起，不管我有沒有聽懂台上的人在說什麼。
後來我從一個 Newbie 成長成為一個有些經驗的老司機，在這個階段去聽這些會議的時候，我感受到的是失望，就像大學從選課到上課一樣：
1. 看議程的演講主題和簡介，感覺要學到很多東西了。2. 在台下聽講師講，屏幕上是框和線，描述的是業務上的架構流程。事實上我根本看不明白。3. 如無意外，下一張 slide 就是性能打點，表示用某某某技術之後性能提升了多少。4. QA 環節，台下必問生產環境性能。
我也會偶爾接受一些邀請做過一些 talk, 每次都想跟活動方要求取消我的 QA 環節，但又不想顯得自己搞特殊所以最終還是要接受這些 QA。因為台下能問到點子上的問題很少，而一般我都能想到聽眾會有的疑問，然後把這些疑問插進 talk 里，作為要講的點。QA 只能算是一個補充。我很討厭在台上興緻勃勃地演示完一個令人激動的技術之後，要被台下的人問這個技術用在業務上的性能啊兼容性啊怎麼樣。我更樂意去和大家討論這個技術是如何實現的。
說到底，我就是不喜歡把技術分享和業務綁在一起的這種會議氛圍。講師不應該從直接從業務的角度向聽眾宣講，而是應該把聽眾都當成一張白紙，首先介紹這次主題要講的這種技術是什麼、他的出現可以解決什麼問題、我們在業務中如何用這種技術去解決問題。
可能是因為我的位置不夠高，我對性能打點、業務整體架構真的興趣不大，演講中可以提到，這是很正常的。但是講師把這些東西作重點來講就很沒有意思了。我們大家都是寫代碼的，just show me the demo code!
舉個國外的例子：
Netflix JavaScript Talks - Async JavaScript with Reactive Extensions (https://www.youtube.com/watch?v=XRYN2xt11Ek)
整個 talk 的主題是 Netflix 如何解決非同步問題。在前 10 分鐘，先給觀眾一個概念：現代的應用基本都是 Asynchronus 的。然後表示，Asynchronus 是很難處理的，並用一個小小的代碼片段做非同步處理有多繁瑣。然後又解釋了 GoF 里的 Observer 和 Iterator 兩個模式。科普了這些基本的知識後，才開始給出 Netflix 上一個現實的場景。他們用 map, filter, concatAll 這些方法來處理數據，然後告訴你，連 event 都能用這些方法這樣來處理。這裡才開始講到整個 talk 的重點——Rx.
整個 talk 沒有出現讓你莫名其妙的架構流程圖，而是把 Netflix 業務中很小的場景(比如一個搜索框)拆分出來，告訴聽眾，工程師如何用 RxJS 解決這個小場景中遇到的問題的。
這樣的分享，才會讓觀眾覺得乾貨滿滿，因為講師都把進入 Rx 世界的鑰匙交給你了，還帶你看了看他們的 Rx 世界。至於觀眾聽了以後用不用，那是觀眾自己要考慮的事，但最起碼觀眾明白了什麼是 RxJS, 什麼樣的場景可以用 RxJS, Netflix 是怎麼用 RxJS 的。
再舉一個例子：
What if the user was a function? by Andre Staltz (https://www.youtube.com/watch?v=1zj7M1LnJV4)
Andre Staltz 是 Cycle.js 的作者，對 FRP 有很深入的理解。這個 talk 講的其實是 Cycle.js 背後的思想，觀眾能夠順著他的演講，用另一種角度，另一種思維方式去看待 Web 的 UI 開發。這種 talk 的意義在於，講師能給你帶來啟發。
我比較喜歡老外的這種模式，所以國內的技術分享我就越來越少去了。不是說國內講師的技術不如國外的。國內講師們的技術都相當好，而且經驗十分豐富。只是，貌似國內的很多講師對技術分享的看法和我想的不一樣。我希望技術分享是一群熱愛技術的人的聚會，也是有經驗、有想法的講師給觀眾帶來啟發的過程。我作為開發者，我希望看到的是，講師對某個技術很有自己的想法，他把自己的看法分享給觀眾，讓觀眾了解這個技術，知道這個技術應該怎麼用。技術分享應該是面向社區的，而不是面向業務的。而那些數據啊，性能啊，都跟老闆說去吧。
純屬個人看法。
今天聽了七場 D2 分享，簡單記錄一下所見所聞，以及我自己的一些思考。
首先聽的是 FUSION平台 的安利，核心思想在於 粒子 -&> 簡單組件 -&> 複雜組件 -&> 模版 -&> 頁面 的樣式抽象，讓設計師在平台上完成樣式的配置後，前端工程師直接導入生成的配置即可。在多品牌，多場景基於同一套組件庫的情況下，不但將前端工程師從枯燥的樣式調整中解放出來，也會降低設計師與前端工程師的上下游溝通成本。
FUSION 是上升到 頁面粒度 的，但在分享中著重體現了組件粒度的抽象。我想是否到 組件粒度 就可以了，頁面會由於交互導致狀態變更，從而引發樣式的變更，這該如何讓設計師配置呢？如果僅僅是組件粒度，是否只需要開發一個工具完成設計稿到樣式抽象即可，無需一個平台去承載？讓設計師去適應雲端設計與變更，對設計師而言是有成本的，對前端工程師而言也是需要去推動設計師一起玩的。
上午第二場是 FEX 團隊負責人吳多益老師分享的 前端服務化之路。2年之前開始思考如何提高前端的開發效率，從業務中將通用的部分抽象出來，通過運營活動、信息平台頁面可視化配置，內部管理平台的 JSON 配置，由寫代碼轉化為調配置或者寫配置，一方面提高開發效率，另一方面隔離了代碼杜絕 bug 的產生。
聽到後排有人吐槽 "怎麼都是內部平台?"，類似於 FUSION 或是百度這一系列的服務化平台初衷必定是為了提高團隊整體開發效率，減少重複性開發工作，或多或少有針對於其本身的業務場景、技術框架的"特別定製"，這是無法避免的，最初考慮的一定不會是通用性，要讓平台在開源後適應大部分場景，是需要做非常多工作的。"零成本"在我看來是個偽命題，"零成本"實質上是一個前人種樹後人乘涼的過程。其中有兩個問題是值得思考的：
（1）搭建服務化平台的成本與直接開發的成本，現場就有小公司的同學提問，是要學思想搭平台還是等開源或者商業化接入？對於小公司而言，去搭一個短期內看不到收益的平台顯然是不現實的。
（2）接入平台的靈活性與直接開發的靈活性，接入後會不會有無法支持的場景，那該怎麼辦？平台是否會一直維護？未來如果要脫離平台的成本，更換技術方案的成本等等。上午第三場是騰訊工程師分享的 微信小程序解決方案，這一塊不是特別感冒，主要持觀望的態度，主要講了些相比於傳統 web 的區別，比如：沒有 window 對象、無法使用 DOM 元素，非 URL 訪問，無跨域，無 cookie 等等，以及微信小程序在網路、安全、websocket 上的處理，但比較遺憾，分享的內容偏通信實現與後端架構，在前端層面只做了簡單介紹，沒有過多的展開，比如大家最為關心的開發模式與成本、前端性能、以及與目前 react native、weex 的異同與優勢等等。
下午第一場是螞蟻金服湯堯分享的 螞蟻財富的BFF實踐，剛聽到 BFF（Backend for frontend）的時候，會感覺這個概念很新。核心思想是在前端頁面與後端 java 間加入一層 node，讓 node 直接調用 java 架包，node 層完成多端 API 接入、裁剪、格式化、聚合編排，從而控制介面數量，規範數據格式，只把用戶關心的數據輸出給界面，同時也方便了數據的 mock。node 這塊我接觸的比較少，關於 BFF 需要再 review 一下。
下午第二場是 阿里小蜜的移動智能客服前端實踐 ，分享中的 pipeline 的前端架構給我留下很深刻的印象，參考了 middleware 的思想，從小蜜的特有的業務場景出發，將組件註冊到 pipeline 中，消息進入 pipeline 後尋找到對應的組件，然後返回給用戶，暁麥也現場演示了組件的即時替換，充分體現了架構的靈活性。而在小蜜的接入方面，統一了上層 API，底層通過客戶端檢測和配置腳本完成不同業務方的兼容。性能優化方面基於 RAlL 性能模型，利用好 Chrome 開發工具 Timeline 來分析整個載入渲染過程，這塊較為常規。
下午第三場是來自 UC 工程師分享的 大數據下的前端優化實戰。由於 UC 本身就是一個瀏覽器，因此提出基於 UC 內核的性能統計方式，相較於使用 w3c 介面來得更加精準，這個條件是一般 PC 與 App 無法達到的，因為用戶瀏覽器對我們並不透明。優化方案是基於用戶的行為數據分析得出的，一般用戶打開 UC 平均瀏覽列表推薦文章7篇，每篇文章平均瀏覽1次，文章所需要的前端資源除了媒體資源（圖片、視頻等）外是一樣的。由此否定了資源內聯的方案，內聯每次都需要請求整個頁面，而外聯除了第一次需要請求外聯的資源，之後就可以使用本地離線資源，而對於外聯的第一次請求通過頁面預熱、資源預載入的方案達到類似第二次請求的效果，來優化首屏時間。
最後一場分享是 @題葉 大大的從 React 到 ClojureScript ，才疏學淺，函數式編程的歷史，Clojure 與 ClojureScript 的概念，由於之前了解甚少，聽得基本處於一種懵逼的狀態。題葉大大應該看得很超前，希望將 React 基於 ClojureScript 來解決基於JavaScript 所導致的函數式不倫不類的問題，不知道這個點我是否 get 的對？感到題葉大大在國內一個人玩這套東西是相當寂寞的，至少現場我感覺很多人沒怎麼聽懂，提問環節有人還提出這能不能解決非同步流的問題，我想題葉大大是不是有點崩潰啊。。。大家在 React 全家桶下目前可能還停留於探索最佳實踐這個階段，語言層面的問題在當下可能因此被掩蓋了。關於 Redux 的 Store 抽象問題，這也有點體會，在我所在團隊的 Store 抽象中，是基於 Page -&> Card -&> Component 的，這是我們所基於的業務場景所決定的，之前我在 react+redux項目的協作中，如何解決state結構變動時可能造成的隱患？ - 淡蒼的回答 - 知乎 也討論過。
以上是我在分享中的快速消化，必然會有疏漏和理解上的偏差，歡迎大大們指正。
這是我第三次參與 D2，感觸頗深，2年前參與 D2，那時啥也不懂，就會寫點 C 語言，聽蘇千大大講支付寶node前後端分離，完全不知所云，難道前端不是html+css+js 么？node 是個什麼鬼？去年參與 D2，剛會點 React，聽承玉講 React 及其生態圈在螞蟻的落地，雖然沒有使用過整套架構，但可以基本聽懂。今年參與D2，最大的感受就是在分享中基本可以找到自己團隊實踐中的一些影子，大家的方向和思考有很多碰撞，包括樣式抽象、頁面配置、node中間層、性能優化等等。D2 記錄了我的成長，希望 D2 越來越好吧。看到一些回答，很有意思，打算以一個後端工程師的視角給你們補充一點看法。
這次 D2 我全程都在，早上在第一會場，下午在第二，比起去年在阿里園區那界，確實少了很多有技術含量的演講，反正我全程都在和不要透露姓名的聚聚，龍神，管管打情罵俏（刪掉）。
不過聽完 D2 我倒是有點欣喜，對於國內這樣幾乎全是業務驅動的公司，前端終於開始更多地關注「業務」和「價值」的重要性，說明前端已經快要邁過技術動蕩的時期，去思考自己如何才能產生更重要的價值。百度的吳多益分享的那幾套系統在我看來就非常屌，雖然他本人的演講風格令人有點昏昏欲睡，但他分享的內容其實對前端非常有啟發性，如何脫離繁瑣的業務，去關注平台、性能和價值。在校招必談批發價，談 flv.js 都能炸鍋的知乎，卻很少有人能誇兩句這個幾乎是晉陞範例的 ppt，我表示很難理解。
其實 BAT 都有這樣配套的系統，只不過參與的部門不一樣，面對的問題也有點差別，如果你參與了很多前後端的技術會議你就會有個感覺，就是 BAT 的分享相比小廠會顯得很水，這大抵就是原因。
我舉個後端的例子，現在 docker 非常火，但 docker 從技術上說，一句話就能概括完，cgroup + namespaces + image，都不是什麼新東西，比 10 年前的 lxc 略有創新的也就是那套鏡像打包機制，這兩年技術大會的常客 mesos k8s 從原理講大概也就是一張架構圖外加一篇文章。但 docker 的價值就在於他的這套打包機制，很好地補充了原來發布流程的缺陷，而容器帶來的不穩定也被更好的資源利用率所彌補，我們願意放棄 kvm 的溫床邁向容器的懷抱，這不是什麼技術優劣的抉擇，這是對於整體效率的權衡。
我因為部門的關係，工作有一部分職責是推動公司的 devops 文化，但這玩意跟技術本身有一毛錢關係嗎？根本沒有，把原來部門裡測試裁掉，運維裁掉，公司自然就形成 devops 文化了。。。才怪。為了保障整個研發上線流程的可靠，我們需要很好的項目管理流程，很好的需求管理工具，強大到變態的持續集成工具，還得有發布平台，監控平台，私有雲，甚至自建機房的公司需要有自動裝機工具。
所以類比到前端，如何發揮更大的價值？除了在在框架在語言層面折騰，我的建議是加強對流程和對端的控制，構建強大的持續集成系統，從測試接管對於質量流程的控制，產出更好的前端代碼，從架構手中接過上線和監控流程，加強對於線上治理的控制，用 nodejs 加強對於服務端的控制，還有你們一貫來的陣地瀏覽器和 hybird（如果拿到 CDN 的控制權那就更好了），做到這些，前端就能形成閉環發揮最大的價值，這也是為什麼我說百度的那個分享很有價值。
有個簡單的方法測試你離這樣的閉環還差多遠，google 新提交的 bbr 演算法，如果你想應用在你的應用里，請問需要多久的時間？對於創業公司來說這個時間應該很短，所以再加個問題， bbr 對於你的業務收益有多大？不算老人，亦不是新人，以我這樣的角度參加這屆 D2，最大的感受就是，前端的生態，在各大公司的實踐，優秀前端開發工程師的著力點，完全不是如阿當老師 - @曹劉陽 在 2016 年前端技術觀察 https://www.zhihu.com/question/53625757/noti-answers?group_id=793254798634930176 中所描述的那樣，2016 年的前端技術壓根不是這個樣子，好么！
一共聽了 7 場，比較在意的是 Fusion Design 、 Web3D AR 在天貓雙 11 互動中大規模應用 和 從 React 到 ClojureScript。
Fusion Design 就像一個中間件一樣，減少了設計師與前端溝通交互的成本，而成本向來是前端開發工程師，在各大公司的資源瓶頸，於是業界不斷湧現 Angularjs，react，react native，sass，less，stylus，vue，node，es6，coffee，typescript... 等等這一波又一波的技術演變，有語言層面，有工具層面，有組件設計層面，有前後端協作層面，而 Fusion Design 則從底層抹平由於技術壁壘帶來的協作成本，不能說一勞永逸，但也稱得上是農改解放。
Web3D 技術是一個很有意思的方向，如果用 CSS3 設計一個 3D 的網頁，很容易遇到性能的問題，所以 WebGL 應該是目前最好的方案了，使用 GPU 渲染畫面，還有成熟的 3D 貼圖技術，three.js 師出這麼久，卻沒有實打實的去把玩過，真是要好好補課，基礎固然重要，但是上層建築更要時常觀摩。
函數式編程有一種自己的美感，可以讓自己的代碼看上去像個聰明的孩子，被安利的一波 CloureScript 之後，內心也是蠢蠢欲動，這就是阿當老師可能會說的：你們新人要有定力，不要隨波逐流，見啥學啥，要夯實基礎。
但是我想，前端的魅力不就是欣欣向榮，一日百花，奇蹟競出，波浪滔滔響天下么，有誰非要壓制自己對於新技術的嚮往，而漠視這風雲突變呢。
如果大家都這麼想，我們就停留在 2006 年或者 2008 年，Flash 依然火熱，IE6~8 依然要剛性兼容，圓角依然要切邊角圖 Background-position 固定，jQuery 一統天下，回調地獄依然風靡全球，this 指向依然神秘難測，遠程調試工具寥寥無幾...
我很感激全球前端開發者的努力，Nodejs 社區的貢獻，瀏覽器廠商的知恥而後進(微軟也要不支持 Flash 了)，如我這樣的人，才有了今天這麼多的選擇，才有了這麼好的職業前景，才有了即便做一個遊戲死宅也能有那種工作尚還不錯，技術也能玩遍天下仍不過癮的程序員生活日常。
最後，感謝每一屆辛苦組織 D2 的童鞋，幫助這麼多人受益。
-
導言：本篇以前端新人為受眾，試圖推廣一種積極向上的前端參會心態，達成富強、民主的參會氛圍，用以實現文明、友善的會議大和諧。
一句話總結：本年度的 D2，「亮點」和「乾貨」都比去年少，不過這可能是個好現象。
一方面因第三屆 CSS 大會的同期舉辦，把講師團和老司機見面會強行分成了杭廣兩個分舵（沒算上海Strikingly還有場RN的小型交流），另一方面群眾可能受到 D2 夜場的前輩們在盡量剋制地表達某觀點磁場干擾，導致線上線下的交流討論都沒有去年活躍。
我無意流水賬搬記錄每場主題的參會感悟。稍等幾天，就可從官網下方「合作媒體」的某幾家獲取全部視頻與講義。隨著當下信息獲取會越來越便捷，很自然地，線下技術論壇進化為開發者面基論壇是遲早地事情。這不是純吐槽，對合適的人，帶著問題小團體溝通是非常高效的溝通方式，後面會細講。那麼歪個樓回答下「看了知乎對第11屆D2前端技術論壇的吐槽，你有什麼感受？」應該挺好玩的。
你像熬夜觀看 Apple 發布會一樣等待新品推出，你並不關注這些新產品背後實現的技術細節，但期待某個發布的最新產品改善了你的工作環境和生活品質。你只需接受刷信用卡般的接入成本，即可享受著封裝工藝精美，整合後的接近零成本開發等新技術帶來的快感。你關注訂閱各個技術門戶的推特和博客，與眾多的吃瓜群眾一齊站在前端技術的最前沿，感嘆科技之創新，時代之進步，期待某個新產品線能提升你在的團隊業務系統的迭代速度。遺憾地是：你掃過本屆D2發布會的所有演講者的標題，用失望地語氣嘆息到：沒有亮點。
咳……與手機市場相似，在我看來，當下的前端生態在充分擁抱開源、技術實現方式公開的前提下，也處於從寡頭壟斷逐漸向壟斷競爭市場的過度階段。兩個競爭團隊為了搶佔專利與佔有率先機，會採取提早發布0.0.1版繼而快速迭代小版本的策略。這樣的結果是，部分大廠發布的產品和技術框架在正式版交付前已經在社區炒得火熱。與此同時，很難再看到某個大廠的前端團隊，憋大招般地放出一個全新概念的框架和庫，其底層採用全新的支撐技術。
然而我認為，不放大招恰好是前端環境透明開放、良性循環的結果。你只要稍稍關注當前熱門的前端產品的演進路線，會發現他們各家都汲取了 YUI 的教訓，從高度集成的重型框架逐步拆分成積木般的性質不同的模塊。從構建工具，編譯工具，與框架本身幾乎沒有耦合性開始，構造函數，渲染函數，Addon 工具函數也進一步分離，同時提供函數式與類對象式兩種構造風格，虛擬 DOM，不可變數據，單向流與雙向綁定，響應式編程等模塊的選擇性接入…不一而舉。假設你熟悉前端框架的各個功能模塊的組成，會發現搭一個新框架的成本和難度比幾年前低太多了。
遊戲屆有句俗話叫「普通玩家使用默認配置，高級玩家使用自定義配置」，如果你還在吐槽選擇太少，技術選型只有全家桶可用，如果你的簡歷里沒法分辨「會 Webpack」與「會用 Webpack」的差別，如果你還在期待某個產品線和團隊，憋大招般的放出一個框架或者庫，易用性強，突然一下子解決工作中遇到的各種瑣事，是不是可以反思一下平時工作中太過在意技術「亮點」了？
你在全端與全棧的十字路口徘徊不定，小心試探並觀望著A黨，R聯盟， 和後起的V教各個武林高手西湖論劍，冷眼觀望的曾經輝煌一時的J帝國忠臣的悲涼地引戰吶喊；你剛練好了單向流的起手式，你像訂閱小道消息一樣刷著Hacker News、 Reddit 和 medium，左手 ReactiveX 右手 ClojureScript 兩本武林秘籍，小心翼翼地分辨著哪本是你的獨孤九劍，哪本是辟邪劍譜；此時你用眼角的敏銳地同時捕捉兩個會場，突然激動地發現其中一套連招正是你的期待降龍十八掌。你抓起手機衝過去希望錄下一招半式，要是會後再要份完整的 PPT 慢慢研習就完美了~卻發現屏幕右上角標著「本派內部系統，傳女不傳男」。只好嘴角45度向下感嘆到：沒有乾貨。
咳……假若讓我來定義「乾貨」這個詞，可以理解為解決某個問題的特殊技巧、實現原理以及某個領域的最佳實踐。我所看過的大會分享（包括錄製視頻）中，很少有講師能在四十分鐘到一個半小時的限定時間內，在照顧大部分聽眾能聽懂的前提下，把自己技術團隊大半年的工作，用深入淺出的方式，兼顧實現原理，覆蓋重要特性，語言生動有趣地講述出來。你感受下這句話定語如此之長，就知道這類型的分享要有滿滿地「乾貨」幾乎是不可能的事情。
然而（又是然而），在前端領域的分享中，沒有「乾貨」不一定是壞事。除了培訓教學的分享外，我並不希望分享者在既定時間內費時解釋其原理或者新技術科普的。為什麼？因為我可以在會後有會議數倍的時間去研磨實現原理——與夜場的幾位前輩講得一樣——通過研習前端技術或框架的源代碼。根據以前 D2 的傳統，至少阿里前端團隊在 D2 宣講的前端技術，總會在幾個月內公開大部分源碼，某些團隊乾脆直接貼出項目github騙star，笑。對於這類以代碼和框架為產出的項目，通常開發團隊都樂於接受開發者的有效反饋，只需要掌握讀源碼和調試技巧，多去issue上針對性地提問，獲取到你要的乾貨不是難事。
對於暫不打算公開源碼但有線上商業產品的前端技術或內部系統，通常會著重講解某種特殊場景下的特定的實現思路。如果你關注到某個實現細節，通過分享者留下的聯繫方式，正確地提問並且帶著問題去一對一請教（最好是郵件或者私信一次把問題說清楚）和獲取反饋（能解答的都會直言相告，可以提前想想用什麼信息與大神交換）。可以對分享內容和方式提出中肯的意見，作為不錯的切入點。當然，對於「你先加入我們團隊我再詳細解答」的情況，我也沒什麼更好的辦法，見招拆招吧……
那麼在分享中應該捕捉什麼關鍵信息呢？我更傾向於傾聽和試圖理解講師在什麼環境下，面對怎樣的受眾，為了解決什麼問題而做出了怎樣的抉擇和妥協。此時不必太過在意聽懂每一個技術細節（全聽懂的反而不正常），也不要因內容不適合你當前的技術場景就全盤否定這個技術方案。未來的前端，很可能在框架層面抹平，根據特定的場景搭積木般選擇接入與之適應的特性模塊與工具。
用 Fusion Design 舉例：可以思考一下講師是如何運用「開閉原則」對模塊樣式種類進行變數封裝與抽象的。在實現層面， DPL 對應 React 模板的技術，結合既有組件庫的實現方式（antd 的 perfix 命名空間，react-toolbox 的 mapToCssModules，blueprint 的classes）等實現類似 UIkit 的動態換膚功能，我預計不會有特別高的技術門檻（通過動手實踐，轉化成自己團隊的東西）。我真正在意的是，設計一套DPL作為各類產品線的設計師與前端工程師橋樑，在推廣階段一定會經歷各種實現阻力和妥協。這種工程實踐方面的真正「乾貨」，各種曲折，豈是通過一場分享即可全盤知曉的呢？
總得來說，亮點和乾貨少了，KPI 驅動的輪子也消停了。作為聽眾不要對期待參加某場技術會議，效果立竿見影。不要急於從一次分享中貼標籤，試著站在分享者的角度理解當前技術解決什麼場景的問題。像D2夜場的各位前輩總結的那樣：如果想深入到技術使用場景和細節，那就花一萬小時閱讀源碼動手實踐吧；如果想背後的設計思想和妥協，那就帶著問題找作者一對一交流吧；如果你想通過會議增長見識，拓寬視野，那就帶著一顆虔誠的心面基吧！（好押韻~）
勿忘初心，來過，愛過。
利益關係：沒正經用過阿里前端產品，但從其開源項目中受益頗多的開發者。-EOF-
加了 nw.js 作者的微信，發現了 nw.js 的一點小秘密Question: Electron Origins · Issue #5172 · electron/electron相關問題：維護一個大型開源項目是怎樣的體驗？ - zcbenz 的回答 - 知乎
有句話讓我感觸很深: 前端的初心就是前端的未來。
這幾年新技術層出不窮，前端的邊界和能力在不斷擴展，Desktop, Native, Server, WoT我們現在都能做了，但這些真的是前端么？前端到底是要解決什麼問題？前端的標準在哪裡？前端工程師相比其他工程師的核心優勢到底是什麼？...
我們好像都把精力放到了前端技術這個點上，而忽略了前端這個領域的使命是什麼。這樣在新技術浪潮里，很多人其實不知道自己要學什麼，因為他們並不知道自己要解決什麼樣的問題。
所以前端的初心到底是什麼？借Fusion Design周源老師一句話:
「鏈接商業，設計，計算能力，為用戶提供專業的人機交互體驗。」
這句話簡潔精鍊卻發人深思，明白了這個，也就明白了為什麼會有PWA, AMP, WASM以及各個公司推出的一系列為了更好提高人機交互體驗的諸如RN, WEEX, XCore, 微信小程序等技術方案了。
不忘初心，方得始終，我們不是需求機器，也不是技術信徒，而是一群有想法有使命的前端工程師。
以上是就本次D2最大的收穫了。至於分享本身，不要指望能學到很深的技術知識，能夠擴展自己的技術視野，了解別人解決問題的思路和項目的工程思想，並能夠應用到自己的業務中來就非常不錯了。第二次來參加D2，比第一次少了很多興奮。
上午聽了三場，分別是《Fusion Design》《前端服務化》和《微信小程序》。
《Fusion Design》是我們團隊開發的一套可配置組件庫，但又不僅僅是組件庫，它基於一套規範的 DPL(design pattern language)，保證了配置出來的組件的一致性。另外，它改變了前端和設計師的協作方式（設計師配置一套主題，可以導出 sketch，也可以發布成組件包給前端開發使用），這是其他組件庫不具備的。Fusion 大概在明年初開放服務，後續也可能開源。
這次 D2 最大的感受就是，好像乾貨越來越少了，變成了一個產品推介會，抱著開闊眼界的心態或和老友面基的心態來可以，但抱著很大學習技術的態度你可能會失望了。
附和前公司小夥伴們的面基照一張（只有飛哥和大師兄出鏡了。。。）
阿里 B2B 體驗技術中台工程產品團隊誠招前端、NodeJS、IOS、Android 開發，坐標杭州，P6+，有意者可以私信。（PS：我們團隊是公共技術團隊，做的產品都是同時服務多條業務線，比如前面的 Fusion 和前端服務化方案，在這裡無論你的產品觀還是技術都可以得到盡情施展，相當有挑戰~）
手機碼字，加上沒有全程專註聽，可能有紕漏，見諒～
update: 糾結會議分享夾私的同學，歡迎直接「打入」內部，切身體驗一下大廠內部的技術體系發展／工程效率相關建設，有意私信帶簡歷。
---
水一貼，恰好在杭州，就過來了。D2越做越好了，乾貨濕貨仁者見仁，畢竟背景不同，如果你願意聊實現，可以約個時間來望京阿里中心，我們慢慢聊。
見到了不少老同事，老面孔，老司機，一言不合就飆個車，當然也認識了一些新童鞋。
客串發票志願者，散發了一些票，見到不少網路真人，諸如@情封@丸子 等等...
和兩波老司機去吃了兩頓，東北菜和某創意菜還不錯。
最後，寒老師鎮樓……
最有感覺的是
期待 fusion design 開源～typescript 大法好
前端更新速度太快，D2這種活動越多越好啊～自己成長的空間還很大～
題葉大大的思想太超前了
因為是92後的妹紙且手機里安裝了釘釘獲得了一件T恤 哈哈 幸運
最後 現場的牛軋糖好棒啊
杭州，真的好冷。
迅速疏理本次D2的部分宣講的主題關注的點和問題
【Fusion Design】
&> 暫時未找到線上的該項目開源的地址，預計本次可能現場直接開源，假如只是現場演講，可能就成為團隊實踐的經驗分享。
- 在大量業務需求下框架是如何形成的？
- 業務線推廣的情況和阻力，怎麼克服？- 與其它同類組件競爭力？- 基於何類開源框架開發或自研的框架？【 Weex 在雙十一會場的大規模應用】
- weex 與 react native 各自適用的場景是什麼？與 react native 相比有什麼劣勢？
- 是否有份持續維護項目的計劃？（roadmap)例如音頻功能支持計劃等- weex 不支持的業務場景有哪些？【前端服務化：通向零成本開發之路】
- 跨部門推廣該平台遇到哪些阻力問題？
- 通過配置和可視化降低了哪些簡單重複的工作？帶來的效果是否有更直觀的數據展示【XCore —蘑菇街移動端動態跨平台開發框架】
- 密切關注與 weex / react-native 差異點？
【微信小程序解決方案】
- 將在什麼時候開放微信小程序社區？
- 是否會考慮引入更多開發者參與到生態里來？- 何時引入NPM模塊生態？（目前微信小程序不支持第三方模塊通過npm引入，需要比較繞的方式實現，例如構建一套自己的工程化環境）...... 夜深了，明天再戰我所見過得妹子最多的一次技術會，皂片作者: @穆心。多圖預警~流量君請自行選擇是否觀看~
謝邀。但很遺憾，由於本次D2與CSSConf（中國第三屆CSS開發者大會）時間衝突，我無法前往。可以邀請我回答「參加中國第三屆CSS開發者大會，你有什麼收穫？」
更新：CSSConf體驗已經回答，見：參加2016年12月17日廣州第三屆 CSS Conf 大會是個什麼樣的體驗？
【PS. 12月17日同時至少有5場技術和設計方面的會議，但我毫不猶豫選擇CSSConf，因為今年12月17日正好是CSS標準（https://www.w3.org/TR/REC-CSS1-961217）發布20周年。 】目前沒有看到亮點。不過這些技術產品的價值還是很高的。
大部分演講都太硬了，不注重聽眾的體驗。
這種行業會議是不是應該多講思考；數據和實現步驟提一下就好，畢竟大家都是前端。
沒有 Ruby Conf 的演講聽著過癮。也許下次應該去 CSS 開發者大會。
天貓晚會的 AR 確實是讓用戶眼前一亮，不過小公司沒這個成本去做。
期待 @題葉 的演講中。
困，先休息會。
等到了。
幻燈片看起來是最高級的。
編程語言的歷史
各種函數式編程語言。最終講到 Clojure
開始講 React
1 都有純函數的概念
2 組件。組件模擬純函數，引用透明，可複合成高階組件。3 都有不可變數據概念。
數據不可變但是引用可變。
然後是一些思考
產品推介會。 乾貨太少。實在聽不下去了。提前走了
可莎蜜兒的麵包好吃的 hahaha 居然有五個贊同，看來大家下午都餓了。。。早上在一號廳聽了三場，分別是Fusion Design、前端服務化、微信小程序。首先第一個Fusion Design，第一眼看到以為是螞蟻金服的ant-design，實際上不是。它設計的初心是使UI設計師與前端工程師能協調同步工作，它基於一套規範的 DPL，保證了配置出來的組件的一致性。預計明年（農曆）開放使用。前端服務化不管是東西還是設計理念都很好，可惜百度的演講依舊。。。微信小程序沒有太多的在講小程序的設計，而是在介紹小程序和微信伺服器如何會話以及騰訊雲的產品-Wafer，提問者問了許多微信小程序的性能以及開發上面的問題但都沒有得到很好的回答。。
昨天D2回來困到不行，回到家洗洗睡了，今天翻看知乎上大家對於D2的吐槽，有人說是產品發布會，有人說是在秀輪子而且修完還不給我們玩，也有人說不虛此行的。我也談下我的感受吧。
昨天我大概聽了7場分享，由於昨天早上才趕到杭州，所以第一場關於fusion的分享聽的不是很全面，但是今天 遠舟在群里收集了一把郵箱，然後每個人都發了一封郵件，關於昨天的分享的內容和ppt。
1/Fusion Design-解構設計，抽象工程
Fusion 不僅是一套涵蓋多端、多品牌、可配置的組件庫，並重新定義了 「體驗工程」 的工作方式。她對感性和藝術性工作進行解構，對工作流程和工程能力進行抽象，形成體系化的解決方案，賦能自身和業務方，真正實現跨團隊的設計與組件復用，是前端、 UED 工作方式突破和創新！
這雖然是阿里內部的一個技術項目，但是這個實踐的分享對於我們日後的工作方式也許會有一定的指導意義，讓設計師和開發者之間的協作方式更加高效，同時也讓我們能夠跳出我們平時工作的角度，跟著分享一起從一個更高的角度去審視我們的工作和工作方式。QA環節貌似大家最關心的就是這個項目什麼時候開源，看到一個讓我們眼前一亮的東西也許我們都希望能夠體驗或者在我們的工作中使用，但是我覺得這個項目的思考方向比技術本身更值得讓我們去思考和學習。
2/前端服務化：通向零成本開發之路
前端開發經常需要面對許多看起來簡單重複的工作，比如運營頁面、內部平台、數據報表等等，我們開發了 FreeFE 系列平台，它使得這些重複簡單的工作都能通過可視化操作和配置來完成，極大降低了人力成本，並且明顯提升了項目質量，提升了內部工作效率。
前端服務化，其實這個思路和fusion的方向時一致的，都是為了減少協作成本提高開發工作效率的一種思考和實踐。這個也許做起來會更加有難度，因為不同的場景和定製化的需求會使得做一個全面的服務平台更加點複雜，但是這個做的卻是比較徹底的。這個思路很多的建站工具很像，讓學習的成本很低就可以完成開發的目的。這個話題是很好的一個話題，但是整個分享聽下來卻像是在彙報工作一樣，都是在用數據證明這個平台對於公司的各方面的提升，反而更應該細緻的分享一下一些實際的設計和開發中前端的角色，我相信大多數同學都是去聽技術的，對於那些數據反而不是那麼的關心。
總結下：很好的一個話題和方向，但是分享的效果卻不是很理想。
3/微信小程序解決方案
今年11月初，微信小程序開始公測。小程序是一種新的開放能力，開發者可以快速地開發一個小程序。小程序可以在微信內被便捷地獲取和傳播，同時具有出色的使用體驗。那麼在小程序的開發過程中有哪些挑戰？ 《wafer》 微信小程序全棧解決方案，和您一起探索。
這個本來抱著很大的期望來聽的，從這場的人數可以看出來，大家也許對這場都抱有了很大的期望，但是只能說套路太深啊。關於小程序只講了一些官方文檔中也有的內容，反而主要是講後端通信和架構，主要就是為了引出硬廣 wafer的一款產品。其實一整天停下來，只有這個我覺得算是產品推廣，因為其他的一些實踐項目，它們都是一些對於前端發展的思考和優化的項目，是值得我們去學習的，而這個就是一個為了借小程序推廣產品的分享。本來以為這個分享會是微信小程序團隊的同學，最後發現缺是騰訊雲的，QA也是各種不知道和不了解。總體來說有種被騙的感覺。
4/螞蟻財富的 BFF 實踐
隨著無線的普及，近幾年用戶訪問的形態越來越多樣化，環境也越來越複雜，隨之而來的前端開發成本也慢慢升高，BFF （Backend for frontend） 就是應對此類問題的一種架構上的探索和實踐。這次分享將會帶給大家我們在螞蟻聚寶業務中，進行的一些實踐和思考。
BFF是一種實踐和探索，這也給很多多有這方面困惑或者問題多同學或者團隊提供了一些幫助，主要從為什麼會探索BFF模式，什麼是BFF模式，以及一些實踐過程中的優勢和缺點去分享了BFF這種在越來越多樣化的訪問形式下怎樣幫助我們去降低開發成本。總體來說本場的乾貨還是很乾的。
5/Node.js 在 YunOS 中的最佳實踐
YunOS 是萬物互聯時代的操作系統；Node.js 天生擁抱互聯網，在服務端對 IO 敏感的計算證明是高效的，把 Node.js 引入到 YunOS 的基礎架構中，在這個過程中我們總結了一些獨特的實踐經驗以及創新思想，對 YunOS 的發展起到積極的推動作用，同時也對 Node.js 的發展有啟發意義。
這場分享其實幹貨是很多的，但是感覺超出了前端的範疇，雖然是nodejs相關的分享，但是是在操作系統層面的應用，就拿對於事件循環中yunos對於node的隊列的改造就是操作系統的知識，只不過是用了nodejs的載體，所以大家的反應一臉懵逼。說實話我都快睡著了。
6/大數據下的前端優化實戰
跳出 Webview 的範疇來審視頁面的資源載入、渲染以及緩存等機制，從頁面瀏覽涉及的全路徑上（後端、網路環境、前端、外殼、內核以及中間件等）進行全局思考，尋找出最恰當的性能優化策略並實施落地
這個分享是我比較感興趣的一個分享，因為最近我在工作中正在做關於優化的事情，雖然分享中也充斥著大量的數據對比來證明優化的性能，但是乾貨還是比較多的，從各個方面（後端／網路／前端／瀏覽器等）分析存在性能問題的因素，然後並對應的多端協作完成優化。有一點比較贊同的是性能優化不單純是前端的優化和事情，應該是個部分協作一起來完成的一項工作。畢竟性能存在的因素也是多方面的。很多關於前端方面的 優化建議跟網路上談的優化方法不一樣有的是截然相反的，但是卻是正確有效的方案，就拿css的內鏈和外鏈，就是一個很好的例子。
7/興趣部落的架構演進與服務優化
興趣部落做為一款億級 PV 的社交類 Web 應用，技術側也在產品的快速發展中不斷尋求架構突破，保障開發效率與質量。本次分享將介紹整個項目架構演進與重構的過程，在組件化與工程化的實踐思考，以及在性能監控、用戶反饋響應的優化提升。
這個分享講了一個全面完整的前端架構過程，從各個方面的一些思考和實踐，我想一般的團隊都會有同樣的經歷，這也許讓我們更能理解對於本身項目架構的優化和調整的一些思考。這個分享和上一個優化的分享可以說是完全沒有秀輪子嫌疑的吧。
總體而言：
慢慢的一天行程，雖然大家各種吐槽的都有褒貶不一，但是蘿蔔青菜各有所愛，加上每個同學的技術水平不一，所處的環境不一，眾口難調。我個人感覺總體上聽的這7場每一場都有每一場的價值所在，無論是不是產品推廣和秀輪子，實際上都會給我們帶來一絲的思考。這也許就是分享的意義吧。
感覺聽了一上午的產品發布會。fusion的產品發布會，百度內部產品發布會，小程序的實踐方案，感覺講了很多，但仔細想想，又覺得和小程序沒什麼關係。
於是中午場結束，午飯是前端網紅@前端小強小強和@一絲 姐姐請客，一絲姐姐還現場幫妹子debug代碼，贊到不行。
大獎被我拿走了，哈哈
上午在一號廳聽了3場，第一場fusion,PPT做的不錯；第二場前端服務化，PPT做的很一般；第三場微信小程序PPT也一般般，有些配色反人類。學渣就只能從這個角度給答案了。
推薦閱讀：
※package-lock.json 需要寫進 .gitignore 嗎？
※深JS(2015 JS中國開發者大會)有哪些女生參加?
※如何評價fibjs？
※Promise then中回調為什麼是非同步執行？