第十五期 AMA 掘金團隊請來了來自前端娛樂圈的老人 & Facebook 實習生 & CS 研究生美國在讀-- Hux黃玄做了為期三天的 Ask Me Anything (AMA) 活動（活動已結束）。
我們在此精選了一些來自使用者的提問及黃玄的回答。
關於黃玄
- 個人掘金主頁：juejin.im/user/55e9d1…
- 微博：weibo.com/huxpro
- 知乎：zhihu.com/people/huxp…
社群小夥伴精選提問--非技術直接相關類
阿里互動設計轉飛豬前端的契機？當初做了多少準備？ ─ @ALISONLY
阿里互動設計轉飛豬前端的契機？當初做了多少準備
當時因為人在北京所以互動實習選擇在北京而非杭州，可惜北京那時並沒有太多好的互動設計團隊，所以被安排的工作非常沒有挑戰性，於是動了轉前端的念頭。我通過內部的旺旺聯絡了之前知道的 拔赤，他在聽到我的聲音後列印和我聊一下，最後同意了我轉崗到航旅前端團隊的申請，分在了他親自帶隊的無線團隊下面。
當初其實並沒有做太多準備，可以說是天時地利人和吧。那時前端技術門檻確實比較低，自己只是剛剛看過一些高程，能用 jQuery 寫一些頁面的水平。而且那時懂互動在前端中的地位我覺得比現在更高一些，畢竟那時候大部分前端還是 「UED」的思維，而現在則更接近大部分純開發團隊。那時無線前端（Mobile Web）興起，拔赤的團隊剛好在拓張缺人的狀態，我也比較主動，畢竟已經以互動方式進了阿里，所以得到了這個機會。
你是如何在前端領域下沉澱下來的？學習心得是什麼？ ─ @Calpa
你是如何在前端領域下沉澱下來的？學習心得是什麼？
這是一個很難回答的好問題，實話說得話，我並沒有覺得我在前端領域下沉澱下來了。
這幾年工作學習下來，我愈發覺得前端領域有著非常強的複合與交叉性：
前端技術主要依賴其宿主平臺的發展，而即使是後者也只處於電腦科學的應用層面，註定受網路、圖形學、程式語言、系統等更基礎領域的發展的交叉推動。 前端技術的自身發展（層展現象）則更像是上述眾多因素的一個快照，旨在以提高生產力為目的滿足「某特定時代儘可能多的特定需求」的軟體工程產物，容易有技術斷層。 前端技術的廣義定義與工種需求主要受產品、市場、裝置形態、人機互動方式的影響，廣義來看不僅包括 iOS/Android，更是包括了 wearable、VR/AR/體感外設等，這就導致會有完全不同的技術棧需求出現。
所以我個人的愚見是，可能只能在前端所涉及的這些更細分的領域（包括但不限於我所能列出的這些）才能沉澱一些「跨越不同時代的前端技術棧」的東西，而不能期待直接在前端有所沉澱。
如何跟上前端的更新步伐，如何取捨一些技術，如何評估自己所處的階段欠缺，如何評估自己的薪資。 -@前端小屌絲
前端初學者，如何跟上前端的更新步伐，如何取捨一些技術，如何評估自己所處的階段欠缺，如何評估自己的薪資。
關於「如何跟上前端的更新步伐」：前端的快速更新既是真的也是假的，真是因為「層出不窮的業務需求」以及「活躍的開源社群」。假是因為「萬變不離其宗」，其實也只有「應用組織方式」、「程式語言與正規化」、「web 平臺 API」等有比較突破性的變化。
關於「如何取捨一些技術」：無論使用的是什麼技術，往上走必然會走到一個更高的抽象層面，這個時候所有「變化的表象」就 merge 成了「更不變的基礎」： Domain-specific (領域特定) 的有一大堆 spec 規範（TC39 的 ECMAScript、IEFF 的 HTTP、W3C/whatwg 的HTML/CSS/WebAPI）和框架的「特徵」（MVC/MVP/MVVM/Flux、資料流、狀態管理、廣義的「髒檢查」、廣義的「髒更新」等等）
電腦科學來說有「程式語言理論」（型別系統、執行時、OOP/FP/FRP 等正規化）、「系統」（比如 GUI 併發、網路 IO 的並行與併發、各種快取）、「圖形學」（渲染/動畫/視覺化的實現與效能優化）、「軟體工程」、「資料庫」、「安全」…… 所謂「條條大路通羅馬」，有句話叫「有造輪子的能力和不造輪子的覺悟」，我覺得對很多技術則可以抱著「有學輪子的能力和不學輪子的覺悟」來看待。
關於「如何評估自己所處的階段欠缺」：可以閱讀一下有關「前端領域有著非常強的複合與交叉性」以及「成長」的其他回答，思考一下自己離想成為的「那種角色」還欠缺什麼？
關於「如何評估自己的薪資」：不是我擅長的……看脈脈？
對選什麼方向考研有一些迷惑 -@某某某同學
您好，我是大二軟體學生，想問問前端讀研推薦什麼研究方向，在國內大學對前端重視程度大多不高，我現在的一個老師（他是博士）對前端的評價是“簡單，只用做一個頁面” 由此，我對選什麼方向考研有一些迷惑，希望得到解答，謝謝?
「前端讀研推薦什麼研究方向」：「前端」自身顯然不是一個可以進行「（學術）研究 」的領域，希望我關於「前端的複合與交叉性」的其他回答能給你一個更全面的理解。
「老師（他是博士）對前端的評價是“簡單，只用做一個頁面”」：評價「前端」「“簡單，只用做一個頁面”」顯示又是過於草率的。但站在一個（假定）「電腦科學」博士的角度來說，大部分「前端在實際業務中所要解決的複雜問題」在他眼裡「很可能都不是一個所謂的前端問題」，所以這是可以理解的言論。
「方向」:= 「對於應屆生想做前端領域的工作有什麼樣的學習建議和找工作的建議」
有哪些計算機基礎知識讓你覺得在工作中依然能夠受益 -@2014_
有哪些計算機基礎知識讓你覺得在工作中依然能夠受益，希望能夠推薦幾本書
這是這次 AMA 裡我最喜歡的一道問題 ;)
關於「基礎」、「成長」、「深入」的問題很多同學都在問，我想直接在這個回答下面總結一下我自己的感想。
「在特定領域內工作與學習」可以被認為是一種 Top-down （從技術棧的應用層向更下）或者說 Just-in-time 的學習方式，很多非科班前端（或者任何覺得基礎不夠用的時候）的學習路徑可能都會是比如 「JS -> JS 中存在的程式語言特性與模式」 「JS Callback -> EventLoop -> 併發模型」 「JS -> Babal +| V8 -> 編譯原理、程式語言執行時/虛擬機器」 「React + Redux/Flux -> Immutability/FP」 「Flow/TS/ReasonML -> 型別系統」 「CSS -> 瀏覽器渲染引擎 -> 圖形學」 「Ajax -> HTTP -> TCP/QUIC -> 計算機網路」 「實時通訊 -> Web Socket -> Socket」 「寫 UI -> 寫更好的 UI -> UX（使用者體驗）」 這樣的路徑。這種方式是不可缺少並且在很多時候更加快速實用得，但這種方式可能會由於對「共性更強的基礎知識」的欠缺比較容易出現「覺得永遠都在跟進新東西」的感覺，並且缺乏「創新」所需要的視野。
我在「如何取捨一些技術」裡提過：無論使用的是什麼技術，往根上走必然會走到一個更高的抽象層面，這個時候所有「變化的表象」就 merge 成了「更不變的基礎」。（這裡請想象一顆樹，根是最 generic/abstract 的基礎（你也可以理解成基類或者型別理論裡的 Top type，比如 OO 語言中的 Object），越往葉子節點是越 specific/derived 的技術（你可以理解為派生類）
而「CS 基礎的學習」相比之下則更像一種 Bottom-up（以技術棧比喻）或者說 Ahead-of-time 的學習方式，你可以從一種「更高層次抽象」的方式去理解新技術，並且更容易「子型別化」出新的東西。
React 從架構上來說，其實是越來越接近一個程式語言虛擬機器的，而從設計模式來說，是越來越接近 Haskell/OCaml 這樣的函數語言程式設計語言。這些都不是「原有的前端領域內知識」可能自然演化出來的。 這也從另一個側面回答了為什麼中國很多技術團隊創新能力不如國際團隊，即使只限定在前端框架領域，大部分在技術模型上有突破性的框架也都來自國際團隊：Knockout/Rx 來自微軟，React 來自 FB，Angular 來自 Google…
所以很多同學問的如何「基礎」和「前端有什麼深入的方向」也都可以從這個角度來回答，比如說我相對了解比較多的「程式語言」領域，「哪一門語言對前端未來發展或是學習上有很大幫助」？
從 JavaScript 來說，JavaScript 是一門比較雜交的語言，其發明與發展過程一直到目前為止也主要是「借鑑」其他語言的特性。這些特性通常在「原有的上下文」下有著更好的表達，另外大部分這些特性技術（OOP、FP、型別、執行時）本身的或學術或業界的發展也都是貢獻在這些語言而非 JS。所以說「基礎」可以是「學習 JS 發明與發展中過往或正在借鑑的語言」，「深入」可以是「瞭解這些語言的發展、瞭解 TC 39 的動向、瞭解未來可能影響 JS 去向的語言、影響或貢獻 JS 語言的發展」等。 舉例來說：
- Scheme 作為 JS 的最主要本源之一，學習 scheme 或類似的 Lisp 方言會讓你對 lambda 運算元、first-class function、CPS、closure 這些函數語言程式設計概念有更純粹的理解，並對這些概念在 JS 中的運用有更本質的理解。
- Java/python 或類似的 class-based OO 語言會讓你對 ES6 以及未來 ES 的 class、field、property、（private、static）有幫助；
- Java/OCaml/Haskell...等任何一門強型別語言會讓你理解「型別有什麼作用」、「型別安全是什麼」對 TypeScript/Flow/Reason 的各種概念和設計有同樣幫助；（比如讓你更容易理解 subtying、variance、只讀只寫的關係等）
- Rust/Swift/Kotlin/OCaml/Haskell 等嘗試用某種靜態分析機制約束異常（比如 option type 或 checked exception）、非同步（比如 Promise、async/await）等「效果」的程式語言能讓你對 JS 的未來、或是 React 這樣的框架 API 設計有幫助；
- Rust/C++ 能讓你對一切跟指標和記憶體有關的概念有無可替代的幫助；
- 學習任何一種與 JS Event Loop 不同的併發（或更好的支援可能的並行）模型的語言會讓你對「同步非同步」、執行緒程式、阻塞非阻塞有超過「能理解他們的字面意思和比喻」的理解…對 Web Worker、Sharedworker、sharedbuffer 這些 Web API 有幫助；
- 學習 assembly、JVM bytecode、stack machine 會對 web assembly 有幫助；
- 學習任何一門編譯到 JS 的語言都會讓你對 JS 「有什麼缺陷」這件事有幫助； ……
在「你是如何在前端領域下沉澱下來的？學習心得是什麼？」說過得這裡就不重複了，前端的複合性體現在他對眾多電腦科學（和其他學科）領域都有依賴，而不是說「層展現象」就完全替代電腦科學的基礎作用了……
我自身讀過的書並不足以推薦太多書籍，但是參考美國大學的課程教材（也就是那些知名大學教授編寫的經典書籍）絕對足矣。比如 程式語言相關的 SICP、TAPL、PAPL、Software Foundation、虎書、龍書… 計算機網路的 Top-down approach 體系結構的 CSAPP …… 這些教材都是「大部頭」，相比於大多「行業內的工具書」要嚴肅嚴謹得多，並且有大量「習題」，可以說能啃下來任何一本的任何一個章節都會有一種「被重新整理」的感覺。 除了書籍之外，如果希望對某個領域有非常理論化或前沿、試驗性的瞭解，可以嘗試觀看、閱讀學術會議與期刊的 presentation 與論文，其實很多都非常有趣。
以上。
碰了這麼多語言, 最喜歡哪一個? -@題葉
碰了這麼多語言, 最喜歡哪一個? 還喜歡 JavaScript 嗎?
碰得多了，反而很難挑出「最喜歡」的了。
- Rust 語法現代友好，記憶體管理方式卻是與 C++ 的 RAII 最為接近，然而其核心則幾乎就是一門 ML 方言…？
- Haskell 經常以 ML 方言被提及，然而其核心抽象方式 Type Class 卻更新 Java 等 OO 語言的 Interface 與代界多型…？
- Java 總是作為 OOP 語言的典範，其泛型（引數化多型）是由兩個函數語言程式設計教父（Haskell、Scala）設計的…？
- JavaScript、Python、Java 到底誰更誰走得更近？從語法來說 Py 好像最不同，從型別來說只有 Java 是靜態型別，從核心來說 JS 的核心則無限接近 Scheme + Self？
- OCaml 的 Module、Haskell 的 forall 的一種、Java 的 wildcard、Scala 的 existential，都是一個叫做存在型別的東西？
- 有沒有 Subtyping？Variance 怎樣才不會像 Java 陣列那樣不安全？有沒有 Coercion？
- 有沒有分清 Void 與 Unit？有沒有 Null？有沒有 Option？ 保障 null safety？ higher-kinded, higher-ranked?
- Immutability vs. Mutablity？
- Pure？Pure vs. Total?
客觀的相似和差異性總是存在的。 雖然我很認同王垠說得「語言不是工具，而是材料」並且認為「使用的語言會大大影響程式設計師的 mindset 與解決問題的方式（資料結構、演算法、組織……）」，但「看山不是山」後「看山還是山」，這些差異也使得程式語言有著不同的擅長於不擅長。
JavaScript 仍然是一門優秀的 動態型別 GC 語言、尤其是其 scheme 核心的特質使得 JS 與 Py 尤為不同，造就了其特有的利用回撥（CPS）的併發模型，直接影響了所有 web API 的設計與 Node 的出現，也奠定了其未來對函數語言程式設計的優秀支援…而 TC39 在升級過程中大量吸納包括 Python 在內的語言同時又使其語法更加現代化。
如果一定要說一個，我現在「最喜歡的『程式語言』」是「lambda 運算元」。拋開語言之間 insignificant 的差異，大部分這些特性在學術界都是使用 lambda 運算元來進行「形式化」描述得，可以說是一門「自選 feature」的語言了，當屬 “the mother language of all programming languages” 。
社群小夥伴精選提問--純技術
想聽ReasonML在facebook的實際應用的經驗？ ─ @DB維一(s.y)
想聽ReasonML在facebook的實際應用的經驗
這個問題就大了…不知道您具體關心的是哪一點？ 從使用情況來說，據我所知像 Messenger.com 幾乎完全 ReasonML 化，Ads 有大量基礎設施使用 ReasonML，Instagram 等其他產品有小部分功能在使用。 從使用體驗來說，主要帶來的優勢還是其背靠 OCaml 的型別系統：幾乎不需要顯式寫型別的型別推斷、遠超 Flow/TS 的速度、以及與 Flow/TS 最主要的區別，完全 “sound” 的型別檢查。這代表著用 ReasonML 編寫的程式碼在執行時有著絕對的可靠性。缺點是較 Flow/TS 更高的遷移門檻。
感謝回答，還有幾個問題想了解下。 1,遷移的過程中除了學習語言本身和給其他library寫binding之外還有其他可能會遇到的阻礙嗎； 2,在開發效率上相比flow和ts是提高了還是降低了；
- 主要就是這兩個阻礙了，另外關於「寫 binding」可以看一下 genType！相當於自動化了 Reason <-> TS/Flow 的 interop
- 這個主要是「人」的問題，我覺得很難有一個指標去硬性得衡量。比如說 TS vs JS，花時間寫 type 與省時間 debug type error，如何衡量誰的效率更高呢？
pwa除去service worker，和普通h5，有什麼區別呢？ -@一條沒有夢想的鹹魚
請教一下，pwa除去service worker，和普通h5，有什麼區別呢。你們在開發pwa遇到過那些優化或困難呢
PWA 較完整的介紹還是可以看我之前寫的大長文「下一代 Web 應用模型 —— Progressive Web App」huangxuan.me/2017/02/09/…
Technically，我不知道「普通 h5」的邊界到底是什麼。但是 PWA 除開 SW 之外，最主要的是在 「更好的、跨平臺的『類第一公民能力』」，比如單獨的應用視窗與 icon、推送通知等等。
PWA 可以帶來的「優化」與「困難」主要還是在 SW 的運用上：
SW 可以做的「優化」可以說非常有想象空間：「想象一下給你一個可控的使用者端的快取你能做什麼？」而快取可以說是解決 IO 效能問題的一種通用手段，具體解決哪一部分 IO 、IO 資源如何分配，這些都要具體問題具體分析了。
SW 所帶來的「困難」一是與其他特性的「interop(互互動)」，比如我之前寫的「餓了麼的 PWA 升級實踐」中提到的瀏覽器多頁渲染模型的效能問題：huangxuan.me/2017/07/12/… 二是其本身帶來的「複雜度」，比如快取更新策略、快取使用策略、工程問題等等。
特選：關於國內外的那些事
希望介紹一下美國大公司前端的招人流程和內容 -@Hc_Zzz
希望介紹一下美國大公司前端的招人流程和內容
主要的差異還是在技術面試的內容上，國內更偏重領域/業務相關的知識，重點看你能不能幹活。美國這邊「基本的資料結構演算法」仍然是必考甚至最重要的內容。總得來說，無論你是科班還是“野路子”，美國這邊的內容要更偏重電腦科學素養而非幹活能力一些。
關於在美國留學初期的經濟收入，和美國的消費。 -@明非
關於在美國留學初期的經濟收入，和美國的消費。
Hi 明非 ;)
留學的經濟問題確實比較頭疼，我自己主要是從幾個角度「緩解」，但大頭還是靠家裡和以前的積累來支撐，很難做到收支平衡：
- 獎學金 —— 理工科即使是研究生也還是有學校提供獎學金的，我選擇的學校給了我半獎，而且據我所知（之前微博上流傳過），有的學校招有經驗的工程師兼職給他們幹活是可以給到全獎的。
- TA/RA —— 教學助理和研究助理。按小時給工資，基本上在 10刀 - 30刀/每小時工作這樣，解決日常開銷足夠
- 實習/Coop —— 利用暑假或者某個學期使用 OPT 去公司實習，這個期間是不用交學費的，矽谷工資的實習收入大約有全職員工的 60%-80%。
美國的消費很大程度上取決於你生活的城市，村裡和城裡的差距可以參見二線城市 vs 北上廣，差異比較大。基本的消費水平因人而異但是基本隨便搜尋一下就可以估計出來。
你好，你覺得目前中美CS研究生的水平差異大嗎，體現在什麼方面呢？-@ChakkeiLam
你好，你覺得目前中美CS研究生的水平差異大嗎，體現在什麼方面呢？
說實話我沒有在國內上過 CS，也不瞭解中國 CS 研究生（ 只能說我覺得美國這邊 CS 研究生非常偏重「科學」和「學術」，這點國內可能有一定缺陷
畢業三年的非科班還有機會去fb等大廠嗎 -@1003
畢業三年的非科班還有機會去fb等大廠嗎
永遠都有機會，出國工作主要需要解決的問題是：
- 簽證（通常通過留學然後申請 H1B、跨國公司工作一年 L1 遷到總部 如輪子哥）
- 英語
- 技術（白板面試） 很多國內程式設計師覺得 3 是最難的，其實 3 反而是最最最最最簡單的。
本期 AMA 黃玄同學也回答了很多其他的技術、非技術問題，歡迎去他的 AMA 下面交流技術喲，傳送門