ShopFiber

I have been asked by numerous folks why we chose Django for ShopFiber over the alternatives like Ruby on Rails, PHP (Symfony) or ASP (MVC), and what they should be looking for in a framework.  So, here is my answer in hopes that this information will help you make a good choice for your needs.

This is a long post, for the summary scroll to the bottom.

First of all, I believe the main goal of these frameworks is to increase programmer’s productivity.  Productivity is a very subjective topic, so before I fuel the flamewar over which one is better, let me say this: what works for us is not necessarily going to work for you.  My goal for this post is to help your think about the things that you should consider when choosing a framework, and briefly mention the reasons behind our decision.

Underlying language

Depending on your timeline, your familiarity with the underlying language or the language’s general approach is going to play a big role in your selection.  We were open to new languages because a relatively little upfront investment for saving time later was worth it.  I had played around with Ruby on Rails for a few months in the past, but my general conclusion was that it had too much “magic” (plus other issues hinted below).  This was partly because of the language, and partly because of the framework.

Before ShopFiber I used to spend a lot of time on learning new things, and django was a natural progression after my RoR experimentation.  So, I took on the challenge and played around with it.  Surprisingly, django and python felt a lot more natural.  This experience made django a very viable option for us.  Also, python is a very good investment from a programmers perspective because it is much more widely used than Ruby.

In my experience django’s source code has been significantly easier to understand than RoR’s.  I have even been able to inject an SSMTP module into the source because my ISP blocks port 25 and it was easier to use SSL over SMTP with my development host.  Also, this ability to easily understand the source code has saved us time when we wanted to see how django preferred to do things, and when we didn’t understand the documentation completely (code sometimes is easier to understand).

What’s in the box?

You should also pay attention to what is included in the framework. There are several different pieces to this: the basic ORM layer, templating language, additional features, debugging facilities, and monitoring features (once you go to production site).  The ORM layer in RoR and django are fairly comparable, but the two have very different approaches to templates.  Django approached this by creating its own template language, whereas RoR’s templates let you do pretty much anything that you can do in Ruby.  I personally like RoR’s approach, but that is probably because I am programmer and not a designer.  The debugging and monitoring features are also very important because we all make mistakes.  Rails 2.0 has improved its debugging support, but Django has had very good builtin support for debugging (technically, python does: import pdb, pdb.set_trace()) and emailing the state (variables + call stack) both of which have made troubleshooting much easier.

I skipped over the additional builtin features.  Django provides integrated authentication (django.contrib.auth), and the admin interface (please keep reading) that you can get by adding only one additional class per model.  So far we love this interface, it has prevented us from tinkering with the database directly.  In fact for a long time we were able to concentrate on the user’s view of the data because of this functionality.  Similarly, RoR has its own set of builtin features, for instance, the very smooth AJAX integration.   So, you should pay attention to the additional builtin features.  The community goes hand in hand with the additional features so make sure to read the next paragraph.

Community

Pay close attention to the community because a good community is very important.  Right now one of the great things that RoR has going for it is the excellent community that it has built.  Many of the django features (like the admin interface) are available for RoR as plugins.  RoR’s community has also spawned off Capistrano, a great deployment tool, that you can use to automate pretty much any remote operation (including deployment of other framework based applications) across multiple servers.  This is not to say that django’s community isn’t active either, similar to RoR’s community, a lot of the RoR features are available for django (like django-evolution for db updates).  The bigger the community the greater the chance that you will find good prebuilt modules to save you even more time.

Scalability / performance

Lastly, scalability/performance is another topic of great contention, but in most of the situations it should not be considered.  If you are writing an application that is either fairly simple or will not be getting a lot of traffic then don’t spend too much time on this because almost all frameworks out there are fast enough to meet average needs.  In our case this played a small role because we have high hopes in ShopFiber   My research a little while back (when we were making this decision) showed that Django was shining in this aspect, and RoR had some issues when it came to scalability (i.e. more painful than django, e.g. twitter, I know it is a very extreme example).

Conclusion

So, in summary, most of the current frameworks are very comparable.  I would suggest doing simple weekend projects to feel the ones that attract you, and pick one as soon as you find one that fits your needs.  Make sure to at least consider django in your selection.

As you are doing this evaluation pay attention to the following aspects:

1. Familiarity with the underlying language: how easily can you pick up the language?
2. How much magic is involved: generally less magic means shorter learning curve.
3. What is included: how much more productive will it make you?
4. Community: a good community will help you fill in the gaps that the framework has left.
5. Do not pay too much attention to scalability/performance for average sized projects: generally the difference in performance between the frameworks is minimal compared to the gain in productivity.

In the end what matters in the current market is how quickly you can put your ideas in action.  If good old PHP without any frameworks/PEAR and hand coded SQL lets you achieve this goal then that’s what you should be doing!

What do you think?  Do you have anything to add to this list?

If you are interested in ShopFiber then make sure to sign up at http://www.shopfiber.com/, we are almost ready to release the beta (towards the end of this month).  Also, you can follow us on twitter (@shopfiber, @farhanahmad, and @jakelumetta).