Two Weeks With Django. A Rails developer tries Django but ends up switching back to Rails. I think we could definitely take some steps towards making the initial user experience a bit smoother—currently you have to decide things like how you’ll serve static files and where you’ll keep your templates. Once you’ve got that lot set up it’s mostly plain sailing but it does mean there’s a bit of a bump in the learning curve.
Sign in with 
OpenID
I totally agree, there's a lot of beauty in Django but there are so many frustrating spots where they could do convention over configuration.
Demian Neidetcher - 15th October 2007 23:30 - #
I read the same post a couple of days ago and had the same thoughts. Was kinda my inspiration behind http://code.djangoproject.com/ticket/5742.
Perhaps Django would benefit from a document explaining all the parts of Django as a "10000 feet" overview.
I think probably the biggest obstacle for understanding django right now comes from newforms. There just isn't enough documentation showing how to use it, how to create crud type views with and get going with it.
I know that people have been holding off on documenting it because it's in flux. But if it's going to be in flux for this long maybe there should be some documentation thrown up that at least gets users started.
Anders Conbere - 16th October 2007 00:00 - #
SmileyChris: I'd actually go a step further and suggest that the django-admin.py wizards should create templates/ and static/ directories which are pre-configured. It's not a trivial change though as there's the question of whether static/ and templates/ should belong to applications, projects or both.
I think one of the problems is he was trying to learn Django without learning Python. I think one of the problem or good things with Ruby on Rails is that you don't have to learn Ruby to use it.
And migrations are so much easier in Rails than Django. There have been so many attempts at implementing schema evolution in Django but never finished properly.
@Simon
"it's not a trivial change though as there's the question of whether static/ and templates/ should belong to applications"
Ah, but by convention, apps generally use the app template loader (app_name/templates) and include the app name in the template expression (e.g. admin/base.html).
There's the issue of different apps with the same name, but that's been there all along.
I suspect an app name registry would be useful, just to avoid collisions.
----
@Harish: it's a worthy goal, but a hard problem, given the model definition approach taken by Django. ...But my db_upgrade.py is about 100 lines of code, including exception handling, and took a couple hours to write and test.
Jeremy Dunck - 16th October 2007 05:27 - #
There are a lot of little inconsistencies that make django frustrating to learn.
One of my example is blank/null attributes in model fields whereas form fields have required attributes. Basically it's the same idea behind but you have to learn it twice because it is not intuitive.
I guess it is a question of maturity and things are going to be harmonized soon.
Grégoire Cachet - 16th October 2007 10:32 - #
The learning curve is definitely steeper than with Rails, but this is not the most important thing. In my day, it was a given that learning any new language or framework would be difficult. I agree that newforms is the main culprit. Some more documentation there would solve a lot of frustration for beginners.
James - 16th October 2007 11:22 - #
No offense to John Taber, but if that's all he could get working after two weeks, he probably needs to give up programming.
Case in point, serving static media via the development server is *trivial*, and finding the document that explains how to do it is found by site-searching for "serving static media".
To be fair to him, though, Django documentation is probably not for the layman.
doug.
Doug Van Horn - 16th October 2007 19:34 - #
I found that strange. I'm a 2nd year undergraduate student, and I gave Django a go, with no prior knowledge of Python. And I got Django going pretty nicely, used it for a school project Got an A+ too :D ). Regular expressions were pretty easy to come to grips with, really.
I suppose its where you're coming from. If you're coming from a blank slate like me, maybe its a tad easier, but if you're coming with a set way of doing things, then maybe it takes a bit of pattering around.
Currently working on another school project which requires PHP. I recreated a simple version of Django's URL pattern system, regular expressions mapped to function names in an array and all :). Its working out quite nicely!
Mario - 17th October 2007 00:09 - #
I am coming to the end of a (for me) major site done in Django -- about 300 articles, 100's of videos, audios, q&a's, complicated nav structure (read: the designer got clever), etc. This was my first Django site and my first substantial use of Python.
All things considered, it went amazingly well .... but, there were a number of things that were non-obvious. Some of them (e.g. static files) were not too difficult to figure out, but the fact is that I *did* have to "figure it out" instead of just having it work.
The null=True, blank=True thing is really irritating. I understand the explanation for why it's that way, but the fact is it has snagged me a few times.
Mind you, I am not someone fresh out of school -- I have been programming professionally for 34 years and I have lost track of the number of languages/environments I have worked in. I would give Python a 9.5 and Django a 9.something for usability, but that doesn't make either of them a 10.
I have had to get clever to work around the one-database limitation, I have had to add a number of tags to get the template system to do things that should have been baked in (and even then I ran into some limitations involving recursive templates, argument passing, and such like), and the way people suggest extending user/userprofile is just a mess.
And, yes, the newforms will be nice .... some day. Ultimately we couldn't use them, partly because of where they are in their development cycle but also because of the state of the docs --probably the weakest part of all the Django docs. How about some good, solid examples that aren't too kludgy?
Grumbling aside, I have genuinely enjoyed working in Django. I am already in the design stage
for my next major site and it is being done in Django.
As soon as we hit launch and I can catch my breath I have a number of changes I would like to submit.
Peter Rowell - 17th October 2007 06:16 - #
I got a first django project working into 2 weeks too with complex models. It was at the prototype stage though, but you can do things.
I had some basic knowledge on Python but I needed to read the doc for almost every single function at first.
The conclusion was : I lost a lot of time on tiny little things that need to be polished and I had to hack things in the SVN version to get my stuff done, but Django does a pretty good job on the whole.
Grégoire Cachet - 18th October 2007 21:10 - #
I was rather put off by this series of posts.
Perhaps non-programmers appreciate the hand-holding that convention affords them, but as someone who builds a lot of websites and wants to do it fast -- they get in the way. Having the guidance is fine for "most cases" as Rails is designed for, but there comes a point when you're asked to design something that steps outside the bounds of established conventions.
Django stays out of my way. It remains "Pythonic;" relying on the design patterns and style guides established by the Python community. The framework remains modular and unobtrusive as a set of Python modules that I am free to pick and choose from. No conventions to over-ride and document.
Django gives you enough to get going and leaves the rest up to you as the respectable and knowledgeable developer. It doesn't hold your hand or get in your way. I think it should stay that way and not be swayed by these "Rails developer tries X for a week" posts.
As for directory structures -- I despise the Rails convention. Django gives the "batteries included" approach; suggesting a sane set of defaults, but isn't restricted to them. Rails isn't either, but it takes a little work to get over the convention, which shouldn't be necessary in the first place. Django is pythonic.. just change your import statements and structure your app any way you like -- it is after all, just another python module...
James - 22nd October 2007 18:37 - #