Django’s Flaws
This is a response to Brandon Taylor. It was a bit lengthy, so I thought a post would be better off.
Like you, I felt this "poor" design pain from Rails. The less then spectacular docs (although that's changing too) made me prefer Django over it.
With that being said, the settings.py of Django is a crutch. There's quite a bit of needless configuration: You need to set template directories, installed apps, etc. While that's less than Java, why can't there be some reasonable defaults? Make template point to a local 'templates' subdirectory; default directory for media files; default to sqlite3 database config; time-zone defaulting to your computer's time settings; etc.
No migrations. Sure there are third party apps, but an official version would be nice. Most projects would be greatly aided by such a feature.
Django's reverse URL lookup system is a pain. Besides the fact that the {%url%} is usually long with all the parameters (imagine a date-based a blog post URL). get_absolute_url in models seem dirty and hackish, but it's a lot shorter. Rails' routes provides this style of url referencing (by model instance).
Why isn't there JavaScript integration with Django? Sure you can say it provides free choice, but that's why Rails has an advantage: it's not using the best javascript framework, in my opinion, but something is better than nothing. It's far easier to write simple javascript code through Rails then it is in Django.
Related to the JavaScript issue is the templating problem. A view function usually only directs to one template. How would one support themes? What about different templates based on the incoming client? This has to be manually handled by custom-view code. Rails' render_to dispatcher in the controller makes this a lot easier.
No doubt Django's admin is awesome; however, it's more towards data entry and site admin (hence the name) but not regular usage -- it's not designed for web apps which have users "managing" their own content: for that you want to create a polished experience for the end user. Validations for both frameworks are done through the model.
Recently, the admin interface has gotten a lot more extensible, but it's still designed for the site admin in mind. While Rails' scaffolding isn't great, it's closer toward user-generated content, you're improving the design on behalf of the end user going to see it. Writing HTML isn't fun -- for me at least.
If you like the argument from more of a Djangoist, I'll refer you to one of the creator's of Django.
http://simonwillison.net/2009/May/19/djng/
I've shared many of his pain points.
But Django's documentation is second to none in comparison to any open source project. Django's querying system through models is also great in comparison to Rails. Rails 3 intends to copy Django on that respect.
The merb probably slowed the progress of Rails in the recent years.
It’s been quite quiet…
I'll apologize for my recent lack of updates. I would cite my personal health as a reason, but there's a better excuse 
I'm working hard my next tutorial/article which focuses on JavaScript and like the Django Tutorial, it's geared towards new-comers in the field. I feel that good "where do I start?" guides are often missing on the internet. Not to refute the great resources the web has out there, but snippets of tips and advice are not great ways to gain. I recall learning almost everything I know about photoshop from a massive article online about the common editing techniques (unfortunately, I can no longer find it anymore).
Unfortunately, this also partially conflicts with a personal agenda to record details of a framework/language. I find these resource "dumps" a great resource when I need to relearn the material again from lack of use.
Although I'm still writing it, I intend on start releasing portions of the article in bite-sized chunks. So stay tuned!
In the meantime, here's the table of contents as of now (currently ~50 pages):
Table of Contents
- Introduction
- About the Author
- Table of Contents
- What is JavaScript?
- Using JavaScript
- Script Tag
- Variables
- Operations
- Conversion
- Special Values
- Branching (Conditionals)
- If Statement
- More Expressions
- && || Oddity
- Single-Statement IF
- Elses, Else If's statements
- Ternary Operator
- Repetition (Loops)
- While (death do us part)
- For
- Global Scope
- Functions
- Parameters
- Returning Values
- Scoping
- Anonymous Functions
- Arrays
- Objects
- DOM Tree
- What is it?
- Manually Navigating the Tree
- Manipulating the Tree
- Window Object
- Events & Handling
- Attaching Code to Events
- Capturing & Bubbling
- Event Object
- Browser Specificity
- Stopping Event Propagation
- Removing Attached Events
- Utility Functions
- Math
- Strings
- Regular Expressions
- What are Regular Expressions?
- Constructors
- Using Regular Expressions
- Timeouts & Intervals
- Advanced Topics
- Apply This Call (ordered for pun)
- Optional parameters
- Undefined Parameters
- Variable Parameter Length
- Object-based Optional Parameters
- Trying and Catching
- DOM Ready Event
- Namespaces
- Ajax
- What is it?
- Pros & Cons
- XMLHttpRequest
- XML / HTML data
- Json Data
- Objects Revisited
- Static Classes
- Instanciated Classes
- Mixed (Static & Instanciated Classes)
- Inheritance with Prototypes
- Combining It All
- Wrapping it up
- Conclusions
- Where to go from here
NoteMe and Lessons Learned
As displayed in my AIR post before, I was working on my note taking application: NoteMe, but I’ve already been learning too much that stifled my development. Adobe AIR is a great framework, but I’ve also realized how little I know about web encryption/security. I don’t really understand about digital signing and certificates. Unfortunately, certificates cost, which isn’t something I prefer to dish out for a simple test app like this.
Before I get on with the learning experience, here’s the download (and source). As a warning, the source code is a bit disorganized since I was still learning AIR as I developed it.
It still has a relatively crappy interface as well. I hope to rewrite the application entirely, especially the note editor portion using canvas. Currently I’m using iframes, but AIR has a flawed iframe with no undo/redo support. I’m not sure why it was excluded, unless it wasn’t functionality part of webkit.
Furthermore, there is a bigger problem. I’ve come to the conclusion that jQuery isn’t quite the best for developing large javascript-based applications. It’s very nice and concise for the small amount of javascript here and there, but jQuery code isn’t particularly too clear. This seems more due to my fault for not getting in the habit of commenting my javascript files. In addition, jQuery doesn’t provide a clear guideline for developing large-scale javascript applications. The normal Object Oriented programming in javascript is flawed.
function dog(name){
this.name = name;
this.bark = function(){ alert("woof!"); };
}var snoopy = new dog("Snoopy");
snoopy.bark();
alert(snoopy.name);
This isn’t the most elegant solution when defining classes. The main problem is that methods you define may not always have this equating to the class. This is evident by some jQuery provided functions ($.each, bind, etc.) which alter this in the context of the function. I prefer to avoid this syntax when possible. It’s ugly to program in.
Of course there’s the static class way:
var dogs = {
repos: [],
add: function(dog){
dogs.repos.push(dog);
},
bark: function(){
for(var d in dogs){
d.bark();
}
}
};dogs.add(new dog("Snoopy"));
dogs.bark();
This still isn’t too pretty. Although it’s better than previously. The main problem is if you need to refactor the static class. All code that calls the static class needs to be renamed, including internal calls (see red, highlighted line).
MooTools, Prototype and other JS frameworks provide class behavior with static-class-style definition. Although this represents the class object (removing the need for internal refactoring like regular static classes.
As much as I love jQuery, I may have to look into other frameworks when developing a larger javascript powered application that doesn’t have a few ajax or visual effects. Or I’ll plow through my hatred of function-class definitions. Trying something that generates javascript entirely doesn’t seem like a bad idea either.