Hypothetical framework choices

An entry published by James Bennett on June 2, 2007, Part of the categories Django and Frameworks. Six comments posted.

I subscribe to feeds of items tagged with “django” on a couple of sites, and tonight I noticed a link which posed a hypothetical situation of wanting to port a large J2EE application to either Rails or Django, and asking about making the choice between them.

I wrote up a reply, but attempts to post it there netted me “The page you were looking for was not found. Moron.” So here it is in all its glory; maybe someone will get some use out of it, maybe not.

Choose wisely

As always: it depends.

Some good hypothetical questions to ask in this hypothetical situation:

Does anyone on the team already have good working knowledge of Ruby or Python? And by “good working knowledge” I mean not just syntax, but standard libraries, third-party ecosystem, etc. You need to know up-front what the language already has and what you’ll need to write on your own.
How willing are team members to adapt to a dynamic language and the accompanying set of programming idioms? Some God-awful things have been foisted on the world by people who just straight ported Java code without wondering whether the target language could express the same intent in a more effective way.
Do you have the ability and willingness to make any necessary infrastructure changes? Rails and Django both rely heavily on a shared-nothing architecture and scale out rather than up, which can involve some serious changes when coming from J2EE. Standard deployment is also different and multiple “standards” exist — Python, for example, prefers either mod_python or WSGI, while Ruby prefers FastCGI, SCGI or (increasingly) proxying to Mongrel.
What assumptions from Java need to be thrown out or reconsidered when transitioning? Threading, for example, is nowhere near as ubiquitous in Ruby or Python, and programmers fluent in those languages seem, on average, to be much more skeptical of threading as a concurrency model. The “application” itself is also somewhat different, and generally far more tightly focused on request/response cycles with a very different concept of persistent state between requests.
What other systems will the application have to interact with, and what expectations do those systems have? Most J2EE applications don’t exist in a vacuum, so you need to plan ahead for how you’ll handle communication with legacy components. Additionally, Ruby and Python can certainly do SOAP, XML-RPC, etc., but the code to handle them tends to look unnatural — “everything happens by passing XML documents around” is not the preferred idiom of either language.

That’s just for starters, but hopefully it’s an indication of a more productive line of questioning for choosing a framework (and remember that there are more things out there than just Rails and Django — Ruby and Python both have a variety of frameworks available).

Disclaimer: I’m the release manager for Django and work for the company which originally developed it.

← django-registration update Hacking comments without hacking comments →

On June 2, 2007, Jacob Kaplan-Moss said:

Great points, James.

I think far too often people ignore these types of considerations — especially the first. It boggles my mind to think of a team choosing a tool because it’s “cool” or “trendy”, but it happens all the time.

Our goal as developers should be to pick the best tool for the job, not the one with the most buzz behind it.

On June 2, 2007, Nicola Larosa said:

Threading, for example, is nowhere near as ubiquitous in Ruby or Python, and programmers fluent in those languages seem, on average, to be much more skeptical of threading as a concurrency model.

It would be great if that would actually be the case for Python.

There’s definitely some sensibility for alternative approaches, as testified by Twisted and all the budding coroutine-style approaches, but threading is unfortunately still prevalent.

It would also be great if preemptive multithreading would be evicted from Python 3000, but I know, same chance as snow in hell.

On June 2, 2007, Stefane Fermigier said:

Not everything that has been written about Python / Ruby against Java (including stuff that I have written myself in the past) holds true in the face of medium to large projects (> 100 kloc).

Here is a counter-example: We had a 300 kloc application written in Python/Zope. We have rewritten it into a 150 kloc Java EE application leveraging existing Java EE libraries and frameworks (Jackrabbit, JBoss Seam, Hibernate…). We have more unit tests than we had before, and we can leverage static code analysis tools (the Java compiler, IDEA, Checkstyle, FindBugs, TPTP…) to ensure higher code quality.

On June 4, 2007, Mike Simoens said:

The “The page you were looking for was not found. Moron.” error seems to have something to do with their system not handling yer fancy dancy characters like: ’ “ and —.

I pasted a link to your reply there and a then I plagiarized you a little too. Hope you don’t mind.

I think Python and Django deserve to see a little more of the “hey this is easier than Java!” hype that seems to be reserved for Ruby and Rails.

On June 6, 2007, Ludvig Ericson said:

It would be great if that would actually be the case for Python.

There’s definitely some sensibility for alternative approaches, as testified by Twisted and all the budding coroutine-style approaches, but threading is unfortunately still prevalent.

It would also be great if preemptive multithreading would be evicted from Python 3000, but I know, same chance as snow in hell.

Python’s threading is awkward, to say the least.

On June 11, 2007, Nick said:

2Ludvig Ericson:

Have you tried Stackless Python? http://stackless.com

It has great lightweight threading model - “green threads”, so you can have millions of concurrent threads on usual PC.

Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.