Re: WO vs. Ruby on Rails
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