Please read for an updated status on RailsCasts:
Learn more or hide this
GitHub User: smidwap
Designing a site with turbo links in mind is a lot easier than making turbo links work on an existing site. In fact, it's a great tool to have in the rails stack by default. If I had to guess the rails team put it there because it genuinely makes every site better, and with little cost when designing a new app
@cpuguy83 You're absolutely right, that's one big advantage of clint-side MVC.'s
By sticking with mostly Rails, you can avoid having to test/debug lots of JS, devising a strategy for sharing views between Rails and JS, logic duplication in Backbone models and Rails models, etc.
I think caching + utilizing Rails UJS + RJS (rails js templates) is a winning combo for many apps. That's why cache digests is sweet :-)
I'm wondering what the purpose of caching an individual task is? It seems as though caching the project view may be sufficient.
I understand the benefit of caching an individual task is that when a project is re-rendered (after a task changes), most tasks will still be cached. But does rendering a task really take that long?
I think the answer to my question lies around how we avoid hitting the database when using fragment caching. I haven't fully thought it through, though.