Start with Django unless you have a very good reason to use one of the other ones. Very good reasons include
1.) Previous skills with Mako, SQLAlchemy, Paste, or any of the other libraries that Pylons or Turbogears is based upon.
2.) Previous code in one of the above libraries
3.) Functionality needs that Django cannot satisfy in at least a couple of the following areas: authentication, user models, multiple database support, template extensibility, deployment. I say "at least a couple" because if you just need one, you can import it like you would in any other framework. The price is that many existing Django add-ons won't be aware of your choice.
Bad reasons include:
1.) "Django's only for CMSes." Not true; it works just as well for anything that involves web apps, including AJAX apps.
2.) "It's not scalable enough." The Washington Post runs on Django; I doubt you're going to get more pageviews than them.
3.) "My data doesn't easily fit in the relational paradigm." That's what the import statement is for; you can hook any data source you want up to a Django view.
4.) "Django's templating language is too restrictive." That's what template tags are for.
5.) "I'm really doing a full-fledged AJAX app, not a website." You can output JSON or XML data from a Django view as easily as HTML, and you're not limited to any particular JavaScript library. (I actually think Django views are more convenient for this than Pylons controllers; there's less boilerplate.)
> 2.) "It's not scalable enough." The Washington Post runs on Django; I doubt you're going to get more pageviews than them.
Just FYI, the Washington Post does not use Django for their main page. They only use it for small side projects.
At reddit we tried to use Django, but had to switch to Pylons because, lo and behold, it wasn't scalable. Specifically, it has a problem caching templates under high loads.
Interesting...that's very helpful to know. Did you try memcached? I've heard Pownce has been doing just fine with Django + memcached, and they get a decent amount of traffic.
Alright, thank you. I guess exactly what I was looking for. Couple of other questions that just popped up while reading your (thoughtful)reply
a)- How much is the learning curve--considering my skill-set? From what I can tell from their website, I guess decent amount of documentation is available so I hope I won't get stuck.
b)-My only fear is the lack of JavaScript(Ajax) skills. For that reason alone, I was interested in Pylon as I thought Pylon would make this easy for me(just by reading their website). But after searching the term 'Ajax+Django' using Google I think Django is not a bad choice. I think I will need to know JSON. Any other things you can recommend that will make my life easy while doing Ajax using Django?
Appreciate your help.
a.) You do need a solid block of time to devote to it, but if you have that, it's not bad. Start with the tutorial and work your way through it, and be sure to follow along. I had a decent grasp after about 2 days, and in 3 weeks I'd rewritten my whole project in Django, getting back to the functionality level I'd previously written in Pylons. This included delving into some of the more esoteric corners like template tags, custom management commands, and the authentication & user system.
b.) Don't worry about that - doing AJAX well depends a lot more on your JavaScript skills than on the server-side technology used, and for anything serious, you'll need to know real JavaScript. Pylons does have a nice shortcut in that they ported over all the Rails JavaScript helpers, so you can get simple things like pagination, reloading divs, and JavaScript buttons without actually using any JavaScript. But they implement this using Prototype, which is a library that I personally refuse to touch for the reasons in b.3)
b.2) There're actually like 5 different JSON libraries for Python, and you can mix & match them with web frameworks (they just output a string, and any decent web framework will let you send a string to the browser). I use simplejson (which comes in the standard library of Python 2.5 - no installation necessary) for flexibility and cjson for speed.
b.3) Stay away from any JavaScript library that messes with the prototypes of built-in object types or adds lots of functions to the global namespace. The bad list includes Prototype, Mootools, and 99% of random JavaScript snippets you'll find on the web. The good list includes JQuery, YUI, and any libraries built on them. The reason for this is compatibility: JavaScript has no native namespacing support, and so if you get 3rd-party libraries from two sources that don't pay attention to namespacing, they invariably end up stomping on each other's functions.
b.4) If you're serious about doing an AJAX app, take the time to really learn JavaScript well. My last employer thought they could paper over all the dark corners and browser incompatibilities with AJAX JSF components; they always ended up coming back to bite us in the end. Know what you're doing. The Rhino Book and John Resig's "Professional JavaScript" are good sources, as are the websites of Doug Crockford, John Resig, and Dean Edwards.
b.5) Start by doing non-AJAX apps with Django and only add AJAX when you absolutely need it to improve the user experience. Aside from flattening the learning curve, this also disciplines you into treating AJAX as an additional tool for the toolbox, not a buzzword. A lot of companies have gone AJAX-crazy (like my last employer) and are treating everything like a desktop app when they should start as a plain webapp and only add additional interactivity when necessary. The web succeeded for a reason; trying to recreate the desktop in a browser is a step backwards.
Thank you very much every one and Nostrademons in particular. I really appreciate your insights. Very helpful. What web-host (cheap and reliable:-)you guys use to deploy python-based apps?
When I started hacking in Python which was over a year ago, I started with Django. That was a mistake because Django has too much magic which leaves the newbie clueless - I switched to Pylons and it has always felt right. Additionally Pylons has allowed me the necessary space to grow my skills and the Pylons apps I build now are very customized.
That was my experience - I think you should try out Django, Pylons and a few other frameworks to see what suits your style.
As mrtron points out, most of the magic was removed fairly recently, and modern Django code is fairly intuitive. I also first looked around Jan 2007, and discounted Django because there was too much magic. But I took a second look in Dec 2007 and it was much, much better.
Biggest annoyance for me so far with Django is it not following the MVC model I would have expected from it going in. We'll see how it works out for one of our newer/silly sites, though.
I forgot to check out Pylons for the project one of our contractors is working on. Thanks for mentioning it, we might consider it if Django continues to be cumbersome.
I switched mostly because of the large collection of apps (= plugins, in other framework terminology) available for Django. The admin app gets most of the attention, but it's way more than that. For example, there's an app for built-in CSRF protecion. There's one for a comment system on any type of object, and another one for threaded comments. Generic tagging and voting apps. Instantly generated RSS (yeah, I know Pylons has this too, but it's built into the framework and not a 3rd-party add-on) or Sitemaps. There's an OpenID plugin. A way to automatically generate robots.txt files. A couple different forums, and a blog. (This is huge: in past projects, one of my biggest frustrations has been getting 3rd-party forums to interoperate with the site's custom authentication scheme. Django lets you use one user model for all components.)
Some other things I liked about it: I thought that Django views were conceptually cleaner than Pylons controllers, with fewer global variables needed. I thought the templating language looked cleaner than Mako as well, though less powerful. The admin app saves me lots of time for mundane tasks that I'd probably just forgo otherwise. I could get used to the ORM - don't particularly like it, but as ORMs go, it's quite nice. I really like that it comes with authentication, sessions & user models built-in. I liked that it was well-documented.
Some things I thought Pylons did better: I think Pylons packaging & deployment is much more mature, built on setuptools, Paste, and eggs. I like that I don't have to use an ORM, and that it's loosely coupled in general. I like how Mako lets me define template functions directly in the template.
Also, Guido blessed Django as "the" Python web framework at SciPy 2006. So far, the rest of the world has basically ignored that pronouncement, and I haven't really heard anything further about it. But I thought that it was generally more prudent to be on the same wavelength as the BDFL.
I was a big pylons fan until about a week ago. I had go take another look at Django this week for my job and for some reason it feels better. I recommend walking through the tutorial. You'll either like Django or reinforce your preference for Pylons.
1.) Previous skills with Mako, SQLAlchemy, Paste, or any of the other libraries that Pylons or Turbogears is based upon.
2.) Previous code in one of the above libraries
3.) Functionality needs that Django cannot satisfy in at least a couple of the following areas: authentication, user models, multiple database support, template extensibility, deployment. I say "at least a couple" because if you just need one, you can import it like you would in any other framework. The price is that many existing Django add-ons won't be aware of your choice.
Bad reasons include:
1.) "Django's only for CMSes." Not true; it works just as well for anything that involves web apps, including AJAX apps.
2.) "It's not scalable enough." The Washington Post runs on Django; I doubt you're going to get more pageviews than them.
3.) "My data doesn't easily fit in the relational paradigm." That's what the import statement is for; you can hook any data source you want up to a Django view.
4.) "Django's templating language is too restrictive." That's what template tags are for.
5.) "I'm really doing a full-fledged AJAX app, not a website." You can output JSON or XML data from a Django view as easily as HTML, and you're not limited to any particular JavaScript library. (I actually think Django views are more convenient for this than Pylons controllers; there's less boilerplate.)