Pros/Cons of Turbogears/Rails?

[Sam Smoot]

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

 

[Jorge Vargas]

But that is not really true. If you use Cheetah instead of Kid, you
lose out: No widgets,

that is not correct all widgets have a template attribute which yes
it's kid but replacing it is as simple as changing it's value to a
Cheetah template.

no auto-generated code and the (incomplete)

that is not correct, the only part I can think about is not having
default templates, which are just a demostration/sample app. other
then master.kid I don't think any of the others are used, and the
concept of master.kid doesn't exists in cheetah I think,

if you are really concern about this please create pasteScript with
the chettah default templates and I'll make sure it gets into the
trunk as the sqlalchemy autogenerated code did.

documentation won't apply anymore (it assumes Kid templates ofcourse).

actually no, you get a dict of values into your template, now if your
talking about teaching how to use the "other templating engines" then
I suggest you read their docs, because at that point TG changes
nothing (except 2 or 3 variables that are populated by TG into the
templates)

If you use SQLAlchemy instead of SQLObject, no identity framework,

not true it was commited together with the support for SA 0.2

no administrative tools (tg-admin sql, CatWalk etc)

ok first tg-admin sql is just a wrapper around sqlobject-admin so the
lack of that tool is actually a lack in SA.

about Catwalk and model designer they where created to work with SO,
in fact they are so couple that probably a new tool will be written.

and no documentation.

yes we had many troubles with that we have went from one system to
another but we settle with rest and are going to use moinmoin for a
while until docudo is ready. all the docs are being integrated there
and as we have said there wont be 1.0 until we have lots of docs.

If you use prototype instead of MochiKit... I have no idea what
happens

MochiKit is the most decouple part of the project you can include
almost anything as long as the javascript doesn't collide with
eachother (for example there was a problem with prototype and MochiKit
used together a couple of months ago)

and using another webserver than CherryPy isn't possible right

now, I guess?

there have been some initiatives (experiments mostly about it, and
docs about it on trac) and they work although changing CP is the most
challenging part and I don't think anyone involve with the project
wants that, although you are welcome to try, if X becomes a
replacement for CP we'll migrate to it. all that needs to be done is
write the method/paths logic and make X handle dictionaries as return
values.

you may as well make your own smash up of tools if you want to replace
all components
a couple of emails below you said you just wanted to say that there is
no infix replace and I never said it was like that I said if you want
to change it go ahead the framework wont stop you like happens with
RoR or Django.

at last I dont' agree with you that making the framework support more
things makes it more complex, TG design is genious in that part for
example all template plugins (which are small package define a small
set of variables (actually a class, or abstract class or interface,
whatever you want to call it.)
http://www.turbogears.org/docs/plugins/template.html so after that the
rest of the code doesn't cares about which render is actually going to
be use.

and that's why the same TG app can render with more then one
templating engine at the time. in fact you can have the same method
render with 2 different engines if you may need it.

 

[Paul Boddie]

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

 

[paron]

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

I've found that familiarity with Windows in the Ruby/Rails community is
less than in the Python/TG community. Ruby/Rails seems to have been
mainly *nix until fairly recently.

Sometimes the Windows version of a module or tutorial will lag
significantly. (ldap comes to mind.) Sometimes Windows-oriented
questions get pretty short shrift along the lines of: "Perish the
thought!" or "Why would you?" instead of serious treatment.

It's not a deal-breaker and neither community is perfect in this
respect. I now work mostly with Ruby/Rails, but I did Python/CherryPy
for quite a while, and that's my impression.

Ron