Pros/Cons of Turbogears/Rails?

[Adam Jones]

FWIW, and while it's certainly not enough by itself to explain the
phenomenon, I think that Ruby's object model being much more
conventional than Python's may have some influence too on RoR's adoption
by the Java world.

I don't know enough about Ruby to comment, but how is its object model
"more conventional" than Python's? The only thing I can see is access
control for methods, which seems like a silly thing to base a language
decision on.

 

[Bruno Desthuilliers]

I don't know enough about Ruby to comment, but how is its object model
"more conventional" than Python's?

short answer (no time to elaborate...) and IMHO (of course):

Well, Ruby's object model is mostly based on Smalltalk, with private
attributes representing state, public methods representing behaviour,
and a "message passing" mechanism which will select the appropriate
method an call it.

In Python, an object is mostly a set of attributes, some of them
implementing the descriptor protocol, some of them being callables, and
one of them being the class object (which itself etc...). On top of
this, you have a lookup mechanism and a 'call' operator. And "message
passing" in fact boils down to retrieving an attribute (thru the lookup
mechanism, which can itself cause function/method calls, decorate the
attribute etc), and eventually apply the call operator to this attribute.

From the surface, the main visible differences are that Python has no
proper access restrictions and that one can retrieve a reference to a
method object via simple lookup, but the philosophy is really different
IMHO.

The only thing I can see is access
control for methods, which seems like a silly thing to base a language
decision on.

Java's philosophy is bondage and discipline. This has been sold over and
over to both suits and programmers. Making the move to a dynamically
typed language is already a big step for some of these peoples, so even
if all the difference they see is the absence of access control, I think
it can impact the choice. Now go tell them you can even change the class
of a given instance at runtime, and look at them running away screaming !-)

Not to say Ruby is less flexible or dynamic than Python (AFAICT, they
both have roughly equivalent potential in this domain), but Ruby can
surely look safer and way less confusing than Python to Java'ers.

 

[Jaroslaw Zabiello]

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

 

[Jorge Godoy]

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

 

[Adam Jones]

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.

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?

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.

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

 

[Christophe]

Jaroslaw Zabiello 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?

 

[fuzzylollipop]

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.

 

[Lawrence Oluyede]

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

it's YARV - http://www.atdot.net/yarv/

 

[fuzzylollipop]

But at least in most developers' perception ... <snip>

nobody is talking about perception

 

[Paul Boddie]

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

 

[Sybren Stuvel]

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

 

[Jaroslaw Zabiello]

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. 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/djan...read/thread/5149e1c60dc65bff/a177bb34cfde1ec7

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.

 

[Jaroslaw Zabiello]

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

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.

 

[Jorge Vargas]

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.

yes indeed as someone said earlier the support is already there and
all that needs to be done is a migration path.

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.

either that or all the hipy of RoR will go away.

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 for javascript you have mochikit which is really nice.

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.

I believe that is the most important part of TG, taking the best of
the best, and letting the framework adapt and morphe.

for example noone plan to move to SA, 0.1 came out a couple of people
took and look and like it, then 0.2 was "mature enough" so people
started thinking about the migration. after that some code was made
and now we have TG with SA, eventually it will be the default.
Same with templates, kid is really weak at generating non-xml, it has
a plain text serializer but the input must be xml so that's overkill.
So a new template frontend (chettah was born).

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

 

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

I believe that is the most important part of TG, taking the best of
the best, and letting the framework adapt and morphe.

for example noone plan to move to SA, 0.1 came out a couple of people
took and look and like it, then 0.2 was "mature enough" so people
started thinking about the migration. after that some code was made
and now we have TG with SA, eventually it will be the default.
Same with templates, kid is really weak at generating non-xml, it has
a plain text serializer but the input must be xml so that's overkill.
So a new template frontend (chettah was born).

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, no auto-generated code and the (incomplete)
documentation won't apply anymore (it assumes Kid templates ofcourse).
If you use SQLAlchemy instead of SQLObject, no identity framework, no
administrative tools (tg-admin sql, CatWalk etc) and no documentation.
If you use prototype instead of MochiKit... I have no idea what
happens and using another webserver than CherryPy isn't possible right
now, I guess?

In fact, if you decide to replace so many modules that TurboGears
depend on, what do you gain in using TurboGears at all? 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.
TurboGears more seem to be like emacs than Ubuntu - infinitely
customizable...

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.

 

[Cliff Wells]

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

--

 

[Cliff Wells]

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)

And ironically, the one with the *lowest* version number (web.py) is
used to power some fairly large (and ambitious) public projects:

https://www.youos.com/ ( see http://blog.youos.com/?p=49 )
http://reddit.com/

I'd like to claim that in OSS, version numbers mean little, but I still
recall Windows NT 1.0 (er, I mean 3.1), so I guess they don't mean much
anywhere. Version numbers are *picked* by project leads for varying
reasons, so comparing version numbers from different projects is pretty
pointless. Is Windows 2000 more stable than Linux 2.6? It ought to be
since it's 769 times more mature, right? Even if you called it Windows
NT 5.0, I'd have to wonder if it's even twice as stable (I'm being
intentionally generous here, so bear with me).

Personally I tend to look at what the users (especially former users)
say about a project and what's been or being done with that project. If
it seems promising, I try it. I can't think of any other reasonable way
of making that decision.

Regards,
Cliff

--

 

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

Someone ones said on the mailing list TG is the Ubuntu of web

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.

Maybe I stand corrected then. But the definition of the
AutoCompleteField widget is here:

http://trac.turbogears.org/turbogears/browser/trunk/turbogears/widgets/big_widgets.py#L88

I really don't understand how a completely different non-xml based
templating engine, with a completely different syntax, would be able
to grok that.

Completely false.

Yes, I'm sorry. Last time I used it, it didn't work. But now it seem
to have 100% compatibility.

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.

SQLAlchemy does, yes.

You get Prototype instead of MochiKit.

.... And the docs showing you how to integrate TurboGears with AJAXy
stuff ofcourse no longer applies.

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.

I disagree, most frameworks do not let you replace its components.
They are a "take it or leave it" kind of deal. I like that. The more
adaptable you try to make a piece of code, the more complex it
becomes. Obviously, it is easier to make code that supports one
templating engine than to make it that supports everyone.

You then most solve that additional complexity. Both in the code AND
in the documentation and you must ensure that the additional
complexity doesn't "leak" and make users life miserable.

I think Jorge claimed that TurboGears was very pluggable and I claimed
that it wasn't so. My point is that making the code pluggable is not
enough. All the stuff around it also need to support the pluggability,
not the least the docs.

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.

Not so. During 3 months a few months ago I've built a pretty big web
application using TurboGears. The easy of use of a framework isn't
writing "hello, world" applications, it is finding out how to do
things, doing them and how fast you can do it.

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

You must have been luckier than me then or maybe you didn't use much
advanced functionality? I converted a site from SVN head somewhere at
0.9 to 1.1 and there were lots of breakages. Anyway, I think we have
different definitions for "not quite ready." Lets say you have to
build and maintain a site or web application together with two other
developers who (like most web developers) doesn't know Python. Would
you then choose TurboGears?

 

[fuzzylollipop]

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?

 

[fuzzylollipop]

Sam Smoot wrote:
big rant snipped since Google Groups 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.