This post originated from an RSS feed registered with Ruby Buzz
by David Heinemeier Hansson.
Original Post: Rails and Django meets in Chicago
Feed Title: Loud Thinking
Feed URL: http://feeds.feedburner.com/LoudThinking
Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp
Snakes and Rubies was a great success. Adrian gave a funny presentation on the origins of Django and I tested the patience of the audience for an hour and twenty minutes with nothing but screens of code, however beautiful. But at least I had the lights turned off in my presentation, so there was no public humiliation for dozing off.
Regardless, it was a good show. The Django guys have their heads screwed on right and we share more opinions on software development and framework construction than not. Of course, the interesting juice is in that diff, so let me riff on that for a bit.
On where to make the cut
Building frameworks are at least as much about when to say no as it is about making programming easier. Adrian billed their auto admin as the crown jewel of Django and I think that serves as a good example of how they have a higher cut than Rails will ever have.
To me, such an elaborate administration interface with login, permissions, and groups and what have you is out of scope for inclusion in the core framework. But I still admire it. It's a great feature. And it shows off Django's newspaper legacy perfectly.
And that's what I really liked about both this meeting and Django in general. It sounds similar to Rails, and it is in a lot of ways, but the differences get larger the closer you zoom in. Which of course makes this less about competing and more about learning from one another. There's less of a desire to one-up each other on features.
On a scale from web site to web application
This of course leads to thoughts of what the differences between the frameworks mean for their use. During the debate, it seemed we narrowed in on the notion of a continuum from web site to web application. The former is lighter on business logic, but benefits heavily from instant admin interfaces and pre-build RSS/Atom creators. The latter is heavier on business logic and thus aiming to be more generic in its use, focusing on problems like making more complex domain models beautiful.
Again, this makes perfect sense when you look at the origin of the frameworks. Django grew out of Lawrence.com, the notion of "software development on journalism deadlines", and the core group of developers work primarily with publishing of various kinds. Rails, on the other hand, grew out of Basecamp. It's seen heavy use in e-commerce, collaboration, organization, community, and even credit rating processing.
So its only natural that Django appear to be more optimized for web sites with dynamic parts and Rails for web applications with static parts. That division is of course somewhat artificial since you could certainly use either framework for each end of the spectrum. But it does give a good sense of where the focus is being put. What the sweet spot that's being chased is.
On flavors of aesthetics
What probably surprised me the most, though, was the difference in aesthetics. While I can appreciate how someone could like Pythons use of meaningful indentation, I was more surprised to learn that someone would actually prefer something like:
class Project(meta.Model):
project_manager = meta.ForeignKey(ProjectManager)
milestones = meta.OneToOneField(Milestone)
categories = meta.ManyToManyField(Category)
p = projects.get_object(id__exact=1)
pp = projects.get_list
...over:
class Person < ActiveRecord::Base
belongs_to :project_manager
has_many :milestones
has_and_belongs_to_many :categories
end
p = Project.find(1)
pp = Project.find(:all)
And that's just the simple case. What I'm more surprised over is the lack of interest in domain-specific languages in general. They just don't seem to turn on Python people :)
But Python is also a pretty hostile environment to domain-specific languages. There are no arbitrary method calls during class compilation allowed (only for attribute assignments), no support for blocks, no poetry (like leaving out parentheses when there is no ambiguity).
I guess its only natural that people are more interested in techniques that their language has good support for, but it still caught me a bit off guard. Considering that those elements are precisely what I love so much about programming.
On whether or not to have a template language
Another big difference between Django and Rails is template languages. Django uses one, Rails doesn't (by default). That lead to a good discussion on whether designers were ever capable of creating new templates from scratch or if it would require they become programmers anyway (understanding methods, loops, variables, etc).
My perspective is that designers won't be creating templates from scratch anyway. Not unless they more or less become programmers. So what you really need to optimize for is to get the dynamic elements "out of the way" and to be comprehensible enough that designers know whether something is inside or outside the administrators block.
Again, this is probably something that's partly driven by language. Python has meaningful indentation, so its a pretty bad fit for use in templates that mix code and HTML anyway. So since you're forced to come up with something else, you might as well pursue an entirely different path.
There are definitely cases where a template language rules, though. That's in the case of end-user customization where you can't afford to have a full programming language at the disposal of the user. You need a sandbox so they won't do damage. Django's templates are great for that and served as an inspiration for Liquid, the optional Rails templating language.
In summary
I had a great time at the meeting and the following dinner. I hope we can do something similar in the future. Adrian, the lead developer of Django, is here in Chicago, so there should be amble opportunity.
And I look forward to seeing Django grow. They released as open source a year after Rails, so they're in an entirely different state in the life-cycle. Not a lot of applications out there, so they can still break backwards compatibility and do wild experiments. I can certainly envy that some times when we have to come up with yet another clever work-around to make old and new API styles jive.
I hope they continue to pursue the publication angle. It gives them a unique profile and makes the case for a prepackaged content-management system that much harder. At the same time, I'd love to see someone "build" Django on top of Rails. An application that did the auto admin, RSS packaging, and all that jazz.
Previous Topic
