So here it is, my first Django project: the gazillionth blog engine on the planet!. As if there weren’t enough, right? :) Actually it was a practical and easy way to learn the Django project, and the result is pretty neat. Feel free to download it, play with it, and give me your feedback. Here’s a sample screenshot in Safari:
Creating this project I have had a practical experience comparing both Django and, of course, Rails. The subject is not new in this blog; however, this time I could play with both frameworks and as such, I can bring my small amount of confusion in this big framework tar pit.
Personally, I found Django and Rails much more different than I previously thought. Both frameworks tackle similar problems, sometimes in similar ways; however; but this does not make for a real similarity between both. They have different philosophical approaches to the problem. This must surely have to do with the underlying programming language and their philosophies.
That said, I found Rails much easier to use. It took me far, far less time to do a similar small application in Rails than it took me to do it on Django. And I must say that when I first used Rails, I had never seen a line of Ruby in my life. I will list some pros and cons that I found in the process:
Good things about Django:
- The “automatic administration system”; impressive! (but you can get it in Rails with some external plugins like Streamlined… but in any case it’s a handy thing to have it already in the system!)
- The form subsystem; great!
- Django does not force you a folder layout; nice!
- The Django Book + documentation: really great resources, nothing to say about that.
- The deployment procedure: really much easier than Rails! We’re in something really close to PHP here, while Capistrano has much more to do with Java’s Maven or even makefiles :)
- The native support for RSS feeds! This is a godsend.
Bad things about Django:
- No native support for “environments”, like in Rails; you cannot separate easily the settings for development, testing and production (and you can add more environments if you want!)
- No native support for REST architectures, or at least “easy” AJAX + API support (like the one you find in Rails)
- The “syncdb” system that ships with Django is, at most, primitive, compared to Rails migrations.
There doesn’t seem to be a built-in infrastructure for tests.There is a primitive built-in test infrastructure. You can add “doctests” to your views and models, and this way you’re “documenting and testing” at the same time. Sorry, but I don’t buy this. Tests are tests, docs are docs. Rails, thanks to rakefiles and unit, functional and integration tests,seemsis a much more advanced platform in this sense. You can get even stats of your projects with it! You can test them! Extract the docs! Everything! This is something lacking in Django. Really. Not to speak about the lack in Python of something similar to RSpec, which just by itself justifies the choice of Ruby and Rails in this field.- Lack of integrated logging. Can you believe this? I had to find an external source of inspiration for this.
- The naming of “Views” for “Controllers” (or said otherwise, the MTV instead of MVC thing) does not make sense to me. Even in WebObjects and Cocoa “views” are, well, “views”…
- The commands for creating, starting or using an application from the command line are slightly harder to remember (or maybe in Rails are just far too easy to remember!)
- The template system; I do not want to learn another language for that. Django uses a really limited one for this matter, and I prefer Rails’ (default) one in this case.
- Finally, Python; I just can’t get used to this language’s syntax. But I can live with that ;) It’s a matter of personal taste, simply.
Of course, these impressions have nothing to do with the power of the platform! Python is a powerful language, and many of the “newbie” observations above have to do with my own lack of knowledge about it. But first impressions count!
In any case, I liked playing with Django & Python; I’m happy to have learnt something new!
20 Comments
#1. Alcides Fonseca 01.12.2008
What about implementing OpenID in you blog system? And trackbacks? It would be nice to adopt it then :)
#2. adrian 01.12.2008
Be my guest! The code is open for anyone who wants to build on top of it :) The good thing of Django (and Rails, for that matter) is that such a change would not take long to be done.
#3. SmileyChris 01.19.2008
Good comparison. Only disagreement is that I don’t have a problem with the Django test infrastructure [1]. You don’t *have* to use doctests if you don’t like them ;)
[1] http://www.djangoproject.com/documentation/testing/
#4. adrian 01.19.2008
Thank you for your comment SmileyChris :) and for the link too! Indeed I had seen it but, then again, from everything in Django, is not what I liked most, that’s all :) In any case, this is a really strong platform to build upon.
#5. Batiste Bieler 01.19.2008
First I have take a look at your code. Good job. Just one thing : your PostManager class don’t have to be so complicated. You better have to use something like this : http://www.djangoproject.com/documentation/model-api/#modifying-initial-manager-querysets
I will do some comments on you good/bas comparaison is the next comment.
#6. Batiste Bieler 01.19.2008
Good things : The last I checked streamlined it was so broken that can’t even make it work with firefox. I don’t know if it’s better now but at the time, it was not something that i will never use in any ways.
Bad things : No native support for “environments” : it’s not like it’s rocked science. You can easily get something approching wich a couple lines in settings.py
Tests : If the Django testing framwork is not enough, python as huge amount of testing framework all over the place. For my part I find that the testing client is well done. I have developed complex login process with it without have to open any browser at all.
Lack of integrated logging : its maybe because python has a powerfull login module. I don’t see point into integrating a loggin system into Django if the language provide a good one.
The naming of “Views” for “Controllers” : Fisrt MVC is more a buzword than anything. Secondly MVC is a lame naming convention. If you look at the definition here : http://en.wikipedia.org/wiki/Model_view_controller you can see that anything that have 3 tier can be called MVC. What is the role of the controller ? What is the role of the model. It’s not clear at all and depend if your are in web development or in desktop development.
The template system : It’s true that there is an overhead in learning a new language for this task. But there is other avantages if you work in a big team. The designer doesn’t have to learn python for example. And there a lot less security problem (for example if you give me access to you ruby templates I can steal your entire application code). Secondly, the language is not as simple as you think and enforce to do things in a DRY style that is always the same across projects.
Finally, Python : Its always a matter of taste in anything :).
#7. Batiste Bieler 01.19.2008
My first advice was not right, I will do something more like this:
Post
…
@class_method
def get_by_date_and_slug(self, date, slug):
return Post.objects.filter(date=date, slug=slug)
So you can always add additional filters if you want: Post.get_by_date_and_slug(.., ..).order_by(’-date’).exclude(id=239)
#8. adrian 01.19.2008
Thanks!!!! :)
#9. adrian 01.20.2008
@Batiste: “The naming of ‘Views’ for ‘Controllers’ : Fisrt MVC is more a buzword than anything”. I do not agree. I stick to the original Smalltalk-80 definition of MVC:
“The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application.” (Burbeck, link above)
This pattern has then been adapted into Objective-C (which is an extension to C with a Smalltalk-like message dispatcher runtime), both into NeXTSTEP and Cocoa, then used again in NeXT’s WebObjects and finally into Ruby on Rails. It’s not a buzzword, but a certainly misused concept, which is my opinion about Django, actually, but also about ASP.NET, by the way. Look at any “quick’n dirty” VB application (or .NET for that matter) and compare it to the same quick’n dirty Cocoa one. The Cocoa one will be the most evolutive, flexible and easy to understand of both, just because there is a clear separation between these layers. And yes, naming matters.
The most successful architectural pattern of all time has suffered from its own success. Given the relative youth of our craft, I stick with the most relevant bits of computer history for some definitions, like in this case. Even if I admit that a good 3-tier architecture looks really like a scaled-up MVC app ;)
#10. adrian 01.20.2008
@Batiste (about templates): “The designer doesn’t have to learn python for example.”
Yesss… but they still have to learn *that* template language :) Will they?
“And there a lot less security problem (for example if you give me access to you ruby templates I can steal your entire application code).”
What? Make them sign an NDA in that case!! If you don’t trust the people you work with, well, don’t work with them in the first place! :)))
#11. adrian 01.20.2008
@Batiste (again, but this time about the logging system): “Lack of integrated logging : its maybe because python has a powerfull login module. I don’t see point into integrating a loggin system into Django if the language provide a good one.”
Rails’ logger is Ruby’s one, and that hasn’t stopped DHH to explicitly turn it on in the framework. See? This is one of the incoherencies I find in the Python world. First they tell you that “the Python way” prefers explicit things rather than implicit, and then you want to use logging, you have to implicitly know that Python has a logging system. Thanks, so what? It’s obvious that you want logging turned on during development and debugging, this is 2007. Just turn it on.
It’s like when you type “exit” or “quit” on the Python interpreter and it answers you with “Use exit() or Ctrl-D (i.e. EOF) to exit”. Please pay attention: the interpreter does not say “NameError: name ‘exit’ is not defined”! IT POSITIVELY KNOWS that you want to exit the interpreter! Then WHY DON’T YOU JUST EXIT INSTEAD OF TEACHING ME! This kind of stuff really puts me off.
#12. adrian 01.20.2008
@Batiste: thanks for the “@class_method” thing about the Post class; I was actually looking how to do that :)
#13. Batiste Bieler 01.20.2008
@adrian
http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
“Smalltalk-80 presents the appearance that control resides in the mouse. As one moves and clicks the mouse, the objects on the Smalltalk-80 screen perform much as an orchestra obeying its conductor”
When I started to read the controller role I get very confused. Certainly this document is the root of a lot of good thing and make sense in desktop development but, for me, it seems that this naming convention has been abused to many times. MVC is a very general concept and must not be taken as the holy graal for naming a 3 tier web app.
ROR and Django have exactly the same layout. Maybe it’s just that the Django guys found that the MVC naming convention sucks and choiced another one.
Qt guys also thougt that MVC is not the silver bullet for their framework : http://doc.trolltech.com/4.0/model-view-programming.html
“Rails’ logger is Ruby’s one, and that hasn’t stopped DHH to explicitly turn it on in the framework. See?”
What do you call explicit is not explicit for me. If you have to know that the framework imported the logging module for you I will call it implicit or maybe convention. In python you more like you have to import implicitly any thing you want use.
“It’s like when you type “exit” or “quit” on the Python interpreter”
So, The interpreter tells you that its not the right way to do it. You are not interested to use the right command and learn a little more about the language? It think it’s valuable to know how to quit a programm correctly.
Claming that python/Django are not explicit will means that python creator had completly failed his mission because it’s on of the most fondamental principle of the language : >>> import this
“Yesss… but they still have to learn *that* template language :) Will they?”
Obviously yes.
“What? Make them sign an NDA in that case!! If you don’t trust the people you work with, well, don’t work with them in the first place! :)))”
I completly agree. But maybe you want to open template editing to someone that is not trusted at all, for exemple the site users (my space)… But this feature let a lot of others unresolved security problems open…
#14. adrian 01.20.2008
“So, The interpreter tells you that its not the right way to do it. You are not interested to use the right command and learn a little more about the language? It think it’s valuable to know how to quit a programm correctly.”
Oh, come on, gimme a break. This is about standards, my friend. If these guys like to reinvent the wheel, I do not. Again, it’s a matter of taste, but in *other* technology stacks, we lose more time discussing about *our* apps’ functionality rather than the underlying frameworks inconsistencies.
#15. Batiste Bieler 01.20.2008
More interesting stuff about MVC and the Web:
http://c2.com/cgi/wiki?WhatsaControllerAnyway
http://wardley.org/computers/web/mvc.html
http://www2.jeffcroft.com/blog/2007/jan/11/django-and-mtv/#c20446
#16. Yoan 01.20.2008
@Adrian:
“It’s like when you type “exit” or “quit” on the Python interpreter and it answers you with “Use exit() or Ctrl-D (i.e. EOF) to exit”. Please pay attention: the interpreter does not say “NameError: name ‘exit’ is not defined”! [...] This kind of stuff really puts me off.”
$ irb
> def quit; puts “quit”; end; quit
Fail!
If you don’t like Ctrl+D, use:
>>> import sys; sys.exit()
About MVC and MTV discussion, does MVC fits a web application that well (all CRUD views apart)?
Weel fed troll anyway ;-)
#17. Batiste Bieler 01.20.2008
@Yoan: Yes we feed the troll but I have nothing better to do :-)
“About MVC and MTV discussion, does MVC fits a web application that well”
I would say not at all according the definition in the orginal document. The definition as been distorded since. I think I have found a document that explain that a controller could generate HTML :
http://www.jcorporate.com/expresso/doc/edg/edg_WhatIsMVC.html
But this document sounds like a bad joke to me.
#18. Olivier 03.02.2008
I hate django’s templating engine as much as I hate all the templating engines out there, no matter the language. This is the only reason why I think that php still has an advantage over advanced language for web developpment.
But there *is* a solution: the brevé templating engine http://breve.twisty-industries.com/. This is a pure python templating engine. No need to learn any new templating engine. It is a very clever solution, in my opinion.
#19. fred 03.31.2008
Have I missed anythng, only… How do you login to the admin???
#20. Adrian 03.31.2008
You must go to the Django administrative console, as explained here: http://www.djangoproject.com/documentation/tutorial02/ (you should go to http://127.0.0.1:8000/admin/ after launching the Django application). Have fun!
Commenting