1. 前言
閱兵放假三天，我哪兒也沒去，宅着看了一些東東：git命令行、svn命令以及下面的主角——百度FIS。對看過的git、svn的命令也做了一些總結，請參見：《git命令學習筆記》和《svn命令學習筆記》
另外，我是開源富文本編輯器 wangEditor 的作者，歡迎大家關注我的項目。下文也會結合我在開發該編輯器過程中的經歷，來對比說百度FIS
在查看下文之前，可以先說一下我初探百度FIS，對它的一個總結——由工具到解決方案。不知道大家對“工具”和“解決方案”這兩個詞如何理解，以及它們之間的區別。如果你有興趣，不妨跟隨着我的文字，一起來認識一下百度FIS。
PS：本人剛剛學習百度FIS，有任何理解不到位的地方，還請各位多多指正！
本文主要針對各位web前端開發人員，對此無興趣的請繞道
2. 什么鬼？
不知道百度FIS的同學，估計第一句話就是要問：“是什么鬼？”
不知道FIS無所謂，但是作為一名web前端開發人員，你至少要知道目前前端比較流程的“工程化”、“自動化”或者再高大上一些的“工業化”這些詞吧？目前比較流行的工具有 grunt、gulp 等。如果這個都不知道，建議抓緊時間去惡補一下，亡羊補牢為時不晚，這種工具入門都很簡單，推薦教程《用grunt搭建自動化的web前端開發環境》
至於為何web前端要用自動化、工程化，有什么好處，本文就不多說了，不是本文重點。總之它是很重要的。
百度FIS也是一個致力於web前端自動化的工具，而且它比常用的那些工具考慮的東西更多，因此實際上它就是一個web前端自動化的解決方案了。
了解了百度FIS的基本內容，現在雖然你還是什么都不知道，但是你仍然可以捕獲到以下信息：
- 百度出品：百度是一個非常重視技術的公司，FIS由專業團隊維護，應用於多個百度產品，這本身就是一種吸引力；
- 解決方案：小型項目中體現不出來，但是一旦到了大型項目，多人開發，解決方案的優勢就體現出來了。所以，你做大型項目，可以考慮百度FIS；你不做大型項目，看看百度FIS至少能提高自己的眼界和高度。
3. 工具 VS 解決方案
看到這里，激動的你是不是着急要一個demo來見見廬山真面目？—— 別着急。
你着急要demo、要 quick start ，因為你覺得看看什么樣子是最重要的。而我覺得比這個更加重要的是，我要用形象的語言給你描述出百度FIS的最強優勢，即工具和解決方案的區別。
舉一個栗子：excel是一款很強大的表格軟件，里面有各種公式的計算，但是你能用它做一個很復雜的財務表格嗎？但是一些專業財務軟件則可以通過一些配置來生成出這樣一個財務表格。同樣是excel，同樣是應用的那些公式。前者就是工具，后者就是解決方案。
grunt 和 gulp 都是很不錯的平台，其下有N多個插件，但是這么多插件都是干什么用的，你的項目中應該用哪些，你一開始未必知道。想知道你就得花時間成本去研究，但可不是每個人都有、或者願意拿出那么多時間去研究的。
而百度FIS恰巧解決了這個問題，它把常用的東西都集成起來，打包起來，任何流程和操作都變得一鍵化、傻瓜化、統一化，拿來就用。而且，你只需要根據它規定的這些操作來就行，不用考慮太多。
這樣描述，想不想剛才說的excel和財務軟件的關系？技術都是一樣的，只不過應用的效果不一樣。
解決方案的好處：
- 對於管理者：從項目管理上來說，減少了開發和管理的成本，因為不需要每一個開發人員都去弄懂那些插件、配置等等；從開發角度，有利於不同技術的集中和分組，讓每個成員往專業方向發展，提高整體團隊能力。
- 對於開發者：不想當廚子的司機不是好士兵，如果你是一個有心的開發者，接觸FIS這樣的框架，能提高你對系統架構和開發流程的認識。
4. 只有三個命令
PS：FIS文檔頁面 http://fex-team.github.io/fis-site/docs/beginning/getting-started.html
百度FIS首頁給出的廣告詞：三條命令，滿足所有前端開發需求。這三條命令分別是：
fis install
該命令可以安裝一些項目中用到的公共組件，例如jquery、echarts等等，可參見組件倉庫，這個主要是用來部署、初始化項目環境。
fis release
把當前的項目發布。release是一個很重要的過程，大家都知道，web前端的開發結構和最后發布的結構，大部分情況下是不一樣的。例如會有文件路徑的變化（img放在一起、css放在一起等），文件的合並和壓縮、增加md5戳用以緩存，還有好多自定義的操作。
針對這些操作，FIS考慮的非常詳細，都體現再它的文檔中。你指需要參照文檔，看看哪些是你需要的，你加上即可。哪些你不需要，你屏蔽掉即可。幾乎所有你能想到的，文檔中都有，幾乎不需要再去查資料了。
（這就是解決方案的能力）
fis server
運行發布環境，測試用。grunt 和 gulp 都是沒有集成 server 功能的，我在開發 wangEditor 時，一直用一個基於 nodejs 的 http-server 插件來提供靜態服務。
大家想一下，web前端的開發過程中，怎么可能用不到 server ？FIS帶有 server 功能，這是一個解決方案的正常體現，grunt 沒有 server，這也是一個工具的正常體現。
還沒完，FIS 的 server 不僅僅可以給前端提供服務，通過配置它還可以支持 java、php、nodejs 的后台，這對於日常的運行和測試，也是極為方便的。而我用的 http-server 就不行啦，不過好在 wangEditor 用不到后台語言。
至此，你可以想一下，在實際開發過程中，除了以上說的 install release 和 server 之外，還有哪些東西你覺得應該有，而這里沒包括？我第一次看到這三條命令的時候，我首先思考的就是這個問題，但是很遺憾我沒有想出來。其實也不用想，FIS這三條命令既然能用於百度那么多項目，為何就不能滿足自己的項目呢？
至於這三條命令如何使用，大家完全可以去文檔頁面大體看一下，或者自己花幾分鍾做一個demo，入門還是比較簡單的。
PS：FIS文檔頁面 http://fex-team.github.io/fis-site/docs/beginning/getting-started.html
5. 三種語言能力
在上文的 fis release 命令提到，FIS 在發布一個項目時候，要對項目進行分析，例如文件目錄的變化、文件的壓縮合並、以及應對這些操作混合起來產生的結果。
開發時，index.html 引用了 a.css 和 b.css ，發布時，兩個 css 整合成了 x.css ，那么 index.html 里面是不是應該引用 x.css ，這是必須的！
—— 其實，應對這么多情況，是一個很復雜的事情。
FIS 開發團隊自己也承認，在這一過程中走了很多的彎路，但是最終它們總結出了能應對以上所有情況的三條技能（它們稱之為“三種語言能力”）：
第一，資源定位
開發時，我們寫靜態資源一般都會用相對路徑，如 src = '../a.js'，而發布時候如果靜態資源變了位置，相對路徑就無效了。所以，FIS要求自己必須有能力去定位一個資源的位置，無論怎么變，都能找到，並根據最新的位置，給出正確的相對路徑。
第二，內容嵌入
最常見的就是css、js等靜態文件的合並、img的合並（css sprite），以及把 img 轉換為64位編碼放在網頁中。除了這些之后，你還可能希望將一個獨立的 css、js 文件，直接把它的內容嵌入到 html 網頁中，而不是引用。
以上這些，只要涉及到文件內容變化的，都算是資源嵌入。
做到這一點，FIS借助了一些成熟插件，如uglify；FIS也定義了自己的一些書寫規則，如 <img title="百度logo" src="images/logo.gif?__inline"/> 發布之后，img就會變為64位編碼形式（重點在“__inline”標識）。
第三，依賴聲明
javascript模塊定義有AMD、CMD、commonJS等規范，它們都有依賴這么一個概念，一般用 require() 函數描述。前端模塊依賴的工具，一般都是 requirejs 和 seajs ，大家在項目中也比較常用。
FIS 作為一個解決方案，難道是把 requirejs 或者 seajs 移植進來了？—— NO —— FIS有自己的思考（也有資料顯示，FIS的這塊思路是參考的facebook的技術，這里就不去糾結了）
requirejs 或者 seajs 能解決前端模塊化，但是它們有些情況是應付不了的——要不然百度FIS（或者facebook）也不可能再重新造輪子。這種情況就是當網站結構變得相當復雜的時候：一來，requirejs 和 seajs 出現性能問題；二來，這時候光靠前端是解決不了所有問題的。
這段很有意思，下文另起一題繼續。
6. 前后端結合的高效靜態資源管理
首先，強烈建議大家看看這篇文章：http://fex-team.github.io/fis-site/docs/more/mapjson.html ，下文就是這篇文章的梗概。這篇文章很好理解，個人感覺也很有創造性。
這篇文章的大體意思就是：我們如果完全用傳統的前后端分離模式，用傳統的前端性能優化（壓縮、合並、減少http）等，是無法最大程度的優化性能。最根本原因就是兩個字——靜態——對靜態資源的管理是靜態的。
解釋一下，由於我們采用傳統的前端性能優化模式，所有的css、js這些靜態資源，都是壓縮之后引用到網頁上的。壓縮之后就是一個大雜燴，有用的沒用的，甚至是已經廢棄的代碼，都在這里面。如果只通過前端優化手段，我們只能做到這一點。那么 FIS 是如何解決這一問題的？
FIS 在 release 項目時候，會生成一個 map.json 的文件（代碼如下），這個文件不是給前端用到，而是給后端（如 php）用的。php 拿到這個文件之后，會知道一個網頁到底依賴於哪些css、js，它就會加載，不依賴的根本就不理會。而且，這一過程不影響文件的壓縮和合並（大贊！）
1 { 2 "res" : { 3 "demo.css" : { 4 "uri" : "/static/css/demo_7defa41.css", 5 "type" : "css" 6 }, 7 "demo.js" : { 8 "uri" : "/static/js/demo_33c5143.js", 9 "type" : "js", 10 "deps" : [ "demo.css" ] 11 }, 12 "index.html" : { 13 "uri" : "/index.html", 14 "type" : "html", 15 "deps" : [ "demo.js", "demo.css" ] 16 } 17 }, 18 "pkg" : {} 19 }
（不明白的同學，急需要看看上文給出的那個鏈接）
這一過程將消耗很小的后台性能，但是卻大大提高了前端性能，項目越復雜，提高的就越明顯。
7. 總結
首先，上文並沒有寫完 FIS 的所有東西，畢竟這不是 FIS 的文檔。這里寫的只是我認為 FIS 中非常重要的概念、FIS 給我留下印象最深的東西。
通過上面的描述，讀者應該能發現，FIS 確實已經到了解決方案級別，它包含了項目的初始化、開發、發布、運行測試、最大程度的性能優化、以及我們本文沒有提及的組件化，等等，這些你在小型、大型系統中用到的所有東西。相比之下，grunt 和 gulp 這類工具性的東西，就有些黯然失色，特別是在大型項目中。
另外，基於 FIS 還擴展了其他的解決方案，例如純前端的 pure ，基於 java 的 jello ，基於 php 的 fis-Plus ，基於 nodejs 的 yog2，基於 go 的 gois ……
作為一個有理想的技術騷年，你是否已經被 FIS 所吸引？
我正在考慮我自己的開源項目 wangEditor 是否也應該切換到 FIS 平台，雖然 wangEditor 是一個很小的插件，哈哈。
-------------------------------------------------------------------------------------------------------------
歡迎關注我的教程：
《使用grunt搭建全自動web前端開發環境》《從設計到模式》《json2.js源碼解讀視頻》
《深入理解javascript原型和閉包系列》《css知多少》《微軟petshop4.0源碼解讀視頻》
------------------------------------------------------------------------------------------------------------
也歡迎關注我的開源項目——wangEditor，輕量化web富文本編輯器
-------------------------------------------------------------------------------------------------------------