Like `ssorallen says, slow CPUs and limited battery life is an issue. In addition, latency on mobile networks is rough and should be avoided for your users whenever possible.
You have two choices when taking an SPA approach:
1) Give your users a webpage that is usable, readable, and navigable as soon as they get it.
2) Give your users the skeleton of a webpage that they then have to accept the latency of javascript parsing and execution, and then the latency of data fetches.
Of subsequent data fetches. Not the first page load. Using JSON fetches to update documents also gives you the ability to not throw away the DOM/CSS and maintain the execution context.
If you use the right technology, you can give a usable application out of the gate without waiting and use JSON data fetches for every subsequent request.
The lifting can be heavy for mobile devices with slow CPUs and limited battery life unlike the servers running your site. Also if your server renders the site and some of the pages are public, the server can cache the HTML and let the web server serve cached HTML rather than render the page in the web framework for each request.
> The lifting can be heavy for mobile devices with slow CPUs and limited battery life unlike the servers running your site.
The reverse is also frequently true: if client rendering can improve cacheability or reduce the data going over the wire the radio savings will pay for a LOT of text updates. Similarly, if you can transfer a large listing without creating thousands of DOM nodes the results can be a wash depending on exactly how much data, the browser, etc.
There isn't a single right answer here - it really depends on the application and good analysis.
It doesn't have to be heavy, even for mobile devices. Decrease your dependency on large libraries, minify and cache everything, and only load what they need. Once they load it the first time and cache it then all they ever need is a bit of JSON here and there.
You have two choices when taking an SPA approach:
1) Give your users a webpage that is usable, readable, and navigable as soon as they get it.
2) Give your users the skeleton of a webpage that they then have to accept the latency of javascript parsing and execution, and then the latency of data fetches.
we have the ability to do #1.