Pros/Cons of Turbogears/Rails?

gregarican greg.kujawa at gmail.com
Mon Aug 28 09:13:14 EDT 2006


As I read in another post on this thread, do some initial scoping out
of either framework and pick the one that seems to suit your way of
thinking/coding the best. If you scan over some sample code on the
projects' websites you should get a basic idea of what they will be
like.

Although a bit more obscure than the two frameworks you are
considering, have you checked out Seaside (http://seaside.st)? It's a
Smalltalk framework that interests me personally. I've had the
opportunity to check it out briefly, but haven't had a chance to
actually mock up an app using it. If you check it out as well as a neat
AJAX library that can overlay it called Scriptaculous
(http://script.aculo.us) you can do some pretty slick things concisely.
I doubt that something like this will immediately skyrocket to the top
of the commercial developer's hit list, but it is something that I
would play around with since it will only expand my knowledge base. And
I can have fun while doing it :-)

Out of what I've seen working with Rails and checking out TurboGears I
chose Rails since it fit in with my way of thinking the best. Everyone
has their own taste so I wouldn't take any one person's (or one
group's) opinion. Read up on them a bit and see which one looks the
most interesting to you.

kenneth.m.mcdonald at sbcglobal.net wrote:
> First, I don't intend this to be a flame war, please. Python
> and Ruby are the only two languages I'd willingly work in
> (at least amongst common languages), and TurboGears and
> Rails seem roughly equivalent.
>
> I'm much more knowledgable about Python, but that's a minor
> issue--I've been intending to learn more Ruby anyway.
>
> Here are the pros and cons that I'm aware of and consider
> important:
>
> Turbogears:
> + SqlObject allows working with the DB tables without
> using SQL itself.
> + Likely to be faster because as far as I'm aware, Python
> is significantly faster.
> + Easy access to other libraries (such as the Python
> Imaging Library) that Ruby, being a relatively newer
> language, doesn't have equivalents to.
> + Built-in default SQLite makes it easier to set up?
> (as far as I can tell, Ruby requires MySql by default--don't
> know how easy this is to change.)
> + I find the templating system somewhat cleaner; code in
> py: xml namespace allows pure .html templates, instead
> of equivalent of .rhtml files.
>
> Ruby:
> + More mature system. More stable? More features?
> + Much better documented. This is a biggie.
> + Built-in Rubydoc system would make documenting the
> system easier. (IMHO, developers almost always
> underestimate the need for good documentation that
> is written along withe the system.) Is there a
> Python doc system that has received Guido's blessing
> yet? D'oxygen would seem an obvious choice.
> + Better coordination with Javascript helper code?
>
> I was initially leaning towards Rails due to maturity,
> but the most recent version of TurboGears seem to have
> fixed a lot of the "ad hoc" feeling I got from previous
> versions. But I'm still very much up in the air.
>
> Thanks,
> Ken
>
> P.S. If I wanted to provide an image by streaming the
> file data directly over the connection, rather than by
> referring to an image file, how would I do that? I'd
> like to build code that would allow images to be assembled
> into a single-file photo album (zip or bsddb file), and
> so can't refer to them as individual image files.




More information about the Python-list mailing list