亲爱的朋友们！
一个小事实：
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上发帖，因为这里没有任何的相关信息。
我无法再模板中设定一个变量，这个变量我会在后面的循环中用到。
对于这样一个需要我去“征服”的模板引擎，要它何用？
- [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
模板中的数据转换又怎么样呢？
在我把所有数据转换成模板形式之前，我应当使用@Before标注。比如我要在每个页面显示菜单，现在我必须把所有的菜单数组在每个模板调用中转换一下，然后在每个调用里面再通过原始类型传参，这么做不是多此一举么？
语言转换
你可以说Scala语言是未来发展的方向（但是我怀疑在短期内可能无法提升其编译的速度，不过这些都OK）。那么尝试创新，但是不要企图替代！你认为Eban比Hibernate更好？——只有熟悉Ebean的人才会这么认为吧！
假设在日本开一家餐厅，你尝试着用叉子代替筷子（因为有广泛的观点认为，叉子比筷子更有利于进食），然后看看这会不会成功吧。
向后兼容性永远是Java语言的根基，这也就是Java版本为什么演进缓慢的原因，旧的程序在新版本中运行不会出现问题。
你取消了的War包的创建，那我怎么把程序部署到Tomcat里？你通过修改 org.apache.commons.lang.StringEscapeUtils.escapeHtml(text)包来增加输出文字处理功能。很好! 但是这样就会把文字搞得乱七八糟，比如像：
- Сыновья
为了关掉额外的文字处理，我必须编辑Templates.scala并可能产生重新编译（说实话我还真不会手动编译）。如果Play框架的版本更新了，我又得重来一次。
结 论
现在，Play已经成为了我脖中之刺！如果刚一开始它是一个又简单又快速的开发框架，那么如今它已经发展到和其他许多框架一样臃肿和笨重。也许它能吸引大量Scala的粉丝，但是必将遭到Java开发者的厌恶。因为使用Play开发产品，你无法回避使用Scala语言。
也许Scala不是那么糟，但是我是一个Java程序员。我只在我有足够闲心的时候才会去学习一门新的语言。但是我现在不得不去学，才能将我所知道的方法，和Play框架开发者们所宣称的那些知识融合起来。
PS1：还记得苹果公司的格言“简洁至上”么？如果框架不给用户提供那些不需要的东西。那么用户也许会少一些花招，但是这会迫使用户使用真正有价值的方法。他们同样也可以完成一切需要完成工作，与此同时，那些普通用户则被华而不实的东西搅得心烦意乱。
PS2：返回 ok状态 (…) 你不是开玩笑的吧？ 如果我已经做好了准备返回，那我肯定是已经达到ok的状态了，否则我就抛出异常了。
PS3：如果使用Scala的主意是来自某个做酸绿网站的家伙，那么他就是万恶之源，消灭他！
英文原文：Open Letter to Play Framework Developers
原文来自：http://blog.jobbole.com/16631/
【编辑推荐】
- Play 2.0的完整演示过程记录
- Play Framework 2.0 新特性介绍
- Play framework 2.0 Final发布
- 拯救Java程序猿的神器：Play Framework
- Play可以做的5件很酷的事
