Play!也一直在关注，包括最新的1.0.1和1.1 branch。
在View层、缓存、测试这三方面Douyu跟Play!要实现的东西和采用的套路都差不多，
比如Play!内置的模板引擎也是先把模板文本转化成Groovy代码然后再运行，
Douyu现在也是先转化成Java代码然后编译再运行(跟JSP一样)。
在开发阶段，这种先编译后运行的方式通常比Velocity或FreeMarker这种动态解析的方式要慢。
但是在部署阶段因为模板文本已经编译过了就比动态解析的方式要快一点。
Play!新加入了“Japid template engine ”，无非也是要提高view层模板的渲染速度，
具体实现技术我还没去研究。
Douyu现在也正尝试Velocity或FreeMarker动态解析的方式，
这在开发阶段很有用，如果熟悉JSP的话，只要JSP页面代码量稍大一点，
每次改JSP代码然后刷新浏览器一般需要1.5到2秒的响应时间，
1.5到2秒在开发阶段还是不能承受的，只有响应时间不超过1秒才不会感觉到有延迟。
缓存方面Douyu跟Play!现在也是直接整合一些流行的缓存框架
Douyu目前整合了Ehcache和OSCache，
Play!目前整合了Ehcache和Memcached
测试方面Play!现在要比Douyu强一些
Douyu只是整合了JUnit，可以进行单元测试和功能测试。
Play!除了能进行单元测试和功能测试外，还集成了selenium，
可以进行Selenium测试，这是Douyu目前未实现的。
老实说也曾想过看看能否把Douyu跟Play!整合一下，
但是除了上面说的三点相似外，内部的核心架构完全不同，
比如最简单的一个例子在Play!中每个控制器类要继承play.mvc.Controller，
而Douyu的控制器类不采用继承方式，
Play!的render是采用抛异常的方式来结束Action的执行的，
一个Action只能render一个模板，而且每个Action方法都是静态的，
而Douyu不抛异常，一个Action能render任意多的模板。
动态编译方面更加不同，Play!是从编译后的字节码下手，
而Douyu是先从Java源代码下手。
Play!目前在Modules开发方面比较活跃，
这些并不属于核心架构的东西，
在Play!上能运行的Modules，只要那个Module的开发者愿意，
其实很容易就能移植到Douyu。
Play!在1.1 branch中要加入对Scala语言的支持，
Douyu并不打算支持Scala语言，Scala语言学习门槛太高，
近期内要普及还是件难事，所以我想Douyu应该先把时间放在其他更实际的问题上。
另外，Play!还加入了Grizzly、Netty的支持，
我觉得这些都不是很大的亮点，中小规模的应用Tomcat足够了，
大点的应用Apache加Tomcat集群也能应付，
Grizzly、Netty这类http服务器处在一个不上不下的位置，
普及性也很低，所以Douyu目前也不打算支持Grizzly、Netty。
Play!在Model层还没看到什么大点的变化，跟Douyu的实现方案也很不同。
当然还有很多的不同，这里就不再细说了，
所以我想以后Douyu跟Play!应该不会走merb跟rails合并的路，
谁好谁坏就留给开发者去选择吧。
本文来源于"阿里中间件团队播客",原文发表时间" 2011-07-06 "
