SuperJared June 26, 2006 at 1:08 p.m.

Django has diamonds on the inside.

Meir Kriheli June 27, 2006 at 3:28 a.m.

Thanks for the "very cool" regarding BiDi support :)

Django now is one of the few which supports right-to-left out of the box (many localized projects are forks of the original ones, with all downsides of it).

One note: the correct changeset would be Changeset 3121, 3091 was the early messy version.

If you'r developing multilingual sites and need to support both right-to-left and left-to-right, take a look at the admin templates and stylesheets for an example.

Pete Crosier June 27, 2006 at 5:43 a.m.

Three cheers for the new fastcgi option and associated documentation.. I'd tried in the past with various guides and always ran into a wall somewhere when trying to get lighttpd / fastcgi / Django to play nice, and now it's all working like a dream :)

Xet7 June 28, 2006 at 12:29 p.m.

How easy/hard would it be to have admin interface created in web page, without writing code?
So that users could (with limited privileges) add new forms to web application?

Do changes on admin interface code require server restart?

RoR is going to have admin interface too with Streamlined:
http://streamlined.relevancellc.com
and Adrian made some comments about it here:
http://www.approachingnormal.com/arti...
but didn't answer to follow-up question... I hope he'll answer later.

Xet7 June 29, 2006 at 4:43 a.m.

Oops, that server at approachingnormal.com got Internal Server Error :)
Google cache here:
http://66.249.93.104/search?q=cache:v...

Adrian Holovaty June 29, 2006 at 7:11 a.m.

Xet7: That's how the Django admin interface works: You don't have to write any code.

There aren't any plans to enable non-programmers to create models.

Yes, on a production server, changes to code require a restart. On the development server, changes don't require a restart.

Hope this answers your questions!

Larry Wright June 29, 2006 at 10:52 a.m.

I'm the author of the article at http://www.approachingnormal.com/arti...

I really wasn't intending to criticize the Django project, I honestly can't see any major piece of functionality that Django provides that Rails does not, other than the automated admin screens. I understand that there are some design differences, but as far as functionality, I don't see anything. I would love for somebody to explain it to me.

P.S. As for the 500 errors, I'm running a couple of sites on a TextDrive shared hosting plan, and I keep running up against their memory limit :(

poko June 29, 2006 at 2:10 p.m.

+1 to larry's question. could you please explain why someone would choose django over rails after rails adding a new admin interface?
(any new features in the pipeline etc.)

thanks in advance,
poko

Simon Willison June 29, 2006 at 2:43 p.m.

Here are a few reasons you might choose Django over Rails:

1. You prefer Python to Ruby.
2. You prefer Django's API to Rails' API.
3. You prefer Django's admin interface to the Rails one (has anyone seen screenshots / a demo of this on the Web yet?)
4. The better performance (in terms of actual language evaluation) of Python over Ruby is a relevant to your project.

It mostly comes down to personal taste and using the best tool for the job at hand.

Colin June 29, 2006 at 4:05 p.m.

Another reason to choose Django: stability.

The rails framework is based on the presupposition that it is easy to hack in the source. By doing so repetitive tasks can be "hacked into" the rails framework. An example is the impossibility to add ".html" to the generated urls by configuration. By hacking in the framework this is easily achieved. Another example is adding advanced automation to activerecords db retrieval (ignoring items flagged as invalid).
If you have achieved such a thing in rails 1.0 then when you update to 1.2 all of a sudden both fixes throw errors because the internals of rails changed.
the result is that when one chooses to use rails the instability of the code (it is under continued development, backwards compatibility is often ignored) forces you to stay with the version you developed your code on. I hate to say it, but this sucks. I cannot fullheartedly recommend rails to be used on a large website knowing that a new version of the framework will more that likely break that website. The largest problem is that the changes are not obvious, and alternatives for the broken functionality might not even be readily available.

The Django framework, considering the recent magic-removal, at least give me the impression that the api will be stable.

SuperJared June 29, 2006 at 4:53 p.m.

+1 to Simon's answer

Anyone saying that Ruby on Rails is better than Django (or vice versa) is simply touting the one they prefer.

I prefer Django.

Larry Wright June 29, 2006 at 8:11 p.m.

Simon: With all due respect (and I'm not just saying that - I've been subscribed to your blog forever), that's not what I'm asking. Preference is one thing, and I do understand that is ultimately what the choice comes down to. That was really the point of my original comment - that with Streamlined, there was more feature parity between the two projects. Typically, when I've seen Django advocates speaking about the advantages of their platform of choice, they bring up the automated Admin screens as one of the major benefits.

What Adrian seemed to imply on his comments on my site was that this wasn't true - that Django still had features that Rails did not. As far as I can see (and I confess that I've not dug terribly deep), this isn't the case.

As for performance, you're right - Python outperforms Ruby in raw speed tests. As a result, I would imagine that Django would outperform Rails, although I don't know that I've seen any tests done on that. I do expect that this will change, and in the next few years Ruby will be much closer to Python in terms of speed. That said, I think both Rails and Django have been proven to scale very well, so I don't think it's as much of an issue as some people make it to be.

Colin: I haven't experienced the same pains that you apparently have, but I've not deployed any large scale public sites with Rails either. That said, I'm not sure that I view the rate of change as a negative. The functionality that has been added in the last several major releases of Rails (and the one upcoming) have provided dramatic improvements in developer productivity (rjs templates come to mind particularly). I think most Rails users are willing to deal with a little breakage to receive the productivity benefits.

I really never intended this to be a debate over which platform is better - I firmly believe that the world is a better place because both Rails and Django exist.

Larry Wright June 29, 2006 at 8:15 p.m.

Simon: I forgot to mention in my previous comment that there have been some screenshots for the Streamlined interface. See this post: http://streamlined.relevancellc.com/a...

It's not fully baked yet, they're waiting on a designer to give them a little css love prior to release.

Adrian Holovaty June 30, 2006 at 7:16 a.m.

Larry, in addition to the fundamentals Simon pointed out, I'll add these to the list, off the top of my head:

* Internationalization
* Generic views
* Less coupling
* No code in templates
* RSS/Atom framework
* No stupid pluralization
* Less overall "magic" -- Rails is implicit in many ways, Django is explicit in many ways

Also, the "admin interface" provided by Streamlined is scaffolding. That is, it creates a bunch of code for you. The Django admin interface is not scaffolding; things are created dynamically. This is a tremendous difference.

There's no scaffolding at all in Django, because code generation is almost always a bad idea. In fact, before it was open-sourced, Django used to do code generation, in all layers from the admin interface to the model API. It became so redundant and unmanageable that we abstracted it.

It boggles my mind that Rails encourages scaffolding. (Well, maybe it doesn't boggle my mind, when I consider some of the other decisions they've made.) But the first thing I always hear from Rails people is that they never use scaffolding, and that it's more of a curse than a blessing.

With all of this said, of course there's room for both frameworks, and, in the grand scheme of things, many, many more people use Java and PHP than Django *or* Ruby on Rails. Arguing over this is unproductive. We should be encouraging the non-clued-in Web developers of the world to turn to dynamic languages.

Larry Wright June 30, 2006 at 8:58 a.m.

Adrian,
Thanks for the clarification.

I hadn't caught that the admin stuff in Django was dynamic, that is a big difference. I don't agree with your position on code generation, but we can agree to disagree here :) Several of your other points appear to be your opinion of how things should work - which is perfectly fine. As DHH often says, software should be opinionated.

To be honest, I don't think that Rails encourages scaffolding (I'm assuming you're referring to the scaffolding that comes with Rails, rather than Streamlined). It's in there, and it's useful for certain things, but I don't see it encouraged these days. I think where the Rails community went wrong in the early days was that every demo, and every article, showed the scaffolding. People came to Rails thinking that scaffolding did everything for them, and got confused when that wasn't the case. I'd like to think that we've learned our lesson.

All in all, Django looks like a great framework. Please know that my comments were never intended to be critical, I was just looking for clarification. I agree that arguing between the Rails and Django camps is completely unproductive.

I think I'm going to port a couple of my Rails projects to Django to better learn for myself how the two platforms compare.

Xet7 June 30, 2006 at 9:13 a.m.

I added some follow-up ideas/dreams to page:
http://streamlined.relevancellc.com/a...

Adrian Holovaty June 30, 2006 at 1:54 p.m.

Larry: Yeah, you should give Django a shot rather than dealing only with the marketing for either framework.

Discover Django is better by actually using it, not by reading my biased comparisons!

__SERF__ July 1, 2006 at 2:36 p.m.

Adrian, I would really be interested in your opinions of Rails' treatment of Databases (beyond CRUD), especially existing databases being used currently by potential new users.

Your comment on the so called "pluralization" is a hint, but I feel you are holding back (to keep the peace perhaps) even after watching the detailed tete-a-tete in the snakes and rubies conversation.

For the sake of general health and well being of the open-source movement itself, I believe sometimes you've got to break some eggs rather than walking on eggshells :)

I for one (and I'm sure many others) would be very interested in hearing your thoughts on what Django does right (strategically) in terms of not only new projects where db design is up for discussion, but for existing systems where re-engineering existing (and working) DB backends can easily cost a middle manager their career if it goes south. Not that we should concern ourselves too much with the fate of middle managers, but sometimes it makes sense when their fate is deciding where they would spend their budgets.

Rails might want to shun "enterprisey" to feign the rebel kid on the block, but unfortunately, that's where the BIGGG dollars are. BTW, I second your thoughts on this whole pluralization business (FWIW).

poko July 1, 2006 at 10:35 p.m.

while i agree that pluraziation is kind of weird in RoR but so does the misleading view->template, controller->view naming convetion in django (especially for a newbie).

the areas where i think RoR is better at the moment: web service support, db backend support, ajax support (whatever it means), test framework, db migration. the areas where django is superior: admin interface, db-tables-after-model, easier deployment, template language, less magic.

also you mention less coupling, as far as i understand django's views deal with HTTPRequest, could you please ellaborate?

sorry, i did not want to turn it into ror vs django debate.

keep up the good work!

Jason Huggins July 2, 2006 at 3:38 a.m.

I have to agree with poko that Rails does have a lead with web service support, db backend support, whatever-ajax-is-but-to-me-that-means-draggable-sortable-rows-in-child-tables-in-the-admin-interface, and test frameworks.

Ironically though, Rails provides XML-RPC and SOAP out of the box, but it seems like it was just put in there as a bone to throw to the "enterprise" crowd. (Okay, maybe that's true about SOAP, cause XML-RPC has never been considered very 'enterprise'y.) But in light of David Hansson's recent "FUC'D" presentation at RailsConf, I think XML-RPC and SOAP in Rails are as walks-like-it's-deprecated-smells-likes-it's-deprecated as Rails' scaffolding is. It's like they include those features to "bait" newbies, but once they are "hooked", they're encouraged to "switch" to other methods quickly. ;-)

For my part, I'm trying to help Django close that gap, though! (I personally like XML-RPC (but not SOAP), Ajax, Oracle dbs, and test frameworks. :-)

Andy Bold July 2, 2006 at 7:58 a.m.

It's horses for courses.

I love Ruby as a language, and I have spent a lot of time trying to grok Ruby on Rails. (Pluralisation I still don't get. Why oh why is this required? OK, many "Persons" can be referred to as "People", but why?)

It is obviously a strong framework. Basecamp, Backpack, Typo, et al prove this.

I also have a passion for Python, so Django was on my "To look at again" list for a long time. Being fairly language agnostic, along the way I also had a hack with Symfony (http://www.symfony-project.com/) and Catalyst (http://www.catalystframework.org/). Symfony = scaffolding - yuck. Catalyst = too much bloody choice! :-)

I originally looked at Django about a year ago. At that time it looked like things needed to settle down a little before I took a more serious look.

And now that things seem to be settling down I am looking at Django again. The test app that took me four days to get working in RoR was up and running in a couple of hours on Django.

Something about Django just 'clicks' with me. Whenever I need to do something I just try and do it the way I think it should work, and it usually works. And when it doesn't a quick look at the online docs usually show a more sensible way of accomplishing whatever it is that I am trying to do.

For example, if I create a "Person" model, I don't have to keep remembering to refer to it as "People". ;-)

BTW, Simon - really looking forward to your Django related talk at Lugradio Live. Will definitely be one of the event highlights for me. (http://www.lugradio.org/live/2006/ind...)

Frankie July 6, 2006 at 11:57 a.m.

<quote>
For the sake of general health and well being of the open-source movement itself, I believe sometimes you've got to break some eggs rather than walking on eggshells :)
</quote>

I totally disagree with this, django isn't just going to die and every currently using it switch to RoR. It's much better to just let both of them grow. I like django, but I realize some people prefer rails, some people prefer seaside and for some reason a lot of people seem to prefer php. I mean really, if we're going to have to have some "eggs that get broken" then I know what I'd prefer it to be.

__SERF__ July 7, 2006 at 6:05 p.m.

@Frankie: umm.. that's so ENTIRELY _NOT_ what I meant! but thanks for playing. :)