有人說小程序是原生應用，不知道是現在什么立場這樣說的，微信內嵌web view 控件，本質上就是一個定制化的web瀏覽器，與普通瀏覽器相比只是增加了一些豐富的內部交互，比如可以輕松用戶信息等等，雖然站在前端的角度，小程序和H5應用有一點區別，但是虛擬機永遠是虛擬機，跟原生永遠差了一個解釋執行的鴻溝。還提到了自更新，只要你是基于HTTP協議的那就是古老的HTTP REQUEST 和 RESPONSE方式，沒有什么值得吹捧的。如果答主稍微對Native了解深一點，可能就會拿application stream來說了，這才是目前解決Native程序分發方式的一大方向，ctrix 有application 虛擬化，Google有dynamrio，微軟有drawbridge，這些技術含量可比react或者codepush技術含量高多了。一個是接近OS級別的革新，一個是虛擬機里面的優化，層次高低，技術深度不言自明。虛擬機永遠是虛擬機，玩不出花來。不過如今的CPU架構也是發展了幾十年而沒有大的改變，這也制約了native程序的基本運行原理。-----------------技術上沒什么區別，但是在意義上小程序是騰訊實現“成為互聯網的水和電”這一企業愿景的堅實而正確的一步。很普通的技術，但是放到騰訊的平臺中，都可以因為量變引起質變。比如公眾號，其實就是增加了主動Push的RSS訂閱一樣的技術。應該沒有什么下載不下載，最多是給你在手機桌面添加一個自定義scheme的hyper link的快捷方式，打開以后也是直接切換到微信內置的Webview控件。

首先明確幾個概念：

Runtime，運行時環境。

所謂 runtime 就是能夠運行我們寫的代碼的代碼。說來很繞，理解起來很簡單——我們寫的代碼是要運行在一個特定的環境中的，這個環境負責具體執行代碼所表示的指令，也就是說代碼最終能有什么樣的能力、能實現什么樣的效果，不取決于怎么寫，而取決于 runtime 怎么理解和執行。

比如，你用 console.log('Hello World'); 想在控制臺里輸出「Hello World」，如果 runtime 就是要把「Hello World」轉換成「Vote for Trump」你也沒有任何辦法。HTML，特指符合 W3C HTML Specification 的標記語言，包括 4.01、5、5.1 等等眾多版本。并不是用「< 」和「>」符號包起來的就都叫 HTML，比如 <吃飯></吃飯>。CSS，特指符合 W3C Cascading Style Sheets Specification 的樣式描述語言，包括 Level 1、2、3、4 等眾多版本。網頁技術、web 技術——隨便怎么叫，特指用 JavaScript、HTML、CSS 幾種技術構建應用，最終運行在「瀏覽器」這個特定 runtime 中的技術。瀏覽器（中的 JavaScript 引擎）和 Node.js（中的 JavaScript 引擎） 都只是 runtime 的一種——它們決定了我們的 JavaScript 代碼能做什么，有什么樣的能力供我們使用。window.alert('Hello World') 就只有瀏覽器能理解，同樣 require('fs').readFile('/'); 也只有 Node.js 能明白是什么意思。微信小程序是眾多實現了 JavaScript（MAYA、3DS MAX、Nginx 以及某些游戲引擎也有） runtime 的環境中的一種。瀏覽器作為一個 runtime 的另一個重要特點是有 UI 繪制和用戶交互行為的捕獲能力——（曾經）只有瀏覽器能識別用 HTML 和 CSS 描述的 UI 結構和樣式，并捕獲用戶的輸入傳遞給 JavaScript 進行相應的處理。小程序也有 UI 繪制和用戶交互行為的捕獲能力，但嚴格來講，它并不能識別 HTML 和 CSS，對應的，它使用 WXML 和 WXSS 兩種標準來解釋標記語言和樣式描述，而標準由微信小程序自己制定。HTML 和 WXML 有交集、CSS 和 WXSS 有交集，但他們是不同的。Runtime 能理解我們寫的標記語言、樣式描述和業務代碼了，接下來需要去執行它們。而問題里提到的當年 Facebook 的客戶端，使用的是 Hybrid 解決方案——就是在平臺原生應用的外殼里嵌入一個 webview，它能提供基于 HTML、CSS 和 JavaScript 這些技術構建的應用所需的 runtime，因為它其實就是一個閹割的瀏覽器，不提供前進后退按鈕、書簽管理等等，只提供運行環境和繪制 UI 的能力。Hybrid 解決方案繼承了所有 web 技術的優點——跨平臺、易維護、易部署和開發成本低等，同時也繼承了所有缺點，而其中最為人詬病的缺點就是——安裝包體積大（由于兼容性問題，很多應用不想使用用戶設備自帶的瀏覽器環境，而選擇打包一個瀏覽器核心在自己安裝包里），以及 UI 繪制效率低。嚴格來講，所有最終放棄 Hybrid 解決方案的公司，都不是由于過分相信 HTML 5 和 JavaScript，而是對移動設備上的瀏覽器的核心部分（webview）的性能，特別是 UI 繪制性能，過分樂觀了。時間推移到 2015 年前后，開始出現了以 ReactNative 和 Weex 等技術方案為代表的新型技術解決方案，而小程序單純從技術實現角度來講，同這些技術方案差異不大——提供 JavaScript 的 runtime，用某種同 HTML 相似的結構化標簽語言來描述 UI 結構，用某種類似 CSS 的語言來描述 UI 樣式，然后將這些代碼直接繪制為原生 UI。這個過程中已經沒有 webview 什么事情了，所以微信小程序并不是我們平時所說的 web 技術，他們只是使用一樣或類似的語言而已（總不能說在 MAYA 里寫 JavaScript 腳本也叫 web 開發吧？）?？蛻舳碎_發的核心是通過 runtime 來調度和控制 runtime 之下的平臺能力，瀏覽器這個 runtime 下面的平臺是操作系統（Windows、macOS、iOS、Android、*nix 等），而小程序這個 runtime 下面的平臺是微信，這是二者的本質區別。再說下載。以前，網頁的所有內容必須要先下載再執行，而近些年瀏覽器提供了離線緩存的相關功能，讓網頁應用的非數據部分可以離線使用，但這樣會把問題復雜度直接拉成指數級提升——以前默認所有東西都要連網才能使用，現在要區分哪些可以連、哪些必須連、連上怎么處理、連不上怎么處理、要緩存的話緩存策略怎么設置，產品和技術上面臨的問題都太多，收益也未必有多大，如果離線使用是剛需還不如索性直接做 app，所以瀏覽器內的離線應用發展一直不溫不火，但如果你真心想做，還是可以實現首次下載后再次使用速度得到質的提升的。所以問題描述的慢，下載慢并不是癥結，UI 繪制慢、交互響應慢（得益于 JavaScript 引擎本身的性能提升，連 JavaScript 執行都不是瓶頸了，但占用 UI 線程導致整體卡頓是另外一個話題）才是根本問題，而這是瀏覽器本身的實現原理導致的。小程序也需要在首次加載的時候把應用相關的代碼（當然資源大小可能有差異）下載下來，這同網頁沒區別，而性能的提升體現在后面同 UI 相關的效率上，從這個角度講也不是什么新鮮事兒了，ReactNative、Weex 都是類似的原理和訴求。

所以需不需要下載，并不是兩種技術之間相比在性能上的主要差異。小程序的價值不是在技術上，而是在能否通過它來 leverage 整個微信生態及附屬其上的相關資源。這就要涉及到小程序作為 runtime 到底給接入商提供什么樣的能力、多大程度的把微信生態的資源暴露給開發者、入口位置、限制上等等，這就取決于微信自己的生態策略了。瀏覽器作為開放標準的中立技術，廠商對生態的控制其實非常有限，因為大家不希望互聯網的入口被某一家商業公司所完全掌控，這是為什么當年微軟選擇在操作系統捆綁 IE，也是為什么會被起訴壟斷。作為開發者，（大多數情況下）不需要考慮用戶用什么瀏覽器，因為各品牌的瀏覽器（通常情況下）遵循同樣的標準。過去十幾年不停有公司想基于瀏覽器做封閉的生態和標準，比較成功的也就只有 UC 一家了，但是大家可以問下作為 web 開發者對 UC 瀏覽器的平價是如何的 =。=...強化微信的「入口」能力才是小程序的野心。入口就是個門，既然是門就是雙向的——作為用戶，從什么途徑獲取到我需要的信息/服務（從哪扇門進去？）？作為內容/服務提供商，從什么途徑能夠接觸到我的目標和潛在用戶（在哪扇門后等候或者直接出去？）？

目前從官方發布的信息來看，微信描繪的圖景對于用戶確實還是很美好的，裝了微信，掃下二維碼就可以方便的交水電費；而對于服務商，現在還看不到太多的好處，沒有高曝光的入口，不能推送等等，直接限制了服務商 touch 用戶的能力，但如果你天然是個自帶流量的大 V 服務商，小程序能提高現有流量在某些場景（現在看線下可能是主要）的轉化率，則是能馬上實現的，但想從微信的生態拿流量可能就沒那么簡單，微信成貔貅把大 V 流量都轉化成自己的倒是很有可能。有微信全球 7 億月活的用戶（2015 年底數據）資源，至于是不是基于所謂的 web 技術來實現，who cares？

=========補充一下關于小程序最終使用 webview 渲染的事情。目前的小程序最終還是使用 webview 渲染，這是之前表述不嚴謹的地方。而我所說的 runtime 差異，是指開發者的運行環境依賴于什么。小程序的環境，就是開發者所能接觸到的最底層環境，開發者只依賴小程序給大家提供的環境。而這個環境再下層如何處理，并不受開發者控制，也沒有任何辦法 access，這意味小程序的開發并不依賴 webview，開發的目標平臺也不是 webview。

這樣實現的原因，可能有很多，比如綜合考量研發成本和收益、最大化利用現有技術等等。而可能性同樣很多，比如他可以隨時把渲染換成原生 UI，而不需要現有的接入商做任何調整。無論開發體驗多像瀏覽器，它都不是瀏覽器，即使它現在最終使用 webview 來渲染，開發者同這個 webview 中間還是有個中間件的，就像你不能說我在一個跑在 Windows 上的瀏覽器里做 web 開發就是在做 Windows 開發一樣。它是微信自己規定的一個新環境，只能同微信允許訪問的資源互動。

二十幾年 web 開發所積累的經驗，能復用到其中的除了語言層面之外，并不多，當然目前它的復雜度也不高。只要它定義好的 API、標準不變，作為 runtime 如何理解、執行就同開發者無關，更重要的是我們無法控制。WXML 轉成 HTML 再給 webview 渲染，這是 runtime 的行為，對開發者是透明的。

某個版本如果把 WXML 直接繪制成原生 UI 了，他不說用戶和開發者可能都是無法感知的事情。