Hacker News new | past | comments | ask | show | jobs | submit login
Rails versus Django (superjared.com)
67 points by twampss on Feb 10, 2009 | hide | past | web | favorite | 37 comments



Oh christ on a bike, not another one of these. It's not even well-written - I wish I could downvote this thing just for the giant chunk of writing completely in italics.

Here's my problem with all of these articles with the rails versus django battle-to-find-the-one-right-answer approach rather than rails and django different-arrows-in-the-quiver: they always seem to focus way down at too small a level of detail in their comparisons. I understand that being a programmer means being down in the trenches with the framework every day, so the temptation is to assume the important differences are down at that altitude as well and that's where the focus of any comparison should be. But it's totally wrong - they're just different at that level (not necessarily better or worse) and the important difference is at the higher level of what these tools are good at. And for that, you can look to where they came from to see their overall focus:

Rails -> came from building a web app (Basecamp) -> great for building apps, has to be rejiggered a bit for web sites

Django -> came from building a web site (several newspaper sites in Lawrence, Kansas) -> great for building sites, has to be rejiggered a bit for web apps

The idea for this has been building in my head for a while now and was solidified when I saw the creators of each framework say basically the same thing in a video showdown a few years back:

http://www.djangoproject.com/snakesandrubies/


The best summary I've heard is:

Rails -> If you know Ruby

Django -> If you know Python

I've been using Django for a while now, but the more we evolve our site, the less of Django we are using. Luckily, the separation of concerns thing really does work and we are able to replace components as we need to.


Just in my own experiences at work and with friends, I've found the opposite to be true - people pick up the language to use the framework and haven't met anyone that knew either language before choosing which one to use. Plus both frameworks (especially Rails) have a history of encouraging people to take that route as well.

That also partly explains why I started a Ruby tutorial ages ago and never got around to finishing the series, even though I still get pretty good googlejuice from it:

http://alabut.com/nonsense/2005/03/ruby-self-tutorial-day-1-...


So true.


I actually went the other way around and used both Django and Rails as means to learn (or get deeper) in Python/Ruby languages. Both frameworks do a great work on abstracting bits of the language, which IMHO made it easier to start (I tried getting Python a couple of years before but gave up since I didn't have a good 'hello world' idea to keep me motivated - being able to build some useful web app also helped, when learning along with the framework)


Here's my problem with all of these articles with the rails versus django battle-to-find-the-one-right-answer approach rather than rails and django different-arrows-in-the-quiver

I think the latter is exactly what the article is saying, the title is actually a little misleading.


Re: the web "site"/web "app" split: It would be nice to see someone elaborate on this a bit more, past the "where it came from" bit. In "Snakes and Rubies", I got the impression that dhh just threw that out there, and Adrian didn't really agree or disagree.

Perhaps I can think wishfully of one of them chiming in... ;)


In Rails, it's a bit easier making web apps because AJAX is built in with RJS and helpers. With Django, you choose your own Javascript framework and do it yourself. Which isn't a bad thing at all, I actually prefer Django's way.

With Django, it's easier making web sites because of the built in automatic admin interface. It's production ready. With Rails, you have a lot of plugins/generators to choose from which does the same thing though (which again, isn't a bad thing at all).

Honestly though, Rails/Django users have created plugins/apps to extend their favorite framework, so it's really easy to make websites AND web apps with both now.


Django I don't feel qualified to comment on (and I am going to stay as far away as humanly possible from the pointless religious arguments that tend to rage around these kinds of articles), but one thing I could point to in Rails that supports the "web app" over "web site" lineage is how you handle static (or "semi-static") pages in a Rails app, and the techniques and workarounds that have sprung up to deal with this issue.

Stuff like this really does make me feel like Rails was (at least originally) meant for "web apps" more so than websites with a large amount of static content. Not to say the latter can't be done in Rails, though. But the original focus of the framework seems clear.


This is a good point. Rails has a pretty ad hoc way of dealing with static pages - throwing them in /public mixed up with everything else. Cached pages get thrown in there too, and sweepers need to be able to delete them. I don't like the mess of permissions that arrangement necessitates so generally redo it.

Rails is also by nature a one-app pony - many web pages have more than one app that could reasonably be called "discrete" except they share users. Setting up something like that in Rails is messy no matter how you go about it. Further evidence would include the "REST everywhere" approach, which is wonderful if you're focussed on a full blown machine-accessible web app but a waste of time for something simpler.

I'm not exactly a Django expert either but I've heard that ones runs into limitations there quickly too - as you'd expect, no free lunches!

To sum up, both frameworks are good for what they are: a starting point. Any large project is going to find itself doing a lot of custom work anyway. So pick the language you like best, basically. For me that's Ruby but I have nothing against Python that goes much beyond the level of "I don't like the way it looks".


Is that you, Sho Fukamachi? The Guyver? If so, fancy running into you here! :) How have you been?

I'm working on my first Rails project at the moment and, as an exercise more than anything else, have been trying to keep things RESTful as much as possible. I am finding it quite difficult in some more complex situations to keep so strictly to the RESTful ideal and find that I must sometimes stray in deference to the way I want the UI to behave. Do you find that you need to stray out of the strict 7 actions when things like complex model relationships, user access control and AJAX come into the equation?

But yeah, I've also made my choice, for the foreseeable future, Ruby is for me, so Rails it is.


Lol, hi Jonny, small world isn't it...

Well, I've never been a huge fan of REST when it comes to user-facing web pages. The "big 7" verbs seem to me to be limited and arbitrary, and while very interesting as a kind of natural API I don't use it for browser pages.

I think Rails over-hypes "REST everywhere" and if you don't have a clear use case, I'd forget about it, at least on "normal" pages. Trying to unify API access and normal web pages seems pointless to me. I also have other concerns, which I funnily enough wrote about:

http://fukamachi.org/wp/2008/04/01/restful-confusion/

Good to see you, look forward to seeing the fruits of your labour!


They're kinda trying to accomodate 'web sites' on the framework on the latest releses of Rails... I'm afraid this effort on 'covering all bases' is getting RoR a little too bloated, a little too fast...


Defending the app/site split notion here...

While this is obviously not the entire case and Django is a fantastic general purpose web framework, lemme just say this:

When using much of the django middleware, django.db.models, generic views, django.contrib and quality third party "apps" ( http://djangoplugables.com/ ), it's pretty close to the perfect "CMS".

And that's not a bad thing at all, it's just not the direction Rails has ever, or probably will ever, go.

Also, let me reiterate what I said above: this is obviously not the entire case and Django is a fantastic general purpose web framework.


I would prefer something like

Rails is a domain-specific language based on Ruby for building web applications.

Django is a framework you can use to build web applications with Python.


Wow, I can't even begin to tell you how misinformed you are.

Rails is not geared towards web apps, and Django is not geared towards web sites. Both tools are what you make of them; just because Django includes a built-in admin interface doesn't mean it has to be "rejiggered" to build anything else. Both, as full-stack frameworks, provide nearly exactly the same set of tools to the developer: an ORM, a templating language, a routing framework, and the glue that ties everything together.

You are also patently wrong about the importance differences being at a higher level. If you are only using the shallow, superficial features available to you, you are missing out on the differences that do make each framework unique. Anyone who has spent any quality time with either framework can tell you that these "high level" features (e.g. Rails scaffolding or Django's Admin) are almost never used in a real project. Next time, I would highly recommend going beyond the 15-minute screencast and actually reading into the guts of your framework. Who knows, maybe you could become a professional one day ;).


You speak with such authority, evdawg, I find myself wondering which of your many Django and Rails projects I must use every day without even knowing it. Care to tip us off?


Interesting rant about being misinformed, considering the assumptions you make about both my experience with the frameworks as well as my "professional" working experience. How about the fact that I've worked exclusively at two different Django startups over the last year and a half? And with several Rails startups in the 4 months that I've gone freelance since then?


> Python doesn't allow monkey-patching;

Do I misundetstand what monkey-patching means? Because other than a few types such as int & str and cmodules(I believe) I can patch my monkey with python all I want.


Maybe he meant the community frowns on monkey-patching.


I am quite sure Python allows monkey patching. It looks ugly because, perhaps, it's better that way.


I think he is refering to open classes...?


Oh, OK, I'll bite.

When choosing a framework, I want it to be community supported. This means it's under active development and open to change.

When programming an app against a framework, I want it to simply not break when updating to a point release.

I'm not really interested in a comparison of app implementation details of Rails versus Django. What I'd like to know is the crap I'm going to have to deal with moving from x.2 to x.3. Or y2.3 to y3.0. And how does the plugin/addin/module structure enforce limits and consistency?

And while we're at it, someone come up with more interesting posts than Rails versus Django. Can we get some well written comparisons of, say, a Clojure-framework for apps versus a C# one or a server-side JavaScript one?


Python has a numpy and matplotlib, as well as really easy binding with boost (which gives you ublas etc.) This allows you to write really nice optimized numerical algorithms that plug right in. That's what sold me for Django over Rails.


That's neat, but really, do you do heavy matrix and vector computations from your web application?


Oh I didn't mean to imply it's a common need. But yes I do - in my case it really makes the difference between it being feasible and not-feasible.


Then I'm very curious what your web application is.


They are both good. What matters is your background, requirements, and timelines. Checkout my post for a detailed article on what to look for in a framework.

http://blog.shopfiber.com/?p=90


I am in the Django camp, but I am still interested in using ActiveMerchant. Anyone have ideas what the best way to use both would be?

Perhaps one approach would be running a Ruby instance internally, dedicated to exposing ActiveMerchant functionality.


What about compiling ActiveMerchant to Python?

http://github.com/why/unholy/tree/master


Oh God yes. Please, please, please.


http://satchmo.python-hosting.com/ don't know much about it or ActiveMerchant but maybe interesting to you.


One of my coworkers was in the exact same position, so he's beeon working on porting ActiveMerchant to Python. It's on github: http://github.com/afarnham/openmerch/


Satchmo support many payment modules including:

        * Authorize.net
        * Trustcommerce
        * Google checkout
        * Cybersource
        * Paypal
        * Protx
        * Purchase orders


django-accounts has a very simple implementation of interaction with authorize.net. havent tried it. but it looks good.


The world of Web development is oh so much larger if you just look around a bit.


I haven't used Django. Rails is both great and seriously flawed. Comparisons are generally fatally biased but they still get people thinking.

The transition of Rails to Merb shows that things are still in play. The reason that even the short-sighted, flawed comparisons are worthwhile is because we have so far to go towards creating a web framework that really helps or, for that matter, a language that really helps.

However difficult the discussion here is, it is necessary.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: