導讀：3月中旬，Play Framework 2.0 正式版釋出了。2.0 版本的主要新特性：內建對 Java 和 Scala 的支援、完全非同步程式設計模型、側重於型別安全、強大的構建系統、資料儲存和模型的整合等。本文是 Roman Bykovskiy 釋出在 Play Framework 的 Google 群組的一篇文章。
親愛的朋友們！
一個小事實：
Scala遜斃了。好吧，我承認這個語言或許被捧上了天，但是編譯它而產生的昂貴的時間花費也是不爭的事實。整整13秒！這還是在做了微調將其變成模板以後！我自己為了優化編譯而專門分配一個分離式伺服器，最終將編譯速度提高到了5秒——但是這仍然是很大的時間花銷！我們已經嘗試使用別的平臺了！
一個大謊言：
“Play框架讓網路應用開發更簡單！無論是Java還是Scala”
事實是：“Play框架讓網路應用開發更簡單——僅僅對於Scala，如果你使用Java……那麼，好吧，讓神明賜予你力量吧！”我一會兒再討論這個問題。
（伯樂線上配圖）
我的故事
當我剛聽說Play框架的時候，我開啟了官方網站，並觀看了1.x版本的介紹視訊！額滴個神啊！就是它！我當時就認準了！我安裝了Play框架，在我的電腦上實現了所有教學視訊裡的例子，並根據我當時正在做的專案，迅速地寫出了一份開發文件。
整整一個月的時間，我都在嘗試說服老闆，在新的專案中使用Play框架，因為它比我們在使用的所有框架都更優秀！最後我做到了！像變戲法一樣，迅速地改變了一切。
但是現在，當我們已是到新的專案將使用Play 2框架時，我的同事們臉都變綠了，並且我無法找到任何藉口——來解釋Play 2跟Play 1完全不是一碼事。如果我自己都不理解Play 2是如何工作的，那我怎麼去幫助我的同事呢？
快速細化
我之所以喜歡Play 1.x版本，是因為它的速度。這裡不是指它的執行速度快（隨著電腦速度的更新，人人都能做到速度快），而是它的細化速度。框架的一切都是如此的敏捷和簡單。而在2.0版本里，這一點簡直就是煎熬。2.0版本丟棄了1.0的結構和成果，反而去尋找另一種方法，實現那些本來在1.0中可以輕鬆搞定的事情，而且還是以好幾種模式去做。
Scala
我是一個Java開發者。那麼我為什麼要去學習用Scala語言來製作一個基礎模板呢？我僅僅就是需要一個模板而已！只不過是一種格式化輸出資訊的方法。它能編譯當然很好！但是如果為此我就需要花費大量的時間去處理細化，而且絕大多數時間還是在乾等，那我編譯它有個鬼用？
也許在美國，你們編譯Scala程式碼，但是在我們俄羅斯，Scala是在編譯你！
這感覺真是相當不好！
為了說明一些最簡單的事情，我不得不在Google groups上發帖，因為這裡沒有任何的相關資訊。
我無法再模板中設定一個變數，這個變數我會在後面的迴圈中用到。
對於這樣一個需要我去“征服”的模板引擎，要它何用？
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[error] /home/romka/projects/ponominalu/target/scala-2.9.1/src_managed/main/views/html/event.template.scala:156: '(' expected but ')' found. [error] """),_display_(Seq(/*123.14*/for)),format.raw/*123.17*/(""" ((sector,i) <-subevent.sectors.zipWithIndex) """),format.raw("""{"""),format.raw/*123.64*/(""" [error] ^ [error] /home/romka/projects/ponominalu/target/scala-2.9.1/src_managed/main/views/html/event.template.scala:421: illegal start of simple expression [error] """)))})),format.raw/*388.2*/(""" [error] ^ [error] two errors found |
呃，我應該如何根據這些輸出查詢錯誤？別告訴我說錯誤在156行。這些破資訊怎麼能幫助我理解發生了什麼？他們就是一大堆額外的空白字元！
模板中的資料轉換又怎麼樣呢？
在我把所有資料轉換成模板形式之前，我應當使用@Before標註。比如我要在每個頁面顯示選單，現在我必須把所有的選單陣列在每個模板呼叫中轉換一下，然後在每個呼叫裡面再通過原始型別傳參，這麼做不是多此一舉麼？
語言轉換
你可以說Scala語言是未來發展的方向（但是我懷疑在短期內可能無法提升其編譯的速度，不過這些都OK）。那麼嘗試創新，但是不要企圖替代！你認為Eban比Hibernate更好？——只有熟悉Ebean的人才會這麼認為吧！
假設在日本開一家餐廳，你嘗試著用叉子代替筷子（因為有廣泛的觀點認為，叉子比筷子更有利於進食），然後看看這會不會成功吧。
向後相容性永遠是Java語言的根基，這也就是Java版本為什麼演進緩慢的原因，舊的程式在新版本中執行不會出現問題。
你取消了的War包的建立，那我怎麼把程式部署到Tomcat裡？你通過修改org.apache.commons.lang.StringEscapeUtils.escapeHtml(text)包來增加輸出文書處理功能。很好! 但是這樣就會把文字搞得亂七八糟，比如像：
|
1 |
Сыновья |
這樣。
為了關掉額外的文書處理，我必須編輯Templates.scala並可能產生重新編譯（說實話我還真不會手動編譯）。如果Play框架的版本更新了，我又得重來一次。
結論
現在，Play已經成為了我脖中之刺！如果剛一開始它是一個又簡單又快速的開發框架，那麼如今它已經發展到和其他許多框架一樣臃腫和笨重。也許它能吸引大量Scala的粉絲，但是必將遭到Java開發者的厭惡。因為使用Play開發產品，你無法迴避使用Scala語言。
也許Scala不是那麼糟，但是我是一個Java程式設計師。我只在我有足夠閒心的時候才會去學習一門新的語言。但是我現在不得不去學，才能將我所知道的方法，和Play框架開發者們所宣稱的那些知識融合起來。
PS1：還記得蘋果公司的格言“簡潔至上”麼？如果框架不給使用者提供那些不需要的東西。那麼使用者也許會少一些花招，但是這會迫使使用者使用真正有價值的方法。他們同樣也可以完成一切需要完成工作，與此同時，那些普通使用者則被華而不實的東西攪得心煩意亂。
PS2：返回 ok狀態 (…) 你不是開玩笑的吧？ 如果我已經做好了準備返回，那我肯定是已經達到ok的狀態了，否則我就丟擲異常了。
PS3：如果使用Scala的主意是來自某個做酸綠網站的傢伙，那麼他就是萬惡之源，消滅他！
英文原文：Open Letter to Play Framework Developers 編譯：伯樂線上 – 黃小非
【如需轉載，請標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】