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.
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:
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...
Perhaps I can think wishfully of one of them chiming in... ;)