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.
My Rails CRUD experience is the opposite. Template rendering always dominates database time. Without caching, rendering templates with nested partials is generally 5-10x slower than data access. Typical times are 20-50ms for ActiveRecord, 100-300ms for views. This is in production environments with production databases, Rails 2-4, even with alternative template engines that optimize for speed.
Your experience is colored by the language / framework of your choice. For example, look at the fortunes benchmark in the techempower benchmarks. Rails makes a good showing for a dynamic language framework, but it's clear that an order of magnitude better performance is possible on the same server hardware with java or c#: http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...
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.
Err, as a comparison, if my C#/ASP.Net MVC responses takes more than 50ms I start looking for reasons why it was going so slowly. An uncomplicated page will take 20ms or so.
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.
> going to Basecamp, the entire time waiting in chrome ... is between 150-200ms
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.
I suppose you could move your entire controller server-side and share a cache for the complete composed JSON documents such that you do a single HTML page request followed by many cached JSON requests afterward one for each "page", but if a page always gets rendered to HTML, you'd only be skipping the last step.
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.