从这个角度考虑，微信小程序过去说过的 “没有入口，不能转发到朋友圈，没有应用商店” 是合理的，它增强的就是现实，你不在那个现实环境中，就不需要它，为什么需要入口呢？虽然从今天发布的情况看，这个思路略微有了一点点变化，更多的非常现实场景应用也出现了，这算一种妥协或者野心吧。不过必须要扫二维码，而不是长按识别二维码才能使用小程序这个限制，仍然暗示了小程序在当前阶段是倾向现实场景的。

　　前面说了，无论是扫码还是 NFC，最终都是通过一个 URL，定位到需要的信息，这符合 URL 真正的含义，我们通常把 URL 翻译为网址，但它真正的字面意义是 “统一资源定位符”。在制订万维网 WWW 这个协议的时候，URL 的意义就是明确的，一个 URL 指向一份特定的资源（信息）。到了移动互联网的 APP 时代，新问题来了，一个 URL 到底应该展现在浏览器里面，还是通过浏览器再唤醒一个 APP，进入 APP 的对应条目呢？这个资源定位的链条突然变长了，不确定性也增加了。对于开发者，不同设备和不同浏览器最终展现出来的结果差距甚远。从这个角度看，微信试图提供一套统一的开发库和运行环境，让信息以小程序这种方式展现出来，这是一件好事。开发者可以避免更多的不确定性，用户在获取信息的时候可靠性也更强。我相信这是微信以小程序这种方式解决问题的初衷，其他的各种限制和规则都是在这个基础上的为了安全实现它而产生的。当然，这样如果做成功了，就顺便控制了一批新的数据的入口，战略意义重大。

　　至于有多少应用会使用这种形式，这是另外一个争论已久的话题：HTML 应用 vs App。在 iPhone 刚刚出现的年代，就有很多公司（尤其是媒体公司，比如 FT.com）试图通过 html5 的一些特性提供更好的网页浏览体验，避免开发 App 的高成本。特别需要指出的是，无论 iOS 还是 Android，从一开始就有把一个 URL 对面的页面，变成主屏幕上一个图标的功能，这并不是微信小程序的发明。今天回头来看，历史证明了，所有试图用 HTML 取代 APP 的公司，atv，最终都还是提供了原生 APP。后来还流行过一段时间混合应用，即在一个 APP 外壳里面装入 HTML5 的内容。毫无疑问，这种做法也失败了，其中最悲惨的失败者是 Facebook，直到 2012 年 Facebook 终于醒悟了不能这么做，回到了原生 APP 奋起直追，又收购了 Instagram 和 WhatsApp 两个最红的 App，终于没错过移动互联网这一波浪潮。2012 的问题在于 HTML 糟糕的性能，对硬件支持不够等等造成的用户体验不好，使用感受非常不流畅，今天这些问题差不多解决了。Facebook 也并没放弃过 HTML APP 这条路，现在份额最大的 Java 界面库 React 仍然是 Facebook 出品，它已经几乎成了事实上的标准。在移动互联网之前的时代，Facebook 自己实际上就是一个 Web App Store，里面塞满了无数基于 HTML 开发的应用。今天微信做的颇似 Web 时代的 Facebook，有趣的是 Facebook 自己反而走了另外一条路，后面我会再提到这条新路。从目前实现的情况看，因为 HTML 本身的限制以及微信自身增加的限制，多数情况下，微信小程序仍然没法替代原生 APP，它更像原生 APP 的一个快捷应用，或者叫 Widget 也许更准确。在用户没有安装或者没有打开 APP 的情况下，先快速获得信息。也许一部分小型应用会停留在小程序中，但大公司的目标一定不止于此，无论从任何角度看，小程序对于他们仍然只是一个快捷的接触客户导流入口，最终仍然要回到自己的 APP 才安全。至于所谓低频 APP，他们本来也就是无所谓形式的，这些 APP 存在什么平台并不重要，本来也没法靠它们构成一个平台的主要支撑应用。

　　微信公众号的发展也是这样的情况。最早的时候，公众号是为商家开发的应用。虽然也有不少商家使用它，不过一直不成气候。直到大量的个人用户进入公众平台，把它做为单纯的内容发布渠道，终于通过内容引爆了这一波公众号的浪潮，进而影响到商业应用。不过奇怪的是，微信官方的态度始终是重视企业应用，压抑个人应用。似乎个人总是更容易伤害用户利益，必须要时刻提防着，公众号各种权限都是对企业认证用户开发，对个人订阅号不开放。微信似乎认为公司更可靠，不过现实情况恰好相反，要做坏事的人花几百块钱就能注册一个公司壳，但个人总不能换名字换身份证。何况商业应用利润和 KPI 考核总是带来更大的作恶动机。从整个软件和互联网的发展历史看，最终获得最大利润的是公司，但每个平台最早拓荒的第一批人总是个人开发者。张小龙自己当年不也是以个人开发者身份开发的邮件软件 Foxmail 吗？到了微信小程序时代，个人开发者如果不去注册一个公司壳，竟然都不能参与开发了… 这显然是一种倒退。