一些關於前端Framework的想法(上)
Published in
3 min readNov 14, 2014
看到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種類
- 不使用任何Framework:Vanilla JavaScript、使用Native DOM API。
- DOM Manipulation framework/library:如jQuery、Backbone.View、React.js與Batman.View。提供的是DOM操作的包裝,主要解決跨瀏覽器問題。
- General framework:如Backbone.Model/Collection/Controller、Angular.js、Flux與Batman.Model/Controller。可能包含1.的內容,除了對DOM包裝以外,提供的是一套「資料流」的定義方式。
所以我們應該把問題換成:我們應該選擇的開發方式是哪些?1. or 2. or 3. ?分成這樣會比較好討論。
不使用任何Framework
這其中又可以細分成兩個小項目來看:
- 不使用任何第三方Library,完全自幹:
這樣做不是完全不行,只要A是全世界前0.1%的JavaScript developer,其他人當然完全沒有理由反對A這樣做。不過身為技術長或共同創辦人的B,可以想想B的工程團隊至始至終都只有這個A嗎?不可能會成長嗎?成長之後招募的人可以跟A合作嗎?如果B有信心解決這些問題,這邊右轉離開謝謝。 - 使用一些第三方Library,但是不會超出Library的範疇:
你使用的這些Library,總學習成本加起來會比學一個Framework低嗎?另外,文件的完整程度如何?提供的Interfaces可以跟其他第三方Library良好銜接嗎?或是他們的設計理念是否相似?如果不是的話組起來會很奇怪。另外這些Library的社群活躍程度也是很重要,就算遇到問題協作者可以馬上解決的話,自然是再好不過。
這樣看起來,大多數人(99.9%)是不應該選擇1. 這條路走的。若選擇2.「在這個專案」的成本遠低於使用Framework,那當然也是一個好的選項。不過我們常常都會遇到的是,專案需求不停變更(這絕對不是誰誰誰的錯,這個世界本來就是這樣),身為技術長的B要怎麼保證未來成本不會超過Framework呢?
文章寫到這篇有點長,先這樣好了,請靜待下回分曉。