Why would I choose RoR over Turbogears

I’m trying to get some answers as to why I (my company actually) would
go with RoR over TurboGears. The developer staff is fluent in both Ruby
and Python so that is not an issue. Rails is well into its release
cycle whereas Turbogears won’t be at 1.0 until later this week. They
both do essentially the same thing and they both have cool features
unique to themselves (Turbogears has Catwalk, RoR has Migrations, etc.).
RoR seems to have some attitude (please, I don’t mean this in a
negative way, but Railers are generally more outspoken that RoR is the
best - period - and if you don’t like it… Web.py in the Python world
seems to also have this attitude). I don’t really don’t mind the
attitude and I think it can be very beneficial, but I think it needs to
be backed up and that is what I’m trying to figure out. What is RoR
going to gain over Turbogears and vice-versa.

Right now after going through tutorials in both I’m pretty sure each one
is capable, but obviously RoR has momentum - and lots of it.

Anyone else in the same spot?

Andy T.

On May 30, 2006, at 12:04 PM, Andy T. wrote:

I don’t really don’t mind the attitude and I think it can be very
beneficial, but I think it needs to be backed up and that is what
I’m trying to figure out. What is RoR going to gain over Turbogears
and vice-versa.

Right now after going through tutorials in both I’m pretty sure each
one is capable, but obviously RoR has momentum - and lots of it.

Look over some code from a similar project in both.

  1. Can you find Turbogears code to look at?
  2. Which framework will Python programmers be using in a few years?
    a) CherryPy
    b> Django
    c) TurboGears
    d) Other?
  3. Most importantly, which code do you want to be looking at in
    3 years?

From my perspective, technology is so pervasive at this point that it’s
fair to say that they’re all pretty much equal in terms of capability.
It’s now up to style and preference, not horsepower.

Additionally, if you’re building something that will need to be
maintained in the future, where will you be likely to find people
to do the maintenance? You said yourself that RoR has huge momentum.


– Tom M.

On May 30, 2006, at 2:04 PM, Andy T. wrote:

best - period - and if you don’t like it… Web.py in the Python
world
seems to also have this attitude). I don’t really don’t mind the
attitude and I think it can be very beneficial, but I think it
needs to
be backed up and that is what I’m trying to figure out. What is RoR
going to gain over Turbogears and vice-versa.

Right now after going through tutorials in both I’m pretty sure
each one
is capable, but obviously RoR has momentum - and lots of it.

I know nothing about python or any web frameworks available for it.
But I still have an opinion.

I think you nailed in it in the last sentence quoted there. Rails has
momentum.

Go with the momentum.

Indeed rails has momentum…

But… it’s unclear in what direction that momentum is heading. I like
rails, it’s perfectly suited for my pet-projects. But… I have the
feeling that i might be forced to rewrite the entire crap because rails
has changed… Sure, there’ll still be rails in two years from now, but
will it be the same rails? I doubt it… (Take, for example, the new
Active record classes for 1.1… It broke quite a few plugins. And the
last minute inclusion of the webservice framework in 1.1 doesn’t
convince me I should rely on it… As for ruby the entire VM discussion
that’ll lead to a VM (and rails having stated they’ll only support the
most recent ruby) will probably break older ruby code, and surely ruin C
or C++ based plugins)
This is especial a “huge” problem because the openness of ruby and the
need to open the rails framework to take maximum advantage of the DRY
principle.

I’m not sure where turbogears stands and whether they do have a
multi-anual development plan. One framework I am recently leaning
towards is Django, a huge effort is being put into making the framework
futureproof (the whole magic-removal branch) and the fact that it powers
and advanced, commercial, CMS will most likely ensure better backwards
compatibility.

The best and only true answer can be found through your own team, if you
have people fluent in both Python and Ruby then you have more than what
you
need to figure this out. Tell them they have to make a decision about
how
to build the project, that they must pick one framework or the other and
that you are expecting the decision to be made by them in the next 72
hours.

…and then get out of their way.

Your team has the answer,

Tim C.
[email protected]
blog.karmacrash.com

On 30-mei-2006, at 21:04, Andy T. wrote:

negative way, but Railers are generally more outspoken that RoR is the
is capable, but obviously RoR has momentum - and lots of it.

Anyone else in the same spot?

Personally I don’t know if I can tolerate Python after doing Ruby.
It’s just at the spot where you see
all of the ugly, hairy quasi-OOP-as-something-bolted-on-after-the-
fact after you do ruby for some time. Besides I like
the dictatorship that exists in Rails. TurboGears binds other
projects together and are just not as “slick” and coherent as Rails is.

But the choice has to be on your developers, that’s for sure.


Julian ‘Julik’ Tarkhanov
please send all personal mail to
me at julik.nl

The only reason you’d need to rewrite is to upgrade the framework
version.
Deploy all of your apps with the rails version you wrote it against in
the
/vendor directory.

…the only way to develop with RoR these days.