Pros/Cons of Turbogears/Rails?

Ruby
21

On Aug 31, 2006, at 9:30 AM, Jaroslaw Z. wrote:

[email protected] wrote:

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

The name of the virtual machine that runs Ruby 1.9 and up, is YARV
(not YARM).

I’m not sure what makes you say it’s “10x faster,” but that sounds a
little high to me. My recent playing with the VM showed a little
over a 2x increase in speed, for the code I was running. This was a
very unscientific test for sure, but it may be a little closer to
the average speed increase people are likely to see.

James Edward G. II

22

Well, TG has a few templating systems… MarkUp, Kid, Cheetah, ZPT, and
others. You can choose the one that best fits your needs / brain. You can
even have multiple template systems used depending on what was requested for
the same controller…

Just to complete the comparison, Rails can also use a variety of
templating systems besides the standard three mentioned.

Liquid
MasterView
Markaby
Amrita2

and many more each day. Many are listed in the plugins page of rails
wiki
http://wiki.rubyonrails.org/rails/pages/Plugins

Blessings,

Jeff B.
MasterView project founder
http://masterview.org/

23

“Jaroslaw Z.” [email protected] writes:

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

TG supports SQL Alchemy as well. With SQL Alchemy I believe you’ll have
a
better experience than with Rails’ ORM.

With regards to Migrations, SQL Object does support something like that,
but
you have to explicitly code it and then you can run sqlobject-admin
upgrade
(or the equivalente tg-admin sql upgrade, since it is a wrapper…).

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

Well, TG has a few templating systems… MarkUp, Kid, Cheetah, ZPT, and
others. You can choose the one that best fits your needs / brain. You
can
even have multiple template systems used depending on what was requested
for
the same controller…

Which one is better isn’t of my concern. I’ve already tested then and
decided
what I want to use. The best thing is try them and see what works. You
don’t
have to choose only one – but you have to use one per project to make
it less
messy :wink:

24

Jaroslaw Z. wrote:

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

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

25

Paul Boddie 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 1.0 releases do mean something, it means the DEVELOPER of the
package things it is just now ready for general consumption. That means
something regardless of what the number is.
Matter of fact, all major version releaese mean that, it is generally
understood thing. x.0 means this is now ready for non-beta general use.

26

I believe he was referring to YARV (yet another ruby virtual machine)
which is planned to accompany the Ruby 2.0 release. YARV is in active
development now but early indications are positive with regards to
perfomance improvements.

http://www.atdot.net/yarv/

27

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.

But at least in most developers’ perception …

nobody is talking about perception

28

Jaroslaw Z. a écrit :

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.

Google doesn’t find YARM and so, YARM does not exist. Care to provide an
URL or something?

29

fuzzylollipop wrote:

But 1.0 releases do mean something, it means the DEVELOPER of the
package things it is just now ready for general consumption. That means
something regardless of what the number is.

In various open source circles, the mere usage of 1.0 may indicate some
kind of stability, but not necessarily maturity, or at least the desire
of the developers to persuade users that the code is ready for them to
use. Consequently, there are numerous stable packages at 0.x because
the developers don’t think they’re near finished (ie. have produced a
mature system), numerous unstable packages at 1.x because the
developers want their 15 minutes of fame (GNOME 1.0 was apparently a
good example of this), and various packages at 3.x or 4.x that would
suggest a legacy of decades when they’ve probably only been in
existence for eighteen months at the most.

Matter of fact, all major version releaese mean that, it is generally
understood thing. x.0 means this is now ready for non-beta general use.

Agreed. Still, let’s take some examples from the python.org Wiki’s
WebFrameworks page to illustrate what I mean:

SkunkWeb (3.4.0), Zope (2.9.4 and 3.2.1), Plone (2.5), Karrigell (2.3),
CherryPy (2.2.1), Spyce (2.1), QP (1.8), Cymbeline (1.3.1), Django
(0.95), Webware (0.9.1), Pylons (0.9.1), TurboGears (0.8.9), PyLucid
(v0.7.0RC4), Paste (0.4.1), web.py (.138)

Now, just over half of the above have presumably passed some stability
threshold, and we could possibly even estimate the age of many of the
frameworks based on how high their version numbers are. However, note
that whilst Zope 3.2.1 is now presumably considered stable, something
like Zope 3.0 couldn’t really be considered as mature as Zope 2.8 or
2.9 purely because of the nature of the code: a rewrite of the
architecture which, even if considered stable, cannot be considered
mature in comparison to its established predecessors with all the
accumulated expertise and experience associated with them.

Such comparisons of unequal things having the same name have also
affected projects like CherryPy, where 1.x and 2.x were apparently
quite different, and whilst CherryPy is currently at 2.2.1 and used by
other projects, it is described as unstable elsewhere in this thread -
contradicting various reports of successful large scale deployments, I
might add. Meanwhile, the original framework upstart, Webware, hasn’t
even reached 1.0, yet it has been around for longer than many of the
others, whilst Pylons bears an identical version number.

Part of the difficulty in maintaining an overview such as the
WebFrameworks page arises from attempting to measure maturity,
stability, vitality and quality - something which some repositories
like Freshmeat attempt to tackle using various methods of measurement.
And as I was editing the version numbers recently, I did consider the
issue of whether they provided a reasonable impression of project
stability and/or maturity, but I rather feel that more considered
evaluations are the only way to get that kind of information.

Paul

30

On 2006-08-31, James Edward G. II [email protected] wrote:

I’m not sure what makes you say it’s “10x faster,” but that sounds a
little high to me. My recent playing with the VM showed a little
over a 2x increase in speed, for the code I was running.

I ran the YARV benchmarks and several of them showed a 10x or more
speedup, though for many others it was 2-3x. I guess anyone who
really needs to know how much faster YARV will run their code should
just profile it and see rather than try to figure it out in advance.

Jeremy H.

31

On Thu, 31 Aug 2006 11:42:47 -0300, Jorge Godoy wrote:

TG supports SQL Alchemy as well. With SQL Alchemy I believe you’ll have a
better experience than with Rails’ ORM.

I would not be so sure. I have tried to work with SQL Alchemy (using
Pylons) and I have been disappointed. :frowning: It’s syntax for selects is ugly
and not intuitive. Django ORM looks much better. SQLAlchemy has to be
added
to Django as alternative ORM but without breaking current, clean API:
http://groups.google.com/group/django-developers/browse_thread/thread/5149e1c60dc65bff/a177bb34cfde1ec7

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

Well, TG has a few templating systems… MarkUp, Kid, Cheetah, ZPT, and
others. You can choose the one that best fits your needs / brain.

This is another topic. Rails can also use another third-party template
system (like Liquid which was inspired by Django). For me using many,
different template systems for the same task make no sense. Rails uses
three templates, but for different tasks. Its RJS is perfect for AJAX.
Really cool, simple, and almost no javascript is required. Just clean
Ruby
for everything.

32

[“Followup-To:” header set to comp.lang.python.]
fuzzylollipop enlightened us with:

Matter of fact, all major version releaese mean that, it is
generally understood thing. x.0 means this is now ready for non-beta
general use.

True, although it’s usually better to let the general public weed out
the last bugs, and wait for the x.1 release.

Sybren

33

On 31 Aug 2006 08:24:29 -0700, Adam J. wrote:

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.

What is the advantage of Data Mapper? I cannot find…

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.

We have created two quite big sites in CheerryPy in past and we have
many
issues with its bad implementation. Sessions were useless, forks were
removed from early code without any warning. Maybe now it is better, but
I
have lost any confidence in CherryPy quality.

34

Paul Boddie wrote:

But 1.0 releases do mean something, it means the DEVELOPER of the
package things it is just now ready for general consumption. That means
something regardless of what the number is.

In various open source circles, the mere usage of 1.0 may indicate some
kind of stability, but not necessarily maturity, or at least the desire
of the developers to persuade users that the code is ready for them to
use.

nope in GENERAL usage, 1.x means that the developer is designating a
version that is feature complete and stable. I never ever mentioned
comparing version numbers between differing packages.

MY POINT was the developers of Rails JUST RECENTLY decided that it was
ready for general consumption compared to all the PREVIOUS Rails
releases.

And NONE of these frameworks has been used to power anything along the
scale of what I work with on a daily basis.

And speaking from experience, autogenerated “Active Object Pattern”
frameworks dont’ scale. And Rails is no exception. It didn’t work 10
years ago when all the ORM vendors were selling ridiculously price
“point and click” database application builders, what makes people
think it will now?

35

Sam S. wrote:
big rant snipped since Google G. has what I responding to:

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.

I got my facts straight, Ruby is not tested in production environments.
And I am speaking from a BIG internet site scale. Apache is mature,
there is a definition of mature tested in the wild in production, and
you qualified your opinion by excluding edge cases, the internet is
NOTHING BUT EDGE CASES. Just look at the SMTP and HTTP RFC’s they are
nothing but edge cases.

And read the entire thread, I am the one that specifically stated that
the original poster was confused on what he was asking about. Let me
make it really clear. Neither Ruby NOR Rails is “mature” by ANY
REASONABLE definition.

36

El Jueves, 31 de Agosto de 2006 15:41, James Edward G. II
escribió:>

I’m not sure what makes you say it’s “10x faster,” but that sounds a
little high to me. My recent playing with the VM showed a little
over a 2x increase in speed, for the code I was running. This was a
very unscientific test for sure, but it may be a little closer to
the average speed increase people are likely to see.

Hi all,

I ran the YARV’s benchmarks and got an 5x increase in speed[1]. Anyway,
those
tests are far away from real production code.

See ya!

[1]
http://devnull.blogs.banot.net/articles/2006/07/24/algunos-números-de-yarv

–
o) Imobach González Sosa
//\ email: imobachgs at banot dot net
V/_ jid: osoh at jabberes dot org
url: banot.net
blog: http://devnull.blogs.banot.net

37

fuzzylollipop wrote:

I got my facts straight, Ruby is not tested in production environments.

That’s odd… it’s running bank websites, credit-card processing, high
traffic sites like ODEO and Penny-Arcade. Seems pretty “production” to
me.

And I am speaking from a BIG internet site scale.

Yes yes, I’m sure that never fails to impress the ladies.

The internet is NOTHING BUT EDGE CASES.

I beg to differ. Step outside of the Top 1000 and the web is largely
marketing, portfolio, reporting, and boring administration sites.

Neither Ruby NOR Rails is “mature” by ANY REASONABLE definition.

Companies and individuals are using it to competitive advantage every
day. Obviously you don’t have much (if any) actual experience with Ruby
OR Rails.

By the way, we’ve yet to hear your opinion on Python and TurboGears…

38

fuzzylollipop wrote:

Paul Boddie wrote:

In various open source circles, the mere usage of 1.0 may indicate some
kind of stability, but not necessarily maturity, or at least the desire
of the developers to persuade users that the code is ready for them to
use.

nope in GENERAL usage, 1.x means that the developer is designating a
version that is feature complete and stable.

Please note the distinction between “stable” and “mature” - these are
not quite the same thing. Django, Rails and Turbogears may be at or
approaching 1.0, meaning that their developers regard them as being
stable (ie. no showstopping bugs), but that’s not the same as being
mature. Moreover, the developers of all those frameworks will most
likely not stop at 1.0 but start working towards 2.0, possibly creating
quite a different product.

I never ever mentioned comparing version numbers between differing packages.

No, but there are important psychological factors at work when choosing
and interpreting version numbers: do you go for ABC 0.9, XYZ 1.2 or PQR
7.1? What about the newly announced XYZ 2.0 - is that a safer choice
than its 1.x predecessor?

MY POINT was the developers of Rails JUST RECENTLY decided that it was
ready for general consumption compared to all the PREVIOUS Rails
releases.

That judgement call may be true, but they haven’t exactly been reticent
about getting people to download and use it before now.

And NONE of these frameworks has been used to power anything along the
scale of what I work with on a daily basis.

I can believe that. Do you have any success stories to share?

And speaking from experience, autogenerated “Active Object Pattern”
frameworks dont’ scale. And Rails is no exception. It didn’t work 10
years ago when all the ORM vendors were selling ridiculously price
“point and click” database application builders, what makes people
think it will now?

My feeling was that any object-relational mapper that (supposedly in
this case) dictates how you’re supposed to design your database
automatically rules itself out over a vast territory of existing and
new applications. Having seen the EJB army march themselves into a
swamp, my feeling is that most such mappers seem to be an increasingly
complicated excuse not to learn SQL.

Paul

39

By the way, we’ve yet to hear your opinion on Python and TurboGears…

Don’t bother… it’s probably not mature: how many 13-year-olds do you
know that are? :wink: Maybe we should just stick to assembly, because
that’s seriously the only thing that is fast and mature.

Oh wait… hell no.

Anyways, I want to take this opportunity to refocus the discussion on
relative maturity: I believe the OP was asking about which of the
TWO options were more mature, Ruby/Rails or Python/TurboGears.

fuzzylollipop: you might want to get the fuzz off your lollipop and
realize that if the internet is nothing but edge cases, that means
that the internet has no edge cases. That’s how edge cases work:
they are the unusual, highly selective cases, on the edge of
everything else. And, yes, I’d dare say that Ruby would be a great
option for most of the non-edge cases, and even a good deal of the
edge cases too!

So stick that fuzz on your lollipop and suck it :wink:

M.T.

40

<…>

MY POINT was the developers of Rails JUST RECENTLY decided that it was
ready for general consumption compared to all the PREVIOUS Rails
releases.
<…>

Another point is that Rails were EXTRACTED from WORKING application,
namely
Basecamp :wink:

Regards,
Rimantas