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. -- Posted via http://www.ruby-forum.com/.
On May 30, 2006, at 12:04 PM, Andy Trump 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 Mornini
cremes.devlist@mac.com
2006-May-30 19:23 UTC
[Rails] Why would I choose RoR over Turbogears
On May 30, 2006, at 2:04 PM, Andy Trump wrote:> 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.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. -- Posted via http://www.ruby-forum.com/.
subimage interactive
2006-May-30 21:57 UTC
[Rails] Re: Why would I choose RoR over Turbogears
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. On 5/30/06, Colin <Colin@no.no> wrote:> > 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. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- seth at subimage interactive http://www.subimage.com/sublog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060530/1abe6e77/attachment.html
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 Case tim@karmacrash.com blog.karmacrash.com On 5/30/06, subimage interactive <subimage@gmail.com> wrote:> > 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. > > > On 5/30/06, Colin <Colin@no.no> wrote: > > > > 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. > > > > -- > > Posted via http://www.ruby-forum.com/. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > -- > seth at subimage interactive > http://www.subimage.com/sublog/ > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060531/7a965170/attachment.html
Julian ''Julik'' Tarkhanov
2006-May-31 11:30 UTC
[Rails] Why would I choose RoR over Turbogears
On 30-mei-2006, at 21:04, Andy Trump wrote:> > 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?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