這篇文章分享的不是成功的經驗，而是失敗的教訓~ 設坑
關於為什麼要研究元件化以及之前對元件化實現方式的理解都在這篇文章——《利用handlebars實現後端元件化》。本來按照之前的思路，覺得元件化應該有三種實現方式，一種是後端模板；一種是瀏覽器端由js實現，包括reactjs的元件、angular的指令等，不過這些對css檔案無法管理（有個外掛程式號稱完美實現元件化，研究完之後再分析）；最後一種就是利用構建工具實現元件化。
如果真能找到這樣一種構建工具，不依賴前後端語言、模板、框架，在構建**的時候直接直接將元件打包是不是很完美？如果你也這麼想，那麼恭喜你可以跟我一其踏上一段踩坑之旅了。 入坑
目標已經明確的話開始尋找工具。理想的是有工具外掛程式直接實現元件化，差一點的話自己稍加改造實現也可以接受。看看現在比較流行的工程化工具：
webpack
首先研究這個最新最火的工具，一進入官網就被那個炫酷的css3立方體吸引了，看上去很高大上的樣子。官網上內容很多，雖然是英文的但是問題不大。看到選單上有一系列教程（list of tutorials）非常欣喜，心想好軟體就是不一樣，教程都寫得這麼多。一點開傻眼了，根本就不是什麼學習教程，就是各種語言湊起來的文章，完全無法引導新手很好的學習，也沒有分類。照著例子使用了之後發現如其所說只是個模組打包工具，恨不能讓任何頁面只引用乙個js乙個css，對第三方依賴的處理也是狗血，要麼合併成乙個，要麼乙個乙個配置，手動在html中維護，而且還是侵入式的改變源**內容。功能很簡單，實現過程很複雜，蛋疼之後更是伴隨一陣心疼，遂放棄。
如有不對之處，歡迎webpack資深玩家拍磚指點。
fis3 現坑
gulp
gulp和grunt功能上差不多，豐富的擴充套件性決定了其能成為最強大的前端構建工具。gulp效率高一些，所以這裡只討論gulp。當不停地尋找合適外掛程式的時候終於發現乙個關鍵性的功能似乎不能實現，那就是元件的巢狀引用以及依賴資源的自動合併，如果需要實現這個功能那麼要動態處理html**識別資源然後進行整合，這個功能是不是有些熟悉，對，這就是之前寫過的利用後端模板引擎做的事情。
想到這裡，這個坑就明顯了：我在試圖用構建工具來侵入**來完成模板引擎該做的工作而同時它還無法像模板引擎一樣填充資料。這就好比我在用羽毛球拍打桌球，還一直覺得是球拍品牌不夠好所以打不好球。
（資質代辦）
（資質代辦） 出坑
回過頭來看看構建工具的職能到底是什麼？
fis3給其定義了三大職能
前端學習之路 思考吐槽
看技術文件的時候最怕什麼，不是看不懂，不是學不會，而是一看發布時間是幾年前，頓時覺得自己胸口中了一箭 作為乙個沒去過大公司的前端 bat 這跟人的差距真不是一般的大，每次自己有所感悟去總結一下，略有所得時，去搜一下這方面的文章，看著別人幾年前的文章，我的膝蓋又中了一箭 每次剛剛掌握一門新技術時，這門...
吐槽！iview的table元件
為什麼要吐槽iview的table元件呢？首先iview的table的使用體驗十分的不友好，每次修改資料都會重刷整個 效能極差，因為重刷 會導致自動失焦等問題！vue不是有diff演算法嗎？重刷 資料沒有發生變化部分是不會重新渲染的，效能為什麼會差呢？是的，diff演算法是可以優化vnode的渲染問...
GraphQL的踩坑之路
為了更好的支援前端能夠自由組合 展示收到的資料，筆者使用graphql go 框架開發了負責的模組，但測試過程中發現，使用graphql會有n 1 query的問題。經過調研發現兩種解決方案 在使用graphql go的同時使用facebook開源的dataloader工具，詳細例子見dataloa...