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.
