1、動畫
動畫有很多種，比如側邊欄菜單的滑入滑出、元素的響應動畫、頁面切換之間的過場等等，在H5之下的眾多實現方法都沒有辦法達到純原生的性能。壹般有這幾種不同的選擇：css3動畫，JavaScript動畫，原生動畫。
css3動畫非常的消耗性能，如果某壹個元素用到css3動畫可能還看不出來，但大面積或過場使用css3動畫會讓app低端手機體驗非常差。最好的選擇是通過框架調用底層的動畫，但不管怎麽樣等於在原來的代碼上包上了壹層，性能還是不可避免的受到影響。
比如在壹個新頁面的載入上，如果調用底層動畫要考慮的問題有兩個，壹個是本身資源頁面的渲染問題，另壹個是遠程數據的獲取。即便是這些動畫能夠很快的響應，但大量的css頁面會導致渲染卡頓，滑入時可能會有白屏/機器卡頓的現象。為了解決這些性能問題又必須要用到預加載或模擬動畫。即便是這樣，滑入滑出的動畫在低端的安卓機器上還是有很多問題，如果獲取服務端數據處理的方式不合適，卡頓白屏的現象會更嚴重。具體看下面的數據獲取方式。
2、獲取服務端數據
首先要接受的是，這裏的數據獲取都是在資源頁面上異步完成的，因為只有這樣才能讓這些資源頁面完成預加載或者渲染。但是異步拿到的數據在填入頁面中時可能會涉及DOM操作，眾所周知，DOM操作非常消耗性能，如果頁面小還好，頁面稍大數據稍微復雜壹點，頻繁的DOM操作會導致明顯的閃白。
而且最重要的壹點是，如果頁面加載進來之後數據更新的速度太慢，也會讓頁面模板等待很長時間，對用戶體驗又不友好，總不能每次打開都像瀏覽器壹樣等待刷新是吧。
這個問題如果沒有得到解決，H5APP是很難承擔大規模數據的頁面，在它們之中頻繁切換更是難上加難，那麽肯定有人也會想到用MVVM的方式，相對來說它們獲取數據和更新數據的方式更敏捷更科學，但寫的過程中又要註意很多H5獨有的問題，這些問題在下面的頁面切換裏來講。
3、頁面切換
上面幾種不錯的實現方式，比如預加載和模擬動畫，甚至有批量的預加載，批量的截圖模擬動畫等等，雖然看起來很友好解決了不少問題，但事實上如果頁面足夠多就會引發另壹個問題：頁面的生存周期。
試想壹下，如果引導頁或者主頁面緩存了5個子頁面的資源，在跳轉到響應的子頁面時又會緩存這些子頁面的下級頁面資源，如此反復肯定會占據大量內存使APP的體驗下降。那麽怎麽知道哪些頁面是需要的，最多緩存多少頁面，什麽時候結束哪些頁面的生存周期呢？在很多H5APP的框架裏都沒有對這些問題有壹個完美的解答，因此在頁面較多、內容較多的APP中可能會因這些資源分配的問題降低性能。
這時再看看MVVM的數據加載問題，實際上不管哪個MVVM框架，寫過的人都知道管理這種新型的前端代碼最重要的問題是內存的問題，妳既要保證代碼寫的足夠優雅沒有任何內存泄露問題，也要考慮到在頁面生存周期結束時它們的控制器/頁面資源是否得到釋放，這對全局有沒有什麽影響，在多個請求時也要合理的分配資源，甚至是復用這些父級頁面傳過來的緩存資源等等。較小的APP可能並不會有這些問題，如果妳想用純H5來開發大型APP，這很可能會浪費妳很多時間——而且結果還不會讓妳滿意。
HTML5有多少坑可以分為3大點和7小點，3大點上文有詳細的介紹了，下面說說7小點。
1.過分依賴網絡
2.渲染性能較弱
3.頁面過多
4.標簽太多，代碼量也不少
5.不能調用移動硬件設備的功能
6.不支持離線模式
7.消息推送不夠及時
雖然H5 APP有很多缺點，但不得不承認，存在必然有其作用，正如前幾年流行的混合開發模式，通過原生和H5結合也是不錯的方案，比如淘寶、京東等電商類App。
HTML5 的優勢在於他的排版，要做出相同效果的 Native 界面排版成本又太大，JavaScript由於其復雜的文檔對象模型（DOM）、糟糕的實現和調試工具、不壹致的瀏覽器實現而不受開發者的待見。而隨著技術的發展， JavaScript變得越來越強大、完善，比如， Ajax技術可以創建更加迷人的Web應用，Angular JS提供web應用的架構支持整個開發進程，Node.js將JavaScript的應用範圍擴展到了服務器端，imag.js將JavaScript延伸到移動端，各種層出不窮的框架使得JavaScript的開發更加簡捷。尤其是近幾年node.js和imag.js以及react.js的發展，將 JavaScript提升到了前所未有的高度。
我們也可以看看用imag.js開發的微信頁面（支持Android和iOS）