優點
a) 提高開發效率。
b) 規范名稱定義，便於維護。
c) 規范項目開發流程
d)css代碼更清晰、簡單。html代碼更合理。
e) 大規模項目中可以減少用戶下載
弊端
a) 學習成本提高。你需要了解整個框架，需要閱讀框架的文檔。
b)css框架對於一個小項目等頁面來說很臃腫。框架中可能有大部分你用不到的代碼。
c)可能會無法幫助你的技術提高。太依賴框架，以至於很難排除bug。包括框架中本身就帶的bug。
d) 選擇自己需要的框架與開發框架都很痛苦。寫到後面發現越來越不靈活，越來越臃腫。
常見問題
1、頁面外部引用樣式過多。
譬如關於ul的margin定義,在格式化的css中會聲明為0，而在基本樣式的css中又可能會聲明margin:5px 10px;
所以在Yslow中會出現多次定義。
2、組件復用性的考量。
譬如表單定義的css中定義了所有表單的修飾,而假定在注冊這個頁面中只是需要這個css的百分之三十。那是否應切割出去那不要的百分之七十?
綜合以上的二個問題，個人認為解決的方式便是封裝，讓該有的有，不該有的沒有。盡量減少http連接數和css的大小。但如果徹底是這樣做的話，css的復用性又會變得很差，後期手工的封裝會很痛苦。
3、到底該不該支持em?
可見如要支持em，最大的目的是為了在浏覽器中可以根據用戶的分辨率大小自由縮放，對於擁有超大顯示器的用戶與小顯示器的用戶是非常有用的。可是在采集我們用戶的浏覽器數據後，發現分辨處於這二端的用戶非常少，可想而知，為這部分的用戶多花比正常開發一倍以上的時間顯然是件不劃算的事情，所以當初在開發tbsp的時候，我們團隊就決定了不支持em。當然這是個建議，我們也希望能使用em帶給用戶最好的感受。