Wednesday, May 10, 2006

Ruby, rails, and more thoughts on Zope3

the more time i spend with ruby on rails, the more convinced i am that, on some level, Zope3 has entirely forgotten that it's a web development platform.

i'm not badmouthing zope3. it has some of the smartest people working on it that i've ever seen in action. stephan, gary, phillip, jim (o' course), martjin, jeff shell, et. al. are brilliant bastards, certainly. no doubts about it.

but it's like zope3 has forgotten that it's a web development framework first and foremost. i say that in a way that is not to cast aspersions on zope3, but more to cast them on myself. i spent a year or more chugging away with zope3. and i learned a LOT about programming. but i learned really very little about real web development.

let me clarify.

i've spent more time messing with javascript, ajax, and css in three weeks with RoR than I ever TOUCHED with zope3. and that's my fault, certainly. but i didn't really have to, with zope3. i could spend my days whiling away on the controller level, once in a while messing with my interfaces and base classes at the model level, letting the view level just kinda sputter. not because i really wanted to, but there just wasn't that much effort or interest in view-level logic and interaction in the zope3 documentation and community.

that may be because they assume a level of mastery over that level for anyone who's coming to zope3 as a solution. but i'll be honest and say that isn't the case for me. i'm not a neophyte certainly, but i'm not an expert. i can write javascript when i have to, and i can throw a "this-was-designed-by-a-developer-wasn't-it" level bit of css together, but that's about it. ajax was a thing for other people, on other platforms... it wasn't that i didn't want to use it, but there was no standard way of integrating it, no out-of-the-box solutions for data access across ajax.

so why does it matter?

speed of implementation. rails says, even explicitly in the agile web dev book, that the visible web page is what it's all about. get it coded get it out, let your users see it. if you can't point and click at it, if you can't edit and create data quickly, sensibly, and immediately, something is wrong.

what rails gives you is the ability to do things fast, and it's smart enough behind the scenes to make sure that you have the flexibility to do them WELL without slowing you down.

zope3, you can and will do it well, very likely. but you're not going to do it fast. and anything special you want for your display, you're goin to do on your own.

one thing i love about rails is that data type validation is done at the model level. in zope3, up until VERY recently with the ability to put in validators in your interfaces, all of the type validation was done at the controller level. as far as i'm concerned, data validation is a model-level thing.

eh. i'm getting off on a tangent. but the point that i'm trying to make is still the same. zope3 has concerned itself so much with the soundness of its architecture, with the flexibility of it's model and controllers, that actually producing web pages has slipped to the background.

there are a lot of things i miss with zope3. interfaces and adapters are some of the most powerful programming constructs i've ever seen, and i daily miss them in rails. but as a tradeoff for javascript generation for standard ajax calls to data, the tightly integrated prototype and script.aculo.us libraries, the simple conventions, the EXCELLENT documentation...

i'll take RoR. and i'll hope for the day that zope3 finds its way here.

0 Comments:

Post a Comment

<< Home