Argument number one: initial load time is much slower
Argument number two: accessibility for people and robots
It is argued that a web site should be built with plain HTML. We want to be able to serve our content to different channels (like our own blog, and an RSS feed) and we want our content to be crawled by bots. This means we need plain HTML. Everybody seems to agree with that, and it makes an excellent business argument too: clients love SEO and they gladly pay for it.
Argument number three: Future friendliness
you can scale up your servers; you can’t upgrade your visitors’ device or browser. Or downgrade your visitors’ stuff because your code stopped working.
Argument number four: crappy browsers and devices
Matt shared some experiences he had with projects that were built this way, and he pointed out that old browsers have a very hard time rendering thousands of DOM nodes. While old browsers like IE7 and IE8 are quickly vanishing from our stats, there is another trend: cheap mobile devices with Android 2.n installed on it are still being sold as new. Right now. And there is a new trend in computing: speed used to double every year or so, which is still the case, but prices for low end devices drop by half every year too. This means that not all of our new stuff gets faster and faster, people seem to be satisfied with slower hardware. It’s not only nerds with the newest gadgets that use the web, like erlehmann rightly points out.
Argument number five: complexity of the architecture
In the progressive-enhancement world you’ve got models on the server, controllers on the server & html generation on the server and rendering on the client. You have small bits of application logic on the client for enhanced bits, if you need to update an area of the page just fetch new html for that page section from the server, keep template rendering server-side if possible.
In JS-only land, you’ve got models on the server, controllers on the server & JSON generation on the server, models on the client, controllers on the client, html generation on the client & rendering on the client. This sounds like more to me. Also, the most code you have on the client the harder testing gets, as more of your logic is running on different engines.
Argument number six: don’t break the web
Argument number seven: Browser support
Jake mentions it in a sentence, and I thought about it a bit more in a separate comment: if you use a client side framework to render the page for you, you lose control over what support means for different browsers: if the framework decides that IE8 does not need to be supported anymore, there’s no way to send it any content at all. There no such thing as gradual support in this architecture: it either works, or it doesn’t.