* nondeterministic testing,

* interactive testing (leaving machines on to run interactive testing at night),

* most of the bugs will live on the client side,

* you'll have to support each and every machine's quirks (you can't pretend everyone are on at least core i5 and chrome, people WILL have machines that do javascript client side template rendering SLOWLY).

* you'll have to find ways to diagnose problems at the client's site, and you will maintain a fleet of various computer configurations to run sanity on.

* which will also cause you to start investing in pairwise testing

* i can go on

DHH is COMPLETELY right. Just because the universe is not ready enough for client side "SPA"s (universe=browsers,internet)

I'm laying my arguments out of experience - I've been a long time Ruby/Rails/.Net/JVM server side dev as well as enterprise software dev (enterprise desktop/workstation application suites, as complex as visual studio and the sorts). I have several node.js projects in production and I'm also doing a couple of projects with Backbone.

Still, I insist that some of these arguments are client side specific. Once instance is javascript template rendering speed. Another is, that you would prefer getting statistics on your speed of rendering at the server's side where it is easily controllable and deterministic, rather than shuffle around to close that loop and build a usage service to report back usage and statistics to from the client's side.

I give my arguments from pain and experience in both sides, and I still do both sides despite of the arguments (since it is not always my own choice).

Fundamentally this is a bikeshedding debate. Whether you're programming on the client or server, the tools are equally capable. The big difference is the server puts you closer to the data, and the client pus you closer to the user. Either way you're struggling with latency, and you do different trade-offs, and either way you reach your goals.

You already are at the server. It cost you almost nothing to manage yourself there (monitor, analyze, etc).

Do you have the resources to handle the complexity of being closer to the user? Is a "true" client side SPA worth it over what 37 are doing?

In terms of value for development investment, I'm not entirely sure, which is what I think David refers to as pleasure of development!

Now, extjs is a DSL, it's closer to flex development than to traditional web development. It has a learning curve with a pay-off at the end, and the pay-off is easier ui development. If you're building ui the traditional way, but client-side, ymmv. Still, anything to do with rendering glitches is something you'll have to debug by eyeballing it, regardless of where you render your ui. There's no way of automatically logging misplaced floats.

P.S. There's also less to monitor. Typically you'll monitor for performance and security. Performance depends on the browser and pc specs, not the server's load, and security has nothing to do with the client. So, really, there's just not much to monitor. You can attach error handlers to automatically report exceptions to the server, but i've not had a need.

When you get below 50-100ms per action, things are generally fast enough that this is not a key problem any more. The user cares greatly if you can go from 800ms to 100ms, but not so much if you can go from 100ms to 70ms.

For example, if you are populating a bunch of divs inside a parent div with the data returned using json, you would describe this using something like jquery selectors. Now if someone else comes and moves around the div during a redesign, he must go through whole bunch of js to make sure his shuffling of the divs around won't break the jquery selectors populating the data from json.

Now think about having a parent div that is simply populated with returned HTML from server-side and it seems way easier than using json to populate the data.

My view is that you will get in significantly less trouble because manipulating an HTML template that is rendered on server side is much easier to manage and adapt to a new design than finding nitpick jquery selectors across the app that depend on a specific div structure.

Btw, my post doesn't imply anywhere that a designer should redesign an app without testing. Therefore, your argument about testing is garbage.

What browsers are you getting the 50-100ms numbers? Similar results on mobile (with a 3G connection)?

That's why it's great to be closer to 50ms so you'll stay under 100ms even with the network overhead.

So it's only natural that for their flagship product they'd rather keep pushing the limits of their comfort zone rather than go all out client-side, no matter how natural that choice might be for a "web app".

But why would there be a performance penalty? Doesn't this result in the client doing _less_ work all around? Less work than the multi-page approach...and less work from the client-side templating approach, no?

As to performance on mobile, i think it might all depend on how large the html fragments are.

The article goes on to state that delivery times for cached segments of HTML are under 50ms in most cases. While I agree that it would be possible for them to improve the user's perception of the app performance even further via JSON or client-side updates, with the level of performance they described that type of improvement is unnecessary and introduces additional vectors for bugs to creep into production code.

If you simply swap out a large part of the page with some HTML right out of an Ajax request you don't have to worry about any of that.

Also, garbage collection efficiency in browsers is a metric of fierce competition among browsers. It's superb already, and it's getting awesomer by the minute. It's a safe choice for the future.