對於《2016年前端技術觀察》的一些看法

近一年來和真阿當有關的話題實在太多了。。。

我覺得我也有很多槽想吐，所以就直接全文吐槽一下吧。。。

我先說一個我的一個核心觀點，我們做需求的時候，經常把用戶當傻子，但是我們不能把程序員也當傻子。做程序這行本身就需要不斷學習和探索，如果連這點都做不到，那我們不是只是要個切圖工具了。

真阿當的文章鏈接如下，可以對照看。

資深Web技術專家曹劉陽：2016年前端技術觀察 - 極客頭條 - CSDN.NET

關於CSS預處理器

這裡真阿當拋出了幾個問題。

• 所有開發團隊成員需要安裝預處理工具，需要學習預處理器語法，增加了上手門檻。

首先，安裝預處理器本身，依賴於目前我們簡單易用的npm，這已經不是什麼門檻了。至於預處理器語法。首先是我們熟悉的28原則，而實際上我們一開始學習的時候，也可能只需要學習這20%的語法就可以滿足我們大部分的需要了。是的，我們不需要預處理器也可以解決這些問題，但是你用了預處理器以後，你的css可以更優雅。而且還可以處理一些不太方便人為處理的工作。例如說移動端 px2rem 的轉換。

• 不可以直接對編譯後的CSS文件進行修改，要統一修改源文件。這在調試時，增加了工作量。

調試時都是 sourcemap，而且說實話，我們處理 css 問題的時候，其實通常是看看為什麼這個東西沒有按預期出現呀，為什麼有些變形啊之類的。這些其實跟我們預處理器並沒有太大的聯繫，具體的規則調試和我們用不用預處理器一般關係不大。

• 源文件增加了很多原生CSS不具備的功能，如定義變數和嵌套，這在提供方便的同時，也引入了一些不必要的麻煩，比如嵌套帶來的副作用——CSS選擇符權重增加，HTML結構與樣式掛鉤耦合，以及預處理器層面需要增加規範（變數和mix模塊放在什麼地方定義、文件如何拆解以配合@import導入、什麼時候定義新的class名、什麼時候使用嵌套），以方便團隊合作。

是的，我們需要一定的規範。但是規範不好嗎？

就算你直接使用原本的css，想要更高效的進行團隊合作不也是需要規範的嗎？制定規範是需要成本的，但是它是有意義的。我們沒有理由拒絕團隊規範的產生。

至於什麼html結構和樣式掛鉤之類的，如果你不需要嵌套，那就不要寫嵌套。非要瞎寫，用什麼都攔不住你。

• 如果需要跨團隊合作，如將代碼和另一支不使用預處理器的團隊的代碼做整合，會怎麼樣？

說真的，我一直覺得這幾年大家不提預處理器不是因為用的人少了，而是因為這已經變成一項基礎能力了。說實話，學個 less，sass 有啥成本？

• 如果團隊有人離職，他維護的代碼在交接上是否會需要多進行一些溝通？有新人入職，是否在正式工作前，需要學習預處理器語法，以及公司關於預處理器的使用規範，導致進入工作狀態的成本變高了？如果團隊在新人入職後的新兵訓練營工作做得並不好，又會怎麼樣？事實上，很多公司壓根沒有什麼新兵訓練營計劃吧？

講道理，連個預處理器都不能自己學習使用的人，感覺當隊友風險很大啊。

• CSS預處理器帶來的這些麻煩，一旦上升到團隊合作，成本和風險就大了，因而並不是筆低成本買賣。再看看它號稱的收益，是否真的沒有別的解決方案了，如果有話，即使是單兵作戰，是不是也不是什麼高收益的選擇了呢？

是的，有別的方式，但是既然已經有工具可以幫你很好的處理這些場景了，為什麼還非要自己搞一套？

跨界、CoffeeScript、TypeScript和ES6

真阿當在這裡提了很多例如說這些都是語法糖之類的。

首先說我對於語法糖的看法。

以前我們經常通過保存 this 的值來保證，我們可以訪問到我們所需的 this 值。那我們是不是要自己處理？沒有箭頭函數我們是不是就要自己寫？但是既然別人都幫你提前準備好了你本身可能要做的事情，那麼為什麼還要自己處理。

更不要說新標準的推進會促使這些方法被原生實現，提升了性能。不過這些性能雖然幫助不到，但是我想所有的程序員都會有想讓自己的代碼運行的更快，代碼更美的想法。別人來幫你把代碼寫的更美，你竟然還要拒絕？

對於 CoffeeScript 我是不太喜歡的。不過 TypeScript 我是很喜歡。具體就不詳述了。

然後我來說說 ES2015。

首先 ES2015 本身並不是簡單的語法糖。很多特性是無法直接被 ES5 模擬出來的。這賦予了前端語言更強大的能力和更優美的寫法。寫 ES2015 開心嗎？我想我是開心的，和我一起工作過的團隊成員也是開心的。很多事情語言幫你做了是很省心的。而且前端規範的不斷發展還代表著前端的良性發展，這就是我所愛的前端。

然後是 Babel 的問題。首先 Babel 確實有不少問題。但是 sourcemap 等的幫助，我們是可以很好的進行調試的。

真阿當還提到了 ES4 的暴死問題。

ES4 死完了嗎？並不是，它的一部分還活在 ES2015 里，在被大家廣泛的使用著。

關於 Node

• Node 的使用情況

真阿當覺得 Node 仍然只是個玩具。

但是，淘寶天貓已經在用 Node 進行前端渲染。

支付寶也有不少的業務在用 Node 做服務。

我們美團內部也有每天非常多大流量大計算量的 Node 服務。

之前有參加淘寶的 Node 沙龍地下鐵，也有非常多的人分享自己生產環境使用 Node 的情況，都非常的穩定。

Node 為什麼對於前端工程師如此重要，因為他對於前端來說學習成本低，可以幫我們做很多事情。比如我現在有在用 Node 進行圖像識別處理。然後如果我們需要前端的一些簡單 Mock 服務，是不是需要自己起個服務？如果後端服務不穩定，我們想本地測試服務端渲染，是不是需要起個服務？我們做自動化的瀏覽器測試，是不是需要起個服務？

是的，我們不用 Node 也可以。但是既然我們使用 Node 對於環境的統一性更好，對於自己自身的學習維護成本更低。那我們為什麼不用呢？

• npm 笑話一般的 unpublish 事件

是的，這是一個問題。然後現在 npm 不允許 unpublish 了。坑被填了不就好了，做什麼不會有坑？

• Node 做腳本工具

是的，不用 Node 也可以。shell 也可以，ant 也可以，可以的工具太多了。但是前端圈有著非常棒的社區活躍度，Node 本身基於 ES 的特性，也讓前端程序員使用的成本更低。

至於更新快的問題。

其實比較有名的工具也就 Grunt，Gulp，Webpack 之類的。

Grunt 因為性能問題，被替換掉很正常。

然後到了 Gulp，Gulp 被替換了？並不太算。Gulp 和 Webpack 解決的是不同的問題。我見過非常多強用 Webpack 然後來噴它的人。但是其實 Webpack 本質是個模塊打包器。想做點別的事，更應該換回到 Gulp。當然我覺得 Gulp + Webpack 是個很不錯的選擇。Gulp 本身作為一個構建類工具已經相當完美了。而且 Gulp 活得很好。

前端工具拋棄的快？我怎麼覺得除了 Grunt 可能真的需要退出歷史舞台之外，別的這幾個都可以繼續好好的奮戰呢。

• 全棧的問題

這確實是個問題。但是呢？

後端確實不是學個 Node 就能一蹴而就的，需要進行大量的相關領域知識的學習和實踐。但是其實我不太明白，這有什麼可噴 Node 的。你學什麼語言不都是要學習大量相關領域知識嗎？

但是我們都是程序員，難道頂了個前端的 title 就要限制自己？學習後端用 Node 可以嗎？如果可以的話，既然我作為一名前端那麼熟悉 ES，那我去學 Node 不是挺好的嗎？

有人說前端學了 Node 就是全棧了？我保證不打死他。

這種言論是有，但是你把這當成是目前的主流看法就不對了。

關於跨界、全棧、公司定崗

這一段真阿當寫的有點多。。。

我覺得關於崗位定位確實有這個問題。但是 Node 做中間層其實還是有意義的。

除了為了擴大前端的話語權之外。（大家也知道前端想獲取更大的話語權，接入 Controller 是很有意義的）

說實話我遇到的很多後端其實是不想寫 Controller 的，這很煩。而且對於前端來說，SSR（Server-Side rendering）之類的其實讓我們自己來管理是更好的。

我一直有一個看法，其實目前前端的職能已經開始發生轉變了。後端應該更關注於各類服務和數據問題，前端負責整個頁面展示的事情。

關於前端的核心競爭力

這個地方真阿當的主要觀點是前端首先需要打好前端基礎，不要學些亂七八糟的。

首先，打好基礎是絕對認同的。但是那些亂七八糟的，是的，比如想成為一個全棧是需要大量的學習的，勢必會花費很多時間的。但是呢？我們是否需要先成為一個稱職的全棧呢？未必。其實在我們的實際工作中，很多時候並不一定要把一個東西學精學透才能用。

比如用 Node 做一些簡單的服務，這就不需要太過精深的相關領域知識學習。而且說實話，不斷探索未知領域真的是一件非常有意思的事情。適當的去學習其他領域的東西，可以讓人更加快樂。

關於Angular，後台，SPA

關於 Angular，我不太喜歡用。但是我不覺得這東西有啥不好的。

然後關於對於後台如此感興趣之類的。

額，程序員保持好奇心也有錯嗎？

基礎是很重要，但是前端也很需要一些橫向領域的知識，這可以幫助你更好的工作，可以更好的尋找問題。我想這是大家都知道的。

關於React

首先，我認同裡面對於 React 的一些看法，確實有目前全家桶等等的問題。

但是其實對於普通開發者來說，是需要有更有經驗的開發人員，先負責幫你做好一套整合環境來進行開發的。我覺得現在的前端開發越來越需要一個前端架構師的存在，因為繁雜的社區選擇和開發實踐，缺乏經驗的人並不一定可以很好的針對團隊進行技術選型。

然後說這句。

• 既然 jQuery 已然可以提供必要的幫助了，那麼還要 React 幹嘛？

那我也想問了。既然 JavaScript 本身也能實現 jQuery 的效果，那要 jQuery 幹嘛？

而且說實話，React 本身對我來說有一個非常致命的擁有吸引力的點。

以前寫 HTML，JS 的時候，其實思維是非連貫性的。畢竟 DOM 是 DOM，JS 是 JS。但是在 JSX 中，HTML 其實變成了 JS 的一部分，這是非常有意思的。當可以用寫 JS 來寫頁面的時候，那種整體思維的連貫感實在太讓人滿足。

這點是別的框架所無法帶給我的。這也是對我而言，寫 JSX 的樂趣所在。

而且當 HTML 作為 JS 的一部分的時候，就給 HTML 賦予了所有 JS 的可能性，這種自然而然的感覺是非常非常有意思的。

關於SPA和Web Site

所以。。。我其實比較奇怪的是。。。

有很多人非常期望 SPA 大爆發嗎。。。？

我是覺得 SPA 在一定程度上可以幫助我們進行頁面的更優化和更好的用戶體驗（例如跳轉的切頁效果等）。但是也會帶來比較複雜的狀態管理。

SPA 是有適用場景的。為啥非要大爆發才能算是好的？我很費解。

React Native和PhoneGap

這邊我基本是同意的。

RN 和 PhoneGap 都是有非常多缺陷的。最重要的其實就是想寫一個真正的有一點複雜度的應用的時候。其實是需要 Native 的人來參與的。

不過其實，我覺得也沒有誰說 React Native 就能取代 Native 了吧。大家應該也都明白，這其實就是為一部分團隊提供了多一種的選擇，當然了，離最優選擇差的很多。

關於微信小程序

微信小程序太封閉保守了。@黃玄 之前也寫了知乎專欄來說這個事。至於這個地方，我倒是覺得真阿當的話沒什麼問題。

關於前端的缺人和高薪水

這個地方我倒是覺得沒什麼槽點。

但是我覺得是 正確 的廢話。

• 你學會了兩個時髦工具，面試官也在面試時問到了你時髦工具，然後你也順利到了很高的薪水，就真以為是工具幫了你，你的能力真的就高了。不是的，是時代的原因。

比如這句話。

沒有良好的基礎，怎麼真正的 「學會」 時髦的工具。

不能隨心所欲的控制和改造工具，理解工具運行的原理。也能叫學會？

這其實根本就只是面試官面試方式有問題吧。

我自己的核心觀點

基礎永遠是重中之重，無論是計算機基礎也好，前端基礎也好。

前端社區是一個非常開放，活躍的社區。這些新技術的誕生和發展都有著各個天才工程師的奇思妙想。這都可以幫助你開闊眼界，獲得更大的視野。

開發沒有銀彈，我們是可以自己用零件拼起來所有我們想要的東西。但是既然人家已經給你造了個可編程小機器人了，你為啥還要自己拼一個？至於覺得耽誤了你的基礎？你搞清楚別人怎麼造出來的不就行了？難道大家不都是這樣推薦的嗎？有人會說你只管用，不要理解實現原理嗎？

程序員就是程序員，我們是不設限的。

程序員不就是那些，無比熱愛代碼，無比熱愛創造，無比熱愛學習的人嗎？

PS：我之前看到有個同學的意思是 真阿當 覺得目前框架沒有決出勝負，不想浪費時間學習。我倒是覺得沒問題。並沒有人拉著你去學。但是呢，既然業界在流行這樣東西，就說明他確實有幫助我們更好的解決問題。根據自己的場景合理的進行選擇是很有意義的。我們團隊的一部分業務，在選擇了新的框架以後，也有了很大的開發和維護成本降低。新框架是給你多了一種選擇，而不是讓你只能用它。

PS2：說到從團隊角度看和從個人角度看問題這個地方。我覺得，優秀的個人也是優秀團隊很重要的一部分不是嗎？回顧我所呆過的那些優秀的前端團隊，可全都是這樣一群，充滿熱情和學習慾望，始終保持技術好奇心的人啊。