一些關於前端Framework的想法（上）

看到Po-Ying寫這一篇，也讓我想起一路學習前端開發的過程中，碰到的Framework，試著把現在的想法寫下來，或許以後回來看會有很精彩的火花也不一定。

作者揭露：目前使用的前端Framework為React.js與Batman.js，曾經用過的有Angular.js、Backbone.js與jQuery。前端工具選擇為webpack與middleman，曾經用過Makefile + gulp.js、Gruntjs與Rails Asset Pipeline (Sprockets)。以下言論嚴重包含作者個人主觀意見，並只會針對曾經用過的部分做討論，並不涉及其他Framework/Library，請斟酌觀賞。

Framework種類

1. 不使用任何Framework：Vanilla JavaScript、使用Native DOM API。
2. DOM Manipulation framework/library：如jQuery、Backbone.View、React.js與Batman.View。提供的是DOM操作的包裝，主要解決跨瀏覽器問題。
3. General framework：如Backbone.Model/Collection/Controller、Angular.js、Flux與Batman.Model/Controller。可能包含1.的內容，除了對DOM包裝以外，提供的是一套「資料流」的定義方式。

所以我們應該把問題換成：我們應該選擇的開發方式是哪些？1. or 2. or 3. ？分成這樣會比較好討論。

不使用任何Framework

這其中又可以細分成兩個小項目來看：

1. 不使用任何第三方Library，完全自幹：
   這樣做不是完全不行，只要A是全世界前0.1%的JavaScript developer，其他人當然完全沒有理由反對A這樣做。不過身為技術長或共同創辦人的B，可以想想B的工程團隊至始至終都只有這個A嗎？不可能會成長嗎？成長之後招募的人可以跟A合作嗎？如果B有信心解決這些問題，這邊右轉離開謝謝。
2. 使用一些第三方Library，但是不會超出Library的範疇：
   你使用的這些Library，總學習成本加起來會比學一個Framework低嗎？另外，文件的完整程度如何？提供的Interfaces可以跟其他第三方Library良好銜接嗎？或是他們的設計理念是否相似？如果不是的話組起來會很奇怪。另外這些Library的社群活躍程度也是很重要，就算遇到問題協作者可以馬上解決的話，自然是再好不過。

這樣看起來，大多數人(99.9%)是不應該選擇1. 這條路走的。若選擇2.「在這個專案」的成本遠低於使用Framework，那當然也是一個好的選項。不過我們常常都會遇到的是，專案需求不停變更（這絕對不是誰誰誰的錯，這個世界本來就是這樣），身為技術長的B要怎麼保證未來成本不會超過Framework呢？

文章寫到這篇有點長，先這樣好了，請靜待下回分曉。