[smidwap]

1. Do not take this statement for granted: "When your page is simple, yes, you don't need that much interactivity. But the market will demand more and more functionality on that page." Simple, fast apps that don't overdose on interactivity seem like a better bet. The vast majority of problems being solved with software do not require the bells and whistles of Facebook & Gmail.

2. A huge aspect of choosing Rails or client-side MVC is productivity. If you're going to build a web app in Ruby, you're going to have to have somebody on your team that is good at Ruby. By layering a client-side MVC on top of that, you're now requiring javascript expertise. Your life is now twice as difficult.

3. It's amazing how powerful DHH's approach is. Just look at the new Basecamp. Does any part of that app feel slow, clumsy, and non-interactive? Absolutely not. I imagine myself being opening up the Basecamp codebase and "getting it" within a day. If you understand your constraints well, you can deliver amazing software with an order of magnitude less complexity.

[SkyMarshal]

>The vast majority of problems being solved with software do not require the bells and whistles of Facebook & Gmail.

Even with FB and Gmail, I've gotten the impression that neither of those is fully client or server-side, but rather highly optimized hybrids where component processing tasks are done wherever they can be with highest performance and lowest latency.

Both seem acutely conscious of comparative speeds of server-side rendering + internet latency vs. client-side rendering.

Not sure though, only an impression based on anecdotal evidence, anyone more familiar with their architectures?

[encoderer]

Facebooks architecture here is impressive and you can read more about it, they call it Bigpipe. (Of course this is probably, to some extent, out-dated by now).