Pros/Cons of Turbogears/Rails?

Ruby
1

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.

2

On Aug 27, 2006, at 3:10 PM, [email protected] 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 also not trying to attack Turbogears, as I know nothing about
it. I will respond to some of those points with a Rails slant
though, just for your information.

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.

Rails has migrations which allow you to manipulate the database in
Ruby. You can also use Rails’s console script to interactively play
with your database.

  • Easy access to other libraries (such as the Python
    Imaging Library) that Ruby, being a relatively newer
    language, doesn’t have equivalents to.

Ruby does have an imaging library called RMagick.

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

You have to change one line of a config file to use an SQLite
database with your Rails application. Its very easy.

  • I find the templating system somewhat cleaner; code in
    py: xml namespace allows pure .html templates, instead
    of equivalent of .rhtml files.

Just FYI, rhtml files are just one way to build output with Rails.
You might want to look at using Builder, which is a pure Ruby interface.

Hope that helps.

James Edward G. II

3

Kenneth – a few comments below…

My knowledge of Rails is slight, so others may
contradict me. If so, they are likely right.

[email protected] wrote:

Turbogears:

  • SqlObject allows working with the DB tables without
    using SQL itself.

Rails can do this.

  • Likely to be faster because as far as I’m aware, Python
    is significantly faster.

Perhaps. If you do measurements, share your findings with us.

  • Easy access to other libraries (such as the Python
    Imaging Library) that Ruby, being a relatively newer
    language, doesn’t have equivalents to.

I don’t know what that is, but we do have RMagick, which
binds to GraphicsMagick or ImageMagick.

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

Ruby can do SQLite. I think Rails makes it pretty easy to
change databases.

  • I find the templating system somewhat cleaner; code in
    py: xml namespace allows pure .html templates, instead
    of equivalent of .rhtml files.

Matter of taste. I don’t have an opinion really.

Ruby:

  • More mature system. More stable? More features?

Perhaps. I know nothing about TurboGears.

  • 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?

Did you mean RDoc?

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.

Hmm… I did this once. Had something to do with the content-type.
It’s usually text/html or text/plain, but if you change it to
the proper string and set the content-length appropriately also,
I think it Just Works.

You might try the old trick of telnetting into a web server on
port 80 and pretending to be a browser. (If you can remember
exactly how to do this; I don’t). Use a URL that points directly
to a small image and watch the stuff you get back.

Cheers,
Hal

4

[email protected] wrote:

Looks like you mixing comparisons.

Ruby:

  • More mature system. More stable? More features?

uh, no, Python predates Ruby by a good bit
Rails might be “older” than Turbogears but it still JUST went 1.0
officially.
It can’t be called "mature’ by any defintition.

  • Much better documented. This is a biggie.

Rails has no documentation, period. The authors acknowledge this
openly.

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

Pydoc IS standard. This has been around for a long time.

  • Better coordination with Javascript helper code?

Again, is this a Python vs Ruby or Turbogears vs Rails post, you seem
highly confused on the distinctions between language vs framework.

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.

again, Ruby can’t be considered ‘mature’ by any definition.

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.

???

5

Looks like you mixing comparisons.

Ruby:

  • More mature system. More stable? More features?

uh, no, Python predates Ruby by a good bit
Rails might be “older” than Turbogears but it still JUST went 1.0
officially.
It can’t be called "mature’ by any defintition.

Python itself predates Ruby only three years.

  • Much better documented. This is a biggie.

Rails has no documentation, period. The authors acknowledge this
openly.

Rails has plenty of documentation, it’s just that the quality of the
API isn’t as good as everyone wishes. That’s actively being worked on,
with funds raised by the Caboose folks, and plenty of community
participation. However, there are plenty of materials on Rails itself,
including Agile Web D. with Rails from the Pragmatic
Programmers which is itself an awesome resource.

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.

again, Ruby can’t be considered ‘mature’ by any definition.

As far as speed is concerned, I know Ruby isn’t the fastest out there,
but is not slow. That is, you can tweak things to make Rails run
really fast. There is plenty out there documenting how to set up
Mongrel with Apache2.2 and mod_proxy_loader or Pound or whatever the
hell you want. Basically: you can make Rails very fast.

And as far as SQLObject, the ActiveRecord library is very good, and
produces the SQL for you. It works with a number of RDBMSes, including
SQLite, MySQL, and, my favorite, PostgreSQL. ActiveRecord is also
connected to Migrations which allows you to handle revisions in the
schema, and actually generating/modifying your databases without SQL
at all. Also, ActiveRecord has the distinct quality of not requiring
you to specify what columns the table has: it finds this out for you.

As far as templating goes, I’ve found that the concept of Rails’
templating system was a bit jarring, but in practice it’s actually
quite beautiful and easily understood. I think it’s so easy a design
team wouldn’t have any problems picking it up (if they can function
logically).

For me, the only reason to use the Python-based TurboGears would be a
specific Python library. And, given that, I’d probably go with Django.

Cheers,

M.T.

6

[email protected] wrote:

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.

Just output the encoded / compressed byte stream the image manipulation
library of choice can surely provide to the HTTP connection? Setting the
MIME type of the response accordingly. You might want to look up hacks
on how to do efficient byte-pushing for this, standard Ruby IO might or
might not be optimal.

David V.

7

On 8/27/06, fuzzylollipop [email protected] wrote:

[email protected] wrote:

Looks like you mixing comparisons.

Ruby:

  • More mature system. More stable? More features?

uh, no, Python predates Ruby by a good bit

Where ‘good’ means ‘shifted left once?’ (2 years – 93 vs 95)

Rails has no documentation, period. The authors acknowledge this

openly.

http://api.rubyonrails.org/

… wha?

I was initially leaning towards Rails due to maturity …
again, Ruby can’t be considered ‘mature’ by any definition.

Looks like you['re] mixing comparisons.

8

Rails has no documentation, period. The authors acknowledge this
openly.

Huh? You might not like the documentation, but it’s actually quite
substantial, especially for so new a framework. Don’t be telling
people stuff like this that is blatantly untrue.

9

fuzzylollipop wrote:

uh, no, Python predates Ruby by a good bit
Rails might be “older” than Turbogears but it still JUST went 1.0
officially.
It can’t be called "mature’ by any defintition.

But at least in most developers’ perception, it is (not necessarily in
the absolute sense, but perhaps relative to Django or Turbogears).
Mind, it doesn’t even need to be true, we’re talking of perception
here. Also, I’m not talking about only Python and/or Ruby developers
here, I’m talking about developers in general, a huge bunch of which
comes from Java/.NET background.

I know many of them and a lot of them do know Rails. When you say
Turbogears or Django, however, they go, “what?”.

Sadly, there are more Java guys who know about Ruby than Python,
despite the fact that Python predates Ruby by quite a few years…
(this must be that Bruce Tate dude’s fault! )

10

On 8/27/06, James Edward G. II [email protected] wrote:

On Aug 27, 2006, at 3:10 PM, [email protected] wrote:

  • I find the templating system somewhat cleaner; code in
    py: xml namespace allows pure .html templates, instead
    of equivalent of .rhtml files.

Just FYI, rhtml files are just one way to build output with Rails.
You might want to look at using Builder, which is a pure Ruby interface.

Take a look at MasterView:

http://masterview.org/

To quote its own web site:

MasterView is a ruby/rails optimized HTML/XHTML friendly template
engine.
It is designed to use the full power and productivity of rails
including layouts,
partials, and rails html helpers while still being editable/styleable
in a
WYSIWYG HTML editor.

Curt

11

I think the original poster is getting Rails and Ruby confused a fair
amount. To be clear, Ruby is a language like Python. Rails is a
framework for writing web applications like Django.

I have no experience with TurboGears so the best I can do is try to
help explain some of your ideas about Rails.

Turbogears:

  • SqlObject allows working with the DB tables without
    using SQL itself.

Although migrations have already been mentioned, I think you’re
referring to something like ActiveRecord in Rails with is an object
mapping of table rows. Yes, Rails has it. I don’t really write SQL
anymore.

  • Likely to be faster because as far as I’m aware, Python
    is significantly faster.

I’m not sure about the benchmarks between Python and Ruby but Rails is
plenty fast as long as it is deployed appropriately. I’d expect the
same from TurboGears and expect them to be capable of similar results.

  • Easy access to other libraries (such as the Python
    Imaging Library) that Ruby, being a relatively newer
    language, doesn’t have equivalents to.

Python isn’t that much older than Ruby. Check in on the libraries you
need before deciding based on this. It hasn’t been a problem for me
thusfar.

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

Ruby certainly doesn’t require MySQL. Rails configures for MySQL by
default but it’s trivial to change. If you know your’e going to use
sqlite instead you can even do ‘rails my_project -d sqlite’ and it’ll
do it for you.

  • I find the templating system somewhat cleaner; code in
    py: xml namespace allows pure .html templates, instead
    of equivalent of .rhtml files.

I’m not sure what you mean. If you don’t like ERb there are several
alternatives.

I’d say try both out and work with what feels more natural. This will
also give you a chance to see what you’re missing in each.

12

[email protected] wrote:

First, I don’t intend this to be a flame war, please.

Then avoid crossposting to both c.l.ruby and c.l.python !-)
(BTW, fu2 c.l.python).

Turbogears:

  • SqlObject allows working with the DB tables without
    using SQL itself.

I personnaly don’t like SqlObject. SqlAlchemy looks like a much better
solution IMHO. And FWIW, Ruby has it’s own ORM too.

(snip)

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.

Then take a few days to play with both Rails and TG and go with the one
that better fits your brain.

FWIW, you may also want to check Pylons (another Python Web-MVC
framework).

My 2 cents

13

Mind, it doesn’t even need to be true, we’re talking of perception
here. Also, I’m not talking about only Python and/or Ruby developers
here, I’m talking about developers in general, a huge bunch of which
comes from Java/.NET background.

Sadly, there are more Java guys who know about Ruby than Python,
despite the fact that Python predates Ruby by quite a few years…
(this must be that Bruce Tate dude’s fault! )

Well, sorry, we were responding to Ken who acknowledges both Ruby and
Python (even claiming his proficiency in Python) as the only options
he’s considering for the job. Which means, implicitly, that we can
narrow our scope to just these two platforms/frameworks.

:smiley:

M.T.

14

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 :slight_smile:

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.

15

Ray wrote:

fuzzylollipop wrote:

uh, no, Python predates Ruby by a good bit
Rails might be “older” than Turbogears but it still JUST went 1.0
officially.
It can’t be called "mature’ by any defintition.

Version numbers are a fairly useless general metric of project
maturity, taken in isolation.

But at least in most developers’ perception, it is (not necessarily in
the absolute sense, but perhaps relative to Django or Turbogears).
Mind, it doesn’t even need to be true, we’re talking of perception
here.

So actual maturity isn’t important when using a technology: it’s
“perceived maturity” that counts, right? Any continuation down that
particular path of reasoning surely leads you to the point where you
claim, in concert with the developers, that increasing levels of
inconvenience caused by gratuitous changes or broken documentation is
not caused by bugs or general immaturity but by “features”. I guess
this is the definition of “opinionated software” that some people are
so excited about.

[…]

Sadly, there are more Java guys who know about Ruby than Python,
despite the fact that Python predates Ruby by quite a few years…
(this must be that Bruce Tate dude’s fault! )

If you only listen to Bruce Tate et al, I imagine you could have the
above impression, but I’d be interested to see hard facts to back up
those assertions.

Paul

16

Sam S. wrote:

http://rubydoc.org (For basic Ruby help)

It’s http://ruby-doc.org

You need that hyphen.

–
James B.

“Blanket statements are over-rated”

17

In my understanding, which relies completely on the judgements of
co-workers regarding the rails side of the debate, TurboGears is more
flexible. Tasks which fall inside the scope of Rails’ “opinion” are
probably easier there, but anything outside of what Rails was built to
do is harder than equivalent deviations from TurboGears. Obviously this
amounts to little more than hearsay, but nonetheless I think it is an
important element to look into.

I can say that each of them has their own genius decisions, and neither
is so lacking in documentation or community support to preclude
choosing either framework based on how well it suits your project.

18

fuzzylollipop wrote:

uh, no, Python predates Ruby by a good bit
Rails might be “older” than Turbogears but it still JUST went 1.0
officially.

Wow that’s a lot of FUD, especially since you’re beating up on Rails
for it’s docs and maturity, when I doubt (but couldn’t prove)
turbogears comes close.

Lets be specific:

12/13/05: http://dev.rubyonrails.org/changeset/3303

It can’t be called "mature’ by any defintition.

It’s easy to deploy a site without running into bugs as long as you’re
not dealing with any edge-cases. As far as OSS solutions go, that
pretty well fits my definition of “mature”. So there’s one.

Rails has no documentation, period. The authors acknowledge this
openly.

Why you would just talk out of your ass like this escapes me.

http://api.rubyonrails.org (Look at any of the :Base classes for
overviews)
http://rubydoc.org (For basic Ruby help)
http://rails.techno-weenie.net/ (Help with the lesser known areas of
RoR, and tips & tricks)
BigBold - Informasi Tentang Bisnis dan Marketing (Snippets other people have
found useful)
Peak Obsession (Lots of “Getting
Started” type how-tos)
http://caboo.se (A blog aggregation of some of the committer’s )

Then again, you could just google for “rails documentation” (here’s a
link:
http://www.google.com/search?client=safari&rls=en&q=rails+documentation&ie=UTF-8&oe=UTF-8
)

And the top link will take you to a page on the Wiki that describes all
of this. Until you want to start writing plugins and such, this
documentation pretty much fits the bill. Could there be more? Yes. Is
it perfect? Obviously not. Is finding documentation going to be a
problem for anyone willing to spend a few minutes with Google or on IRC
asking questions if you’re genuinely trying? I seriously doubt it.

again, Ruby can’t be considered ‘mature’ by any definition.

It seems like you’re the one confusing things now. Ruby is obviously a
pretty mature language. There are definite feature holes (encoding
aware Strings, native Threads), but the community, documentation,
tutorials (by far the best of any language I’ve learned), are all
pretty mature.

Is Rails mature? Compared to JSP? Probably not… compared to
TurboGears? (The entire point of this topic, which you conveniently
side-step by managing to not mention it once) Easily.

So if you decide to reply, might I suggest spending a few minutes with
Google to get your facts straight next time? Oh, and keeping an eye on
the actual topic might be a good idea too.

19

[email protected] 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)

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

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

  • Built-in default SQLite makes it easier to set up?

What? :slight_smile: YAML is much easier.

(as far as I can tell, Ruby requires MySql by default–don’t
know how easy this is to change.)

Change in config/database.yml driver: mysql to any you want,
like db2, postgres, sqlserver, sqlite, firebird, oracle etc. You can
change
default settings as well. See: rails --help

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

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.

20

Paul Boddie wrote:

But at least in most developers’ perception, it is (not necessarily in
the absolute sense, but perhaps relative to Django or Turbogears).
Mind, it doesn’t even need to be true, we’re talking of perception
here.

So actual maturity isn’t important when using a technology: it’s
“perceived maturity” that counts, right?

Well depends on “counts” in what sense. Counts as in the managers up
there perceive something as mature, despite proofs of the contrary,
certainly “counts”, because then we’ll end up having to work with a
probably immature technology (nothing about RoR here, I’m talking in
general). Yet with more people using it, its actual maturity will
inevitably rise as well, maybe eventually to a level near that of its
perceived maturity.

“Counts” as in to us developers who are actually spending our lives
doing this? Perhaps yes too. If you’re well-versed in something that is
widely perceived to be mature, you may find it easier to win bread for
your family, even if you have a painful time using it.

Sadly, there are more Java guys who know about Ruby than Python,
despite the fact that Python predates Ruby by quite a few years…
(this must be that Bruce Tate dude’s fault! )

If you only listen to Bruce Tate et al, I imagine you could have the
above impression, but I’d be interested to see hard facts to back up
those assertions.

Yeah, see, the thing is that Python is not lacking luminaries endorsing
it either, e.g.: Eric Raymond and Bruce Eckel. But for some reason this
“Python is good” meme is not that viral. I wonder why…

And, since when do hard facts matter anyway? I’ve met a number of
people who’ve told me they’d program in Eiffel if they could. And hey,
perhaps in its day Eiffel was the best OO language out there.
Certainly it looked cleaner than C++! :slight_smile: