Mombu the Programming Forum

Go Back   Mombu the Programming Forum > Programming > Pros/Cons of Turbogears/Rails?
User Name
Password
REGISTER NOW! Mark Forums Read




Reply
1 10th August 17:49
jaroslaw zabiello
External User
 
Posts: 1
Default Pros/Cons of Turbogears/Rails?



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)

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.


Ruby is not so young you think. It became more popular
when Rails has appeared.


What? YAML is much easier.

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


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.

--
Jaroslaw Zabiello
http://blog.zabiello.com
  Reply With Quote


 


2 10th August 17:49
jorge godoy
External User
 
Posts: 1
Default Pros/Cons of Turbogears/Rails?



"Jaroslaw Zabiello" <hipertracker@gmail.com> writes:


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


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 ;-) --
Jorge Godoy <jgodoy@gmail.com>
  Reply With Quote
3 10th August 17:49
james edward gray ii
External User
 
Posts: 1
Default Pros/Cons of Turbogears/Rails?


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 Gray II
  Reply With Quote
4 10th August 17:50
jeff barczewski
External User
 
Posts: 1
Default Pros/Cons of Turbogears/Rails?


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 Barczewski
MasterView project founder
http://masterview.org/
  Reply With Quote
5 10th August 17:50
adam jones
External User
 
Posts: 1
Default Pros/Cons of Turbogears/Rails?


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.

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?


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.

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.


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
  Reply With Quote
6 10th August 17:50
christophe
External User
 
Posts: 1
Default Pros/Cons of Turbogears/Rails?


Jaroslaw Zabiello a écrit :

Google doesn't find YARM and so, YARM does not exist. Care to provide an
URL or something?
  Reply With Quote
7 10th August 17:50
fuzzylollipop
External User
 
Posts: 1
Default Pros/Cons of Turbogears/Rails?


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.
  Reply With Quote
8 10th August 17:50
jeff barczewski
External User
 
Posts: 1
Default Pros/Cons of Turbogears/Rails?


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/
  Reply With Quote
9 10th August 17:50
fuzzylollipop
External User
 
Posts: 1
Default Pros/Cons of Turbogears/Rails?


nobody is talking about perception
  Reply With Quote
10 10th August 17:50
paul boddie
External User
 
Posts: 1
Default Pros/Cons of Turbogears/Rails?


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.

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
  Reply With Quote
Reply


Thread Tools
Display Modes




666