On 11/14/06, iain duncan <[EMAIL PROTECTED]> wrote: > > > Since then however, my impression is that Django is growing faster > > than TurboGears based on the number of subscribers to their mailing > > list and I wonder if that is because they have more people who are > > working on and in the framework full time. > > I would not put much stock in mail list subscribers as indicative of > what you should use, that is more a result of marketing and initial > first impression. By that same token we should all go back to PHP, the > community is massive and their docs are amazing. Easy to learn does not > necessarily mean powerful. ; ) > > And you have to keep in mind that Gears is not "one project" so there > exist mailing lists also for SQLObject, SQLAlchemy, Kid, Genshi, > CherryPy, etc. I have now used both enough to appreciate some strengths > and differences of each, which really have nothing to do with how well > marketed the two platforms are. > > At root, I would say ( as does the Django lead, Adrian ) that Gears has > a more unixy approach, whilst Django is more like a mac. Of course > Adrian and I differ on which of those is cooler ( and I own a mac > too!) ; ) Below are my personal opinions, to be taken with much salt. > > Results of Django being an all-in-one package that came from an > initially closed source application: > - docs are currently better organized > - code base is more uniform and cohesive, more tightly integrated > - initial impression of a new user is going to be better > - easier to get up and running > - more narrowly focused to the initial problem field, in this case a CMS > aimed for high volume relatively low complexity sites where > non-developers need a good admin, but that admin can be very generic > - simple text based templating language, great for non coders and > situations where templating is mostly a presentation *design* issue > - one mailing list, one dev list, one core dev community ( this has a > lot of pros and cons, I believe the cons are bigger, YMMV ) > > Results of gears being more modular and following the unix style of > "lots of small tools integrated": > - IMHO a more flexible, cleaner, modular architecture > - much less group think, therefore much more critical analysis of > architecture decisions and future directions, at the current expense of > dev speed > - much better integration with third party options ( sqlalchemy, other > template engines, mochikit ) > - harder to use template language that is better for coders doing DOM > manipulation > - harder to learn, more scattered docs, more difficult to get going as > there are more components to wrap your head around > - appropriate for a much broader problem set, especially for complex > applications that require a lot of customization. Customizing the Django > admin is not fun, I tell you! And once you get past what most people > want to do most of the time, the django docs stop looking so hot. > - a more open approach to open source development, which I believe to be > a better long term approach even if it is not as fast moving currently. > I think the gears approach will attract a larger dev base in the long > run. > > As someone who will be doing a lot of work with these tools, I'll > continue learning both, but I will almost certainly do any complex > application development in Gears. on the other hand, if a friend told me > they needed to a basic CMS with an admin intergface for a client on a > cheap budget and they had to learn the framework fast, I'd tell them to > learn Django ( and then look at gears later). I believe the gears payoff > to be a bit further down the learning curve, again a lot like linux. > Once you learn grep and awk and bash and regular expressions, gui's > start to look like pretty lame ways to get things done. ;) > > My two cents as a recent convert. I'm always interested in hearing > critical analysis of both sides. ( Though you won't see much of that on > the Django list, frankly. )
It's probably also worth mentioning Pylons, which pretty much does the same thing as TurboGears, but does a better job at being "unixy". I've been playing with both Pylons and TurboGears lately, and I definitely have to say that Pylons really gives TG a run for its money. The big pros are: 1. WSGI, not CherryPy. Easy to plug in or write middleware, easier to get "to the metal". 2. Routes, not CherryPy. Far better control over URL dispatch. 3. Their customized EvalException integration is *awesome*. Debugging is terribly easy, and it's easy on the eyes (unlike raw EvalException, which is ugly and less usable). 4. A "public" directory that covers the whole webroot rather than "/static". 5. Easier to add "stdvars", just stick them in project.lib.helpers The things that TurboGears does better, in my experience: 1. Unicode. Pylons doesn't really touch it, but it's easy to code something up that deals with decoding the request params (or cut+paste). I'm sure they'll fix this soon though. 2. DB integration. Pylons doesn't really have any, but it's really easy to write your own. New users would get bitten here though. 3. The toolbox. I never got much use out of it because I'm using SQLAlchemy and no ORM (ORM is no good for massive reporting stuff with lots of joins). I imagine many users really take advantage of the toolbox though. 4. Documentation. There's definitely more of it, especially with the book now. I can't say that I was exceptionally happy with either TG's or Pylon's docs, but TG's seems more complete and mature. Even after having to write my own unicode and db support stuff, I ended up removing more code than I added when porting a project from TG to Pylons. I would still recommend TurboGears to new users though, because Pylons definitely still has areas where you end up rolling your own solutions to common problems. For advanced users that's not such a big deal, and the pros may very well outweigh the cons. -bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
