冷静的比较一下Douyu和Play Framework

真可惜。只是一份很好的对比而已，虽然有点过而已，但站在我自己的角度看是一篇很好文章。我自身用的是Java的SSH框架开发。Play还没接触过，但就斗鱼来说，刚看到那时着实让我兴奋。
希望看到实质成功。。支持

那个帖子的隐藏，有15票的权重是我投的。这里我要首先说句抱歉，因为我没注意到我的权重那么大。当时我已经见到一些精华，我不希望一下子又看到一个吵架帖，于是做了一个隐藏的投票。

不过在这里，我也需要提出我的一些建议，希望Douyu的作者认真思考：

1. 在你的Douyu没有发布一个可以用于生产环境的版本之前，我认为你不适宜去做比较。事实上，我在你的帖子中，也没有看到你提到Play!这个框架的许多优点，反而在任何地方都在提出对方框架的不足，这似乎也不太公平。

2. 你提出的许多问题是哲学问题，并不是一个谁对谁错，谁优谁劣的问题。所以，我认为你不适宜直接说某些地方是你的优点，而某些地方是人家的缺点。比如，在我看来，Play!的routes是这个框架的亮点，却被你认为是没有必要的东西。你说我和你到底谁是对的，谁是错的？我想还是需要更多的由使用者来决定。

3. 你的框架是近年来在Javaeye这个平台上宣传的质量最高的开源框架。不过我的想法呢，还是说你能够尽快给我们一个正式版，并提供一些可靠的测试数据，告诉我们，我们有足够的理由可以连Tomcat都抛弃了，而使用你的框架来进行企业开发。如果有这些数据的充实，我想我会非常乐意来用你的框架试试。

我已经向管理员申请恢复你之前的帖子，再次表示抱歉。

我想你是站在应用层次的角度看问题的，而我是从底层的实现原理上看问题的，
如果是应用层次的比较我自认Play比现在的Douyu要高几个等级，
但是我的文章是从技术层面来比较的，我认为我可以去比较，因为我专门花了一星期研究Play的源代码实现，如果你也研究过Play的源代码，就像Laynepeng这位老兄一样(他为Play贡献过代码)，
那么你应该知道我在"6.控制器层：有必要RESTFul吗？有必要多加个routes配置文件吗? "这一节讲的是什么？讲的就是Play在
控制器层的源代码实现原理(包括动态编译)，我也是只在这一节明显提出Douyu比Play要好。


在"10.视图"这一节我就明显指出了Play比Douyu做得更好:


其他的小节我基本上没说哪个好哪个坏，
我只是给出了一些我设想的方案，就是那些绿色字体的内容。


我也很感谢JavaEye，16号那天JavaEye管理员说要专访我，但是我谢绝了，因为我认为还不是时候，
我一向是个低调的人，我之所以发"Douyu vs Play!"这个帖除了回复这个帖之外，
先前听说Play这个框架跟Douyu差不多，然后就去看了，接着又一时口快说要写个比较帖，
说出的话不好反悔，只好花一天时间写了篇文章。

不管怎么样我都会好好开发Douyu，
不为别的，这是我的兴趣，没人督促我，我也会不断的做下去。



我并不在意论坛等级或积分什么的，花了一整天认认真真的找资料写篇文章并不容易。
我不会记仇，只要说明问题了什么事都好说。

现在最大的问题就在于，或许在我看来，routes是一个亮点，而你认为没有必要。我想你也做过很多开发，应该也会承认，这应该属于一个哲学问题，不存在谁对谁错的问题，也没有谁优谁劣的问题。

举例来说，我以前为Struts2编写lighturl插件的时候，我自认为实现了非常优雅的CoC，有了这个，大家基本不需要配置文件了。同时，我还增加了支持url模板的Annotation，我认为是一个亮点，因为这已经和Rails中的routes没什么差别了。结果呢？我认为最应该成为亮点的地方，却被许多人提出诟病。因为我没有统一的配置，于是为他们的调试带来了极大的不方便，他们无法通过一个url来快速定位Action了，因为Annotation是不限制的。这个时候我才想起Rails中一个统一的routes文件进行配置的方便之处。

所以在你没有拿出一个我可以用的“成品”之前，我不愿意来和你讨论好与坏，因为在我看来，没有实践的东西，就没有发言权，没有在生产环境中打磨的东西，也没什么价值。或许它有很大的潜在价值，但是这些价值都是潜在的，也有可能成为垃圾的可能性。

所以我还是非常期待你的东西，哪天你把潜在二字去掉，我会从头到尾，认认真真使用你的框架来搭建一个demo系统。然后说说我的感觉。了解我的朋友也知道，如果我开始研究一个框架，一定会把它研究得很透。所以我想我到那个时候再来评论。

我不明白关于routes有什么好争论的，这东西基本上谁都说不服谁的问题，downpour说得很对。如果不喜欢用route，嫌配置麻烦，喜好契约，完全可以在route里面就这样写一句：

# Catch all
*       /{controller}/{action}                  {controller}.{action}

就可以满足需求了。。。

作为框架开发者，虽然要有自己的思想，但是也需要顾及不同用户的需要，功能放在那里，按需使用即可。

ZHH2009很强，douyu的技术的确非常创新，但是有些问题还是需要考虑的。不知道ZHH2009对douyu的愿景是什么？作为一个技术敷发器的研究项目，还是真的想把推广出去，为大家提供一个好用的框架？
如果是前者，ZHH2009现在做得很不错，可以把一些对javac的研究成果，或者一些架构的新思想和大家share一下，但是如果真的想把douyu推广出去，有些问题是要想的。

一个框架其实应该是简单的，轻量级的，在提供了一些很cool的功能的前提下，尽量使问题简化，把javac包含过来会不会太复杂了？如果以后douyu推广出去后，将会运行在异构的环境下，会有各种奇怪的问题，怎样控制这些bug，使douyu稳定是一个考验。框架应该是尽量简单从而稳定的，尽量不要因为框架的bug而造成用户的系统出现问题。我眼中，框架的最大作用是使不同的人，不同水平的人写出来的代码基本一个样，使系统维护，或者项目成员的更替不会受到影响——这个才是框架最重要的作用。然后就是尽量把业务不相关的问题交给稳定的框架完成，我们只做最简单的事，减少错误的出现。当然这个框架能提供一些便捷给我的团队开发，使开发更高效，那是更好。而到底底层是什么，我根本不会去关心。
举个例子，我为什么会接触Play？很简单，我们公司刚好要做一个小应用，非常小的应用，一开始我想ROR解决的；但是这里面需要用到我们原来的一个lib，是java的。但是这个小应用太小，我不想给它配一套SSH，不值得，结果就发现了Play，很不错，就使用上了。。。
然后刚好GAE推出java版本，我发现Play支持GAE，所以就用它简单作了个blog。。。中间出了点问题，就帮他们给解决了。。。

Play很简单，而且下下来的包就包括源代码，他的技术并不先进，但是的确可以做一些很cool的事情，比较适合小的web应用，Bort本身就是个web designer，做些小网站的，所以他的框架的目标用户群也是这种小应用。。。我记得jdon的banq也对play写过一篇文章，说Play很不错，但是没有DDD，没有domain层，我当时就无语了。。。

第二点，我觉得现在douyu在运营上面来看，是不正确的。一个新生事物要发展最好要先在大树底下慢慢发展。MS当年也是先在IBM底下低三下四地活了好多年；等他做大了，才可以不管标准，捆绑IE，绑架web标准。我个人觉得douyu现在还是先要尽量做到能够运行在主流web container底下。。。（如果我没记错，应该是不可以的吧？）Play推广过程中，能够打成war包就是一个大卖点，因为很少人会真正用那个内置的container的。牛如GWT，那个内置的container也不过是给你测试用用。。。另外Play!的大发展，很大程度在于它第一时间支持GAE，如果你去他的group看，一半以上的问题都是关于在GAE上运行问题的，你想想这给它带去了多少用户？为了满足这个需要，硬是在1.0版本底下加上Siena，用来支持big table。。。
Play的胶水，其实就是为了满足更多人的不同需要，支持Spring, openid, NoSql, GAE。。。因为他知道满足越多人的需要，就会给它带来越多用户。。。所以她胶水，他的确很胶水，他的代码很少，按你说法就10000多行而已。。。

第三，关于外部包的问题。这是一个buy or make的经济学问题。不讨论了。。。

第四，对于一个设计，很难讨论到底哪种好，经常开会的时候，拍桌子，大吼也常有的事情。很难讨论的，继续是那个驰名的banq，他骂Spring够多了吧？Spring算是很经典的框架了，但是从不同角度来看，还是能扯出一堆又一堆的问题，坏味。。。但是又如何，Spring赢得了用户，改变了大家的开发模式，同时也为自己获取大量金钱。。。这些东西没多少意思的。。。

我真的很希望douyu能继续下去，毕竟国内很缺少好的开源项目，再说我们的家乡还比较近，哈哈~~

今天刚发现play!一个非常严重的问题，修改了模版文件居然不能立即生效，必须重启play!后才行~~~

我说Play在应用层次方面比Douyu要高几个等级，
那是因为Play开发得早，功能比Douyu要多，比Douyu完善，所以Play能运用于生产环境，
但是并不代表在某一功能的技术实现策略上Play也比Douyu高，
比如在控制器层的动态编译和routes的问题上我都给了具体代码并详细对比了两者的技术实现策略。

你不能总是拿Douyu不是“成品”去判断技术实现策略的好坏，
也不能用你"为Struts2编写lighturl插件"的经验去判断，
因为Struts2或者lighturl插件跟Play和Douyu完全是两种不同的东西，没有可比性。

你说的实践问题，有没有在生产环境中打磨的问题是应用层次的问题，
这跟判断一种技术实现策略的优劣并不存在直接的关系，
举个最简单的例子，Http协议够成熟了吧，实践得够多了吧，在生产环境中打磨得够久了吧，
但是万维网之父Tim Berners-Lee现在向网民道歉了，说:


我举这个例子就是想说明实现一种功能可以采用各种技术实现策略，
只要在技术实现策略之间稍微斟酌一下就可以省掉没必要的东西，省得以后内疚。

如果你认为routes好，就应该像我那样给出示例代码，分析源代码实现原理，
告诉我Play这样做好在哪里，而不是以是不是“成品”的问题来搪塞，
这样会让我觉得你在有意回避问题的实质，
这是因为你对Douyu和Play的了解还不够，还只是停留在表面的认知。

to Laynepeng

你说的东西挺有意思的，有些问题我会好好考虑，
就现在而言我对Douyu的愿景更像是个技术敷发器的研究项目，我本人也更喜欢搞研究。

等我把Douyu的基础框架完善后，把文档写全了，
我会把Douyu开源，然后建个专门的讨论区，让对Douyu感兴趣的人参与进来，
Douyu跟Play的设计目标和定位是非常不同的，
Douyu既可以纵向扩展直达编译器内部的每个细节，
也可以像Play一样当成一个胶水平台进行横向扩展。

因为在跟rich讨论过后，我最近还在尝试让Douyu与Tomcat这类传统的web容器兼容，
实现方案也很简单的，发布包不会依赖Javac编译器，
Javac编译器只在开发阶段是必须的，但是在生成环境中是不需要的。

一个产品出来，需要经过好几个阶段： 构思-》设计-》初步实现-》雏形--》初级版本--》投入试用--》反馈-》改进--》更高级版本--》推广


而所谓革命性的产品，那就更需要一个厚积薄发的过程。

相比最近闹得轰轰烈烈的两个产品： play Framework  还有 douyu。 

才开始到 “雏形” ，就开始大张旗鼓的宣传 。 既然是雏形，那就肯定会有很多问题，你现在一拿出来，自然有吹捧之风，但在资深人员看来不免有这个感慨： “浮躁啊。。。。” 


所以，我建议这两个框架的作者，你们继续努力完善，不断在实际项目中得到经验来完善，然后慢慢形成一个自己的圈子。 这样一个推广过程我认为是很好的。

firebody， 既然你是资深人员，那么你应该明白我在JavaEye做了什么，
更多的是分享自己的一些想法，而不是浮躁。

只不过这两天碰到帖子被隐藏，情绪受了点影响，才在JavaEye上多泡了点时间，
这不是在吹捧，也不是在大张旗鼓的宣传，因为16号我就已经谢绝JavaEye管理员的专访了，我认为不是时候，
我不是在浮躁，不是在吹捧，也不是在宣传什么。