首先對于一家創(chuàng)業(yè)公司而言，這更像是一個商業(yè)抉擇而不僅僅是技術選擇，時間人力物力等開銷都必須要考慮周全。一旦公司規(guī)模上來了資金不成問題了，可選擇的空間就更大了甚至可以進行遷移或重新架構。原文作者Ramigbtech總結了以下10點以供參考。譯文如下：

1.  語法

擁有優(yōu)雅語法的語言無疑可以讓編程工作變得愜意，但有時候我們容易被表象所蒙蔽，如果憑直覺你認定，"this is text".split(’ ‘).reverse.join(‘ ‘)比" ".join("This istext".split(’ ‘)[::-1]) 的寫法要好或差，那么這僅僅是外貌協(xié)會，實際上我們更應該著眼于它本身是否具有局限性或語法是否累贅，用更少的代碼完成等價的工作我們自己或團隊都會對當初的選擇心存感激。

2.  功能和體型

我們需要為路由編寫復雜的正則查詢嗎？路由中含有內建的DSL嗎？我們需要使用ORM嗎？或許我們還想擁有更多其它功能。建議選取一款較輕巧框架作為開始，日后我們可以為它添磚加瓦。

3.  文檔資源

具備豐富文檔資源的框架使用起來的確是得心應手事半功倍。例如我在學習CodeIgniter時，根本不必像無頭蒼蠅那樣四處尋找答案，其自帶的教程和配套范例都做得非常認真仔細。相對而言，我在學習ExpressJS的時候就比較費力了。

4.  代碼自動生成

框架中的代碼自動生成功能通常能為我們節(jié)省不少時間，我們僅需要做好控制器/類等的處理而把其它重復的編碼工作交給框架，雖然有時候不能自由地進行自定義，但對于想快速開發(fā)出一個能運行的原型是有積極意義的。

5.  模塊化

Django在模塊/Apps的處理上令人贊嘆，不僅僅讓代碼復用變得簡便，同時有助我們培養(yǎng)良好的模塊化思維。當我們不再需要X模塊時，我們只需把它移除然后做好代碼重構工作就可以了。

6.  基礎架構

不論是使用LAMP還是MEAN堆棧，或是Rails/Unicorn等，最關鍵的還是我們對這個架構有沒有足夠的了解，有沒有相關組件的維護能力。假如應用的前端和后端都與Javascript相關，采用MEAN堆棧架構是個不錯的選擇。

7.  社區(qū)和更新速度

框架相關的社區(qū)是否活躍？有沒有技術大咖坐鎮(zhèn)？官方會否常常上StackOverflow幫忙解答技術疑難？為這些問題找到完美的答案是有一定難度，但絕大多數(shù)時候數(shù)字是最真實的。日期或參與度/帖子熱度都是不錯的衡量指標。此外，補丁的更新速度也十分關鍵，對安全性和漏洞的重視與否可謂是牽一發(fā)而動全身。

8.  重大變更

就在最近不少程序員聽到Angular 2.0的重大變更后感到震驚和抓狂，盡管要到2015年晚些時候才會全部完成，但一想到辛辛苦苦做好的代碼都會變成過去時，又怎能安之若素呢？另一個例子是Yii框架，新版本2.0的推出意味著對前個版本的完全重寫。

9.  部署和依賴

容易部署嗎？能方便進行擴展嗎？需要花費多少時間來學習掌握部署工具？雖然有Docker這樣的工具可以幫我們解答上述問題，但是抽取時間來思考這方面的問題還是有必要的。

10. 人力

我們能快捷地找到相應的開發(fā)人才嗎？將要使用的框架在我們所處的區(qū)域是否流行？縱然培訓工作是管理的一部分，但對于初創(chuàng)公司而言時間和資金時刻都得精打細算。

寫在最后：

如果是中型的網站，我會選擇Django。如果我暫時不能確定網站的規(guī)模和將投入多少開發(fā)精力，我會選擇Rails。如果我不想前后端工作分得太開，我會選擇MEAN堆棧