Rails and Django - Framework Concept (part 4/15)

Framework Concept

Conceptually both Rails and Django are very similar, adhering to the model-view-controller architecture. I will not go into details here about MVC, as there are plenty of references not the least of which are the introductory chapters to the Rails and Django documentation and books, and Wikipedia .

However it's important to say that Django is not a Rails clone. And there are quite a few Rails-clones around, in any number of languages. Rather, Django and Rails have important differences both in concept and implementation.

Conceptual Commonality

First, the common ground, very briefly. Both Rails and Django adhere to modern principles of

• Object architecture – use object classes and inheritance to organize and encapsulate data and logic;
• Agile development-- the ability to implement small, incremental changes and features quickly; agile development encourages collaboration;
• DRY – stands for “don't repeat yourself,” create reusable snippets of code rather than duplication via copy/paste.

Both projects agree that a framework should provide:

• Allow easy modeling of your application's data, and encapsulate the business logic into objects, including responsibility for create, retrieve, update and delete (CRUD) of these objects in a database;
• Map user events (like URL requests from a browser) to application code that accesses the model and generates a response (view) back to the user's browser;
• Use a separate templating system to define how data is presented to the user, whether html+css layouts and styles, or some other data formats (XML).

In addition, both projects agree that the framework should:

• Support test-driven development
• Support generated documentation
• Support community driven enhancements

Both frameworks provide:

• Scripts for creating a new project with default files
• An embedded web server for development
• more...

Conceptual Differences

Rails

Rails promotes the idea of “opinionated software” and “convention over configuration”, where the system automatically builds and fits the initial pieces together for you. Then you can accept these reasonable defaults or modify/add just what is necessary, incrementally, as you build your application.

Rails also advocates “constraints are liberating”. For example, the directory layout is well defined and your application must conform to this convention. The idea is that when decisions like these are made for you, then you as a developer do not have to spend precious brain cycles making these basic decisions, and can focus instead on what's really important-- designing and implementing your website. It also facilitates team collaboration because new players will more readily know, for example, where to find files and know what they do based on their names.

Another example is naming conventions like automatic pluralization. Let's say your site manages products-- in Rails, your database table is named with the plural “Products”, and your object class is singular, “Product”. Rails handles the pluralization/ singularization automatically. This is handy and makes things more intuitive as you construct your application, as long as you know to expect it. Of course, you can override these defaults if needed.

One more example is AJAX support. Rails has standardized on a common AJAX library, provides conventions for server side scripting (.rjs files), and allows you to integrate AJAX into your apps while programming in the Ruby language and not even see the Javascript.

In this way, Rails takes pride that many things are done “auto-magically”. In Rails, like in life, fun is magical, and magic is fun!

Django

One of the driving principles behind Django is “loose coupling”, where each aspect of the framework tries to remain independent of the others. While all the pieces work together in tandem, they are not dependent upon each other. This makes it possible, in most cases, to substitute alternative components if desired or necessary. More important, it forces a discipline of clean orthogonal architecture.

For example, URL routing is completely decoupled from the view methods that get called.
Another example is how Django does not require you adhere to a strict directory structure. They suggest a file organization (as built with the manage.py script, but you can put and move things wherever you need or desire.

Django prefers transparency over “magic”. In 2006 the project underwent a refactoring (rewrite) where implicit features were removed. This was blatantly referred to as “magic-removal” (for a complete list of changes in that effort see http://code.djangoproject.com/wiki/RemovingTheMagic). For example, Django, like Rails, originally had automatic pluralization, but this was taken out.

With regard to AJAX, Django intentionally does not encapsulate AJAX into its framework. Rather, it provides support for AJAX in how data is passed between server and client (serialization), but lets you choose any of the dozens of good AJAX toolkits available. More loose coupling and being explicit.

Despite what I said earlier about both Rails and Django being MVC (model-view-controller) architectures, Django prefers the MTV acronym -- model-template-view. That is, Rails controller classes are equivalent to views in Django, and Rails views are what Django simply calls templates.

Opinion

"Any sufficiently advanced technology looks like magic" – A. C. Clarke

Or,

ma·gi·cian -- [muh-jish-uhn] -- an entertainer who is skilled in producing illusion by sleight of hand, deceptive devices, etc.; conjurer. (Dictionary.com).

I really appreciate Rails' efforts to take care of the busy work for me, and to encapsulate complexity (like Javascript) that I'd really rather not have to do myself if I don't have to (provided I can get under the hood when necessary). In fact, that's a great way to get going quickly and learn how things work at the same time.

On the other hand, I really appreciate Django's efforts to keep everything clean, decoupled, and transparent. That helps keep the guess work out of programming. It probably also helps with debugging, where questions like “is the problem something I wrote, or just how I'm using the framework?” might be easier to discern in Django.

So perhaps the tide shifts depending whether you put more weight on efficient development versus efficient debugging / maintenance. (I may be extremely wrong about this, it's just a hunch).

I've heard Rails-skeptics caution that the framework could (will) become bloated in a few years (bloated means big, slow, clunky), likened to the enthusiasm Php experienced in the 1990's.

Django may require me to learn web technology more deeply to use the framework effectively. This is probably a good thing, we all should know our craft. Then again, we can't all be expected to know everything, and still get work done. Hmm...

OK, I'm going to get killed for this one-- Rails reminds me more of Windows. Django reminds me of Linux. Sure both are open-source, I'm not talking about that. But Windows took an early emphasis as “the any-man's operating system”, magically hiding a lot of technical details, that's great for many people, and very frustrating for others. Likewise, Linux is composed of many loosely coupled components, is very transparent, is lean, reliable, and frustrates the heck out of normal people. Maybe one day we'll get the “OSX of Frameworks” which marries the best of both? :)

A few words about this rating: Unlike most of the other criteria, my rating here is much more a gut feel than a technical or quantitative assessment. I simply wanted to give Django a higher score for the reasons cited above. From the beginning, I decided not to do fractional values. And I couldn't justify giving either a score of 5, since there's always room for improvement and new concepts will emerge that build on current experience.