aspose file tools*
The moose likes Spring and the fly likes why did rails catch on widely but not roo? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "why did rails catch on widely but not roo?" Watch "why did rails catch on widely but not roo?" New topic
Author

why did rails catch on widely but not roo?

Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30972
    
159

I asked a Ken a variant of this in person, but I liked his answer. So asking here to get him to share it with others.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Bhushan Jawle
Ranch Hand

Joined: Nov 22, 2001
Posts: 249
Having used Ruby on Rails and Spring Roo both, I think view customization in Rails is relatively straight forward compared to that in Roo, at least for a person who might be looking at both frameworks for the first time.
I am interested to hear though other thoughts on it as well
Ken Rimple
author
Ranch Hand

Joined: Jul 20, 2010
Posts: 63

Jeanne Boyarsky wrote:I asked a Ken a variant of this in person, but I liked his answer. So asking here to get him to share it with others.


I hope I represent it the same way this time ;) Off the cuff and into the ether...

Let's see. I think that Ruby on Rails came at just the right time and served a need for the community of PHP, Ruby and Python developers out there who hate compiled languages. Java EE people who hadn't used Spring, or even who had, may have gotten involved in smaller scale projects that Rails fit perfectly - get it out quickly, with fast changes, and a small development team. Java people who jumped on the bandwagon thought that it was awesome - let's face it, if you spent your whole life typing 'mvn package jetty:run' and someone comes over and shows you how you can just iterate while the server is running, you'd probably be convinced.

On the Java front, we had an answer to dynamic languages, and a pretty good one too, Groovy. Groovy begat Grails, and Grails was a runaway hit in our circles - a viable alternative with mostly the same goals - yes, you did have to restart (until Grails 2) to get domain changes going, yes, it's girded on top of Spring/Spring MVC/Hibernate, and so it is a DSL against known frameworks rather than a ground-up implementation, but the thing works. And works well for most applications.

Around the same time Grails was building steam, the Java team at SpringSource, led by Ben Alex, created Roo. It attempted to accelerate application development, but by using what they already had - Spring, JPA, Spring MVC, Tiles, etc... It was a valid decision. It kept the development IN Spring, and it kept it IN Java. Enterprises would then have the choice of a dynamic language platform written around a DSL -vs- a tool that helped keep the C.R.A.P (Completely Redundant And Painful, like that?) from taking over a project, and extensible by add-ons.

The reasons I think Roo hasn't caught on as much are:

  • It is written in Java. Zzzzz for many developers, but it girds the infrastructure of many, many things
  • It isn't cool like a DSL - rather, it relies on the coolness of the existing frameworks (hint, Spring Data JPA for example)
  • It came late to the party - Groovy/Grails was a great follow-up to Rails, but being third isn't always the way to get to the top right away
  • It is perceived as being a replacement / substitute for Grails, which I would not yet agree with
  • In my mind, it's still early, since it has evolved to a much better tool in 1.2.x, and is getting to become viable for multi-maven projects, but I think it needed to mature before it was able to really be taken seriously in the places that would use it
  • The add-on community doesn't yet exist to any big depth, at least in terms of public add-ons. And the add-on API has broken between revisions a bit, causing agita for add-on developers. I think that will start to change going forward.


  • Jeanne, I hope I answered the question well enough... I believe Roo 1.3 will be a strong release, in that we will hopefully have not only a more solid add-on API, but the ability to customize and tailor the application platform and the benefit of stability fixes etc... The team is committed to the tool, are very interested in what the community wants, will accept patches for fixes, etc...

    Also, look at some of the things you can use Roo for, such as writing your own productivity add-ons, dealing with JavaBean, JSON, and other features for just regular old beans, and the like, and you needn't use all of it to get benefit from its productivity. In a way, it's kind of a blank slate that you can apply your abstractions to - think of the Maven archetypes for example, and then think of live archetype commands that can alter an existing program, generate AspectJ ITDs, even restructure things, and you get the idea.

    Best,

    Ken

    Ken Rimple
    ken.rimple@gmail.com
    Co-author, Manning Spring Roo in Action
    I teach for Chariot Solutions (Spring, Maven, Hibernate, other courses). Schedule here
    Mark Spritzler
    ranger
    Sheriff

    Joined: Feb 05, 2001
    Posts: 17259
        
        6

    To add why I use ROO, but also wouldn't use ROO.

    I am writing an application that I started in ROO. It was great just for the directory and maven creation, but I only took it up to web layer and stopped at the web layer. I had it generate the web layer components, but then wiped it out. Because an issue many have with ROO on the web tier, is that it is too coupled to DOJO. Since JQuery is a more popular, and in many opinions a better javascript library, people want to use JQuery in their ROO apps. But since ROO is coupled with Tiles and DOJO, it makes it impossible to use JQuery without ripping all the ROO Web code out.

    Mark


    Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
    How to Ask Questions the Smart Way FAQ
    Ken Rimple
    author
    Ranch Hand

    Joined: Jul 20, 2010
    Posts: 63

    Agreed Mark. I see the web mvc teir as optional and am hoping someone comes up with another one that is more flexible, lightweight and less opinionated. No JS framework plus adding add-ons for that, like in Grails, makes more sense to me for most applications. I also don't really need bi-directional field sync for most apps, if I have to live with JSPX files as a consequence.

    I had shared that feedback with the Roo team but more discussion should be had around the web tier... It may be a JiRA suggestion to file to request a cutting apart of the mvc add-on into a few more pluggable items - view strategy, template strategy, client js framework, mapping strategy (entities or dtos), etc.
    Jeanne Boyarsky
    author & internet detective
    Marshal

    Joined: May 26, 2003
    Posts: 30972
        
    159

    Ken,
    Yes good answer. It is more thought out than the in person one, but the spirit is the same. And I can't complain a "surprise - lets ask Ken questions at lunch" answer wasn't planned out!
    Ken Rimple
    author
    Ranch Hand

    Joined: Jul 20, 2010
    Posts: 63

    Jeanne Boyarsky wrote:Ken,
    Yes good answer. It is more thought out than the in person one, but the spirit is the same. And I can't complain a "surprise - lets ask Ken questions at lunch" answer wasn't planned out!


    Must be all those years playing jazz drums. I actually enjoy that kind of thing...
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: why did rails catch on widely but not roo?