Ask HN: Choosing a Python framework for web development?
Hi all,
I'm new to programming and started developing software using Python around 6 months back. I also know a bit of C#, C, JavaScript, HTML and CSS. Not an expert in any thing, still learning. Also, I'm not very good at Regular Expressions--this was a new-year resolution ;)
Now I've come across a dilemma and find myself completely stumped. I cannot figure what Python web-framework I should choose to start developing web-based software using Python. I've looked at the websites of Django, Pylon, CherryPy and WebPy--and I couldn't decide ;( Considering my naive skills I intend to choose a lightweight framework and a framework with which I can easily use JavaScript for client-side scripting (my biggest fear). I think I'm in a company of some very smart people here so I will really appreciate if you can help me in choosing an appropriate framework--considering my skill-set. Thanks in advance, fellas.
40 comments
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.)
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.
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.
That will be interesting to see. I really don't think Pownce gets anything close to reddit's traffic
I think I've read somewhere that Disqus uses Django.
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.
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?
Webfaction.com is good for Django, Rails, Pylons, etc.
Also note that nostrademons has written code in more frameworks than most of us web programmers have ever heard of. Just saying.
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.
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 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.
It's an "MTV" framework: http://www.djangobook.com/en/1.0/chapter05/#cn16
I'd be interested to hear how/why/where Django is cumbersome.
I've used Pylons, but not Django. Why is Django a better choice?
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.)
http://code.djangoproject.com/wiki/DjangoResources#Djangoapp...
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.
http://code.djangoproject.com/wiki/DjangoResources#Djangoapp...
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.
If you're serious about learning web programming, here's a few thoughts before you pick up the Django book and start wading through it:
Take a look at the HTTP protocol, and learn what it does before you start diving in to web frameworks. You'll understand what's going on inside the framework before you get started.
After looking at HTTP, try some basic CGI programming. Just google: Python CGI Tutorial. CGI is a bit archaic, but it helps to understand why frameworks developed, and what they're making easier.
Pick up MySQL or PostGress and learn some SQL and databases first. Web frameworks are essentially an "easy" way to develop a GUI for a database. If you don't know what the database is, or what it's doing, you'll be chasing your tail learning a framework first.
It's worth mucking around with some *nix and apache. You don't really have to do this first, but you're not going to be able to do too much with your web app, because I don't know of too many companies that serve Django apps off of Windows. It's all Linux or BSD hosting for Django pretty much. That means knowing at least the basics of shell scripting and apache config files.
Take a look at the HTTP protocol, and learn what it does before you start diving in to web frameworks. You'll understand what's going on inside the framework before you get started.
After looking at HTTP, try some basic CGI programming. Just google: Python CGI Tutorial. CGI is a bit archaic, but it helps to understand why frameworks developed, and what they're making easier.
Pick up MySQL or PostGress and learn some SQL and databases first. Web frameworks are essentially an "easy" way to develop a GUI for a database. If you don't know what the database is, or what it's doing, you'll be chasing your tail learning a framework first.
It's worth mucking around with some *nix and apache. You don't really have to do this first, but you're not going to be able to do too much with your web app, because I don't know of too many companies that serve Django apps off of Windows. It's all Linux or BSD hosting for Django pretty much. That means knowing at least the basics of shell scripting and apache config files.
If you are inclined to start from basics, you might want to try this tutorial: http://pythonpaste.org/do-it-yourself-framework.html
I prefer Pylons for many reasons. One of them is that SQLAlchemy is the single most powerful SQL library I've ever used, and Pylons makes it easy to use SQLAlchemy, while Django doesn't. This is just one example of Django's reluctance to use superior outside solutions.
I'd have to second this. The Pylons project doesn't seem to suffer from the NIH syndrome that the django project does, and because of that, they're free to choose best-of-breed tools for every scenario. I think the fact that turbogears 2.0 is going to be based on pylons is a great win for both projects. It really gives you the feeling that if TheGreatestTemplateEngineEver or TheTransparentestORMEver gets invented tomorrow, these guys will be the first to support it. That kind of unashamed blatant code thievery deserves some respect. ;)
Actually there has been a SQLAlchemy branch for over a year. Last I check it had stagnated - not enough interest.
It's a wonder why, when Django's form validation and admin panels require the Django ORM, and last I heard, using the SQLAlchemy branch required extra work.
The SQLAlchemy branch was intended to seamlessly integrate with the model api - in other words you needn't know it was there. I don't think it got too far.
Form validation is not tied to the Django ORM.
Form validation is not tied to the Django ORM.
That's funny, because when I was going through the newforms code, it had a lot of ties to the ORM.
And yet form validation is not tied to the ORM. The ORM is leverage where a form is generated from a model, but that's not what you said.
[deleted]
Study the source of existing sites you like. Then start writing your own Python framework upward to recreate (and fast transcend) them. Extensively study the existing frameworks, especially when you hit a conceptual or implementational roadblock. Understand everything you have to work with at each step. Keep building up.
One thing you might try is to start by writing some small CGI webapps/scripts. Later on, it will give you an appreciation of what the frameworks are actually doing for you.
Also, if you're not married to Python, and are looking for something really simple and easy to learn, you might try Perl's CGI::Application (along with some plug-ins).
Also, if you're not married to Python, and are looking for something really simple and easy to learn, you might try Perl's CGI::Application (along with some plug-ins).
I've used pylons and cherrypy, and did some massive rails things way back when rails was still cool (2007). I prefer the cherrypy way of doing things vs. pylons, but they are mostly aesthetic choices. Django is probably your best bet unless you want something lightweight.
I agree. For a simple web app, Django might be an overkill, that you might not need. Cherry.py, is simple. Web.py is very simple also(not quite a framework), but it also has poor documentation.
It is up to you, on what you want to do. If you are comfortable with writing your own SQL, then Django is not going to be as useful as something more light weight like cherry.py
It is up to you, on what you want to do. If you are comfortable with writing your own SQL, then Django is not going to be as useful as something more light weight like cherry.py
As you seem to be just starting out, I would suggest a ground up approach to learning how to build web apps, choice of language being rather secondary here. Have a look at:
http://philip.greenspun.com/seia/
http://philip.greenspun.com/seia/
Some additional opinions...
Ask Hacker News: What Python web framework should I use?
http://news.ycombinator.com/item?id=129121
Ask Hacker News: What Python web framework should I use?
http://news.ycombinator.com/item?id=129121
web.py is a good one for learning more about Python.
django's templating language is great for small projects, but their object model is a disaster. I'd roll your own data access layer.