Django seems to have reached its tipping point, that critical mass which will enable its momentum to skyrocket. Getting here took a while though; partially because of a lack of hype and partially due to Rails’ very prominent presence in the market. Now this well deserving framework has finally begun to be widely adopted and considered as a valid alternative to Rails, for agile web development. Why do I care about what other people are going to use? I care because I’m deeply passionate about technology that works and that keeps things as simple as possible – as such forms of innovation always should. Independently from their adoption, promotion, and the differences in their approaches, both Django and Rails have at their core, a lot of substance and can greatly simplify and improve the way a web developer’s creative process flows.
Stating that Django has reached its tipping point is a bold claim, but I can present some evidence to back it up. I will use Rails and Ruby as a comparison for Django and Python – but don’t construe this as a race between the two frameworks. Rails is still the most popular and will probably continue to be for a long time. I’m only comparing the numbers to get an idea of where Django stands right now.
Visiting irc.freenode.net, I’ve noticed that the Python (#python) channel is often more populated than the Ruby one (#ruby-lang), and the same goes for Django (#django) and Ruby on Rails (#rubyonrails). For example, right now I see 517 members for Python and 354 for Ruby, 382 for Django and 298 for Rails. Django and Python consistently have more hackers in their chats than Rails and Ruby. This doesn’t say too much, given that the average developer doesn’t hang out on irc, but it’s still somewhat indicative of Django’s growing community.
Moving to newsgroups/Google Groups, things start to change a little. As I write this, there are 12,457 subscribers for comp.lang.python and only 6,935 for comp.lang.ruby (with 1,857 members in ruby-talk-google). “Django users” has 8,178 members versus the 13,355 of “Ruby on Rails: Talk”. So far this month, the Django group has had 1,244 messages versus the 2,890 of the Rails one. By looking at these numbers, without any pretense of being too scientific in our comparative methods, we get the impression that the Rails community is almost twice as big as the Django one, which sounds about right. On the other hand we also get that the Python community is larger than the Ruby one (confirmed also by the irc results above). In looking at these numbers, Rails also has the advantage of being the most used Ruby framework by far. In Python-land, Turbogears (3,303 members), Pylons (1,333 members) and good old Zope split the pie too, even though Django remains the most popular choice. Guido van Rossum’s blessing for Django was just the icing on the cake.
By observing the TIOBE Index, we see that Python is in 7th position versus the 10th position where we find Ruby. Perhaps more interestingly, Python has had a +0.70 delta since last March, while Ruby a -0.11%. Again, this is certainly not an exact science, my friends. TIOBE accuracy is often disputed for good reason, but I think it’s still an indicative factor.
Speaking of less than entirely reliable things, Alexa (django vs rails), Compete, and Google Trends (yes, rails is a very generic term) all confirm the anecdotal evidence that Rails is still far more popular. That said, the values start to be at least somewhat comparable.
In my opinion the strongest indicators of Django’s increasing popularity come from the publishing world. You’ll see many books in print for a given topic, only if their publishers believe that there is a large enough market for them. In 2007 the following two books were published: Professional Python Frameworks: Web 2.0 Programming with Django and Turbogears and The Definitive Guide to Django: Web Development Done Right (available for free online). 2008 has only just started and already there’s been one Django title published (Sams Teach Yourself Django in 24 Hours), with two further titles lined up: Practical Django Projects and Python Web Development with Django (which I’m currently reviewing for Pearson, as it’s in the process of being written – and I must say, I think it’s going to be a very good one).
5 books on Django announced to date and more lined up to be released this year, I’m sure. There are now many books in print that cover Rails (my recommendations here), but the sudden spur of Django books reminds me of Rails a couple of years ago and will surely help widen Django’s popularity. Watch closely because things will move fast in Django-land.
Get more stuff like this
Subscribe to my mailing list to receive similar updates about programming.
Thank you for subscribing. Please check your email to confirm your subscription.
Something went wrong.
In fact, Ruby is an exotic language. This language is known today only because Rails was a good initiative.
Ok, Ruby/Rails is hype today.
But Python is a strong language. Python has a large experienced community (not really the case with Ruby ;)).
But Django is very efficient, with good performance… without AJAX (and other hype word)
I am an eight years experienced with python. Who is eight years experienced with Ruby ?
In fact, it is not a competition. But a reality, Ruby/Rails are hype and Python/Django are powerful.
The last time i took a look at django version 0.95 or 0.96 was released. This was almost 6 months ago if I remember correctly. The problem with this release cycle is that 1.0 is a safe mark regarding api changes. I can’t build an application right now, only to find out that with 1.0 half the api calls break.
I am aware that this might not be the case, and that they might keep the api consistent, but this 0.96 for the last month, just makes me feel a bit uneasy…
Interesting numbers. You are right, Django is on a roll, and the 1.0 version is going to be great, with full Unicode support, the new admin interface implementation, and other goodies.
Turning the pages of the Django book I am carried back to nine years ago, the incredulous laughter while wading through the first edition of “Learning Python”: the same clarity, the same simplicity, the same attention to detail.
While I agree that on the whole there is not necessarily a competion between Python/Django and Ruby/Rails, I do believe that, on a personal level, an investment in both is not justified: they are similar technically.
However, they are *not* similar in two important aspects: intentions and diffusion.
The intentions of Python and Django, in both tools and community, are simplicity and clarity; Ruby and Rails seem more skewed toward cleverness.
And while Rails may be more known than Django, the range of usage of Python widely surpasses the Ruby one: this means more libraries, more diversity of competencies, more support.
Through all these years of web development I’ve been using Zope, Quixote, Twisted, Django, and many other Python tools. I do not see myself using Rails, nor Ruby, any time soon.
Namiah: you might want to take a look at Django’s document on API stability: http://www.djangoproject.com/documentation/api_stability/. In it we document exactly which APIs can be considered stable, and which may change before 1.0. We treat this list as a “contract” with our users, and are extremely careful when we deal with any API on that list.
You’ll see that the APIs declared stable are something in the ballpark of 90% of the public-facing Django API; 1.0 certainly won’t break “half” your calls. As with any software package there’ll be an upgrade path, but it should be moderately easy.
Thanks for the link. I realize that Python in general and django more specifically has a much more serious and less playfull approach to developing and integrating then other head-over-heels-follow-the-hype frameworks.
The document you mention is a step into the right direction, and I (realizing that I am not an active contributor) can’t and won’t question the django communities decisions. Nevertheless I think the 1.0 step should be reached as fast as possible since 0.XX release cycle have the bad karma of beeing too actively developed to be usable. Superstitions, misconceptions? Yes might be.. the feeling remains though..
I’m pretty sure things are going to move fast to a 1.0 now since one of the lead developers is working full time on Django. Thanks Jacob!
Just to add to your conversation, I’d like to let you know that Compete.com is built on Django. We’re glad to see that Django is really getting the credit it deserves.
I do think that 1.0 will be the true tipping point. Django itself is in an interesting place, being between the 0.96 and 1.0 releases. There are a bevy of changes that have been made since the last “official” release (e.g. the unicode, queryset refactor, newforms admin) that really puts the framework over the top. A number of sites in production are still using 0.96, as tracking trunk has definite issues in terms of maintenance, and I know that we personally would like to go through the process of fixing API breakage one time, if possible, instead of on a much more regular basis – which if by referencing the backwards-incompatible changelog, is a weekly occurrence right now (however small, they’re still API breakages, and who knows how big the next one will potentially be).
Once there’s a newer “official” release (read: not an SVN checkout version or trunk proper) with all the new features added since 0.96, and a full-on stable API set (even 10% potential breakage is a number that is tough to swallow on larger, and multi-site deployments), I think the number of sites using it will increase at an incredible rate.
@Nemlah – 0.96 was WAY more than 6 months ago, and honestly, Django doesn’t see too many backwards incompatible changes. The last one that really affected me was the autoescape, but that just meant I had to remove the calls to the escape filter that I already had in. I have MULTIPLE production Django apps deployed from svn.
Django will never win because the name cannot be shortened or ancronymized meaningfully. “D” does not count, nor does ‘go.
Just kidding. This is good news. Having more popular, smart MVC frameworks should make them all better.
Great points, but do we really care about ROR? Does it have any bearing on the success / failure of django, NO!
I do agree that you need some sort of critical mass to make sure the platform stays popular / supported, but I think if we continue to compare ourselves to ROR, we are destined to be limited. Similar to Desktop linux being like Windows, two different animals.
What I would rather see is django and ROR compared to .NET deployments. If we could get more penetration into the enterprise, like Java and .NET have, we’d really start smoking then.
Also, what website vendors support django? Thats a little more difficult since we aren’t at 1.x yet, but honestly, is it that tough for a VPS site so support django <1.x? If you google for VPS django you come up pretty short, do the same for VPS .NET or ROR and wow!
I love django lots, but I’d love to see an blog / article with ROR being mentioned.
Django has its shortcoming. Don’t understand me wrong, I use it now for several months and the ideas in the framework are great. But it has its limits and you quickly hit on them when you scale up:
– No stable APIs (or: there is no 1.0). One example is the oldforms framework, which is still there, but anyone developing with oldforms has to switch sooner or later. Others are the Unicode changes, the pending ORM changes (queryset-refactor branch) and I am confident more will come before 1.0 (or even after?). So you have to shoot a moving target right now.
– DB scalability is not there. In short, there is no Hibernate for Django. Don’t know what the status is to incorporate sqlalchemy, but last time I checked that branch was dead. Perhaps after the queryset refactoring there will be some work going on in this direction. And no, using memcached or the internal caching just doesn’t cut the deal. Hibernate/sqlalchemy gives you much more than that.
– No easy localisation. It would be nice to have a simple, single switch somewhere in Django to turn your app into eg. french, or german, or whatever behaviour (including date/time, currency, etc. handling). There is some boilerplate code in the localflavor directory, but you still have to do a lot manually.
So, enough ranting. Django still rocks, so here are the plus sides:
+ Excellent documentation. Even better than most commercial docs I have read. This is key for fast adoption and development.
+ Platform independent. Works on a lot of platforms, and with lots of HTTP servers.
+ Database independent. Also a major plus. Unit tests with sqlite, deployment for Postgresql/Oracle etc.
+ Nice ORM model. Not scalable (see above), but still a very nice API. And the refactoring puts that hopefully up another notch.
+ Built in I18N (note that I complained above about localisation, not i18n)
+ Flexible template language. It is yet another template language, but it does the job. Could be faster though.
+ Lots of “batteries included”, like caching, email, RSS, etc. Remember, it’s written in Python, which is the grandmaster of batteries!
This seems to be a relatively objective analysis and I too agree that Django is reaching that big tipping point. However, comparing Ruby to Python is just silly. Python is used in everything from highly popular server command-line tools to enormous MMORPGs. Python has so many useful libraries, both first and third-party, that at this point there isn’t much that can’t be done with it. Both Python’s usage at all levels of programming and maturity as a language are levels of magnitude greater than Ruby’s.
“If you google for VPS django you come up pretty short”
Which is why our company plans to offer Django-specific VPS hosting with the entire environment already setup. It really is exceedingly easy…
You are not suggesting rails scales better, are you?
DB scalability problem solved this week! Ivan Sagalaev introduced mysql_cluster.
“Mysql_cluster is a DJango DB backend supporting master-slave MySQL replication.
It works by switching global Django’s DB connection between master database and
slave replicas allowing usage of two connections from within standard ORM.”
http://softwaremaniacs.org/soft/mysql_cluster/ (there is english readme in zip archive)
I don’t think this means what you think it means. It sounds like Django users are all busy reading books, forums, and newsgroups in order to make things work. In the meantime the ruby/rails folks are so productive, they don’t need to crack a book, or look look on line. They just put their heads down and code.
(putting my head down to avoid the crossfire)
Django seems as the logical choice in our rewrite of a legacy python based database frontend. The only thing that keeps us a bit away is the lack of multi database support (yes there is a branch, but I hate to use branches)
@J nahhh. RoR is only good for toy web apps. I used it for almost a year and ended up switching to django.
Django is an afterthought of a website developer. Ruby on Rails, on the other hand, is a creation of a programmer.
I can make an application only using the ‘model’ portion of the MVC in Rails, without any ‘web’ part — and it still will be a useful framework for that purpose.
I’ve tried Django, and I always felt that I’m pushed to be a… website creator. Also, I’ve discovered contradictions. Views are not called ‘views’. Controllers are not really controllers. Templates… Well, the framework is doing its job for web application developers, but on relative merit – it is much less elegant than Ruby.
To those python developers who pride themselves on their knowledge of python I can only recommend to learn Ruby. It is much more flexible and fun to work with than Python. Steve Yegge once called python ‘frozen’. That’s right. It is a dogmatic and over-engineered language. Ruby on the other hand is fluid and immensely powerful.
If you’re tracking mindshare just use Google to track the conversations:
“ruby” = 118,000,000
“python” = 75,000,000
“rails” = 45,000,000 hits
“django” = 8,700,000
“struts” = 14,900,00 (who knows how many are automotive)
“spring framework” = 2,500,000
“zend framework” = 613,000
“grails” = 1,100,000
“rails” = 6,700,000
“django” = 1,151,000
I can’t see using IRC as a great measure after a technology crosses over. Rails IRC heyday was 2 years ago when the framework was new and the makers were on the channel. Rails has passed the tipping point with books, blogs and lots of other people to talk to who are in the same room as you, the need for IRC has really dropped off.
Try these queries instead:
python language : 1,460,000
ruby language : 755,000
python programming : 2,890,000
ruby programming : 2,540,000
django framework : 474,000
rails framework : 438,000
your queries mix-in too many pages that have nothing to do with the languages/frameworks.
Sam – I’m always using google to “track mindshare” and while I find it great, its definitely no better than the other examples listed here…
For example, the first 3 pages of “ruby” results yield several hits not related to the programming language… first 3 pages for “python” were 100% python programming language…
All in all, possibly the worst way due to the words; ruby is a gem, someone’s name, etc… rails, well, a ridiculously common word 🙂
@Didier: I have 6 years of experience with Ruby. Before learning Ruby I tried to learn Python but I didn’t like it. Ruby clicked with me instantly and I was able to port a rather big Perl script (not knowing Perl at all) in 2 weeks, while studying the language.
@Nicola: I think that Pythonistas and Rubyists just have two very different definitions of “simplicity and clarity”, both equally valid. What you call “clever”, we call “elegant”.
@oligarch: right on. “Frozen” and “dogmatic” are the words that come to my mind most often when I look at Python (both the language AND the community).
I think the fact that A. Holovaty was *annoyed* (!) by _why’s Ruby guide is rather emblematic 🙂
A few more numbers for comparison:
groovy language: 523,000
groovy programming: 446,000
grails framework: 429,000
Here is an english version description for mysql_cluster http://softwaremaniacs.org/soft/mysql_cluster/en/
Try these queries instead:
perl language: 1,710,000
perl programming: 5,960,000
catalyst framework: 578,000
AFAIK there is only one Catalyst book
Catalyst offers both a choice of ORMs and a choice of template language
I am a long time programmer…I started in C, then Perl, then Java, then Tcl, then Python, then more Java, and finally…Ruby.
I have recently started Python again because I have a need that Twisted fulfills rather nicely. I have read the online tutorials, studied Python in a Nutshell, and have a very good grasp on the language.
Let me say this very clearly…once you have tried Ruby, most other languages seem ugly. Python, unfortunately, is painted by this broad brush. I really, really tried to like it, but it is a language that severely lacks clarity.
I see many people comment on the clarity of Python, which I think can really only be attributed to two things: significant whitespace and the enforcement of parentheses in method calls. Other than these two features, the language is a mess. The inconsistency of the object model, the fact that there are new objects and old objects, the __builtin__ methods, the metaprogramming facilities…it all adds up to a LOT that you have to keep in your head when developing.
Contrast this with Ruby, where the object model is simple and clean, there are no builtins (i.e., everything is a message to an object), the metaprogramming facilities are relatively easy to grok, and Ruby has true closures…there’s really no comparison.
I like pythonistas and the #irc channels of Python, Twisted and Django have a great bunch of folks there. However, many times Ruby is criticized when they haven’t spent any time doing it. Ruby is a real improvement upon Python as a langugage (implementation aside).
I do like things about Python. I wouldn’t mind having significant whitespace in Ruby…and I see the lack of parentheses enforcement abused too many times.
Anyway, I hope those who are critical of Ruby will take the time to use it. I think you’ll find it hard to remove from your frame of reference.
While I don’t find Python ugly Mnmer, for the way my mind works, Ruby is cleaner and I do agree that it is, in my opinion, more consistent. I generally prefer Ruby to Python for pretty much any programming task, but that said I recognize Python’s strong selling points and Django’s value and productivity level.
I agree with you…Python has strong selling points…but they’re largely based on implementation and timing. I think python got to where it is today by basically being a cleaner alternative to perl with a solid implementation at the right time and right place…*and* by having an English-speaking community. When Python was rising in popularity, the Ruby community was largely Japanese…even Matz still struggles with the language. The headstart that Python got led to may libraries being developed.
Look at Ruby and what are the problems? Libraries and implementation (speed). Ruby 1.9 and rubinius should solve the performance problems…I don’t have an answer for the libraries. Hopefully just continued use will provide better !documented! libraries.
Sure there is room for both Python and Ruby, but in a blind “taste” test I believe people will prefer Ruby time and time again. Python is sort of like Perl to me…when there was nothing else, everything thought perl was the coolest thing. Now, after seeing languages that can be powerful *and* beautiful, everyone wonders what the hell perl programmers were thinking. I read Python docs and think exactly the same thing. There just doesn’t seem to be clarity in the design of the language.
I would like to see django include more database flexibility, like a stable mssql, db2, and odbc. For new construction and smaller sites mysql, postgres and such are great, but many larger companies run on mssql and db2, which are the other two “big wheels” in the database world, probably more important than sqlite. I do realize there is work being done on these and I can’t wait to be able to play!
I have a question. We’ve developed/are developing a website in Plone/Zope. It includes my favorites, people should be able to upload audio, video, and create lots of content and share it with friends or collaborate. There are user profiles as well as voting and tagging.
OK.. now we feel we’re totally wrong with Plone. It doesn’t even have any social components, and just ajaxifying the stuff is difficult. More things that you think are just normal (creating a subdomain for every member, or at least a normal url) are just not easy if not impossible.
Now later we want to add collaborative filtering, (off the shelf filters but only in php or C, not python) or simply subscribing to people’s activity (voting, recommendations whatever)…. is also not simple in Plone. A lot of stuff is stored in a postgresql database, and some in zodb.
Even our IT team mentions that we make very little use of Plone itself.. just lots of CSS, ajax and some basic processes.
Obviously we can migrate and maybe we should. Question is to what ? Migrating to Django would probably allow us to re-use a lot of what we have. Migrating to RoR would probably allow us to choose from more providers, tap into a larger community and more mindshare.
What to do (I understand noone is going to give me a custom answer here.. but perhaps some insights what to think about in choosing either would be possible and already quite helpful ! ) ?
I really love the clarity of Django. It reminds me of merb/ramaze 🙂 At the same time I love Ruby. Python and Ruby are both really nice. I dislike Rails, however. Django is clearer. Perhaps they took lessons from rails’ weaknesses?
I would say if you have a large rails site you’ll probably need about 4x as many app boxes as you would if you were running Django. Possibly because of a slow ruby runtime (the language is so open that it’s hard to optimize a runtime for it).
So Django wins overall for now for large sites. Most sites aren’t large, however…it’s more balanced for them.
The last time i took a look at django version 0.95 or 0.96 was released. This was almost 6 months ago if I remember correctly. The problem with this release cycle is that 1.0 is a safe mark regarding api changes.