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
But if you're building Document-based CRUD app number one-billion-and-five where rendering templates is a significant portion of your app's execution time, doing that in the frontend means you cant cache the output, so every render for every user forever has to do all of the work. Sure, it scales well in terms of user volume because you will always have roughly as many resources to process templates as you have users, but it doesn't scale as far in terms of data size and template complexity because when if it gets slow there's nothing you can really do.
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.
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.
37Signals are optimizing on ms here, re their previous articles on caching in Basecamp Next. So I think you are both right. Yes, it is nice & semantically correct to have client side templates but if you have an app under heavy load, you can save up some time from client side processing by rendering a piece of HTML on the server. Would not want to maintain their code though.
