Your arguments are a checklist of responsibilities for anyone running any web software, whether the actual DOM elements are being rendered on the server or the client.

I agree that you do most of these arguments when most of your content render on the servers too. However, you DO have limited resources (time, money, people), and these points become more and more painful as you push towards client side.

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).

You can still do unit testing of your client-side code if you wrap everything in components that separate state from rendering. The rendering itself you can only test with a human looking at the page anyway (or by comparing to reerence renderings). Extjs uses this approach. I can easily unit-test my forms written on top of extjs.

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.

Great! You may have put it better than me with the closer to server - closer to user analogy. So to complete my goal I'll ask a question.

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!

I used to build stuff on the server, then i switched to extjs, with the server only exposing a bunch of json-rpc web services. It's not as big a deal as people paint it out to be. Extjs abstracts away browser differences well enough that i rarely come across issues that aren't reproduceable for me. If they're reproduceable for me in my browser, they're easy to fix.

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.

Very true. This is why I'm sticking with a server-heavy design (i.e. Rails) for my main projects. I agree with all of your arguments about the difficulties of testing. And I'd add that there's a distinct lack of tools for testing client-side. Sure, you can get unit tests for client-side JS, and you can run integration tests in Selenium etc.. But the client-side testing ecosystem is tiny and immature compared to that for server-side testing. This will all change, but for now, I don't envy anyone who has to test a heavily client-side app.