Tornado is a server which is also a minimal framework, Django is a full featured framework which includes an ORM and is not a server. The early stage decision to use one or the other seems to often hinge upon the concept of speed. This, as well as my framing as “versus” to get your attention, is wrong, and here’s why.

(If you’re looking to benchmark geek, the baseline is that Tornado is asynchronous and fast compared to the still speedy Django served through nginx and uwsgi.)

These two pieces of tech have different purposes. Pairing them in a death match isn’t the right way to start thinking about a project, they serve different purposes.

If you’re building anything other than the most well spec’d small featured set web application, you’ll be building a lot of pieces from scratch in Tornado if you’re using Tornado as a framework. There’s a very good chance that you’ll eliminate every bit of speed you’d been hoping to get through writing messy code or patching on an ORM. I’m not saying you aren’t the best developer in the world, but you know, really, you aren’t. I’m certainly not either. One of the things I realize as I get older is that if a group of much smarter people can get together to build fundamental reusable components, and all their tests, and their upkeep and improvement, that I should let them. I’ll then use those to build flexible features quickly and cleanly.

Good frameworks are systems you devote a certain amount of energy learning, and in return you get the knowledge of a collective. Bad frameworks are systems you devote a certain amount of energy learning, and in return you get the mistakes and bad design decisions of a collective.

Both Django and Tornado are very good projects. Django is a much better framework. Tornado is a server with some framework type helpers. Tornado isn’t trying to be Django.

Tornado is great at what it does. Glance through the code. It’s super clean, well organized. Tight. It’s making a much different set of decisions, quite legitimately, to get out of your way.

Django has, from day one, realized that building web applications traditionally means lots of boilerplate and repetitive work that has usually led to lots of bugs, mess, brittleness -- and it wants to help you avoid this, to build things better. It needs to get in your way by applying conventions and patterns to prevent you from fucking it up.

You’re building a web app, OK, how much time do you have? This should be the basis for your decision about your project, not speed.

If you have lots of time to write the components you need to play with Tornado solely as a platform, given that you are shooting for a web app with a commonly sized featureset (social, admin tools, content scrubbing), and you want to control every piece of it, then you’ll be making a good choice. Be ready to write lots of code, be ready to choose an ORM. Yes, I’m making the fantastical assumption you’ve got a database and need to manipulate data from it. If you are writing a web app without a database, please tell me where you live and how you’ll let me visit your magical world.

If you have very little time and a featureset that is either commonly sized, or uncertain (and what developer has ever worked with an uncertain spec), or needs to be flexible, the amount of time you’ll put in to learning Django will come back to you tenfold. You’ll be able to turn around pieces radically quicker. You’ll also be looking at fewer bugs because you’ll be writing less code, and less maintenance because you’ve written less code and have fewer bugs. More time for feature building.

That said, if you have any extra time whatsoever, spend it learning whichever you didn't build your project with. Both are worthwhile, and both can help you in the long run.