RoR的正确定位

最近由于工作原因，用appfuse、asp做了些东西，猛然间又怀念起四个月前学习的RoR，这才领悟到了RoR正确的定位。

自从RoR开始流行以来，一直就口水战不断。原因何在？其实就在于不知道国外大佬们作何感想，一上来就把RoR的矛头指向了php?name=Java" onclick="tagshow(event)" class="t_tag">Java。php?name=Java" onclick="tagshow(event)" class="t_tag">Java是大家热爱了很久的老大，MS炒了好几年的C#都动弹不了它，说明其在稳定性、规范化、应用范围上是具有统治力的。RoR本身是相当优秀的，可惜指错了矛头，反倒搞得四处树敌，难以推广。
笔者在几个月前接触RoR的时候，有个大体模糊的感觉，认为它应当是asp、php的劲敌，经过这几个月的实践，更加坚定了这种想法。

RoR为何会在J2EE程序员这个群体中火热起来，甚至让很多人倒戈？原因就在于大家吃够了J2EE的苦头。扔掉了分布式的EJB后，大家拥抱 Spring，而Spring+XX+XX+XX的模式也还是太复杂了。它们的复杂，就在面对的是真正的企业级开发，要考虑太多、太远，稳定性、高性能、扩展性、异构系统集成、遗留系统重用、多种客房端等等，全是一堆头让人头疼的事情。需求如此复杂，技术架构自然就复杂了。而国内大多数吃J2EE这口饭的，90%的情况下所面对的，都是Johnson所说的那90%的简单问题，说白了，就是用Web+DB就可以解决的问题。而这种场景下，RoR是当前最好的OOP解决方案。

RoR与ASP、PHP一样，都是为Web+DB量身订做的。在这个领域，动态脚本语言有绝对的优势。
JSP刚开始跟ASP、PHP在internet领域闹腾了好几年，结果还是干不过简单的后两者。时至今日，MS的“弃儿”ASP在国内的网站仍占统治地位、PHP则在欧美一路领跑。这缘于internate领域业务的快速变化性，那些编译来配置去来回折腾的技术实在浪费了程序员太多的时间精力。这些快速变更的东西，我们要的是用editplus修改之后，浏览器刷一下就可以看到结果。在这个领域，我们不需考虑那么多复杂的事情，我们要的是简单快速。所以即使如ASP.NET封装得那么好的tag，到头来还是不如HTML嵌代码好使。
所以在Internet领域，我们需要的还是动态脚本。

作为J2EE程序员，我们历经了多少探索和磨难，好不容易习惯了OOP，习惯了ORM，习惯了MVC。走尽万水千山路之后，当我们发觉做Web+ DB竟然不如当初甩到一边的ASP、PHP时，真是无比沮丧。那是否意味着我们要回到ASP、PHP或者纯JSP呢？答案自然是否定的，因为RoR出现了。
它可以让习惯了OOP、ORM、MVC的我们继续宝贵的设计思想，以不低于ASP、PHP的效率开发出结构合理、统一规范的Web+DB，这正是RoR的可贵之处。
唯一令人遗憾的是，我们又必须学习一门语言了，而且是小日本搞出来的Ruby。一门语言入门容易，精通则难。想当初弟兄们不知费了多少宝贵的日日夜夜才把Java练纯熟啊。不过想想那帮费力气练熟了VB、VC、ASP、WinForm的MS同行们吧，它们不是更惨，不但语法变了，连设计思想都变了，MS太不厚道！相对起来，Java时至今日仍保持良好的兼容性和技术延续性，就凭这一点，我们也应该继续支持Java。同时，为了在近两三年内（Groovy和Grails真正成熟起来）不让那90%的Web+DB继续痛苦，我们的确应该暂时用RoR来了。

近日终于想明白了这一点，在此与各位共享。
愿各位弟兄们早日用RoR搞出几个像样的CMS、Forum、Blog、Eshop、Email这类俗气但广泛应用的东西，并成功发展出一片价廉物美的RoR主机空间。这样的话，RoR一定可以走出现在这种叫好不叫座的局面。
至于原先真正的“企业级应用”，还是继续发扬静态编译语言的优势，好好站稳Java的脚，免得被MS趁乱了夺了去，那样的话，将是整个开源领域的灾难。

Javaeye看到的文章，写的还不错。转摘一下。不过我是MS阵营的，不太了解Java。呵呵。

说的好。。。茅塞顿开啊。。。

应该把ROR看成是对Java的一种补充。Java在页面功夫上面还是不够好，这时可以考虑采取ROR
但是Java在后台或复杂逻辑处理方面仍然是Number One。