I agree, I wish the author brought reasoning to those points. I do think that it is a little odd of us to push more & more processing to the user's device, rather than doing it ourselves and purely delivering content. However, it does seem to have a net positive on server reliability, and the perceived performance & responsiveness of the apps.
It makes business sense: server cpu cycles you have to pay for, client ones you don't. (If the client is fast enough not to notice -- if not, of course, you could lose customers).
"If the client is fast enough not to notice -- if not, of course, you could lose customers"
This.
I honestly think most front end devs don't test with anything except a fast PC (or Mac). They sure don't test with last year's phones. Web pages are getting more and more sluggish (generally speaking) all the time.
It's one thing to always want to work with new technology, but devs really need to spend some time in their customers' shoes.
I've been pushing this strategy for years. It makes more and more sense to have the clients- which include phones- do the processing. They have an excess of power. And more importantly, once the app is downloaded network lag is not as big a factor (it still is, of course, for any ajax-based stuff- but we minimize this).
