An overview of how we use Redis for caching at Stack Overflow can be found at:
Our "global inbox" and "frequented tags" features are built on Redis as well. There's a bit of traditional SQL behind global inboxes (mostly for persistence and backup purposes), however.
Though that has more to do with their community & content than their structure. Of course, SO's structure is part of the reason for its community/content (though I personally believe Atwood & Spolsky's star status was more important), but just copying that isn't going to get a similar site a lot of users or quality content.
MVC is not a fixed design, it's a legitimate universal Design Pattern (unlike most of the GoF book). It's a shared nomenclature for describing the arrangement of concerns, not a prescriptive blueprint.
Who cares, really? The percentage of people who purposefully break their browsers isn't worth catering to.
Accessibility. Is there really any reason why a questions/answer site with voting can't provide noscript tags?
Refactoring ours to deal with that, so not trying to throw stones.
EDIT: I understand mythz's comment about being a play project. i'm just responding to the 'why break your browser' sentiment.
Because making two versions of the site is twice as much work?
This demo doesn't let you link to (or bookmark) a page or open questions in new tabs. For an app like Gmail that probably doesn't matter, but for something like this I'd say it's pretty crucial functionality to be missing.
Progressive enhancement where you add JS to improve the experience is a much better approach. That way you get all the basic functionality for free instead of trying to retrofit it onto the ajaxy app.
Now that you can manipulate the address bar with pushState  you can even make these enhancements completely transparent.
Is there a way to make it degrade gracefully? The problem I see is that you can't have the JS and non-JS parts have the same URLs. The JS part will have urls like thesite.com/#question123, whereas the non-JS site will have urls like thesite.com/question123. So now you have two urls for each page, giving problems with search engines (and I think search engines will consider thesite.com/#x the same url as thesite.com/#y, and only load one of them).
And why redis? It's definitely the wrong database for the job.
couchdb is indubitably a better choice here.
redis is a k/v store that will force you to write a lot of code to get the results you want out of it, people use it for purposes like caching, not storing your main content which you'll want to query in complex ways.
meanwhile couchdb is just more complex enough to make things easier, and it features database side authentication which will allow you to write full client side apps, which seems like what this author was going for here.
anyway it just seems to me like couchdb fits the use case here perfectly. when i wrote hipchan i used mongodb because I had server side code to auth, no bias here...
IMHO Redis comp-sci data structures provide elegant and fast solutions to the requirements of a StackOverflow Q&A site.
It purports to do for your web application what git did for your application development -- you can clone just the app from one DB to another, or clone the entire DB for backups, offline work, or even peer-to-peer production hosting or web.
I haven't done web apps very much myself in a couple of years, but that's one area that's a bit tempting for me since the ones I have been interested in have peer-to-peer data accumulation and offline work + synchronization needs.
* They all require two servers running (redis + a web server)
* None provides a framework for building an application.
* None provides n-way replication.
* None provides offline support.
So? separating web service access to the datastore is simply separation of concerns and just good modular design. A redis hybrid solution is still going to be faster than Couch.
>None provides a framework for building an application.
There is lua scripting available in some of them and the application fx is generally on the client.
>None provides n-way replication.
Out-of-the-box Redis supports trivial (as many as slaves as you want) replication.
>None provides offline support.
Q&A sites are not about the code, they are about the people, asking and answering the questions. It's nothing without the community.