Yep, I finished reading but I disagree with this approach. Even in a mostly document based project I would recommend using frontend templates. Fire and forget type actions are just really easy to do and the whole thing just makes more sense IMO
Doing it serverside with russian-doll caching means that each template only gets rendered once for a given set of inputs and (at least for most CRUD apps I've ever built) you have huge cache hit rates, so it'd mostly be people pulling static HTML out of memcache all day. Crazy fast.
Why couldn't you just memcache the json response for a given set on inputs?
Template rendering is never, ever the slow bit in a CRUD app. Ever. At its core it's simple string concatenation. Getting the data, the SQL, is almost always the slow bit unless you're doing some serious computation or file jiggery, which is still not template rendering.
And that's on a small VPS.
But even going to Basecamp, the entire time waiting in chrome (which is basically the entire server-side run time + a few ms) is between 150-200ms and that's on what I assume is a fairly busy server.
So I suspect you're doing something wrong.
The numbers in my comment are "without caching". Comparing them to Basecamp, which caches views and fragments heavily, is apples to oranges. Once I add caching, my typical response times for a cache hit are in the 10s of milliseconds.
You made an Amdahl's law argument that view caching is fruitless because rendering is an insignificant part of total response time. So I responded with uncached performance to show why Rails needs view caching.
It's no accident that Rails has comprehensive caching support; that the Rails team has worked hard to refine and optimize caching in each release; and that DHH writes about it so often (including in this article). You can't have performant Rails without view caching because rendering is dog slow.
So, someone using java or c# could very well say view render times don't matter, because for them that is true and their bottleneck is indeed the database.