Brodie Rao December 6, 2006 at 5:31 p.m.

And there are those who tie together the components that they want to use and just create a simple application template.

It's too bad Django doesn't emphasize this kind of development, and using individual components from it isn't an easy task (at least when I last tried).

Brantley December 6, 2006 at 5:41 p.m.

Who needs enemies when you have friends to hate?

Gabriel Puliatti December 6, 2006 at 6:14 p.m.

Hey! The only actual flamebait was the title!

Still, I must admit that jesusphreak's was much, much better.

Cale Gibbard December 6, 2006 at 9:31 p.m.

Dynamic vs. Compiled? This is such a false dichotomy that I just have to speak up. I apologise in advance. :)

"Dynamic" refers to the type system of a language. A language is dynamically typed if types of some terms are not determined before the program runs, and hence may depend on the actual path of execution or evaluation in the program. The proper thing to contrast with this is a statically typed language, where the type of each term is determined by the execution environment before the program is run.

Another thing to note is that statically typed does not necessarily mean that the system requires type annotations from the programmer. In many statically typed languages, the types of functions and values is inferred completely by their construction, and checked against any type signatures which the programmer bothers to include, as well as against each other. When a function is applied, its (inferred) type is matched against the (inferred) type of its parameters.

You can very roughly think of this as whether or not the execution environment (compiler, interpreter, bytecode compiler, JIT compiler, etc.) attempts to prove that the code will never 'go wrong' in various ways before the program runs.

The downside to static typing is that computers are only so good at proving theorems. A human programmer may want to do something which they can prove correct (or at least they suspect it won't fail), but the system can't. Sometimes the static typing language just doesn't have the types necessary to express the conditions on code which the programmer would want to express, and sometimes adding those additional types will either spoil type-inference, or make the problem of proving that a program satisfies its types much harder, or even make it outright impossible for the compiler to do for itself.

The upside to a statically typed system is that the programmer can (at least in any system worth its salt) express more constraints about how code may behave than without it, and the system will actually go about proving those constraints before code ends up running in production. It's like documentation which is machine verified. Note that it's very different from unit testing, which in general can only prove that certain properties do not hold, rather than that they always do. Hence, you eliminate a whole class of potential bugs from running code. How large that class of bugs is tends to depend on how expressive the typesystem is.

As for the compiled vs. interpreted distinction, this is a property of an execution environment for a language, not an intrinsic property of any language itself. There are quite a few compilers for dynamically typed languages (look at Scheme, Smalltalk, Icon for a few), as well as interpreters for statically typed ones (even for Haskell, which I'd consider a poster-child for expressive static typing, as well as C, which most people usually think of as very close to bare metal).

Adrian Holovaty December 6, 2006 at 9:50 p.m.

Cale: Whoa! Thanks for the awesome explanation/correction. I've fixed the entry.

Jeff Croft December 6, 2006 at 10:41 p.m.

It is amusing (and usually pretty annoying) how people fight so intently over two things which have far, far more in common than they have differences. It's certainly not just in this industry, either -- Christians sometimes seem to fight more with other Christians than they do with those who have drastically different beliefs than they do.

We really ought to try to recognize that Rails has a lot in common with Django. The two come from similar backgrounds and aim to solve very similar problems. There are no doubt things each camp could learn from the other.

So, by all means continue to evangelize Django if you love it -- but you don't necessarily have to bash something else in the process. And don't be afraid to talk publicly about the faults in Django and those things that Rails does better -- I don't think the Django developers are so proud that they wouldn't steal a good idea when they see one. :)

Hugh Bien December 7, 2006 at 6:29 a.m.

"Good artists copy, great artists steal." Both frameworks are open source for a reason =P. I would hope that both frameworks steal good ideas from each other.

David S. December 7, 2006 at 8:17 a.m.

Reasons for one framework are not reasons against another. It is silly, especially when there are so many people using PHP, Java, ASP, etc. And, anyway, most of these so-called comparisons would be more useful without the distraction of mentioning a competing framework, since they do not really compare at all. The authors should stick to what they really want to say, which is, "I made a great development decision--here is why."

Peter Bowyer December 7, 2006 at 8:44 a.m.

Is Alan Green and Ben Askins's presentation available anywhere (audio/video/slides)? I dug around that website but didn't turn anything up...

Andrew Donaldson December 7, 2006 at 9:38 a.m.

Most people who write comparisons are doing it simply for the short-sharp Digg/Reddit/Etc traffic they get. Thanks for reminding us of Mark's writeup.

mike December 7, 2006 at 10:55 a.m.

lol...

Neuruss December 7, 2006 at 1:08 p.m.

I don't want to avoid flames nor being constructive.
I want to crush my enemies and rape their women.
Die Ruby, Die!!!!

Vugar December 7, 2006 at 6:31 p.m.

There's one cause for all flame wars: persons arguing for their point of view is just not completly confident with their point of view.

Tim December 7, 2006 at 8:07 p.m.

That "with apologies to emo phillips" business was done for emacs a while ago, too:

http://www.dina.kvl.dk/~abraham/relig...

Justin B. December 8, 2006 at 7:20 p.m.

Competition is good for the market, and I'm all about framework harmony. But, some of the "flames" are well deserved, i.e. that DHH fellow is annoying as all hell. Just watch the Snakes & Rubies on Google Video to see what I mean. It's David's way or the highway with the RoR framework. No thanks, I'll pass on the magic and the attitude.

Ruby is an excellent language, but it has too much hype for web apps. IMHO the most impressive stuff being done with Ruby is in the field of computer security. The developers of the Metasploit framework migrated to Ruby and are amazing things that really utilize the strengths of the language:

http://www.metasploit.org/projects/Fr...

Lukas December 10, 2006 at 7:58 a.m.

In recent weeks I've read many comparisons between Django and Rails. In fact my agency is currently using both the frameworks for small/medium projects.
While these frameworks are slowly converging on many points, IMHO they greatly differ in the following areas:

DOCUMENTATION
Good Ruby and Rails documentation is not freely available on the web: you have to buy real books. Instead Python and Django online docs are authoritative, updated and well organized, true to the best open source tradition.

DATABASE
With Rails coding a data model in your app is not sufficient: you have to deal directly with the database to create tables, columns, etc. using raw SQL or a more user-friendly interface. Rails simply binds together the two layers when the user adds, edits and deletes records.
With Django you concentrate on the application layer and simply code some models in Python: the framework itself translates these models to SQL and creates a working database. In other words the database is invisible.
Of course if you need to change the schema of a database already full of data you can deal directly with the RDMS or use a schema migration tool (integrated in Rails, coming soon in Django).

BUILDING A SITE vs BUILDING A WEB APP
Rails, born out of Basecamp, is a great framework if you want to build a single monolithic web application with all those Ajax bells and whistles, following the Web 2.0 fashion.
Django, developed in a media environment, is a tool to build and manage a real-world web site with (one or) many plug-and-play applications glued togheter. In my view this approach is more flexible.

HYPE
The hype sourronding Ruby on Rails nowdays is simply astonishing: the people at 37signals are really marketing-focused. Instead the people behind Django appear more humble and product-focused.

HOSTING
While Python hosting is relatively popular only a few hosting companies officially support Django at the moment.
Ruby hosting is still rare but more and more companies officially support Rails.

TEMPLATING and ADMIN INTERFACE
Integrated in Django, available as plug-ins in Rails.

PYTHON vs RUBY
Python and Ruby are two elegant and powerful programming languages. However, while Ruby's popularity is growing, Python has more libraries, a larger user community in the west and it's faster (in most cases). Moreover, according to recent findings, the cult of Python is more ancient -> source: http://www.timesonline.co.uk/article/...

CONCLUSION
While Django and Rails have some important differences, I think they are two excellent frameworks. We are lucky to have many great options for web development.

Jeff Wheeler December 10, 2006 at 2:44 p.m.

Ha, I just wrote a blog post about the two, before I saw this. So, here's a little shameless plug:

http://nokrev.com/blog/when-use-djang...

I feel each has it's own job that it does very well. Django is an excellent publishing framework, while Rails is a better application framework. I guess that makes sense, from their origins.

Adam Isler December 10, 2006 at 6:41 p.m.

I guess I'll throw my 2c in.

HOSTING
I have no trouble setting up Django on most hosts. It's pretty simple. Just because more places put the name Rails in their selling points, doesn't mean it's better supported. I find Django to be more reliable on Dreamhost than Rails.

TEMPLATING
This has gotten better in Rails with the new yield blocks (essentially the same functionality as the Django blocks). Both are good for what they need to do, but I like the Rails partial system (you can extract parts of templates so they can be used in different templates) and I'm a fan of their Ajax helpers (hey, it's a personal preference and there are good args on both sides - decide for yourself).

PYTHON VS RUBY
Oy, I really couldn't care less about a language war.

DATABASE
While people say Rails makes you go into SQL here, you don't have to. It's actually prefered that you use migrations. With migrations you define your schema as:
t.column :name, :string
t.column :date, :datetime
etc.
The migrations also allow for schema evolution in a way that Django doesn't. That being said, when I use Rails, I have to put all the fields for a model in a comment at the top because I forget what they are and the introspection that Rails does is quite a performance hit.

DOCUMENTATION
Yeah, Rails wants you to buy their books, but they have an extremely helpful Wiki and it's really easy to Google for extensive information due to the hype/size of community.

THE REAL BIG DIFFERENCE
Comes from where the two came from. As some have said, it's app vs. publishing. It's somewhat true. Django is a pain when dealing with user-submitted data (newforms look nicer than the current manipulator system, but Rails really gets it right here). At the same time, it is absolutely painful to build an app with an extensive admin in Rails. THIS IS THE ONLY AREA IN WHICH I WOULD CHOOSE ONE OVER THE OTHER. In all other areas, they're so similar that even well written articles don't really tell you anything. I've written a couple web app-ish things in Rails and a few publishing things in Django and I wouldn't want to rewrite either in the other framework. That's my opinion and, frankly, neither framework is that different syntactically that you can't learn both rather easily.

Idiot Magnet December 12, 2006 at 6:48 p.m.

How does the RoR "partial" system differ from the Django inclusion tags or the {% include %} tag?

Martin Maney December 14, 2006 at 12:12 p.m.

Has there been any progress on the wish list items about making some of Django's components usable without all the rest of it? I've been enjoying the Jinja templating system for a while, and am now looking for something like the URL mapping system. The restricted data model remains the reason I can't use Django itself. :-(

http://wsgiarea.pocoo.org/jinja/

Ciro December 14, 2006 at 12:57 p.m.

Hi, congrats for your excellent work on Django and its documentation.

I'm a web designer from Italy. Last summer, tired with hacking CMSes (Expression Engine, Word Press, Textpattern, etc.) for my clients, I decided to learn a web framework.

I've spent the last 4 months reading all relevant literature about Ruby, Rails, Python and Django.

My conclusion is that for a web designer entering the web development universe Django is probably the best choice to make: you simply can't beat Python code philosophy, the wonderful integrated admin interface of Django and its terrific templating system. Jeff Croft's work with Django is a great case study from a designer perspective.

Of course RoR is the framework of the moment: new books are hitting the shelves these days, more and more hosting companies are offering RoR integrated in their plans, bloggers are talking about it, etc. But I can remember the same hype sourronding PHP (the current evil) some years ago...

The reality is that with Django you can build the same things that you can build with Rails. But with Django, in most case, you can use an integrated and customizable (but optional) admin panel.

However I have a suggestion to speed up Django diffusion, based on my personal learning experience.

Let's face: to use Django you have to learn Python. On the market there are many good Python books but they are general purpose tutorial or reference, covering many topics simply not relevant for Django developers. A gifted Python author (Alex Martelli ?, Magnus Lie Hetland ?) should write a compact (max 350 pages) Python book especially addressed to Django users, in other words a perfect companion to the Django book. It should teach the basic concepts necessary to work with Django and the more advanced topics needed to expand the framework itself. The examples should be extracted from real-world django applications and from studing the framework itself. A similar book already exists in the RoR camp, Ruby for Rails (Manning 2006), and it's a very useful book. Such a book could also help push Python web developers towards a standard framework. (I wonder whether Guido van Rossum has ever declared its preference for a specific web framework.) After all the great popularity of Rails can be explained also by the fact that it is, de facto, the only web framework for Ruby.

Santosh December 15, 2006 at 8:28 a.m.

Ciro,

Actually the Python core is much smaller than Ruby. U can learn it faster than Ruby. Learn the 'Byte of Python' available at www.byteofpython.info & www.dpawson.co.uk/bop/byteofpython_12.... It is actually very introductory stuff sufficicent for u get started of in Python as well as Django

Ciro December 15, 2006 at 10:10 a.m.

Santosh,
thanks for the tip. In fact I've already learned the Python core with the following resources:

1) "A Byte of Python" (free online book)
2) "Learning Python" (O'Reilly)
3) "Beginning Python" (Apress)

Another book with good reviews is "Core Python Programming" but I have not a direct experience.

While these books are excellent resources, I think a "Python for Django" book would be a great addition to the Django developer library. As I told, the example to follow could be the book "Ruby for Rails" published by Manning in 2006.

In my view, Django is the real Python killer app in the web development universe. I know many people learning Python only to use Django. I'm so enthusiast with Django that I rarely use Ruby on Rails nowdays. When I create a site with RoR I have to build an admin interface from sratch (scaffolding is not a serious admin interface but a development aid) and this is a boring and time-consuming task.

Giovanni Russo December 15, 2006 at 5:29 p.m.

Hi Ciro,
it's nice to see an Italian fellow using Django :) This framework and Python itself seem very popular in our country.

You're right about Django admin interface: it's great!

My concerns about Django are mainly related to a missing schema migration tool.

You know, with Rails you can create a working database schema step by step interacting with your client and if you are not satisfied with the changes you can roll back to a previous schema in 5 seconds. And look, ma, no SQL! Only Ruby code.

With Django you are forced to build a solid schema before loading some data in the database. Once data is loaded, you can use syncdb only when you create a new table; otherwise (add/edit a column, etc.) you have to apply the changes two times, in the models.py file and directly in the database, writing raw SQL or using phpMyAdmin/pgAdmin III. Moreover, if you decide to roll back your changes, you have to revert them again in models.py and in the db!

I'm fluent in SQL and I generally apply only a few corrections to my original schema, so this is not a great issue, but I have to to recognize that Rails is more flexible on this matter.

I know there is a project to add a schema evolution engine to Django but it will take a long time to catch up Rails migrations.

However, apart from this issue and from the RowLevelPermissions one, Django is simply perfect and really mature! I appreciate above all its obsession for performance and stability.

However I wonder how people at World Online and The Washington Post currently manage their schema evolutions...

Ciro December 16, 2006 at 10:09 a.m.

Ciao Giovanni,
IMHO Rails migrations are far from perfect. They are a boring affair, your schema definition will be spread across a large number of separate migration files and in some cases they fail and there are no alternatives to using directly SQL with the database.

Django approach is more pratical: you can read the details in the Django Book (Chapter 5).

In my experience when an application is already live with the database full of data, schema changes are not so frequent and they are always a risky operation: in these cases I prefer to deal directly with the db (I use pgAdmin III with PostgreSQL).

So a schema migration tool would be a nice addition to Django but in my view it's not a priority.

Grimboy December 18, 2006 at 3:39 p.m.

Obligitary Monty Python reference:

Judian Peoples Front?!? @#!?* off! We're the Peoples Front of Judea!

* Damn self censorship!

Marcus January 9, 2007 at 4:41 p.m.

I think it comes down completely to prefence. Neither are terrible or perfect, Rails has gotten alot of attention, but Ruby is still too young. Both frameworks have simular flaws and should be patching those holes instead of posting a link to this argument on their front page.

jrockway May 13, 2007 at 2:18 a.m.

> Both frameworks have simular flaws and should be patching those holes instead of posting a link to this argument on their front page.

Or, you can use Catalyst and get the benefits of 10,000+ CPAN libraries and a very pleasant community. Rails and Django are great in some ways, but for getting real world (complex) problems solved, Catalyst is what you want to use.