Matt De Leon's Profile

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

But after spending a year battling with Backbone, I'm just not a big fan. Backbone and javascript is a lot of fun, but I find sticking to mainly Ruby/Rails to be where I'm most productive.

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.