打开APP
userphoto
未登录

开通VIP,畅享免费电子书等14项超值服

开通VIP
微信小程序和网页版程序的区别在哪里?


首先明确几个概念:
  • 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 了,他不说用户和开发者可能都是无法感知的事情。
作者:赵望野
来源:知乎





我想先从信息传递的角度来解释微信小程序的意义。

落入俗套,从张小龙谈起。大家都知道,张小龙加入腾讯是因为他做了一款特别成功的邮件客户端 Foxmail,腾讯收购之后,他就留在了腾讯,做成了QQ邮箱,做成了微信。

Foxmail 就诞生在 Web1.0 的时代,那时候张小龙的背后还没有腾讯,但他利用一种 POP3 的公开邮件协议,让 Foxmail 可以连接到全世界任何一个邮件服务商的服务器上,下载用户的邮件,他没有和他们一一谈成合作,这个协议是公开的,自由的。

Web1.0 的时代这样自由的协议有不少,IMAP、Telnet、HTTP……,作为冲浪者,最常用的是 HTTP 协议,HTTP 协议是基于「超级链接」的,你想要在自己的网页里引用别人的回答,完全没必要做什么「非法转载」,只要将对方的超级链接附上去,你的用户就能通过这扇门进入新的世界。也许可以说,互联网始于超级链接。基于超级链接,形成的最伟大的互联网应用是什么?搜索引擎。

搜索引擎掌控着几乎全网络的超级链接,然后把它们按照你的关键词整理好,让分散的互联网有了关键节点。你输入一个搜索词,点击十几次,可能切换了十几个网络服务提供商,你是没有任何疼痛感的。

张小龙的身份是很有趣的,作为 Web1.0 时代的遗老,从当年的开放性中获益,后来他把自己的 Foxmail 也搬到了 Web2.0 上面,做出了成功的QQ邮箱,再后来在移动互联网时代,他做出了一个超级 App ,在每个时代取得了成功,他眼中的互联网变化是怎样的呢?我斗胆猜测一下,他也许能看到无数令人兴奋的进展,但他也一定感觉到了一点:互联网的信息流动不再自由了。

是什么造成的这一点?两个东西的出现,社交网络和 App,他们的特点都是一样的:把自己封锁起来,让信息只进不出。互联网挨了这两刀,信息就都被困在小盒子里面了,不登录不能看,不关注不能看,不回复不能看,不用 App 不能看,不交费不能看…所谓的分享功能,好多只不过是吸引用户下载或注册的幌子…这时候我们再看看古老的「超级链接」,它可以说是互联网自由的大门,但是它在渐渐的关闭着。

我们能阻止么?很难。让信息只进不出,是互联网公司们一直想做的事情,在 PC 时代,大家虽然互有防备,但多少都基于同一个自由的协议,相互之间也就是一个标签页的距离。

而移动时代,大家把信息交换的标准都私有化了,开始可能是网页的效率问题只能用 App,但之后就是军备竞赛了。看一看有多少 App 几乎就是一个 Webview 就知道了,这和网页唯一的区别是能推送、抢入口、垄断信息。从商业上看,这是死循环,从互联网的本质上看,这让人难过。

张小龙作为一个文青高管,他的厉害之处就在于他总能找到自身执念和商业逻辑的结合点。如果手机只能装一个 App,那一定是微信。有了这个条件作支撑,他也许可以试一试,疯狂执行刚才那个无比正确的商业逻辑:让信息只进不出,形成闭环。但是,物极必反,巨大的信息垄断,也许会造成垄断之下的自由。

微信实际上在做一件什么事儿? Cosplay Web。(@黄玄 老师把这个叫做 Weixin Wide Web)

这件事,我觉得从公众号开始就有苗头了,公众号有 Timeline 吗?没有。有排行榜吗?没有。所有的得到,要么是主动出击,要么是接收别人的分享。搜索、点击、转发,一气呵成,我们既不需要跨越无数个内容 App,也没有一个什么公号推荐系统,就像 Web1.0 时代我们访问网络达人的博客一样,发现新的达人,要靠朋友的口口相传或者大神博客底部的友情链接(这不就是朋友圈和底部二维码么?)。

说到这里我好像看到张小龙大会发言一般紧张的笑:“你怎么能说这叫信息不流通呢?你看,你点这里,可以搜索所有的微信公众号,基本上中国生产的新内容,这上面至少有一份拷贝,你随意分享,什么,分享出微信?你不用微信,你分享给谁看啊?”

但公众号说白了也就是一个静态页面,和知乎这样内容社区的区别只是体量和质量上面的,只能吸引个体的内容作者加入,这只是模拟了 Web1.0 的时代。

微信小程序标志着微信终于到达了模拟 Web2.0 的时代,它真的像它自己的名字一样,是一个纯洁的小程序吗?不是的,它更像是一个在线可交互的服务,就拿知乎举例子,把知乎放到微信小程序上开个分店,是绰绰有余的,你一样可以提问、回答、关注、点赞(加粗)。

订阅号、服务号、小程序,就是一个个静态或动态的 Web 站点;二维码和消息气泡,一个现实,一个虚拟,就是微信提供的超级链接。

如果有微信这样的大盒子如同张小龙想象的那样一统江湖,想必微信会做类似 iOS 上面深度 spotlight 搜索小程序内数据的功能,这样,内部搜索也就成了通用搜索,内部链接也就成了通用链接……微信在里面结结实实地模拟了一把互联网,不自由里面的自由,会是美好的吗?这是中国里的互联网,也是互联网里的中国。

我们从商业的角度再考虑一下。

Web、App、微信小程序,这三种东西就像三种不同的流通货币,谁有货币发行权,谁就能吃全世界的红利,看起来 Web 是其中最中立的,但实际上,Web 的标准也是被大公司垄断的,Google 为什么在手里有 Android 这样的王牌的情况下还要大力推动 Web呢?前面说过,搜索引擎是 Web 时代自由链接的最大获益者。

那么,以前都是用 Google、苹果的货币结算,现在微信要入场了,对于微信而言,小程序不是程序,小程序是微信看上的整个互联网。

最终能赢得份额吗?我个人认为有可能,自由的 Web 在手机端渐渐褪化成底层技术,无根浮萍;强势的 App 又没能解决「盒子化」的问题,小程序的出现是很解渴的,我的印象中,UC、豌豆荚一览也都有过类似的想法,但他们的体量和这个目标比起来有些小了。

看马化腾和张小龙的朋友圈截图能发现,原本小程序想叫应用号,苹果绝不让步,足以看出苹果对「应用」这个词含有的使用属性的看重,但我们凑近来看,哪个更贴切呢?

苹果还不让微信做商店,但很可能这本来就不是微信考虑的层面,微信或者说张小龙的执念早早就被印在了首屏和导航:孤独与发现。

--------------------------------

2017 年 1 月 9 日更新:

今天,微信小程序正式发布了,我也深入地体验了一下(Android 端),并且进行一些具体场景下的思考。

先说说体验,起码在 Android 端,微信小程序的独立性可以说是非常好的:可以挂载到桌面,在最近任务栏也是独立窗口,独立线程,可以后台运行,微信暴露的 API 端口也算丰富,运行效率还不错,除了偶尔有闪屏现象。

从前有一个没有提到的问题,是大家很关心的:作为厂家,要不要开发微信小程序?什么样的厂家才应该开发微信小程序?

无论微信小程序的企图心有多大,厂家是否踊跃才是决定了它能不能成为新一代结算货币的关键。那么,厂家该怎么看这事儿呢?

我认为,对于有企图心的「工具类企业」,微信小程序是一次「颠覆性变革」,这么说并不是在耸人听闻,而是微信小程序制造了一个内在的逻辑尴尬。

如果我们研究一些互联网产品,会发现一直以来我们都面临着一个矛盾,工具类产品容易冲量,但不容易产生经济效益、不可替代性差,平台化产品又不太好同时引爆供应方和需求方,所有能看到非常多的巨无霸互联网企业,是靠着一个「工具类产品」走红,借着用户量开始平台化战略,比如 YY、迅雷、360 安全卫士、QQ 都是这样的。(我的另一个回答 微信与 QQ 的区别在哪?中有过对于「工具」和「颠覆性变革」的思考)

但微信小程序制造了一个逻辑尴尬:它的标准是「小」和「易流通」,这天然与企业背后的「平台化」战略相悖,也就是说,如果你是一个小程序平台上的工具制造者,将无法给投资人画出一张未来的大饼,说破了天,就算用户量破几千万,它也仅仅就是一个工具罢了。

仅仅这样,还称不上「尴尬」,尴尬的是,如果你是一个网络工具制造者,小程序偏偏还就是最适合「工具」的开发、发行手段,如果你由于「无法支撑平台化」不去做,怎么敢保证那些没那么有企图心的小富即安的开发者不去做呢?他们如果做了,借助微信的可触达性,你又怎么抵挡呢?

所以你会发现,很多类似工具型企业是把小程序当做第二个 Web 来用的:目的是诱惑用户下载 App(比如 今日头条Lite),而有关于纯粹工具类小程序的变现,仍需要腾讯官方予以重视。

但对于那些核心竞争力不在功能上的企业,就不需要有这样的顾虑了,大可以放手一试,尤其是「以信息为核心竞争力」的企业,比如招聘、旅游、论坛乃至值乎、知乎,微信用户身份的接入和最快的触达是所有信息企业梦寐以求的事情。

这也给了我一个新的看法,在微信的限制下,以前 App 时代用工具突围的模式可能不再靠谱了,但通过微信提供的账号体系和流通速度,也许创业者们可以跳过第一步,直接做出一个平台,这是个崭新时代,这一次,我们对接虚拟和现实。

---------------------------------
本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请点击举报
打开APP,阅读全文并永久保存 查看更多类似文章
猜你喜欢
类似文章
【热】打开小程序,算一算2024你的财运
微信小程序和公众号H5自动化测试技巧,赶紧GET!
27个赚钱思路 160G小程序干货 240个互联网小技巧
微信小程序:原生热布局终将改变世界
前端的就业方向有哪些选择?
Build an app with JavaScript and Lua
SAP Cloud for Customer的Container应用设计原理
更多类似文章 >>
生活服务
热点新闻
分享 收藏 导长图 关注 下载文章
绑定账号成功
后续可登录账号畅享VIP特权!
如果VIP功能使用有故障,
可点击这里联系客服!

联系客服