2012/04/06
导读：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的主意是来自某个做酸绿网站的家伙，那么他就是万恶之源，消灭他！