深刻分析：微信小程序與H5的區別

做爲前端工程師，從前端的視角，爲你們分析下微信小程序和HTML5與之間的主要區別

第一條是運行環境的不一樣。

傳統的HTML5的運行環境是瀏覽器，包括webview，而微信小程序的運行環境並不是完整的瀏覽器，你們注意，我這裏寫的是「非完整的瀏覽器」，有如下幾個緣由

小程序的開發過程當中會用到HTML5相關的技術(並不是所有)

小程序最後的發佈上線須要微信審覈，微信在不更新自身軟件的狀況下能夠將小程序更新到自身軟件內，這就聯想到了React Native框架,而且已經有開發者在微信小程序的開發工具源碼中發現使用了React和NodeWebkit庫

官方文檔中着重強調了腳本內是沒法使用瀏覽器中經常使用的window對象和document對象（基於這一點，像zepto/jquery這種操做dom的庫就被徹底拋棄了）

因此我我的認爲，小程序的運行環境頗有多是微信開發團隊基於瀏覽器內核徹底重構的一個內置解析器，針對小程序專門作了優化，配合本身定義的開發語言標準，提高了小程序的性能。

不過因爲微信給開發者提供了開發工具，而開發工具中也內置了編程、調試、開發環境、發佈於一身，咱們也不用再探討它的最終運行環境了，只要按照官方文檔進行開發就能夠了。而且從微信團隊給開發者提供開發工具這一舉動，讓我聯想到了蘋果給開發者提供的X-CODE開發工具，能夠想象微信的「野心」可見一斑

第二條是開發成本的不一樣。

這裏我提出了一個問題，當咱們面對一個HTML5 web開發需求時，咱們須要考慮什麼呢？拋去開發工具（vscode、sublimtext、Atom等）不談，大到前端框架（Angular、react、vue、backbone等）、模塊管理工具（Webpack 、Browserify 等）、任務管理工具（Grunt、Gulp等），小到UI庫選擇、接口調用工具（ajax、Fetch Api等）、瀏覽器兼容性等都要咱們一一考略，再不濟用jqery插件寫H5，也要在開發過程當中去尋找合適的jquery插件來配合項目。儘管這些工具可定製化很是高，而且提升了開發者的開發效率，但我相信項目開發的配置工做已經消耗了很多精力，儘管大部分開發者都有本身的配置模板，但長久以來對於項目中使用的各類外部庫的版本迭代、版本升級所產生的成本應該也不低。

而當咱們面對一個微信小程序的開發需求時，咱們須要考慮什麼呢？微信團隊提供了開發者工具，而且規範了開發標準，前端常見的HTML、CSS變成了微信自定義的WXML、WXSS，WXML中儘管所有是自定義標籤，但官方文檔中都有明確的使用介紹，相信上手應該是很是容易的；WXSS、JSON和JS文件中的寫法稍有限制，但總體相差很少。在統一了這些標準以後，做爲一個開發者，你會發現，本身只要專一寫程序就能夠了：

當須要調用後端接口時，調用發起請求API

當須要上傳下載時，調用上傳下載API

當須要數據緩存時，調用本地存儲API

引入地圖、使用羅盤、調用支付、調用掃碼等等功能均可以直接使用

UI庫方面，框架天然帶有自家weui庫加成

而且在使用這些API時，你不用再去顧慮瀏覽器兼容性，不用擔憂生產環境中出現不可預料的奇妙BUG，可見微信小程序的開發成本確實相比以往的web開發低不少。

第三條是獲取系統級權限的不一樣。

微信小程序相對於HTML5 web應用能得到更多的系統權限，好比網絡通訊狀態、數據緩存能力等，這些系統級權限均可以和微信小程序無縫銜接，也就是官方宣稱的擁有Native App的流暢性能，而這一點恰巧是HTML5 web應用常常被詬病的地方，這也是HTML5的大多應用場景被定位在業務邏輯簡單、功能單一的緣由。

第四條即是應用在生產環境的運行流暢度。

這條不管對於用戶仍是開發者來講，都是最直觀的感覺。長久以來，當HTML5應用面對複雜的業務邏輯或者豐富的頁面交互時，它的體驗老是不盡人意，須要不斷的對項目優化來提高用戶體驗。可是因爲微信小程序運行環境獨立，儘管一樣用html+css+js去開發，但配合微信的解析器最終渲染出來的是原生組件的效果，天然體驗上將會更進一步。