- Introducing Easy Web Site Animation with FACE
- Put a New FACE on Your Web Site
- Advanced Uses of FACE
- Help! I’m FACE-ing problems!: Troubleshooting FACE
- Other Uses and Implementations of FACE
- Prototype, Dojo, and jQuery
- Django and Ruby on Rails
- Delving Deeper Into Django
- Andy Clarke
- Kris Hadlock
- Robert Hoekman, Jr.
- Molly Holzschlag
- Sarah Horton
- Miraz Jordan
- Jonathan and Lisa Price
- Catherine Seda
- Dave Shea
- Dave Taylor
- Faruk Ateş
Table of Contents
- Web Basics
- Publishing on the Web: Putting Files on the Server
- Web Design Process and Workflow
- Project Management
- Mark My WWWord: HTML and XHTML
- Standards Compliance
- Meta Tags and Search
- Enhancing Web Page Interaction
- Web Graphics
- Web Page Optimization
- Overview of Servers
- Server Programming Basics
- Careers in Web Design
- Intellectual Property for Web Designers
Django and Ruby on Rails
Last updated Oct 17, 2003.
By Faruk Ates
We've long since said goodbye to the days of creating Web sites purely as static HTML files on a Web server; these days, even relatively small and simple Web sites are most commonly made with a programmed back-end. Just as the front-end world has changed in recent years with the increasing popularity of frameworks, so too has the back-end world.
Two open-source MVC frameworks that have been getting increasingly popular ever since their release to the public are Django—a Python-powered Web framework—and Ruby on Rails, which, as the name implies, runs on Ruby.
Both Django and Ruby on Rails are MVC frameworks, which stands for Model-View-Controller. But what does that mean, and how does it affect you as a developer?
Without getting too technical about it, MVC roughly works as follows: the model component contains domain-specific logic, including things like database configuration and connection. The view component renders the model into an interface, which, in the case of a Web framework, would be the HTML (and CSS). The controller component controls events such as user interaction. A typical MVC framework will take care of a lot, if not all, of the grunt work in building an application.
As a developer, this architecture enables you to write code more quickly and efficiently. By separating the three components, when you make a change to one, it only minimally impacts the other two, allowing you to focus on writing new functionality.
Ruby on Rails is a very close follower of the MVC architecture, but Django is only loosely based on it. The creators of Django explain their interpretation of the MVC architecture in the documentation, though it's mostly a different perspective on the words and their meaning in the architecture.
Ruby on Rails
Rails is based on two core principles: Don't Repeat Yourself (DRY) and "convention over configuration." DRY states that definitions should only be written once, and convention over configuration means that the only configurations a programmer should write are the unconventional ones.
This is reflected in the base idea of how a Rails-powered Web site is built: You start by planning out your database schema, creating the tables and columns you need for your data. Rails will then detect all necessary object data (objects being rows of data in your database, in this context) on its own.
Next, you build your Controller to map request (such as mysite.com/blog/) to certain actions. One of the actions you'll use a lot is the so-called scaffolding action, which is Rails's built-in functionality to allow you to easily perform data manipulation.
You can map actions in a Controller to template files, and this applies to scaffolding too. This lets you cleanly separate your programming code and your HTML markup. Rails templates are run in a full Ruby environment, meaning you can just put Ruby code in there if you'd like. At the very least, you'll be using Ruby in your templates to put the data from your database amidst your markup.
If you build your application or Web site from the ground up for Rails, the "convention over configuration" philosophy it adopts will save you a lot of work. You won't have to configure anything beyond the actions needed for your Web site, letting you focus on the most fun parts of building Web sites.
What you might have noticed is that there is very little coding involved in creating something that's already fully functional. The premise of both of these frameworks is that your time spent on programming is brought down to the absolute bare minimum, and both do a terrific job at that.
Ruby on Rails is available on all platforms, and the download page offers instructions for all of them, including how to fix the broken Ruby that ships with Mac OS X. Fortunately, Apple has announced that the next release of its operating system, Mac OS X Leopard, will ship with Ruby on Rails pre-installed, so that issue will soon be no more.
Where Ruby on Rails was extracted from a Web application, Django was born in a newsroom environment and was originally created by Adrian Holovaty and Simon Willison. Fittingly, Django presents itself as, "The Web framework for perfectionists with deadlines."
Django has many founding principles, including Don't Repeat Yourself and the encouragement of best practices. For a full overview, check out the site's design philosophies page.
The creation process in Django differs slightly from Rails. Rather than having the system deduct information on its own from your database model, you create the model in Django—in a very straight-forward models.py file—and Django will then create the database tables and columns for you. The biggest benefit in that approach is that applications in Django are stand-alone and fully plug-and-play. As the database model for an app—such as a blog or a polls system—is contained within the app, you can just plug that app into any Django project and it'll work straight away.
As previously mentioned, Django has a slightly different interpretation of the MVC framework principles. In Django, you map certain URLs—or to be more precise, certain page requests—to a view using a URL configuration file. The associated view contains the code that needs to be executed and references a template for the presentation of that code. That template can be any text-based format, be it HTML, RSS, XML or something else entirely.
One of Django's most appealing features is its built-in admin interface. When you've specified your model, chances are good that you'll want a Web-based interface for either yourself or your client (or the newsroom editors) to manage all that data in the database. The built-in admin interface, which is fully customizable in both functional and visual design, offers you just that—out of the box. You're not forced to use the built-in admin, but it saves you from having to do all of that monotonous coding yourself.
In contrast with Rails, Django's template system is more robust, but it doesn't allow you to execute any arbitrary python code. This is good from a security perspective and it's easier for designers (who are most likely to be using the template system). It does, however, restrict you a little bit.
At the time of writing, Django hasn't hit 1.0 yet but it's been a very stable, production-ready system for well over a year now. It's already being used for various high-profile sites, such as The Washington Post.
The most notable difference between Django and Ruby on Rails is their origins, which influence their philosophies on Web development, which in turn influence the approach they both take on a technical and practical level.
It should be noted that both of them are moving towards each other in terms of features and approach, which means that at some point in the future, your choice may come down to whether you prefer Python or Ruby as a language and little more. For now, they both have their respective strengths that make them unique and different, but one thing is certain: these Web frameworks can really speed up your development!