Pros/Cons of Turbogears/Rails?

[Cliff Wells]

On Thu, 2006-08-31 at 23:31 +0200, BJörn Lindqvist wrote:
> On 8/31/06, Jorge Vargas <jorge.vargas at gmail.com> wrote:
> > On 31 Aug 2006 08:24:29 -0700, Adam Jones <ajones1 at gmail.com> wrote:
> >
> > 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.

>  no auto-generated code 

What auto-generated code?  The example templates that you get with 
quickstart?  Hardly a loss.

> and the (incomplete)
> documentation won't apply anymore (it assumes Kid templates ofcourse).

True.  However I've had little trouble translating from Kid to Stan (and
that's probably a longer jump than from Kid to Cheetah).

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

Completely false.

>  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.

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

You get Prototype instead of MochiKit.

> and using another webserver than CherryPy isn't possible right
> now, I guess?

Not that I'm aware of.  Nor do I think it would make much sense since
CherryPy is the heart of TurboGears.  I typically use CherryPy to serve
the dynamic content and a real webserver (Nginx) to serve static files.
I've never felt this was a handicap.

> In fact, if you decide to replace so many modules that TurboGears
> depend on, what do you gain in using TurboGears at all? 

If you got to the point where you were replacing more parts than you
were using, then you'd certainly want to find a different framework as
TurboGears is clearly not for you.  I fail to see your point.

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.

> It seems like
> the TurboGears developers have a lot of work to do, (and a lot of
> documentation to write) if they want to make their framework as easy
> to use as others (ie: Django) that takes a more holistic approach.

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.

> TurboGears more seem to be like emacs than Ubuntu - infinitely
> customizable...

Not quite enough IMO, but close enough.

> 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).

Regards,
Cliff

--