相對來說，稱這篇文章為基本技能是不公平的，如果你回憶起以前的文章，你會發現這篇文章仿佛偏離了基礎。人們可能會爭辯說，我們應該考慮那些能讓我們找到工作的技能來作為基本技能。但是事實上，市場上有很多前端的工作可以選擇，為了得到一份工作你并不需要太多的基礎。于我而言，我并不想簡單找一份工作了事，我希望參與到一份絕妙的工作中去；我不想簡單工作就度過一整天，我希望能夠與有才能的人一起工作；我不想從事那些已經被大眾所熟知的，坐在這里稍作思考，預計差不多明天之前就可以完成的那種工作，我希望從事那些，因為我知道如何去工作，我能在明天之前鉆研出一個成果，所以我明天可以順利完成任務的工作，對，就是有挑戰的那種！
我的世界正在變得徹底以JavaScript為中心：除了一些必要的性能優化，我的日常工作接觸到的CSS知識越來越少。我知道有許多非常聰明的前端開發者，他們的JS和CSS技能都很厲害，但是根據我的觀察，專注研究JavaScript和專注研究CSS的人們正在逐漸分離。我大概可以寫另外一篇博文來闡述這個話題，但在這里我只想說：我沒有做過多有關CSS的準備，所以不要對這一點抱有過多的期許。
簡而言之：當你以你的前端世界的視角來閱讀這篇文章，不一定能找到你需要的內容。但請謹記，我們都是很棒的開發者！
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來管理它。關于在瀏覽器中加載應用并在每個應用之間通信的策略，你應該擁有足夠完備的見解。你也許應該掌握一個你非常喜歡的應用開發框架，同時也應該對其它的框架是如何運行的有一個概覽，你需要稍作權衡選擇你喜歡的那一個。
模塊和構建工具
毫無疑問，模塊應當是客戶端Web應用的構建元素�；氐�2012年，關于使用什么類型的模塊來構建瀏覽器應用的討論此起彼伏，不過基本圍繞著 AMD和 CommonJS展開。還有一個略顯粗俗的 UMD包裝器嘗試融合二者來方便大家重用代碼——他們認為，既然長得差不多，不如多寫點兒代碼來同時支持二者。
我認為這場爭論沒有一個統一的結論，但是我感覺這是自2012年我寫文章之后，這個領域中最大的轉變，當然這也可能只是我個人的心路歷程。我沒有徹底搞定AMD，但是我被它的實用性征服了，你可以使用CommonJS開發并部署Web應用，使用npm引入模塊。
RequireJS為模塊通信做了很大的貢獻，出于對它的厚愛，我現在有點兒迷戀 Webpack了。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這樣的工具可以幫你完成這些繁雜的過程，你沒有理由不將他們集成到你的工作流中去。
客戶端模板
對于一些“錯誤”的定義可能是我在以前的文章中犯下的最大的錯誤�？蛻舳四０迦匀缓苡袃r值，毫無疑問——它的價值高到它將會內建到ES2015中去——但過度濫用依然會有不好的后果。許多團隊將所有的渲染工作轉移到瀏覽器中，極大的性能開銷使得這種“客戶端生成所有HTML”的方法逐漸失寵，這是來之不易的教訓。成熟的項目現在都在服務器端生成HTML——甚至還預生成它，將它存儲為靜態文件可以快速響應提供服務——然后在客戶端逐步補充這個HTML，當事件觸發的時候用客戶端模板更新它。
我希望無論對于你還是我自己，在考慮到自己的決策對于性能的影響時，不僅局限于瀏覽器領域，這也就是我接下來要談到的……
Node
你說你很了解JavaScript，所以接下來的時間我期待你能夠深入研究Node，如果你知之甚少，那你起碼需要投入一點精力去了解它。的確，Node世界里有一些有關文件系統、流、服務器的知識，甚至還有一些完全與前端開發不一樣的范式，但作為前端開發者，如果你把這些寶貴的財富拒之門外將會極大地限制你的潛力。
即使你實際開發的產品沒有使用Node作為項目的后端，你仍然可以利用它來模擬后端服務的狀態來盡快完成前端開發。最起碼的，你應該熟悉如何 初始化一個Node項目，如何配置一個 Express服務器和路由，以及如何使用 request模塊來代理請求。
原文鏈接：A Baseline for Front-End [JS] Developers: 2015
譯文鏈接：前端（JS）開發者的新起點：2015
轉載請注明： 文章轉載自：愛思資源網 http://www.randomwithlife.com/show-77-672-1.html
