標籤：

大公司或專業團隊目前流行的前端工具有什麼？

01-11

正在嚴格的學習前端知識，謝謝各路好漢的相告。

下面這些東西在大公司可能不流行（你懂的，大公司喜歡自己造輪子），但絕對是專業前端需要了解的：

  • Node.js：現代工業化前端的基礎；

  • RequireJS：AMD規範，即將過時的 JavaScript 模塊化方案；

  • Bower：前端模塊源；

  • npm；前端工具源，另一個潛在的前端模塊源；

  • Browserify：即將過時的基於 CommonJS 的前端模塊化方案；

  • Less：等 CSS 增強工具；

  • Gulp：前端構建工具，如果你在前端開發中不需要使用類似工具的話，我只能呵呵；

未來的 JavaScript：ES6、ES7，兼容未來 JavaScript 模塊化方案類庫、代碼轉化類庫等等。

造輪子的路過：EFE Tech - 百度EFE（Excellent FrontEnd）技術體系

  • ECharts - 數據可視化圖表庫
  • ESL - AMD Loader
  • EDP - 前端開發平台
  • EST - 基於 Less 的樣式工具庫
  • Saber - 移動 SPA 項目解決方案
  • Rider - 移動樣式工具庫
  • ER - SPA 應用框架
  • ESUI - UI 組件庫
  • ETpl - 靈活、高性能的模板引擎
  • iSlider - 輕量、高性能的移動滑動方案
  • 圖說 - 可視化數據分享平台
  • Fontmin - 字體子集化方案

從來沒有發過言，在這裡破處。。。

就具體的工作、開發框架或庫，上面的都列舉得差不多了，就不重複大家的，咱來一個前端開發方面理論層面的東西，從理論層面來反推，前端都要學習些什麼技術，這也算是個人對於前端這個工種的粗淺見解吧，歡迎吐槽，別扔雞蛋~~

這個疑惑是大多數前端開發入門的困擾。。。說實在的，和後端相比，前端的知識體系太雜了，以至於很多入門者找不到方向。其實，前端既要寬度，也要深度，優秀的前端開發人員比後端開發人員難培養多了。

1，興趣是最好的老師

學習前端，或者說(ˇ?ˇ）， 玩代碼這一行，要玩得有深度，最基本也是最重要的，要自己有興趣，沒有興趣就不要浪費時間了。雖然這是廢話，但是當你碰到了技術發展的瓶頸期了，我覺得就應該能很比較好地理解這句廢話的含義。

2，找一個好的導師

找一個願意傳授知識的導師，或找一個有大牛存在的團隊，這是提高技能的最好也是最快的途徑。如果什麼都是自己研究，天賦異稟，或許會比別人快，但有一個人在關鍵時刻提點你，效果其實是非常顯著的，突飛猛進指日可待。

說白了，你要和牛人一起干過活，知道大牛長什麼模樣的。

當然，在大中型項目中，大牛比較多，但這個對於入門者來說，如果你進入不了大中型項目，那麼也可以在很多創業項目中物色，特別是電商領域等熱門的、競爭激烈的領域，前端這一塊至少需要一兩隻大牛來做前端架構和開發模式選型，能承擔這樣子角色的人選，一般都算是比較厲害的了。

競爭激烈的領域，如果連交互體驗都不重視，那麼這種項目絕對是沒有成功的機會滴。

不同level，前端需要的技能分析

1，初級入門

html和css，這兩個基本功。合理的html結構，很多時候可以減少js邏輯、css樣式，以及避免絕多數的兼容性問題。基本功不好，到了一定程度會限制你往後發展的空間。

這一層面會涉及photoshop、美術方面的相關知識，而交互方面，大多數WEB需求是在jQuery或Zepto這樣的庫下進行的，會這兩個庫基本能夠入門了。

2，中高級前端

初中級前端對於原生js開發能力的要求並不是很迫切，但是如果到了高級前端，就需要對js原生層面的API、屬性以及不同瀏覽器的特性，都要有較深的了解了。

這一層面的前端，我個人認為必須深刻理解幾個知識點：js的閉包、作用域以及類。熟練掌握幾種js類的定義以及繼承的方法，了解它們之間的差異，並能結合實際需求，在開發生產應用上。這其實就是具備面良好的向對象編程的編程開發思維了。

此外，中高級的前端必須掌握CMD或AMD的模塊化方案中的一種，還掌握至少一個MVC或MVVM框架，能勝任比如OPOA頁面，又如tmall、唯品會等電商網站的側邊工具條、提交訂單等交互功能複雜的開發需求。

在這個級別的前端，我覺得，才好稱之為程序員，和後端的開發一樣，都是碼農了。對於入門的，只要求會切圖，寫簡單腳本或整合個jQuery插件來完成任務的，在我看來，還不能算是一個程序員。

3、前端leader

之前都是說技術的，而leader角色其實除了開發技能外，可能還需要一些管理方面的經驗或能力。

在這個層面，不同的團隊可能不一樣，有偏技術的，有重管理的，但我個人認為，如果要底下的開發人員服你，至少代碼層面的功力不能少，要不你無法做好代碼review，保障整個團隊是按照規範來執行得，有問題的時候需要leader快速定位問題，提供解決方案或解決思維。

小結，一個優秀的前端leader，我認為應該具備的能力：

①重要功能或需求的開發，或提供解決方案，做技術選型 ---&> 技術功底

②需求分析評審，分發開發任務，和產品經理、設計師以及後端等溝通、協調 ---&> 溝通能力，具備產品思維，前端轉型做產品不在少數

③開發需求的跟進，代碼review，代碼合併與發布等，精通svn或git是必須的，記住是精通，你新招的新手同事很可能不知道什麼時候把別人寫好的東西弄沒了，你至少要知道如何找回吧 ---&> 項目管理能力

④前端開發規範，開發文檔、開發標準的建立和實施，關鍵是實施 ---&> 文檔功力和執行力

⑤新員工的培訓、輔導 ---&> 做老師的能力

⑥前端的技術更新太快了，一個優秀的前端leader還要引導團隊了解和學習新的技術，為以後做技術儲備 ---&>行業觀察能力

……

⑦不能太宅。這很重要，技術男大多很宅，要想做一個好的leader，就要多和不同的人特別是多和溝通方面強勢的人打交道。要不，等你做到leader的位置，即便是站在前端的角度來看有些極度不合理的需求，你也可能鎮不住，天天接這樣的需求，怨言就猶如漫天飛雪，受不了的人會選擇離開，如果你的團隊離職率高的話。。。Boss會覺得你是合適的嗎？

4，前端架構師

是的，前端也需要架構！

前端leader，或高級前端開發不就是了？可能是，但架構是一個系統性層面的東西，能做好前端管理，未必能做好架構，當然，做好前端架構了，未必就能做好前端團隊的管理。

當然，這是兩個層面的東西，也沒所謂誰更高大上。

好吧。還是聊聊架構師這玩意吧，因為做架構要涵蓋的前端方面方面，還包括一些後端的東西。聽起來，還是挺高大上的。

現在的前端已經不再是刀耕火種的年代了，在整個web開發生產流水線上，可能一些企業網站還可能屬於附屬或邊角的工作，就是干php的順手也可以弄一下的那種，但是，但凡有點追求的，重視前端體驗的項目，前端必須是專業人士來乾的，前後端分離開發也是必須的。

如何實現前後端分離？為什麼要實施前後端分離？這方面的知識，似乎不是這個主題的範疇了。我就不說了，這裡主要是給前端架構師，這個細分工種，給出我個人的見解。

首先，在我看來，前端架構要解決三個層面上的問題：

①團隊開發協作層面的——根據項目的情況，設定一套符合項目實際需求的，能夠解決前端團隊多人協作開發、代碼模塊化組織的開發架構或模式，減少前端開發的邊際工作，方便開發人員把絕大多數精力專註於業務邏輯的本身實現。也就是，前端生產的工程化和發布的自動化。

②業務需求實現層面的——根據業務需求，設定或整合一套符合業務需求的，能夠解決絕大多數業務場景的基礎上，保持好良好的可擴展性以及良好的可維護性的Javascript框架或方案。

③除了解決前端自身開發的兩個層面問題外，還可能協同後端架構師，確定前後端對接的API，定一套符合項目需求的RESTful方案，並整合到前端框架中，最終形成一套數據封裝的js API，如果項目有採用MVVM框架的，最好是能結合Model，以便view視圖的控制。

當然，對於前後端交集的部分，比如服務端view模板層的一些東西，可能也需要前端架構師提供一個合理的架構或方案，哪些東西是公共的，可繼承或復用的，該抽象出來的。。。這在PHP項目中是必不可少。

當然，這個工作可能是前端Leader來干也合適的。

或墨水有限，或眼界有限，對於前端架構師這個工種的表述不是很到位的，歡迎補充。

舉個例子吧，然後我再對前端架構師要乾的活做一個小結。

以阿里巴巴為例，淘寶、天貓、一淘等平台，都是基於kissy框架以及基於kissy開發的模塊，這是根據阿里巴巴複雜多變的業務需求，在多次迭代後形成的，幾乎你想要的前端功能它都包含，底層的基礎工具函數，表現層的業務實現代碼，甚至標準模板都有的，如果把所有功能都打包，這個框架就很大，實際生產時不可能這麼干，對吧？

沒關係，它本身是模塊化，可以按需請求。但這還需要結合在Combo技術和CDN技術，這其實是阿里前端的核心技術，這裡也有些相關的介紹：

前端優化：淘寶的Combo Handler和新浪微博的link標籤includes屬性

模塊化高擴展性的前端框架 KISSY

小結： 如果項目中要用上類似kissy這樣的框架，到底涉及多少前端架構相關的技術：

1、前端自動化工程化——nodeJS/grunt /gulp

2、前端模塊化——CMD或AMD，kissy是CMD，也就是seaJS，CMD就是阿里自己弄出來的標準

3、前端發布代碼增量發布系統——git是必須的，NodeJS Express框架的自動化或可視化的發布界面

4、前端按需載入——在線Combo，CND緩存技術，這裡的核心，我認為是解決js模塊依賴分析以及CDN的強緩存問題

5、前後端數據交互——RESTful、模板控制系統（tmall內部好像是TMS系統），前端主導業務系統的API規範

6、前端開發環境的一些相關問題，這個因為前端開發比較零碎，邊際工作多，提高開發體驗和提高開發迭代速度，很多基礎性工作，比如開發環境，數據模擬系統，等都是前端架構師要考慮的事情

當然，kissy很強大，但並不一定適合每個項目，所以架構師要做的事情要對技術做好選型，如果時間允許，架構師不妨考慮自己造一個輪子，但項目的時間規划上不允許，不是要你自己造一個輪子，而是整合各種資源，形成一套能快速用於實戰的整合套餐。

比如，蘑菇街的前端開發框架就是一盤整合的套餐——requirejs+jquery+backbone+一套自定義的底層庫+各種插件+在線combo

如果要了解大公司的前端是怎樣的，或者別人是怎麼做的，可以看這裡的視頻，——D2前端技術論壇——2014綻放丨章節

有不少底料，前端開發理念層面的東西比較多。當然，前提是你都看明白了，如果都理解別人的做法，我想，你距離大牛也就不遠了吧。

題外話：在線combo和本地combo

在阿里和蘑菇街兩個電商上，都用了在線Combo，說明這確實是一個前端非常重要的技術，模仿阿里前端資源在線combo的服務，咱用coffeescript也寫了個在線combo的服務，基於node 的Express框架，有興趣可以參考一下

https://github.com/lmtdit/static-combo

但是，我個人認為，在中小型的項目中，其實還用不上在線combo這種技術，因為這需要良好的伺服器支持，而阿里、蘑菇街在這方面的資源並不是問題，而初起步的項目一開始就引入這種前端資源載入機制，是挺高大上的，但可能投入產出比上考慮不是很划算。。。

而本地化的Combo機制，生產代碼在本地build好之後，再發布到第三方的CDN上，這種可能會比較實際，但也要解決好CSS和JS模塊開發和生產混淆壓縮以及靜態資源的緩存問題。

唉，看了一圈，沒人回答持續集成和在線介面/在線工具相關的東西。

- Gitlab Ci

- 代理工具/在線代理工具/HOSTS管理工具/...

- Mock介面服務/本地Mock工具

- ICON FONT

- 圖片上傳和在線優化/圖片優化工具

- 錯誤追蹤

- DPL + JS TOOLKIT

- ...

工具框架都是為業務提供支持的，更好，更快，更舒服。

知道自己需要什麼，再去看對應的工具，體會和理解會更好。

日常工作 我用的工具大部分都是自己寫的。庫，插件，用的多了，只是懶的自己寫的時候會網上隨便找找。

可能我很土，對其他樓主所說的新東西不甚了解。並不是因為不知道，而是知道後，覺得對自己目前工作沒啥用。沒去深入看完。

我反對什麼都學，把精力留在深度上更好一點。而一些標準也都是人之所為。

需要就用，不足就改，沒有就造。我對前端工具的看法。

工具只是手段啊，哪有什麼流行不流行，更談不上過時。

百度FIS

我看到答案里多數是一些框架, 庫和 CLI 工具, 比較針對編碼, 但是前端還有一些偏設計的工作要做呀.

IDE, 可視化工具

  • WebStorm: 公司里其他人用, 我雖然是堅定的 exVim 使用者, 但是有些心動.
  • DevTools: 這個我想是個前端都要用吧, 但是 DevTools 里有很多細小的功能點, 建議通讀文檔使用.
  • Adobe Edge: Edge 可以幫你做一些小的動畫預覽, 有時缺靈感就用它預演一下, 比你寫動畫 key 方便很多
  • Macaw, Webflow: 這兩個都是用於頁面排版的, 主要也是為了讓自己看一下效果, 特別是整體界面排版.
  • Sketch: 我用的少, 就不多評論了, 和上面兩個的作用類似.
  • Unity3D: 有時要寫點 shader, 調些動畫什麼的, 短時間內還是得靠他.

CLI 工具

  • Gulp: 現在大部分的工作流程都依賴他, 我們連代碼更新都寫成 `gulp update` 了....
  • Git: 就不用多說了.
  • Bower: 我個人用的蠻多的, 比較省心.
  • nodemon: 開小服務測試方便.

說說我們獵豹移動廣研前端團隊的一些實踐方案：

工作流：

Grunt。如果你喜歡Gulp，也沒問題。但是我更喜歡Grunt的寫法。

模塊化管理：

完全基於CommonJS規範，使用browserify組織代碼。至於有人喜歡ES6模塊或者AMD的方案，可以利用相應轉換工具轉換為CommonJS。我們的CSS代碼、JS代碼、HTML代碼都是用require方式引入的(自己實現的插件)。非同步載入代碼，也有browserify插件實現，可以實現按需載入(自己實現的插件)。我們會對引入的任何代碼進行cache bust（自己實現的插件）。以上3個browserify插件未來會進行開源。

樣式：

因為產品需求差異比較大，樣式都是自己寫了。stylus + nib，用過的都說好！

前端框架：

分具體使用場景：

（1）內部管理系統extjs、Angular、React etc.我們鼓勵在內部或者重要程度比較低的項目中，使用一些新的、熱的或者前沿的技術；

（2）移動Web，基礎庫zepto。PC Web，基礎庫jQuery；

（3）小項目、活動頁面，通常沒有架構而言。大型項目，基本除了基礎庫，都會有個自己的業務框架；當然我們也有有些公用組件的沉澱；

（4）複雜的PC Web APP中，使用knockout做MVVM和knockout模塊組織代碼；knockout這東西好啊，大小合適，兼容性好，還支持組件化開發；

質量保障：

項目比較雜，暫時沒有引入專業測試工具，主要是3點：

（1）自己編寫的小的測試模塊，做成工作流中的一部分，構建時就能發現一些低級錯誤（類似JSLINT）；

（2）JS代碼執行錯誤、AJAX質量、PVUV等的數據上報和統計；

（3）運維側的各種監控工具；

前後端分離：

God Bless，我們大多數項目都是非展示型頁面。對首頁載入速度沒有過多要求，所以我們通常都是前後端完全分離，即全部使用AJAX交換數據，即使是首屏。

抓包+替換資源：

Fiddler or Charles。

我們是創業小團隊，我們的前端是：老師客戶管理端 angular 1.3 -&> angular-marterial -&> gulp +bower 學生使用產品web端(以手機端為主，自適應頁面將會與手機app原生的混合) : React + Flux + react-router + browserify + gulp +bower ；

browserify+npm搭建模塊化體系，並通過browserify的transform機制，做一切靜態分析下你想到的能做的事情，AST修改給你足夠的想像空間帶你飛～

手機碼字，改天補充…

好吧，本來不想回答的，從知乎公測到現在都是潛水的，有些慚愧。

先說幾點現實的問題：

  1. 如果你不是項目的leader你完全不必要關心這些，也左右不了。
  2. 如果你只是以學習為目的而不是為了找工作比較符合大公司的胃口，那麼你應該將大家推薦的和提及的都去用一用，最少要看懂文檔，知道他們是幹什麼的。在使用的的過程中你才能知道哪些更適合你，更適合團隊。再深入一些，哪些雖然適合團隊，但是卻不利於優化。要清楚，前端對文件大小和連接數是很敏感的，比如browserify在組織代碼、前後端公用／模糊前後端界限、學習成本（只要會nodejs）方面效果顯著，但是由於需要mock nodejs環境，體積會比其他單純的module loader大出許多，連接數也會高許多，所以在前端優化過程中優化程度有所下降。如果你沒有深入的去學習實踐，那麼你可能就會對單純的module loader有所誤解，現在的module loader幾乎都支持CJS（nodejs／CommonJS）的寫法，打包時會自動轉換成loader的API。
  3. 如果你想以找工作對公司胃口為目的，很不幸，大公司都喜歡自己造輪子，會有人告訴你怎麼讓這些輪子動起來。
  4. 現在大多數前端工具都是nodejs所寫，所以學會nodejs很重要，其他基於nodejs的工具都很好懂
  5. 如果你想學習前端知識，那大公司使用什麼工具跟你有啥關係？反正你都要學的！
  6. 工具提升效率也增加學習／培訓成本。
  7. 不要過於相信、依賴我們所說的，大部分是我們自己的實踐經驗，這些經驗可以分享出來，但不一定適合你，適合你的團隊。

至於工具，大家也都說的差不多了，我也想說幾點：

  1. 大家所說的，務必要親自去弄清楚是幹嘛的，有些只是片面經驗，或許只用到了工具的一部分就認為是工具的全部。
  2. 大而全的工具在構建和組織代碼上很好很強大，但在前端展示與優化上不一定好，甚至會拖累。
  3. 有些時候工具也會造成負擔，當你真正需要他們的時候再去用。就像module loader的出現是因為項目js大而並不會一次性全部用到；項目太大打包發布麻煩，所以出現了grunt／Gulp。
  4. 在國內，你要知道如何使用梯子，比如google，github，npm，bower，沒有梯子再多的工具你都會感覺很難受，真的。

這裡我沒有推薦任何工具，因為我覺得這個問題有些籠統（工具有很多領域負責不同需求），如果你真的需要的時候你就會去找某一方面的工具，而不是為了會用工具而去學習工具。

簡評一下業界常用的並且我了解的一些前端工具

編輯器：

首推：VIM、Brackets

可選：atom、sublime、emacs

webstorm 那叫 IDE，不（僅僅）是編輯器

css工具：

苦於合作的同事一直選的是 bootstrap，我沒有認真比較過 sass 與 less 而直接一路用著 less，不過兩者其實差不了多少。

現在貌似流行後處理器了（前面說的兩個叫預處理器，我也不知道他們差別在哪），autoprefixer 等，推薦看 Pleeease 這是一個這類工具的集合

模塊化工具：

首推：browserify 代碼架構清晰，你可以自己拔插其中的某些部分，比如替換個 prelude（在瀏覽器里怎麼載入模塊的代碼，默認是每個編譯合併後的 js 都帶一小段），或者用諸如 factor-bundle 這樣的插件拎出共用組建來。因為架構清晰代碼量小，你可以通讀源碼了解其原理。

其次：webpack，不得不說 webpack 很強大，如果要用 react 的話 react-hot-loader 這樣的插件目前只此一家。對我來說它的問題在於太龐大了，我無法理清其全貌怕用在項目里踩坑自己無法解決。

不推薦：require.js sea.js，兩個都是要過時的東西，在我還沒成為 sea.js 黑前，就是堅定的 require.js 黑了。兩者的共同問題是要為每個文件寫首尾的 wrapper 在瀏覽器端去解決，而不是像前兩者在開發部署階段去處理，require.js 問題最大，好歹 sea.js 還和 node.js 有所兼容。

流程工具/部署前處理：

部署前處理主要包括用前面的模塊化工具打包、生成版本號、壓縮文件等。我主要用 gulp 來做這些事，從來都不會用也不喜歡 grunt，百度的 FIS 聽說過但不了解，讀過 @張雲龍 的文章推測應該還不錯。我的建議是@張雲龍 的文章必讀而 FIS 可參考，最後用 gulp 來組織自己的工作流。

如果你用熟了 gulp，你可能會厭倦開工一個項目就想切個頁面也要擺好排場寫個幾十上百行的 gulpfile.js，這時你應該做減法，可以向 substack 學學用 npm run （package.json 裡面的 scripts 屬性）或者像 ./task.js 這樣的幾行代碼即可。

包管理：

bower：用 github 來做源，國內使用很不堪，如 @yhben 的回復「100k的js，克隆了一個50M的項目」。它可能簡化了一點點你去 github 上搜索代碼下載保存的工作，但被要下載全庫這個缺點抵消了，對於依賴管理，我覺得他真沒做多少事。

npm：我是無論前端後端甚至 css 都用 npm 的，公司里也用 @蘇千 和 @死馬 的 cnpm.org 搭了一個私有庫在用，個人覺得這個工具一定得掌握好，不然你就自絕於當今前端開發的主流了。

看大家各抒己見，我也從前端開發的各個環節講講了解的一些東西吧：

1. 【調試伺服器】首先如果你是一個準備做WEB開發實踐的，不管前端、後台，首先需要了解一兩種伺服器apache，tomcat，nginx啥的，至少能夠配置一個基本的本地服務和修改索引路徑，前端頁面使用http/https協議訪問，而不是本地文件協議。

2. 【調試自動更新】伺服器搭建好了，那麼現在開始調試網頁，然後你修改一點代碼，去瀏覽器裡面F5刷新頁面看看效果，再修改一點代碼，再去瀏覽器裡面F5刷新頁面看看效果...如此循環往複， maybe讓工具幫助你檢測本地文件修改然後實時刷新網頁更靠譜。

3. 【換種方式寫代碼】然後就是寫代碼了，less/sass是不錯的css組織工具，coffee也能讓你的javascript代碼顯得更嚴謹和邏輯清晰，要是能夠在訪問頁面的時候實時獲取css/coffee編譯結果神馬的應該顯得很cool。

4. 【模塊化】當然在完成邏輯相對複雜的交互功能時候，可能需要你組織非常複雜的代碼功能，這個時候了解一下模塊化的開發思想顯得很有必要require.js事實上更早，也更廣泛一點，sea.js在國內也不錯。

5. 【模板引擎】然後就是對於js生成HTML(或者其他什麼的)的一種包裝方式, 即：js模板引擎(handlebars,jade)， 你可以嘗試在開發時候使用這樣的模板工具生成自己想要的HTML文檔什麼的，也是一種不錯的體驗，這個就像你用less寫css代碼一樣，或者說用php，jsp這樣的服務端語言工具生成實時HTML頁面。

6. 【代理調試】有的時候你開發的東西並不只是前端代碼，牽扯到跟服務端應用之間的數據交互，難免需要使用ajax，ajax這貨基於安全考慮是不允許跨域的，因此可能需要通過代理的方式實現數據調試這樣的工具也有不少，nginx伺服器是其中的佼佼者。

7. 【資源合併優化】OK， 如果到完成開發階段，你需要提交自己開發的代碼到線上伺服器了，在提交之前，你需要考慮將開發的資源進行最優化(合併，壓縮神馬的)， js方面有uglify，css有cssmin神馬的，圖片壓縮還可能根據不同的類型進行不同程度和配置的壓縮，這些事情交給別個工具處理顯得很有必要，要是能夠一鍵處理那簡直了， 百度的fis，業內最流行的grunt.js、gulp.js神馬的，事實上它們在配置化編譯LESS/Coffee這類工作在自己的流程中也很在行。

8. 【Combo】使用非同步模塊化開發帶來的弊端就是對於大量零碎依賴文件需要分別開闢多個http鏈接去獲取，這可不是一個好現象，要知道單個瀏覽器單域名並發獲取資源的數量是很有限的， 因此例如KISSY就支持了簡單配置一個combo參數來組織一個獲取nginx的 http-concat格式資源的路徑，當然這樣的動態合併模式也適用於普通的資源請求合併。

9.【資源緩存和更新】 CDN 能夠確保你已經發布到伺服器上的資源以最快的響應時間到達瀏覽器，但是帶來的問題是，你的代碼更新，CDN則傻乎乎的不理你，除非你在使用的地方告訴它需要更新了( 時間戳、MD5文件名啥的 )。

事實上，我覺著凡是重複進行的工作總有可以程序和代碼可以替你完成的部分，前端開發中這種事情尤其多，工具啥樣的自己去定義才最合適自己，而nodejs的出現使得前端自己可以方便的開發這類東西（上面的less、coffee、uglify、gruntjs、fis、gulp這些個單詞可以說：都依賴nodejs）。

最後是廣告時間 f2e-server就是依據以上環節所開發的工具： shy2850/node-server · GitHub

看看 http://npmjs.org/#explicit 首屏的推薦的這些工具，基本上都在這兒了。

編譯器：sublime（組裝插件，形成一個強大的IDE

自動化流程：fis，grunt，gulp

打包工具：webpack

我是小公司的…大公司我也想知道…

還有就是js基礎是使用這些工具的基本。

意識流寫一下，一個前端工程師應該知道的工具：

1. 模塊化

很多人還在用requirejs和seajs，個人認為這種模塊載入方式相當dirty，在配置、打包、編碼都異常浪費生命。只推薦用Substack大神的browserify。可以和nodejs一樣的方式組織模塊，並且可以直接require npm上的模塊，如果你後端是nodejs的話，連一些前後端模塊都可以共用了。

2. 模版引擎

handlebars, artTemplate, jade, 都可以用用。（不要告訴我你把HTML寫在JS裡面

個人一般用handlebars或者artTemplate

3. 預編譯器

CSS：Less、Sass、Stylus，用和HTML樹狀結構組織你的樣式，

JS：CoffeeScript、LiveScript、TypeScript

個人一般用Sass + CoffeeScript，寫少很多括弧可以延長生命值。LiveScript則是做的有點太過了，犧牲了一些可讀性。TypeScript括弧太多。

4. 工作流

Grunt、Gulp、Makefile、Npm、Shell、Python、NodeJS

看到很多人說到前端自動化工作流只會用想到Grunt、Gulp什麼的，其實自動化工作流這個東西不能受限於工具。很多項目的業務流程都不一樣，需要有不一樣的工作流。需要我們靈活組織和構建工作流，如果有聲稱銀彈一樣的工具一定是騙人的。

有時候為了構建項目的工作流你甚至需要用到很多不一樣的語言，因為每一種工具的所擅長的領域不一樣。例如你編譯要用到Grunt、Gulp，git分支操作你要用到Shell可能會比較方便。我們曾經就試過為了簡化工作流，把makefile，shell，grunt，python，nodejs構建了一個一條命令編譯、測試、發布、部署的工作流。

個人一般用makefile當入口，在makfile中調用不同類型的腳本進行工作流的糅合。

5. 版本管理

git

要學會怎麼把git的分支管理用得出神入化。使用git和github進行協同開發流程

7. 分析與設計

UML：時序圖、活動圖、用例圖等。

一開始只寫代碼不會做系統分析和設計的都是流氓。

8. 事件機制

用事件機制來解耦前端模塊是必備技能。用好eventemitter2這個庫。

9. TDD、BDD

Mocha、Jasmine、Chaijs、ShouldJS、SinonJS

學會做前端測試，讓你的程序的擼棒性更強。

10. 組件化思想

這裡沒有特定的工具，只需要知道，在一個做一個比較複雜的前端應用的時候，需要學會構建你前端應用的組件化體系。讓你的程序scale out而不是scale up。

一個大的應用程序其實都可以break成很多小的應用程序，也就是所謂的組件，每個組件有自己單獨的內容和結構（HTML），樣式（CSS），和邏輯（JS）。組件之間有組合關係、嵌套關係，組件之間的通信，都需要學會如何實現和構建。

11. 函數式編程庫

lo-dash、underscore

12. MVC、MVVM思想

========================== 碉堡了的分割線 =======================

我沒有把jQuery、AngularJS、EmberJS、Knockout、Backbone、ReactJS這些比較流行的庫、框架加上去。我認為這些工具都是有特定的應用場景的，而有些人會把它們其中一個當作是銀彈，什麼情況都用某一個工具。我認為前端最重要的一個思想就是：根據應用場景組合不同的工具構建最合適的架構、工作流。能掌握上面的內容基本妥妥的的。

懂node後就能自己寫很多小工具了，集成起來走個流程就算是自定義框架了，其實很多前端框架沒ant好用，xml比json好寫，就是維護配置比較麻煩。

其實在公司的時候我一直在嘗試前端模塊化，因為一個人寫前端寫後台還是很累的，然後有時候又不想去麻煩大老闆寫，畢竟大老闆很忙的，後台模塊了，前台仔細一看慘不忍睹，好吧，大學生水平。大半年來做了的幾個項目css框架用過一些，我承認手寫代碼比Dreamweaver好了很多，但是仔細一看，和業界標準還是差了很多的嘛。

———————————————————————————————————————————

Gulp

這個東西很好用。

我在裡面

var gulp = require("gulp"),
coffee = require("gulp-coffee"),
gutil = require("gulp-util"),
uglify = require("gulp-uglify"),
imagemin = require("gulp-imagemin"),
cache = require("gulp-cache"),
sass = require("gulp-ruby-sass"),
autoprefixer = require("gulp-autoprefixer"),
minifycss = require("gulp-minify-css"),
rename = require("gulp-rename");
var tinylr;
gulp.task("livereload", function() {
console.log("hi tiny lr");
tinylr = require("tiny-lr")();
tinylr.listen(4002);
});

大概放了這些東西。

反正我最喜歡的時live reload了，你保存的時候就幫你編譯，亂七八的做一些操作，然後幫您刷新瀏覽器，寫起來還是很順暢的。這個在express裡面在監聽一個埠就好了。

寫Rails的時候我用的時guard 然後瀏覽器裝一個插件做live reload的。

框架也接觸過一些，boot，foundation，還有妹子。不過還是最喜歡pure。小而美。

bower到現在並沒有用這個的習慣。主要是網速實在是。。。

包括不用Grunt，Yeoman也是這個原因。

當然不用Grunt，是我覺得Gulp會看起來簡單點。

然後Emmet這個插件很好用的。

學好Native Javascript 自己找個庫 用自己的代碼模擬實現一下 回頭再看別的庫 so easy

gulp、grunt、fis等自動構建工具

RequireJS， Seajs等模塊化載入工具

推薦閱讀：

※如何考察候選人 Vue 技術水平？
※作為一個小白如何讀vue的源碼?
※Vue2用什麼UI 框架呢bootstrap 好像不好用了
※如何評價移動端Vue組件庫 Vux?

TAG:前端開發 | JavaScript | HTML5 | 前端工程師 | 網站構架 |