关于小程序的两个猜测： 1. 性能体验和 H5 几乎持平， 2.不能做出流畅的游戏。

游戏收入才是苹果商店大头。

即便是 2017 ，你可以回想下你在手机上玩到的 h5 游戏最好的是哪个，对于我来说，当然是 flappy fog ，其余的无一例外 native

更正一下，是众筹的小鸟

小程序不是 HTML5

@murmur 所以猜测不是苹果不让，是微信为了遮羞。

小程序的性能在大范围动画上还不行，很卡

@em70 那你用 react native 开发一个游戏咯，小程序不就是 reacT naTive 么

@em70 我昨天在 iOS8 上看了一下，小程序是启动了一个 WKWebView 来运行的。能执行 alert ，可以确定小程序是运行在 webView 容器里的， 也就是用的 HTML 。

忽略主题

苹果和微信有协议 不允许上游戏

@murmur 谁告诉你小程序是 React Native 的？想当然可不好。

@sodatea 看我的拼写 为什么 T 是大写的呢

@arron 那就有意思了，如果他的容器真是 WebView 那性能还不如 Weex 呢
不过最终还是要用安卓或者 IOS 源生的调试工具看最后渲染出来的是组件还是 html dom 元素
能执行 alert 不代表就是混合应用啊

貌似有人提到动画的局限性，所以，我认为楼主说的在理

即使能做出来游戏，费的流量也不会比直接下载少，不值。

@arron
@sodatea
小程序比单纯的 HTML5 好的地方是可以“渐进增强”，即使现在是 webview 做的，完全可以升级到 native 。

其实我觉得，不会是因为协议问题吧。

@ivmm

如果 iOS 平台没有微信、 QQ ，卧槽，那估计也是废了。

应该不是协议的问题，是性能不足，动画一多就跪

@mooncakejs 渐进增强并不容易，现在小程序 native 的部分包括 tabbar ， toast ， alert 等脱离页面内容的东西，页面内并不能渐进增强。要么彻底换掉，要么用 webview 。

Android 上打开开发者模式的显示布局边界可以看出某些控件（地图视频 Tab ）是原生的，而且小程序规范语法有审核，普通 HTML5 加载到微信的 WebView 少不了各种检查预处理什么的，性能应该会好点吧

@murmur 意思是用 cycript 可以把那个 WebView 容器选出来执行 HTML 相关的 js 代码， alert 能跑，那么其他 dom 自然没问题，虽然没细究，但是可以肯定。因为如果用 cocoa UI 去渲染，那么只需要用 JavascriptCore 就可以了，根本不需要 WKWebView 。小程序这一套用 WebView 来渲染比用原生去做要好处理得多，别的不说，就 canvas 那一套规则就不容易搞。至于性能怎么样，就看使用场景了。

小程序是 native+html 结合的控件

游戏可以做，有 Canvas 。
体验嘛，见仁见智。

所以小程序应该降温了么？ 但我还是做了一个， https://hacpai.com/tag/book_share ，需要体验的可前往 https://hacpai.com/register?r=Vanessa 进行注册

@em70 https://mp.weixin.qq.com/debug/wxadoc/dev/devtools/details.html?t=201715 是 H5 ， 类似 phonegap 之类的套路。

@murmur
@arron

问了内部的人，是 native 的。大概就是 native + html 结合吧，像楼主 append 里列的 非原生组件 的渲染。

@yulanggong

@murmur

@arron

跑在浏览器里的不一定就是 HTML,小程序的渲染是微信自己用 js 开发的一套渲染引擎，没有用 HTML 渲染，效率比 HTML 高得多

@em70 对的。

@morethansean
跟安卓一样， native 那是顶部 navigation ， alert ， actionSheet 之类的。内容部分就是 HTML 。你那内部人估计也没搞清楚。
@em70 你猜的？

证据：

[choose(WKWebView)[0] evaluateJavascript:"document.getElementsByClassName('desc')[0].innerHTML='Im webView'" completionHandler: nil];

@em70 你不要告诉我小程序在 webView 容器里面基于 HTML 开发出了一套不需要 HTML 渲染，效率比 HTML 高得多的 UI 引擎！

@arron 只是用了 webview 里的 js 引擎，用纯 js 绘制一个视觉控件，不行吗？

@arron
就像页游，用 flash 渲染的，也没有用 HTML

奇怪，早期的文档中确实写了是使用类似 reactnative 的方式渲染的，现在怎么没有了，不过真说起来这性能真的是不行，用 webview 渲染还真有可能。。

@em70 楼主补充了。 https://mp.weixin.qq.com/debug/wxadoc/dev/devtools/details.html?t=201715
iOS WKWebView ， Android Mobile Chrome 。在 WebView 里面你不论是写 HTML 还是用 js createElement 那是一样的。谈不上性能差。况且小程序就是写的 HTML ，那个 wx-view 跟 div 是一个效果。

试试用 Chrome 去调试 WebView 看看； https://geminiwen.xyz/2017/01/10/mini-program/

@arron 你对 js 理解太局限了， js 并不是非要依赖 HTML 的，和其他语言一样，也是具备图形绘制能力的，完全可以自己绘制一个自己的界面。

@em70 js 的确并不依赖 html ，执行的时候也只需要 JavascriptCore （ iOS 平台）即可，但小程序『是由 WKWebView 来渲染的』，那很明显是（部分）转成了 html ，最终由 webview 来渲染的。

之所以我加了个部分，是因为有些组件（例如上面有人提到的地图）就是 native 的


@sujin190 我也记得我以前看到过是全部以 native 渲染的，估计在实现上踩坑了，然后又得赶着上线，只能先这么用了

@jhdxr WebKit 才是 HTML 渲染引擎， webview 只是一个集成多种引擎的容器。小程序如果是 HTML 的，应该可用 window 和 document 对象，但并不支持，所以也不能用 jQuery

@jhdxr
想要全 native 渲染基本就靠企鹅无限制的堆人力去做 binding ，而且 iOS 一放 beta 就开始全组加班的画面是不是太美了。。。
不过大厂有的是钱，说不定就这么搞 2333333

@arron 再次确认了一下，是 native

楼上一群人连 jscore 和 x5 是什么都不知道。。。所以想当然的说是 html 。。因为他们只知道 html ，，他们觉得 webview==html ， 无知是可怕的，可怕的是无知还要说出来

@em70 你想多了，在 WKWebView 里面只有一个渲染视图引擎，就是 WebKit 。你举出第二个来？小程序不能用 window ， document 是小程序屏蔽了，不让你用。我前面那两张图就是测试了，就是在微信的那个 webView 实例里面，用 document 去修改视图。你要是还是觉得不是 HTML ，你可以说一下小程序的实现原理。

@morethansean 官方文档里写了， https://mp.weixin.qq.com/debug/wxadoc/dev/devtools/details.html?t=201715 iOS 是由 WKWebView 来渲染的。

@d553296416 你以为的 jscore 和 x5 是什么？ X5 基于 Mobile Chrome ， Mobile Chrome 是什么？浏览器啊，你现在告诉我浏览器跑的不是 HTML ？你来解释一下小程序的实现原理。

小程序其它是用易语言做的。

@d553296416 人外有人，山外有山，你说话的语气，真让人受不了

不让用 window 或者 document 可能是因为用原生的方式不太稳定,先用 webview 用着,但是保持以后 reactnative 语法的兼容性.

有直播类的小程序？我正在做这个产品规划。

就流畅度， Android 上的小程序比 H5 好太多了。。。

大 web 一统天下指日可待。

@d553296416 好大的口气，没看见 LZ 的 append 吗？『是由 WKWebView 来渲染的』『是由 X5 基于 Mobile Chrome 37 内核来渲染』，我们讨论说是 html 是基于这一点来判断的。既然你那么厉害，那你来告诉我， webview 除了渲染 html ，还能渲染神马？别告诉我是 css 和 js 。装逼是要给出干货的，不然你就是傻逼了

不管如何，小程序的体验确实比一般的 HTML5 应用好非常多

就是 native 加 html

@jhdxr 这个解释非常合理

初代苹果不允许三方 app 。微信完成了这个轮回。

@arron 好歹上了个 cycript 的运行时分析，支持方都是靠脑补

感觉就是 super webview

@jhdxr 还真的是 js 。。。

本身就是下发 js 代码 通过 x5 或 jscore 解释器 最终调用的原生组件啊。。。

@d553296416 你想说的是像 react native 那样吗？那的确和 html 没关系，人家也没用的 webview ，就只是 jscore 解释运行而已。但是你看清楚了小程序说的是『运行在 JavascriptCore 中』『由 WKWebView 来渲染』，换句话说，最终调用的还是 webview ，那自然很合理的就能推测是翻译成了 html 。而且 29 楼 @arron 也给了例子，你要是调用的是（除了 webview 以外的）原生组件，哪来的 document 给你改？

小程序的产品定位就不是为了做游戏

@arron 这个是怎么看的

大概主要运算单独一个 js 线程了吧， ui 就不会被 block 了

哪来那么多争论的，就现在使用体验来看，不管是 ios 还是 Android ， H5 都比小程序差了一大截-_-

@leefly 越狱设备， http://www.cycript.org/

https://www.zhihu.com/question/54620973/answer/140245002
https://zhuanlan.zhihu.com/p/24782839
https://www.zhihu.com/question/51183070/answer/127210906
https://www.phodal.com/blog/weapp-demo-process-webkit-app/

现在还在坚持小程序是 native 的人你们是多闭塞啊？

小程序是一个产品，不是什么技术解决方案，它的目的是建立一个属于腾讯的庞大生态圈，技术什么的都是次要的。
之所以小程序的开发语言高度抽象，就是为了将来可以无缝切换升级底层技术。

不是微信实现了一套 jsbridge 嘛 难道我想错啦。。。。

@arron 正解，我早上起来写了一篇博客[纠正对微信小程序的一个认知]( http://faywong.github.io/2017/01/12/weixin_xiaochengxu_01/)，观点就是目前的小程序主要就是 native 。

@faywong8888 手抖，敲错了，是：[纠正对微信小程序的一个认知]( http://faywong.github.io/2017/01/12/weixin_xiaochengxu_01/)

我的一些猜测：

应该就是普通的 Web 技术来实现的, 比普通的 web app 体验要好的原因是小程序他有自己的一套框架, 如果框架既定的话，微信就比较容易来实现一些性能优化.
而常规的 web app 体验的好坏和开发者的水平有直接的关系.
我相信能力强的开发者做出来的 web app 体验未必会比小程序差多少.

还有一个重要的原因在于 native 环境可以对 web 的一些关键步骤做增强

比如我现在负责实现公司的 native-to-web bridge, 在启用 bridge 后体验确实会好不少.
而且还有很多优化的余地， 比如把资源放在本地，然后采用某种策略来动态更新本地资源而不依靠 browser 来更新资源, 效果应该还会好不少. 这一步是我现在正在尝试的方向

还有一句话想说： NO Magic ！不必要过分迷信和臆想, 都是可以通过自己分析出来的嘛....

产品考虑业务，总裁考虑战略，我们程序员才考虑性能。

@jhdxr rn 就是用了 webkit 渲染的啊。。 wk 就是 webkit 里面的啊，但 rn 不是 html5 啊。。。。。大哥你是得有多菜。。。。

@d553296416 看到这里可以确认你是无脑喷了

挖坟

再挖