midterm project
For my midterm project I wrote a simple web application in both Rails and Django to teach myself these frameworks and compare them. The application was quite simple allowing visitors to register as users with a username and password, log in and out, and edit a single text field blog that could then be viewed by anyone. The project code is available below:
Since cs.marlboro.edu isn't set up to run Rails or Django, the applications aren't actually running here and I haven't gotten a chance to set them up with hosting yet so I've included a few screenshots below to give an idea:
Login screen
Viewing a blog
Editting a blog
Working with web frameworks
I found working with frameworks to be in many ways quite similar to the less structured PHP programming that I am used to. The largest difference was the strict separation of model, view, and controller. Both Django and Rails do good job of organizing code into the these three pieces. In many ways the two frameworks were quite similar but I also found some important differences.
Many of the differences were superficial. For example both frameworks use the term model the same way but in Rails the main code that processes requests is called the controller and the template structure that formats html is called the view. In Django the main code that processes requests is called the view and the templates are called templates. The purpose of these structures however is the identical and in this paper I refer to them using the Rails conventions. There were many other relatively small differences that mostly boiled down to the differences between Python and Ruby.
The largest differences were in overall approach. Rails has convention over configuration as a design concept which can be both powerful and annoying. The idea behind the approach is that if you don't specify something, then some default kicks in based on a naming convention. A good example of this is the way controllers access views in Rails. To render a view from a controller, you can call the 'render' method specifying a view file, or you can just do nothing and rails will by default find a view file to render based on the name of the controller methods and files using a standard rails convention. There are also ways to specify that you want some other sort of http response etc. There is even a script that sets up the files and directory structures for you with the correct conventions so you don't need to remember them. This is powerful because you don't need to worry about details that are always the same. It can also be annoying if you don't know what the default behavior is.
Django used a more configuration based approach. In Django model files, for example, the schema for each database table is fully described by a python class. The database can be generated automatically from these files using a script. These classes are then used to access the database elsewhere in the application. In Rails the model files only describe modifications to the default behavior of the database. In this case the advantage of Rails is a more dynamic description of the model. The advantage of Django is being able to clearly see the structure of the model instance objects that you are using. The difference is still ultimately superficial. In rails if you go a little deeper into the documentation you can see how things work and you have the advantage of a more dynamic system as the default. In Django you can make the system more dynamic if you need to (and it's easy to figure out how) and you have the advantage of a less opaque system by default.
In the end it comes down to preference and application. My preference at this point leans towards Django but if I were actually starting a project it would probably depend more on what libraries/plugins already existed in which language/framework than anything else.