Pros/Cons of Turbogears/Rails?

[BJörn Lindqvist]

> > > Someone ones said on the mailing list TG is the Ubuntu of web
> > > frameworks, and I think I'll add and you can strip down the kernel and
> > > it wont break :)
> >
> > But that is not really true. If you use Cheetah instead of Kid, you
> > lose out: No widgets,
>
> Untrue.  Even though I don't use widgets much myself, I wanted to make
> sure they *could* be used with TurboStan, so I did a quick test with
> Kevin's autocomplete widget.  Worked fine.  I can't see why Cheetah
> would be any different.

Maybe I stand corrected then. But the definition of the
AutoCompleteField widget is here:

http://trac.turbogears.org/turbogears/browser/trunk/turbogears/widgets/big_widgets.py#L88

I really don't understand how a completely different non-xml based
templating engine, with a completely different syntax, would be able
to grok that.

> > If you use SQLAlchemy instead of SQLObject, no identity framework,
> Completely false.

Yes, I'm sorry. Last time I used it, it didn't work. But now it seem
to have 100% compatibility.

> >  no administrative tools (tg-admin sql,
>
> True.
>
> > CatWalk etc
>
> True.
>
> > ) and no documentation.
>
> Partially true.  The documentation exists but some of it is out-of-date
> and it was never very complete to begin with.  Of course, like many OSS
> projects, the mailing list is your best resource and SQLAlchemy itself
> has quite good documentation.

SQLAlchemy does, yes.

> > If you use prototype instead of MochiKit... I have no idea what
> > happens
>
> You get Prototype instead of MochiKit.

... And the docs showing you how to integrate TurboGears with AJAXy
stuff ofcourse no longer applies.

> Personally I've chosen to go a different route on a couple things and
> leave the rest intact.  I expect most people are the same.  With most
> frameworks, there's typically one or two things most people don't like
> and it's nice to be able to replace those things without a lot of fuss.
> I don't see how that's a liability.

I disagree, most frameworks do not let you replace its components.
They are a "take it or leave it" kind of deal. I like that. The more
adaptable you try to make a piece of code, the more complex it
becomes. Obviously, it is easier to make code that supports one
templating engine than to make it that supports everyone.

You then most solve that additional complexity. Both in the code AND
in the documentation and you must ensure that the additional
complexity doesn't "leak" and make users life miserable.

I think Jorge claimed that TurboGears was very pluggable and I claimed
that it wasn't so. My point is that making the code pluggable is not
enough. All the stuff around it also need to support the pluggability,
not the least the docs.

> That's odd, because I've actually used both and found TurboGears far
> easier to get started with (no mucking about with Apache and mod_python
> for one thing, no need to setup explicit url regexes just to get "hello,
> world" on a page).
>
> Judging from your above comments it sounds to me like you're mostly
> speculating about TurboGears.

Not so. During 3 months a few months ago I've built a pretty big web
application using TurboGears. The easy of use of a framework isn't
writing "hello, world" applications, it is finding out how to do
things, doing them and how fast you can do it.

> > In the future both Rails and TurboGears will probably be great. But
> > since someone mentioned Rails moving to YARV, and TurboGears moving to
> > SQLAlchemy and Markup, it seems to me that they are both in a state of
> > flux and not quite ready yet.
>
> TurboGears is certainly in a state of flux although from an outside
> (i.e. API) standpoint it's not nearly as bad as you might think from the
> changes that have gone on under the hood.  There's been only a few
> breaking changes up til now (I converted a site I'd built on 0.8 to the
> latest SVN last night and most of the issues I encountered were with my
> own changes to TurboStan).

You must have been luckier than me then or maybe you didn't use much
advanced functionality? I converted a site from SVN head somewhere at
0.9 to 1.1 and there were lots of breakages. Anyway, I think we have
different definitions for "not quite ready." Lets say you have to
build and maintain a site or web application together with two other
developers who (like most web developers) doesn't know Python. Would
you then choose TurboGears?


-- 
mvh Björn