• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: WO vs. Ruby on Rails
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WO vs. Ruby on Rails


  • Subject: Re: WO vs. Ruby on Rails
  • From: Mike Schrag <email@hidden>
  • Date: Fri, 14 Mar 2008 11:49:21 -0400

It depends on what you are trying to do.

ROR makes perfect sense for some projects. WO makes perfect sense for others. And sometimes it's a coin toss as to which one to use.

Personally I am most productive with WO, and it leaves me with the fewest concerns about scalability and whether I'm going to hit limitations when managing my object graph.
I totally agree here ... Rails (and Ruby in particular) can do some very cool things that make me envious. The mixin capabilities, alone, make me wish Java was more capable. For instance, you'll find that mixins in Ruby make it very easy for people to package and provide very slick extensions modules where Java makes you work at it. In fact, ERAttachment and ERTaggable are directly modeled after attachment_fu and acts_as_taggable in Rails specifically because the originals are so easy to wire up -- I really want to explore ways to create modular WO extensions that are minimally invasive. It's interesting that WO actually comes from roots that are much more dynamic than Java is, and EOF shows these abilities still, which actually makes some of the tricks possible in EOF where they would be much harder in "traditional Java". In the end, I think ERAttachment and ERTaggable require about as little modification to your code as you can really get and still maintain type-safety, but I had to work at it whereas it's very natural in Ruby.

So I can completely appreciate the aspects of Ruby that make people love it, and Rails is certainly a very capable framework. I think the lack of a good component architecture is a great weakness in the framework, and incidentally WO kills in that department. One of our guys does Rails and WO and prefers WO, in particular because of components (and Ajax.framework, which really takes advantage of the stateful benefits of WO). I do think WO's "getting started" story really sucks right now, and I hope we can make that better. Getting up-and-running with Rails is very easy ... The equivalent process in WO is pretty annoying. But things like Jeremy's WOlips installer will hopefully make that much better, and I think we're continually moving the tools side forward towards greater ease-of-use. What I find to be sort of interesting is that Rails is considered fairly easy for people to get into, yet it's actually substantially less visual than even the WO tools in their current state, so it's not just a matter of having pretty tools -- there's definitely more to it. There's the entire package of the process of building an app, and that process is great in the middle for WO, and sort of crappy at both ends (getting up to development, and getting out to deployment).

I also think that without a framework like Wonder, the stock WO frameworks don't do a very good job of insulating developers from complexity. Things like Wonder's autolocking and automatic inverse relationship management remove huge conceptual complexity from the process of development. ActiveRecord, for instance, has no concept of an "editing context". There are obviously huge pros and cons to this, but it does result in a far simpler persistence framework. I think many of the features of Wonder bring WO much closer to that ideal while still allowing the richness and the benefits of the GOOD parts of an editing context. ActiveRecord doesn't have a snapshot cache like WO. Again, huge pros and cons, but cache freshness management in EOF is really complicated, especially as you start to scale your app. WO does a fantastic job at the first 90 and makes you work hard at the last 10. I think the first Rails 90 is less than WO's in many respects, but the curve is much more level all the way across. So WO does a lot for you for the common tasks, but some of the design choices they made in the frameworks to do this can make your life difficult when things get demanding.

This is what I hope Pierre and his team (along with WOLips) focus on in future major versions of WO. How can barriers be removed on the front-end so new people can get into WO more easily while at the same time removing hurdles on the back-end so that you don't have to work as hard to build a very scalable site (... without compromising what is cool about WO). All I can say is that we always look around, and we keep coming back to WO.

ms

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: WO vs. Ruby on Rails
      • From: Miguel Arroz <email@hidden>
    • Re: WO vs. Ruby on Rails
      • From: Guido Neitzer <email@hidden>
References: 
 >WO vs. Ruby on Rails (From: "Andrew R. Kinnie" <email@hidden>)
 >Re: WO vs. Ruby on Rails (From: David LeBer <email@hidden>)

  • Prev by Date: Re: WO vs Ruby on Rails
  • Next by Date: inline binding problem
  • Previous by thread: Re: WO vs. Ruby on Rails
  • Next by thread: Re: WO vs. Ruby on Rails
  • Index(es):
    • Date
    • Thread