小程序的本质还是WebView, 只是部分组件使用了原生组件，比如下面的TabBar和上面的NavigationBar。但是既然也是WebView，为什么官方还宣称说小程序比h5更媲美原生体验呢？
因为相比传统h5做了很多的优化。首先我们都知道默认情况下浏览器页面是单线程的，也就是js的执行会阻塞页面渲染，这也就是为什么建议把script标签放到body的最后。而小程序把js逻辑抽离出来了，
相当于一个worker线程，因此小程序中执行的js并不影响页面渲染的性能，小程序中的worker线程和UI渲染线程是通过底层的JSBridge去通信的。因为小程序页面和Vue差不多，是动态的，会绑定一些动态变量，
所以需要worker端把数据传到渲染线程。
小程序我们写的是wxml，而既然小程序的运行环境是webview，那wxml肯定最终还是要变成html，而html里面我们都知道并没有小程序的那些标签像view、text这些。这里是通过exparser实现的，本质就相当于WebComponents里面的shadow dom，就是自定义组件。，但是我们不能直接将wxml编译成html，原因还是因为上面所说的有动态数据，因此wxml编译成的是js，通过wcc(微信官方的编译器)可以把wxml编译成js，而后通过$gwx方法可以得到一个用于创建虚拟dom的方法，那么只需要把对应的data传给该方法，就可以生成虚拟dom，最后虚拟dom的dom diff之类的工作是由小程序基础库去做的，这里我们就不必关心了。
同样的道理，我们写的wxss也只能编译成js，因为小程序里面提供了rpx，也就是响应式的大小，类似于px2rem的原理，而要实现响应式肯定还得执行js，获取屏幕dpr，屏幕宽度之类的。
小程序的开发效率比较低，怎么提效呢？因此又出现了多种小程序框架。而这些框架大概分为三种，一种是纯编译时框架，第二种是半编译半运行时，第三种是纯运行时框架。
第一种的代表就是腾讯官方的wepy，以及京东的taro 1.x，这种就是要构建AST，词法分析语法分析，好处是性能高，因为编译完成以后就是原生的小程序代码，和我们原生开发小程序性能一样，缺点就是官方要做大量的适配，如果js框架出现了新语法，这边也要去做对应的处理最终转换成原生小程序代码，而且作为开发者很多用法也是受限的，比如react hooks，如果taro不做适配你就用不了。
第二种代表是mpvue，半编译是说它也要把vue里面的template编译成wxml，而半运行就是说最终小程序里面是有Vue的运行时的，小程序的事件都会代理到vue里面的事件处理，而vue里面的data更新也要通过setData的方式同步到真正的PageData。这样vue只负责数据的处理，不负责页面渲染。
第三种代表是阿里的remax和腾讯官方的Kbone，这种好处就是react或vue的所有语法特性(不是绝对，但相比纯编译时框架要好的多)都可以使用，因为最终运行的就是vue和react运行时。而这种mvvm框架不管是vue和react，底层肯定都是要操作dom的，也就是document.xxxxx，而小程序里面是没有dom环境的，那么我们就自己搞一套适配器，模拟出dom api供vue、react调用，模拟出来的dom api是对虚拟dom的操作而非真实dom，最后再通过wxml把虚拟dom的数据渲染出来(其中利用了小程序的自定义模板特性)。