你知道這些前端開發指南嗎

JavaScript

記憶回到2009年，若是你在文章裏讀到相似「HTML5將會在2014年定稿使用」的預言，是否看起來那一天還很遙遠？若是當時你這樣想，你將要準備好迎接緩慢更新可是穩步向前的ES6（如今被稱爲ES2015，這個名稱已經隨處可見），也就是下一個版本的JavaScript。準備與ES6——啊不對，ES2015——接軌吧，毫無疑問，這是接下來在JavaScript領域中最重要的事情。ES6 classes、真正的隱私、更好的函數和參數、可引入（import）的模塊以及許多其它特性，必定會完全改變遊戲規則。那些能力十足而且十分高產的新語法無疑將會完全從JS社區中孕育出來。爲此，你須要閱讀：

• 理解ES6，一本Nicholas Zakas正在撰寫的書籍，目前已開源（譯註： 新坑已開，歡迎一塊兒填坑）。

• BabelJS，一個容許你編寫ES6代碼並將其編譯爲能夠在市面瀏覽器中運行的ES5的工具。他們還有一個很是棒的 學習章節（譯註：中文版請參考 這裏）。

• ES6 Rocks，有不少探索ES6特性、語義和坑的文章。你是否須要成爲一位ES6/ES2015專家？或許如今不須要，但你至少應該瞭解足夠多或者更多有關ES6的知識才能不落後於你的同行。你在開發下一款新項目的時候，嘗試一下ES6吧，將來近在眼前，只待你去撥開它的面紗。

 

新的語言特性先暫且不談，你應該可以流利地說出JavaScript的異步模式，而且使用回調和promise來管理它。關於在瀏覽器中加載應用並在每一個應用之間通訊的策略，你應該擁有足夠完備的看法。（it熱門職業）你也許應該掌握一個你很是喜歡的應用開發框架，同時也應該對其它的框架是如何運行的有一個概覽，你須要稍做權衡選擇你喜歡的那一個。

模塊和構建工具

毫無疑問，模塊應當是客戶端Web應用的構建元素。回到2012年，關於使用什麼類型的模塊來構建瀏覽器應用的討論此起彼伏，不過基本圍繞着 AMD和 CommonJS展開。還有一個略顯粗俗的 UMD包裝器嘗試融合兩者來方便你們重用代碼——他們認爲，既然長得差很少，不如多寫點兒代碼來同時支持兩者。

我認爲這場爭論沒有一個統一的結論，可是我感受這是自2012年我寫文章以後，這個領域中最大的轉變，固然這也可能只是我我的的心路歷程。我沒有完全搞定AMD，可是我被它的實用性徵服了，你可使用CommonJS開發並部署Web應用，使用npm引入模塊。

RequireJS爲模塊通訊作了很大的貢獻，出於對它的厚愛，我如今有點兒迷戀W ebpack了。webpack的功能——例如容易理解的構建參數（譯者注：build flag，命令行中形如-p的參數）——相比於RequireJS來講更容易理解。經過它的內建開發服務器實現的熱交換構建打造了一個快速且使人愉悅的開發傳奇。它並不強制你使用AMD或者CommonJS，由於它同時支持二者。還有很是多的加載器，使得完成許多相同工做對它來講簡直是小意思。你也能夠去了解一下 Browserify，但在我看來，必定要在熟悉了Webpack以後再去搞它，我信任的聰明人兒告訴我， systemjs在這個領域也是一個的認真的競爭者，可是我還沒用它呢，它的文檔讓我很想拜讀。它的包管理器 jspm很迷人，容許你從包括npm在內的不一樣的源拉取所需的模塊，可是我有點兒擔憂這倆貨結合起來會有些問題。我不得不重複，我從沒想過我會與AMD分開，可是看起來我不得不放棄它了，咱們終將會看到這事情的發生。

我仍然渴望有一天我能夠中止喋喋不休地爭論有關模塊和構建工具的話題，那時候全世界只有一個模塊系統，這樣就能夠在全部項目裏共享使用代碼，同時還能免去使用UMD的開銷。理想狀況下，那一天將會由於ES6模塊而變爲現實——在這一天到來前你可使用轉譯器（Transpiler）來填補空缺——但我發現頗有可能咱們會持續不斷地找一些方法讓它變得愈發複雜。

與此同時，前端開發者須要瞭解至少一對構建工具和相關的模塊系統，這須要在實踐中不斷積累經驗。無論怎樣，就目前JavaScript的發展狀況來講，你仍然須要選擇一個模塊系統，它將支撐你的每個項目。

測試

一些新的測試框架，例如 Karma和 Intern，已經讓客戶端代碼的測試變的垂手可得。我發現Intern基於promise來進行異步測試的方法特別（做者拼錯了particulary）爽，我不得不認可，大多數時候我依然用Mocha來寫測試——有時我還真就是屈於習慣的生物啊。

測試過程當中的主要阻礙是前端開發者傾向於寫的代碼，關於這個問題，我在2012年底公開談論了有關編寫可測試的JavaScript的話題，幾個月後隨即寫了一篇有關這個話題的 文章。

測試過程當中第二個大的阻礙是工具化，Web驅動仍然是你須要處理的巨大傷痛。一個複雜UI在全部支持平臺上的持續自動化測試依然不可行，即便可行開銷也很是巨大，以至於那看起來根本不可能實現——更別提移動端了。很大程度上咱們仍然侷限於在瀏覽器、設備、操做系統結合的支持平臺的很小的一個子集上作一些輕量級自動化功能測試，而且愈來愈難以依賴能夠快速、便宜地運行的底層測試。有時候想一想這個問題就以爲本身弱爆了。

若是你對改進未經檢驗（不可測試）的代碼問題感興趣，有一本書很是值得一讀： Working Effectively with Legacy Code，做者Michael Feathers將「遺留代碼」定義爲任何沒有測試的代碼，在測試的話題上，惟一的底線是接受這一說法的真實性，即便其它約束會阻止你解決它。

過程自動化

你頗有可能認爲 Grunt是任務自動化工具的不二選擇， Gulp和 Broccoli提供了一個不一樣的方法來進行自動構建。我沒用過Broccoli，而且我只淺嘗了一下Gulp，即便Grunt有必定的侷限性，但我絕對要感謝它依靠其它服務幫助我把複雜任務自動化——尤爲天天要運行上千次任務的時候。

Yeoman在我2012年寫文章以後的45天就發佈了。我認可它剛一出來時我並無用它，但最近我（用不熟悉的技術從紙上草稿開始一個項目）嘗試找出如何標準化咱們在Bazaarvoice平臺上開發第三方JS應用的方法，Yeoman的確在這些案例中閃閃發光。在命令行中輸入一個簡單的yo react-webpack就能夠爲你建立一整個新項目，項目裏的你想要的應有盡有——測試、開發服務器、一個Hello World應用，以及更多。若是React和Webpack不是你的菜，可能一個生成器就能夠知足你的需求，一樣，你能夠很輕鬆地打造本身的生成器。

考慮到Yeoman是一個你一般只在項目開始的時候使用的工具。而且考慮到你不總會開始新的項目，它只是一個值得了解的工具。固然了，若是你正在跨越項目嘗試標準化實踐，那麼它或許還有那麼一些價值的。

Broccoli做爲ember-cli的核心被委以重任，我信任的人們說這一對兒未來會有大做爲，還會改一個新的名字，在將來會逐步替代Grunt/Yeoman組合。使用Grunt和Yeoman組合進行開發的確會漸漸淡出人們的視野，因此咱們一塊兒看看將來能帶來什麼有趣的東西。

代碼質量

若是你像我同樣，當你只要看到代碼違反了項目良好的文檔風格指南時就不由自主開始抽搐，那麼像JSCS和 ESLint這樣的工具簡直是天賜之物。2012年的時候他們都尚未出現呢，他們都提供了一個格式化你的樣式指導規則的方法，而後在你建立一個pull request以前自動地按照規則校驗你的代碼，說到這兒咱們就不得不提Git了。

Git

我認爲自從2012年以來，世界範圍內的Git工做流沒有太大的變化，話說回來，Github pull request頁面上仍然沒有給分支名加上連接，誰知道是由於什麼天殺的緣由。

很顯然，在特性分支下工做你應該感到很是溫馨，將你與他人的工做成果進行衍合（rebase），藉助交互式衍合工具來改寫（squash）提交，並且在小的單元裏工做不太可能致使隨時可能產生的衝突。另外一個必備的Git工具的是鉤子（hooks）——你尤爲須要預推送和預提交鉤子來運行你的測試案例並執行全部代碼的質量檢查。你能夠本身寫這些鉤子，但相似於 ghooks這樣的工具能夠幫你完成這些繁雜的過程，你沒有理由不將他們集成到你的工做流中去。

客戶端模板

對於一些「錯誤」的定義多是我在之前的文章中犯下的最大的錯誤。客戶端模板仍然頗有價值，毫無疑問——它的價值高到它將會內建到ES2015中去——但過分濫用依然會有很差的後果。許多團隊將全部的渲染工做轉移到瀏覽器中，極大的性能開銷使得這種「客戶端生成全部HTML」的方法逐漸失寵，這是來之不易的教訓。成熟的項目如今都在服務器端生成HTML——甚至還預生成它，將它存儲爲靜態文件能夠快速響應提供服務——而後在客戶端逐步補充這個HTML，當事件觸發的時候用客戶端模板更新它。Java

我但願不管對於你仍是我本身，在考慮到本身的決策對於性能的影響時，不只侷限於瀏覽器領域，這也就是我接下來要談到的……

Node

你說你很瞭解JavaScript，因此接下來的時間我期待你可以深刻研究Node，若是你知之甚少，那你起碼須要投入一點精力去了解它。的確，Node世界裏有一些有關文件系統、流、服務器的知識，甚至還有一些徹底與前端開發不同的範式，但做爲前端開發者，若是你把這些寶貴的財富拒之門外將會極大地限制你的潛力。