微信小程式的開發與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去開發，但配合微信的解析器最終渲染出來的是原生元件的效果，自然體驗上将會更進一步。你可以通過第三方開發商西裡奧布科技擷取微信小程式。