在Web快速開發框架間徘徊

現今就Web快速開發框架而言，有著許多的選擇，各自分布在不同的語言生態系之中，除了老牌的Rails、Django，還有Play!、Grails、Express、Spring Boot等框架，就架構與主要元件而言，這類框架其實十分相似，然而想要快速開發或是維持設計的簡單與一致前，弄清問題邊界與各自經驗，才有可能真正運用這類框架快速開發。

Web開發至今已經累積了相當多的成熟經驗，就Web應用程式而言，MVC已經是公認且驗證的架構，Web快速開發框架基本上必然實現了MVC架構（儘管有些細節上的不同），多半要具備的元素有URL路由對應、HTML模版系統、ORM與資料庫管理、表單處理與驗證、使用者管理、基本安全管理、測試、部署等；而附帶的元素，則為各種工具、程式庫（如郵件發送、多國語系時區支援）等，其中路由、模版系統與ORM，通常是一開始使用時最先接觸也最關心的部份。

URL路由對應基本上是個模式比對，乍看沒什麼，然而不同應用程式可能會有不同的路由設定方式，因而路由設定規則通常也是最複雜的，在各框架之間的設定方式也多半不一致，有些框架使用自行設計的表達式，有些框架使用規則表達式（Regular expression），例如Django；有些框架直接支援RESTful路由設定，例如Rails；有些框架必須外掛其他plugin或框架，例如基於Django的Django REST framework。

在HTML模版系統的部份，有些框架使用有別於原本程式語言的模版語言，像是Django，有的框架則可內嵌原本程式語言，像是Rails就使用了內嵌Ruby程式碼（Embedded Ruby），這會讓撰寫HTML模版比較不會在兩種語言間混淆，可以降低學習成本。

跟模版打交道時，標記的易用性也是很大考量，像是標記是否複雜或獨特，更重要的是避免與HTML衝突，像是使用了<、>來標記的話，有時就得自行Escape，以免與HTML標籤衝突，基於Java的Web框架，就有這類的問題。

Web快速開發框架無一不採用ORM來存取資料庫，不用撰寫SQL而藉由物件導向方式來操作關聯式資料庫，省去了物件導向與關聯式模型兩者間對照的繁瑣，框架搭配的ORM在API上通常都考量了大部份的需求，使用上並不困難，比較要注意的部分，反而是有無資料庫遷移（migrate）的功能，也就是能記錄資料庫表格變更歷程，未來可依記錄變更或回復資料庫表格欄位等內容，例如Rails、Django 1.7中就內建了遷移功能，而Django 1.7之前的版本，必須使用外掛south才有此功能。

語言、生態系特質

各個框架基於各自語言之上而建立，因而選擇框架的主要原因之一，當然，就與打算採用何種語言來開發，有高度的相關性，訴求快速開發、簡潔與靈活度的框架，多半採用動態定型語言實現，例如Ruby、Python與JavaScript之上，各自有Rails、Django、Express等代表框架，而基於JVM的框架，也有基於Groovy的Grails這類的框架，不過，也有基於靜態定型語言且同樣訴求快速開發、簡潔與靈活度，像是基於Scala的Play!框架。

不過，簡潔與靈活度在不同語言擁護者中，有不同的定義，就基於Ruby的Rails來說，由於有Ruby強力的meta-programming支持，在塑造相關DSL時特別有利，許多開發者甚至是學了Rails才回頭學習Ruby，證明了Rails在DSL上的表述力極佳，加上有慣例勝於設定（Convention Over Configuration, CoC）的原則，開發時能極大加快開發效率，不過，卻也容易因為不熟悉慣例或者DSL的相關魔術，而產生種種問題。

相對之下，由於Python社群崇尚明確（Explicit），沒有過多的魔術，程式碼雖然會多了些，然而，學習與使用過程卻也明確許多。

就語言生態系來說，由於Rails受到注目，才帶動了對Ruby這門語言的關注，因此Ruby社群幾乎是著重在Web開發這塊，單就Web生態這塊來說非常豐富，許多功能也被整合入Rails之中，然而缺點就是越來越臃腫；由於Python本身在Web快速開發興起之前，在其他領域已有相當之發展，Django本身自成一套生態系統，雖不若Rails那麼包山包海，然而學習負擔上比較輕鬆，不過在必要的時候，就得自行整合相關plugin或程式庫。

基於JavaScript/Node.js的生態系是比較特別的一群，由於JavaScript引擎不斷在效能上做了改進，加上採用非同步開發模型，像Express這類框架，效能上擁有很高的表現，擁有各種支援非同步程式庫也是優點，缺點就是多數開發者對非同步模型不熟悉，需要時間適應，JavaScript語言本身的缺陷也是問題（儘管Node.js持續努力實現ECMAScript 6）。

效能、文件、部署、升級

儘管各快速開發框架效能都會宣稱，經由某些適當設計或調校，效能不會是問題（另一常見說詞則是，語言速度不等於框架與應用程式整體速度），然而，當網站需要考量到效能因素時，動態定型語言實現的快速開發框架經常在效能上就捉襟見肘，這時儘管基於靜態定型的框架靈活度或簡潔性較差，然而速度上的優勢就具有彌補的作用，就這點來說，Rails比較可憐，談到快速開發框架效能不彰，總是舉得出從Rails遷移到其他框架的案例。

就我個人來說，選擇快速開發框架的重要考量還有個重要考量，那就是文件的齊全度，其中最重要的是官方文件，一個快速開發框架，卻要讓開發者在瞭解它的過程花費大量時間，對我來說是很不可思議的一件事。最重要的不是那種說明個別功能如何設定的文件，而是功能如何逐步加入應用程式，將之整合在一起的文件，像是Django官方的〈Getting started〉（https://goo.gl/Qy5H8m）文件就是個不錯的例子，就這點來說，Spring Boot就很差，嗯！或許他們的想法是，開發者得先學會整個Spring Framework再來用Spring Boot吧！

網站最終要上線，部署難易度也是得考量，現今雲端時代解決了部份問題，例如已有不少PasS（Platform As A Service）雲端方案，可提供特定語言框架環境，讓問題減少到考慮主機效能與價格彈性。

快速開發框架往往也是改版快速，因而日後版本升級的難易度也是必要考量，這大概也就是為何，快速開發框架都會將測試框架整合在內，平時有撰寫測試的習慣，有越完整的測試覆蓋，升級時對付新變化要花費的時間就會比較少，評估框架時記得查看過去的釋出版本，有無提供清楚的升級指南。

開發經驗與框架熟悉度

快速開發框架由於封裝了許多複雜的底層，經常被作為程式新手入門Web開發之用，然而，就個人的觀點來說，程式新手拿這類框架來學習入門，或者是寫些原型程式是可以，不過這類框架要拿來開發實際產品，應該要有Web相關開發經驗的人來使用，例如就連DHH本人也說過，Rails不是給初學者使用的（https://goo.gl/FCgjyn）！

因為就有Web相關開發經驗的人來說，在有足夠文件前提下，上手這類框架並不難，經驗上會告訴他們，MVC、RESTful、ORM等各是什麼，在某些魔術自動起作用的同時，也會去思考或探索背後的原理為何，這類框架的易用性，是建立在開發者已有相關的經驗之上，實際上，上手框架是一回事，真要能使用這類框架做快速開發，像是想在十分鐘內從無到有建立、修改出一個適用的BLOG，也得時時與框架為伍，加上足夠的開發經驗才有可能。

或許最好的評估方式，就是各自寫個原型實際評估，像是〈Play vs. Grails Smackdown〉（http://goo.gl/euYPYM），就開發過程可能使用之元素、語言、生態系、效能等各方面做評估，找出適合自身或團隊特質的方案！