公司打算做一套手机网站，展现和交互的话类似于APP，参考很多现有这种网站，发现他们在任何页面加载的时候，都是先加载个小圈圈（等待），然后异步加载，用JSONP的方式异步请求数据，JS再处理JSON数据加载到DOM上来展现页面。在监视器窗口也看到了页面发起了很多异步请求。
这样做的初衷很可能是因为移动端的带宽什么的不如电脑端，这样可以不用将一个页面上的请求分成多个子请求来完成，但是这样的话我觉得一方面开发方式会复杂， JS代码里面必须有HTML模版代码，从设计上讲维护性将会很差，还有就是一个页面加载的时候请求增多，这样会不会真的好？不是一直将要将HTTP请求减少才提高加载效率嚒， 这样是不是“违反”了这样的原则？
或许这样有什么决定性的优势，我还不太明白， 也请高人来讨论下
移动端的整体页面重绘（repaint）/回流（reflow）速度慢，基本用不到硬件加速。因此，整页异步的绘制效率异常低下（iTouch甚至比安卓机慢很多），个人并不建议使用。
P.S.楼主看到的页面的整页异步的示例，大多是通过 jQuery Mobile 做到的。个人觉得 jQuery Mobile 太过重型，也无法胜任复杂的页面需求。楼主可以看看百度写的移动端框架，相对而言更轻量级一些。
P.S.2.不过，这二者都代理了浏览器默认事件（pageload，回退等），其实体验非常糟糕。
但是页面模板和数据的分离是一个利于重构的过程，对于工作量来说可以减少不少。
不一定要把页面模板放在JS中，放在HTML中，用JS获取，做正则替换也是可行的。
html5 history的应用
省下了每次重載頁面的初始化時間、Client端重新渲染的時間。
其實只要控制好異步request數，在資源消耗上真的比整頁重載省很多
不過我自己是初始畫面避免異步request，一進門就讓人等的感覺不太好，我偏好把異步request留給使用者觸發事件，像 pjax 應用那樣。
另外套資料的 HTML Template，不一定要寫在JS裡。可以直接寫在 HTML 裡，再用 mustache 之類的 template engine 取得 template 的 DOM Node，把返回的data套上去，這樣JS代碼會看起來清爽很多。
这是网站的又一次变革，归根结底，不是网站开发的方式变了，而是 Web 变了：
以前我们做的是 Web page，而现在做的是 Web App。