A few months ago I picked TurboGears over Django for number of subjective reasons. Part of it was that the website seemed to be nicer, there was a shiny^H^H^H^H convincing screencast and the mailing list seemed to be more active (based on number of subscribers).
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.
So I was wondering how many TG developers are there who develop applications in TurboGears in their day jobs?
I really hope that the upcoming TG book to which I very much look forward to and the ongoing effort to clean up the documentation will put back TG in the lead. :)
> 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. )
> > 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.
"Nyenyec N" <nyen...@gmail.com> writes: > So I was wondering how many TG developers are there who develop applications > in TurboGears in their day jobs?
I do. All of my current ongoing development projects are based on TurboGears.
> I really hope that the upcoming TG book to which I very much look forward to > and the ongoing effort to clean up the documentation will put back TG in the > lead. :)
The book is already there. :-) It was released last weekend. ;-)
"Nyenyec N" <nyen...@gmail.com> writes: > 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.
One thing that I forgot commenting on my message: what languages (and lists, of course) have you considered? There are Japanese, Portuguese, Spanish, Chinese, etc. lists for TurboGears. Not everybody is comfortable or wants to speak English.
I'm being paid a salary to develop a web application. And I'm doing it in Turbogears. It's not exactly my day job, but if I perform well, it will become my day job.
It's my first foray into web development, however. So we'll see how that goes :-)
Stuart
On Wed, 2006-11-15 at 01:03 +0000, Simon Wittber wrote: > Nyenyec N wrote: > > So I was wondering how many TG developers are there who develop > > applications in TurboGears in their day jobs?
> I'm paid a salary to develop TurboGears applications, if that is what > you are asking. TurboGears application programming consumes ~70% of my > day.
> So I was wondering how many TG developers are there who develop > applications in TurboGears in their day jobs?
We are developing an application using Turbogears (and this is our day job). One of the major motivating factor over Django was TG's built-in support for SQLAlchemy. It might be true that nothing restricted us to use SQLAlchemy or MochiKit with Django or Pylons, but being new to web development and python, we wanted to avoid gluing works as far as possible, and rest on TG.
On Tue, 2006-14-11 at 21:45 -0800, Sanjay wrote: > > So I was wondering how many TG developers are there who develop > > applications in TurboGears in their day jobs?
I have only just switched from Django to Gears for a few on the go projects. It's my harf a day job, but only because I only want to work part time. In the last six months it could have been my full job had I wanted to work that much, but I'm self employed as a musician and juggler in the corporate and festival entertainment world when I'm not coding.
> So I was wondering how many TG developers are there who develop > applications in TurboGears in their day jobs?
I develop web applications for my day job 8-12 hours each day. The applications are various in-house information systems for a commercial printer based in Iceland with operations in the US, Poland and Romania.
Since I started to use TurboGears some 6 months ago I have developed 2 fairly large and one small projects with it. However I'm thinking that for my next project I'll just use CherryPy directly, TG is a bit too high level for my needs.
> Since I started to use TurboGears some 6 months ago I have developed 2 > fairly large and one small projects with it. However I'm thinking that > for my next project I'll just use CherryPy directly, TG is a bit too > high level for my needs.
Though a little off topic, I'm interested in knowing at what point gears feels too high level, and which components make that the case. Would it be the ORM or do you find you need more architectural flexibility?
On 11/15/06, iain duncan <iaindun...@telus.net> wrote:
> Though a little off topic, I'm interested in knowing at what point gears > feels too high level, and which components make that the case. Would it > be the ORM or do you find you need more architectural flexibility?
I'll indulge this offtopic response. I don't know how long you've been around, but until a little over a year ago, there were dozens and dozens of web frameworks for Python. They're still out there (and more are added all the time Cloubrid, web.py, etc), but TG, Django, and Pylons cover enough ground that they're good enough for most people.
The thing about the full stack frameworks is that they make a lot of decisions for you. Many experienced Python developers don't like CherryPy, particularly the dispatch. Others don't like Kid. If you're not making use of widgets, error handling, identity, or the toolbox, then there's no reason you can't roll your own framework with Paste. This is basically what Pylons and CleverHarold are.
The goal for 1.1 (as I understand it) is to make TG a wsgi-based framework and to break up the TG pieces into self-contained units so that they can be reused in other wsgi-based frameworks.
> The thing about the full stack frameworks is that they make a lot of > decisions for you. Many experienced Python developers don't like > CherryPy, particularly the dispatch. Others don't like Kid. If you're > not making use of widgets, error handling, identity, or the toolbox, > then there's no reason you can't roll your own framework with Paste. > This is basically what Pylons and CleverHarold are.
> The goal for 1.1 (as I understand it) is to make TG a wsgi-based > framework and to break up the TG pieces into self-contained units so > that they can be reused in other wsgi-based frameworks.
That sounds very cool. Does that mean one would be able to unplug CherryPy from the middle and use Pylons or Rhubarb Tart if they are more appropriate for the task at hand?
I realize this must make docs a lot harder, but it makes for a more attractive advanced tool kit in my books.
On 11/15/06, iain duncan <iaindun...@telus.net> wrote:
> That sounds very cool. Does that mean one would be able to unplug > CherryPy from the middle and use Pylons or Rhubarb Tart if they are more > appropriate for the task at hand?
I believe so.
> I realize this must make docs a lot harder, but it makes for a more > attractive advanced tool kit in my books.
I'm not worried about the docs. They'll be written for the official way of doing things with pointers on how to do things differently, probably about like the SQLAlchemy doc today, maybe a bit better.
> The thing about the full stack frameworks is that they make a lot of > decisions for you. Many experienced Python developers don't like > CherryPy, particularly the dispatch.
If TG moves to CherryPy 3 it won't be a problem anymore considering CherryPy comes in built-in with:
- its own dispatcher - an HTTP method dispatcher - a Routes dispatcher
And adding dispatcher is really easy.
Moreover CherryPy 3 is fully WSGI compliant now (both as a server and as an application).
> If TG moves to CherryPy 3 it won't be a problem anymore considering > CherryPy comes in built-in with:
> - its own dispatcher > - an HTTP method dispatcher > - a Routes dispatcher
> And adding dispatcher is really easy.
> Moreover CherryPy 3 is fully WSGI compliant now (both as a server and as > an application).
Yes, we definitely have to find some body with a little bit of time to work on this. I don't think the CherryPy 3 migration will be hard, and it will be well worth the trouble!
On 11/15/06, iain duncan <iaindun...@telus.net> wrote:
> > Since I started to use TurboGears some 6 months ago I have developed 2 > > fairly large and one small projects with it. However I'm thinking that > > for my next project I'll just use CherryPy directly, TG is a bit too > > high level for my needs.
> Though a little off topic, I'm interested in knowing at what point gears > feels too high level, and which components make that the case. Would it > be the ORM or do you find you need more architectural flexibility?
Sorry for the late response. Others have mention most of the points that lead to my statement. The fact of the matter is, as I have said here before:
* I use SQLAlchemy, so so model designer, catwalk and all the crud-magic widgets are of no use. * I use routes, in effect I short circuit the normal dispatching. * I dislike the explicit turbogears.database.session, for my last project I kept the identity related model in sqlalchemy and used a completely seperate model for my business logic. * I needed more from the identity framework so I had to write my own identity controller. * I don't use widgets, they mostly just don't apply to my projects so far. * I don't like the std. @expose decorator in turbogears since it wraps the function making it unusable from regular Python code, this was partially solved with writing my own dispatch logic.
CherryPy 3 is looking very good imo, currently I'm leaning more towards that rather than Pylons. I also like the asynchronous methodology of Twisted, esp. if one needs long-running requests as in Comet.
