首先明确几个概念：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 了，他不说用户和开发者可能都是无法感知的事情。