Ask HN: Where is the Django community?

Its a keyword, but its not needed (as its not needed in many modern languages) but many rubyists I've worked with said that it was a nice feature that the return keyword was unnecessary and did not use it.

I worked for four years in my startup in which we decided to go with django; four years ago RoR (v1.2.3) and django(0.97) were almost at par. Even though RoR had a slightly bigger community, django was clearly emerging as a leader. Both were equally good but we went for django because it had better performance, the explicit style seemed better than the inflexible conventions approach, Python's one-clear-way-of-solving syntax seemed better suited for teams and django's performance was certainly better than RoR.

Fast-forwarding four years and coming to 2011 with django 1.3 and Rails 3.0: I happened to work in another team to build a product in RoR from scrach. I was blown away by what Rails community has achieved while django is lagging behind a lot and is least likely to catch up.

Here are a few highlights:

* As a generic statement, to achieve anything in RoR, usually there is one clear and simple way of doing it. On the other hand in django you can do in many ways and most of the programmers have their own preferable ways. This is ironic considering Python endorses the very same principle but Ruby has a flexible syntax to cater different styles.

* In RoR, you can find a gem for almost anything. Plugging gem in your app is usually extremely simple. On the other, comparatively there are very few usable django apps and integrating them in your django project usually turns out to be painful. * Resolving and maintaining gem dependencies across the team is a piece of cake with bundler. However when it comes to django, I couldn't find a good tool. There is virtualenv but I couldn't find it comparable with the power of bundler.

* Deployment is fun in Rails. In django, it was and still is painful.

* Rails has a far better support for Backend databases, including some support for NoSQL. On the other hand it was just a while back django started supporing multiple databases and that too is hackish approach.

* Databases migrations in Rails are straightforward and explicity. django doesn't have anything like that builtin but does have a django-evolution app which can be really troublesome in some cases.

* Django's restrictive templating system theoretically lets you not shoot yourself in the foot by imposing a new language. But having to learn a new language and dealing with its quirks sometimes makes you pull your hair. Rails approach of embedding Ruby in templates is much more powerful and practically useful. Sure you can override templating systems in both frameworks but defaults are the ones almost everyone uses.

* There are very few hosting services specifically tailored for django. But Rails community boasts services such as heroku which save you so much time that a django fanatic cannot understand.

* I haven't seen testing in Rails in depth but from the bird's eyeview, automated test-cases in Rails seem much more powerful than in django. I might be wrong here.

* Rails has much better documentation and a much stronger community. Compare the Rails and django books on Amazon, questions asked on SO, blogs, tweets, everywhere Rails now dominates.

Its just that I really love Python and prefer it much more over Ruby. Even then I'll probably completely switch to Rails.

Having been writing web interactivity since before PHP, I'd disagree with you that PHP "is a language like Python".

Look at how it started, as personal home page template processing scripts in Perl, and you'll see it started with much more in common with a templating tool or web framework than with a formal language.

"PHP/FI was created by Rasmus Lerdorf in 1995, initially as a simple set of Perl scripts for tracking accesses to his online resume. He named this set of scripts 'Personal Home Page Tools'. As more functionality was required, Rasmus wrote a much larger C implementation, which was able to communicate with databases, and enabled users to develop simple dynamic Web applications..."

"PHP/FI, which stood for Personal Home Page / Forms Interpreter, included some of the basic functionality of PHP as we know it today. It had Perl-like variables, automatic interpretation of form variables and HTML embedded syntax."

http://www.php.net/manual/en/history.php.php

> In some ways, Django tries to be flexible, but it's clumsy. For example, you can have your templates in your app directories. So, you have /path/to/project/posts/templates and /path/to/project/people/templates. However, you can't just put your templates in there because Django doesn't namespace them. Like, if I do {% extends "people/base.html" %} it will look in both those template directories for a people folder. It won't be like, "oh, I should look in /path/to/project/people/templates/base.html". I have to put the template in /path/to/project/people/templates/people/base.html. That's clumsy.

That one I completely disagree with, especially considering the idea of reusable applications.

While the repetition of 'people' does feel redundant at first glance, it means a second application can have its own `people/base.html` template which will be used instead of the one originally provided by `people`, and without needing any magical manipulation of paths/namespaces in the template loader. The path within the templates folder is completely independent from the path outside of it. And I think that's a fine behavior for the app_directories and the eggs loaders.

Furthermore, note that you could write your own template loader based on these which will do the namespace munging for you. How is that "Django tries to be flexible, but it's clumsy"?

the problem is simple, most people come to django with no previous web development knowledge and no python experience. they expect it to "just work" like php.

this ain't gonna work that way. if you know python, you will always find your way out by looking at the django code (there lie the best examples of how to write django.)

and if you have web development experience, you will recognize the time you've wasted on boilerplate stuff django gives you for free.

'nuf said.