Pros/Cons of Turbogears/Rails?

[Adam Jones]

Jaroslaw Zabiello wrote:
> kenneth.m.mcdonald at sbcglobal.net wrote:
>
> > + SqlObject allows working with the DB tables without
> > using SQL itself.
>
> Rails has ActiveRecord ORM, which IMO has nicer and simpler
> syntax than SQLObject. Rails has migrations, TB - not (Migrations is
> versioning system for evolving database schema)

I don't really see TG sticking with SQLObject. In moving to SQLAlchemy
it would pick up not only a migration system but also a much more
flexible abstraction system due to the use of a Data Mapper pattern
instead of the Active Record pattern. There already is an
implementation of Active Record on top of that, so that benefit stays
as well.

>
> > + Likely to be faster because as far as I'm aware, Python
> > is significantly faster.
>
> Python is maybe faster, but with YARM (which is not stable yet) Ruby
> will be about 10x faster. YARM is full virtual machine like Java.

I tried to check out information on this, but the only docs I found
that looked like what I wanted were written in japanese. Do you have
any links discussing the status of this project? Does it make any
breaking changes to the Ruby implementation that will have to be fixed?
Has the RoR project already agreed to port to this when it is stable?

>
> > + Easy access to other libraries (such as the Python
> > Imaging Library) that Ruby, being a relatively newer
> > language, doesn't have equivalents to.
>
> Ruby is not so young you think. It became more popular
> when Rails has appeared.

Although that is true there are not as many libraries available for
Ruby as there are for Python. This will probably change as the language
gains popularity, but for right now it pays to look into library
support before considering anything else about the language.

>
> > + I find the templating system somewhat cleaner; code in
> > py: xml namespace allows pure .html templates, instead
> > of equivalent of .rhtml files.
>
> But rhtml is much more flexible because it can generate *any content*,
> not only xml. But Rails has THREE template systems: rhtml (main), rxml
> (for rss and xml generation) and rjs (for javascript and AJAX).

Kid can be used to generate xhtml, rss, xml, pretty much anything that
is xml-based. I have even seen it used to generate xul applications for
firefox. The only thing on your list that it doesn't do is javascript.
Personally I would rather learn one templating language that is able to
treat all of my xml as xml no matter what use it is put to.

>
> And last but not least, TG is based on poor, unstable and buggy
> CherryPy server. We had huge problems with CherryPy. I think that
> Django or Pylons are much better frameworks. IMO TG is no competition
> for Rails at all. The only real competition is Django or Pylons.

I have never had much in the way of problems with CherryPy. From what I
have heard the project has made a lot of improvements recently, so it
may have changed since you last took a look at it.

Actually that point right there is where I think TG is a lot more
competitive that you believe. When a new version of any of the
foundation projects comes out, or a better project to fill that
particular need, TG can absorb it in the next version. The TurboGears
developers can spend most of their time working on additional code that
makes the project more useful instead of bug fixes and minor feature
upgrades to the core components. This philosophy is proven to work for
most other open source projects, and I have yet to hear a good argument
why it would not be successful for a web framework.

-Adam