scala中web開發框架，哪一個能最後一統scala天下？lift or play

01-27

scala 中的web框架，希望最後能否發展成 Ruby on Rails

哎，希望大家不要被小豬的答案誤導。

其實不同框架間的特性差異很小，不會存在某個框架上的特性在另一個框架上無法實現，因為我們知道所有編程語言的編程能力都是圖靈等價的，你完全可以用Java編寫一個Scala解釋器，從而支持Scala所有特性。但是不同的框架會有不同的追求，這也決定了它的技術走向。傳統的SSH/SSI/SpringMVC繼承了Java的優良傳統，保守不激進，適用於較大的開發團隊(如20人以上)，人員流動較為頻繁。而新興框架(如Play Framework/Lift)在技術上有更高的要求，希望不斷嘗試新的方法和技術解決面臨的技術難題，但是由於缺乏持續跟進的學習資料，所以適合較小的開發團隊(如10人左右)，團隊相對穩定。正是因為新興框架的學習資源缺乏問題，所以才讓很多人覺得學習門檻高，入門難。其實在有人帶的情況下，Play的入門速度很快，通常一周就可以寫一些小項目了。我以前做過三年的SSH/SSI開發，從2011年轉向Play2，當時Play2剛剛發布第一個版本，再後來2013年從Play for Java 轉向 Play for Scala，一直使用至今（當前版本為2.6.6）。期間我經歷過兩個團隊，成員對Play2的反應都很不錯。

前面說了很多廢話，下面回歸正題。我覺得沒有什麼懸念，Play最終一定會勝出。一方面是因為Play是Lightbend官方維護的框架，Lightbend會為其維護良好的生態環境(如Akka, Cassandra, Spark, Kafka, Slick等)。另外Play自身的優勢也很明顯，它被設計成一站式解決方案，內置了足夠多的服務(如cache,ws,resource, etc.)，開發效率很高，並且非常適合高並發場景；配合Akka可以輕鬆地搭建現在很火的微服務架構；配合MongoDB及內置的JSON庫，統一前後端數據結構，開發非常流暢；配合Vue及內置的模板引擎Twirl，可以隨心所欲地控制前端展示；配合Scala的Future/Promise API及內置非同步的WebService服務，可以開發高性能的非同步非阻塞應用；當然，還有很多就不細數了...

要說好用，那一定是lift好用，但lift的代碼。。。的確是很糟糕。。。。

至於play。。。。我一直是堅定的play黑呀。。。來貼一個play剛出來的時候我寫的東西吧：

注意，這是差不多3年前play 2.0剛剛發布的時候寫的東西，現在也許已經有些變化，但總的來說，當時把我噁心壞了。。。

最近研究了一下被很多人吹噓的Play Framework，當然，是它的最新版本2.0，完全基於Scala開發，Typesafe官方推薦，號稱scala開發web應用的不二選擇。我的基本感覺是，just like a toy。。。
1. 不支持j2ee
Play號稱基於nio的event驅動，自行實現了http協議，比之傳統j2ee應用性能高出無數云云，因此，使用Play，無需用到j2ee容器，也沒有servlet/jsp的概念，只需要jvm，然後run就可以了。看上去的確很美好，然後一個很基本的事實是，除了個人的玩具應用，有哪個企業的IT管理員會願意在已經熟悉的j2ee環境上在出現一個新的環境？更基本的事實是，從管理的角度來說，play提供的容器，能夠達到j2ee規範的高度嗎？更更基本的事實是，你能夠相信它的安全性嗎？雖然tomcat也會有安全漏洞，雖然jetty也不見得就真的安全，雖然websphere和weblogic都是要花錢的，但是比起他們來，你會更相信play的容器嗎？我相信99%的答案是No。
（當然，有一個第三方插件項目在試圖幫助Play部署war，但就其官方的態度而言，我是完全無法贊同的，而且，那個插件項目，遠未到成熟的地步，因為Play從根子上就沒有打算遵循j2ee規範）
2. 沒有服務端session

Play的口號是stateless，但我並不認為這個可以成為不提供服務端session的理由，現實生活中大部分的網站還是需要session的，你哪怕提供一個插件來提供session功能也好啊，可是很遺憾，沒有，官方的文檔上說，請自行處理。。。自行處理。。。這個世界上還有程序員有興趣去實現一個session管理嗎？
3. 編譯成函數的模板
Play認為這是它的優點，靜態編譯的模板，類型安全的參數傳遞。但我卻被它徹底的打敗了，為了向被各個頁面復用的page top傳遞幾個參數，我需要在每一個直接引用到它的模板，以及每一個間接引用到它的模板上添加所有的參數以便傳遞，因為，調用模板其實就是調用函數啊，我必須傳遞參數啊。。。當然，幸運的是，我們用的是scala，scala有implict參數定義，oh my God，我不需要傳遞參數了。。。可惜的是，我仍然需要在每一個層次的模板上聲明必須的參數，這是怎樣的一種精神，這是精神分裂的前兆。。。更加麻煩的是國際化與本地化處理，
Play提供了一個getmessage的函數讓我們可以取得本地化字元串並且填入參數，功能很簡單，當然，這並不妨礙我直接使用JDK的國際化API，因此這倒算不上它有多罪惡，然而，在表現層，或者說view層，當我希望根據locale選擇一個不同的模板文件的時候，問題就麻煩了，靜態編譯的模板，類型安全。。。似乎我需要用到反射才能夠根據locale選擇模板了。。。讓我去死吧。。。
4. Comet

Play內置Comet支持，看上去非常方便，然而當我終於搞明白它是如何實現comet的時候，我實在忍不住噴了滿屏的口水，再放聲大笑。。。這是整個Play框架中最富娛樂精神的實現，絕對可以入圍2012年度最佳編程娛樂獎的評選活動。通常Comet的實現有很多種辦法，典型的無非是ajax based long pulling, iframe based long pulling, websocket based server side pushing，你們還能想出其他的辦法嗎？Play給出了一個絕佳的方案，http chunk based server side pushing via iframe。不明白http chunk的同學請自行google，我簡單的解釋一下就是，在iframe中發起一個訪問，然後服務端不會關閉http連接，而是返回基於chunk的應答，這樣，客戶端瀏覽器就會意識到伺服器的應答沒有結束而一直保持連接，服務端如何有事件發生，就返回一個chunk，通常是一段javascript代碼，然後瀏覽器收到一個chunk，在等待下一個chunk的同時，執行javascript，實現了一個完美的server push機制。Wow，看上去非常perfect哈，不過請大家想像一個瀏覽器在處理一個長連接的時候會是怎樣的動作？答案是瀏覽器會顯示沙漏圖標提示網頁正在下載中，即使它是一個隱藏的iframe也是一樣，於是，你就會發現，你的瀏覽器上會有一個轉圈的圖標在不停的轉啊轉啊，然後像我這樣愚蠢的用戶就會手賤的點停止，嗯，很好，不轉了，整個世界清靜了，太清靜啦，瀏覽器不再接受服務端的response了，連接被關閉了，comet也over了。。。
5. 文檔支持
Play試圖提供一個完整的web開發的生態環境，可是如此偉大的目標，顯示不是官網上那點step by step性質的文檔可以支持的，可是我找不到更多的文檔了，官網提供的文檔足夠我開發一個玩具應用了，然而，也僅此而已了。
網上很多人吹噓Play2.0如何美好，Scala程序員是如何歡欣鼓舞，然而我實在沒有發現任何一丁點Play足以吸引我的東西，而它的不足之處是如此的明顯，我必須聲明的是，Play還有更多讓我覺得罪惡的東西，但我願意承認那些東西更多的取決於個人的審美觀。或許，等到3.0的時候，再來看看它的情況是比較明智的選擇。至於現在，just play.

很久以前，用scala的時候，也這麼糾結過，後來選中了play，一直陪伴至今。play的特性跟j2ee完全不一樣，甚至算是驚喜。

至於小豬這種無腦噴，看看就好了。

1. 基於netty,性能很高。

2.基於cookie的狀態保持，分散式部署非常容易

3.模板引擎沒怎麼用，感覺沒啥難以上手的

4.部署異常方便。現在結合docker之後，更屌。

5.用來實踐微服務非常容易並且不會有額外的大堆無用玩意兒。

當然，我是站在scala用戶的角度。至於java，我還是不建議用Play了，畢竟play第一語言是scala寫的，特性也是和scala相關的。java版本看起來，體驗極差，大概就吃麥當勞的時候，發現餐廳改名金拱門了

話說大家有沒有將play 和 spark 結合使用的？ play裡面提交作業到spark集群

play是金字塔的底層，人多。高端的走lift

Web方面目前喜歡Scalatra (+Scalate模板引擎)。

ORM方面Squeryl很好，感覺完爆Slick幾條街，其上還進一步出現了更易用的Scala-ActiveRecord。

這三者共同組成MVC。

PS: 這些框架的依賴樹好可怕，連標準庫都引用了不同版本，我的電腦都成了Scala版本大集合了。

play的前景應該會好一些。剛到了新公司，使用的是lift，個人而言，真心對lift沒好感，代碼風格和一些實現細節都感覺很噁心。最近還發現有個叫scalatra的框架貌似不錯。

沒用過lift，play確實不錯。了解不多所以匿名了

講真，對於play 累覺不愛，只是簡單創建個app，已經無語了。