1. 中国特色的移动互联网时代
伴随着QQ小程式面向使用者开放，这个手机端月活7 亿的巨无霸正式入场。小程式，终于成为了超级app的标配。
盘点下已经支援小程式的超级app：
微信、企业微信、QQ、支付宝、高德地图、手机淘宝、百度、百度贴吧、百度地图、今日头条、抖音……
这些璀璨耀眼的名字，背后都是巨大的流量。
在这群超级app的支援下，中国的移动互联网格局被彻底改变。
这个有中国特色的移动互联网时代，被称为“小程式时代”。
这是继手机支付后，中国的移动互联网领先世界的第二个代表事物。
中国的技术标准、开发者生态，第一次得到大规模的普及应用，而且很明显，小程式在功能和体验上均超过了HTML5。
中国人能建立开发者生态吗？这个命题曾一度让人怀疑。
小程式完成了这一步突破，这是一场值得歌颂的中国技术生态发展史。
让我们来回顾下这场技术生态，是如何开始，又将要去向何方。
2. 罗马不是一天建成的，小程式不是一天发明出来的
HTML5于 2007年在W3C立项，与iPhone释出同年。
乔布斯曾期待HTML5能帮助iPhone打造起应用生态系统。
但HTML5的发展速度并不如预期，它虽然成功地实现了打破IE+Flash垄断局面的目标，却没有达到承载优秀的移动互联网体验的地步。
于是在iPhone站稳脚跟后，释出了自己的app Store，开启了移动互联网的原生应用时代。
随后的Android，本来是基于Linux的 OS，与之同期的MeeGo等竞争对手采用C +HTML5的双模应用生态策略，然而C 的开发难度太大，HTML5体验又不行。Android依靠Java技术生态，在竞争中脱颖而出。
于是在移动互联网初期，应用生态被定了基调——原生开发。
在那个时候，硬件不行，也没有其他办法，原生开发才能在低配硬件上带来商用体验。
但大家都在怀念HTML，那种无需安装更新、即点即用，直达二级页面的特点，一直让人迷恋。
国内有一批做浏览器的厂商，尝试去改进HTML5，他们提出了轻应用的概念。
通过给WebView扩充套件原生能力，补充JS API，让HTML5应用可以实现更多功能。
不过这类业务没有取得成功，HTML5的问题不止是功能不足，效能体验是它更严重的问题，而体验问题，不是简单地扩充套件JS能力能搞定的。
这类业务发展的顶峰，是微信的JS SDK。
作为国内事实上最大的手机浏览器，微信为它的浏览器核心扩充了大量JS API，让开发者可以用JS呼叫微信支付、扫码等众多HTML5做不到的功能。
微信JS SDK说明文件
但微信团队对这套方案的体验仍然不满意，微信钱包栏目里打车、理财等很多应用虽然嵌入了JS SDK，但每次点选要等半天白屏，让人用着很痛苦，他们在业内开始寻找新的解决方案。
业内早有专业团队看到了相同的问题。
与浏览器不同，Hybrid应用是另一个细分领域。它们为开发者提供使用JS编写跨平台应用的工具，为了让JS应用更接近原生应用的功能体验，这个行业的从业者做出了很多尝试。
笔者所在的DCloud即是其中之一，我们提出了改进HTML5的“性工能”障碍的解决方案 —— 通过工具、引擎优化、开发模式调整，让开发者可以通过JS写出更接近原生app体验的应用。
多WebView模式，原生接管转场动画、下拉重新整理、Tab分页，预载WebView……各种优化技术不停迭代，终于让Hybrid应用取得了效能体验的突破。
Hybrid应用和普通的轻应用相比，还有一个巨大的差别：一个是Client/Server，一个是Browser/Server。简单来说，Hybrid应用是JS编写的需要安装的app，而轻应用是线上网页。
C/S的应用在每次页面载入时，仅需要联网获取JSON资料；而B/S应用除了JSON资料外，还需要每次从服务器载入页面DOM、样式、逻辑程式码，所以B/S应用的页面载入很慢，体验很差。
可是这样的C/S应用虽然体验好，却失去了HTML5的动态性，仍然需要安装、更新，无法即点即用、直达二级页面。
那么C/S应用的动态性是否可以解决呢？对此，我们提出了流应用概念，把之前Hybrid应用里的运行于客户端的JS程式码，先打包释出到服务器，制定流式载入协议，手机端引擎动态下载这些JS程式码到本地，并且为了第一次载入速度更快，实现了应用的边下载边执行。
就像流媒体的边下边播一样，应用也可以实现边用边下。
在这套方案的保障下，终于解决了之前的各种难题：让JS应用功能体验达到原生，并且可即点即用、可直达二级页面。
如今看来，这已经变成了常识。但在当年，先驱们做了无数艰辛探索。
这套技术，需要让客户端引擎提前预置在手机上，就像流媒体的普及，建立在Flash的装机量巨大的基础上，那么普及这个客户端引擎就变得很重要。
2015年，360和 DCloud合作，在360手机助手里内嵌了这个客户端引擎，推出了业内第一个商用的小程式，360称之为360微应用。
微应用实现了在360手机助手的应用下载页面，同时出现了“秒开”按钮，点选后直接使用。
并且在360手机助手的扫码里，应用的分享里，都实现了扫码获得一个应用，点选分享讯息获得一个应用。
为了做大生态，DCloud把这套技术标准，捐献给了HTML5中国产业联盟，随后，联盟开始推动更多的超级app和手机厂商加入，共同推进动态app产业的发展。
然而事情并不顺利，巨头们有自己的利益诉求。虽然有一批厂商同意加入联盟共建生态，但最关键的角色，真正的国民应用“微信”，最终决定自立标准、自研引擎，当然技术原理与流应用是基本一致的。
2016年 1月 11日，微信公开课，张小龙罕见露面，公布了微信应用号的计划，为这个大事件亲自站台。
2016年 9月 21日，微信宣布更名应用号为小程式，面向首批开发者内测。从此，这个词被正式定了下来，“小程式”，成为后续一个时代的代名词。而“流应用”、“微应用”则淹没在历史长河中成为一个令人唏嘘的故事。
2017年 1月 9日，微信公开课，小程式面向使用者正式推出。
从此后，阿里巴巴、手机厂商联盟、百度、今日头条，陆续推出了自己的小程式平台，其中也有很多波折与故事，在有偶然、有必然的过程中，形成了今天的局面。
小程式大潮卷入了更多人，并形成了更大的浪潮，最终迎来了不可逆转的小程式时代。
3. 生态难，难于上青天
发明能解决功能体验和动态性的技术方案，虽然难，但不是最难的事情。
最难的是开发者生态的建设。
最初HTML5中国产业联盟的策略是在HTML5上扩充套件强化，复用现有的HTML5生态。
当微信的标准完全自立重建时，业内人士都悬著一颗心。
在全球，基于Web的技术生态已经非常成熟，各种开发工具、框架、元件、模板...提升著开发者的效率。
小程式丢弃了国际标准组织W3C的 DOM和 Window标准，仅仅采用基础JavaScript。这意味着HTML5生态的各种轮子无法复用，要完全重造一个新的小程式开发生态。
当初微信推广JS SDK时，是那么地顺其自然，开发者纷纷开始使用，因为对于开发者，只是在他们的H5版本上补充一些API而已。
而小程式初期，充满了开发者的质疑声：我的业务迭代那么久，让我重新做一个版本，你的生态到底能不能支撑我的投入？
微信用持续而快速的版本升级、高管的站台，告诉大家微信做小程式的决心，并最终通过2017年底的跳一跳，引爆了小程式。
从此大家的问题不再是我要不要做小程式了，而转向了：既然要做，怎么才能提升小程式的开发效率、降低开发成本？
任何一种技术，或者开发模式的演进，在不断成熟的过程中，都遵循着类似的成熟规律：
技术标准 -> 基础平台 -> 开发工具 -> 培训市场 -> 框架诞生 -> 周边生态逐步完善 -> 轮子之上的轮子
在HTML5生态里，已经发展到最终极的形态，比如Vue是一个重要框架，而基于Vue的各种丰富的UI库、测试框架，则是轮子之上的轮子。
多层轮子代表着生态的繁荣，也意味着开发者的开发效率更高。
可微信的全新标准出现时，它把开发者推回了原始社会，一切都要重来。
这在当时看来，并不是一个必然会成功的事情（其实直到现在，比如图表类轮子，小程式仍然比不过HTML5）。
时至今日，讨论这个标准的选择对错已经没有意义。当支付宝、百度、今日头条都开始参考这个标准做小程式时，时代已经不可阻挡。
所幸，最终的结果是，中国人做成了。在国际标准之外，在中国，终于建立起了自己的技术生态。
并且这个生态，给使用者带来了更好的体验，给开发者带来了更多流量和变现效率的提升，这是一个比HTML5更优秀的生态。
4. 野蛮的技术生态成长速度
两年时间，中国的小程式开发者如何从原始社会进阶到现代文明？这也是一段有趣的历史。
我们来看看小程式技术生态是如何快速成长，走完上面所说的这套技术成熟路线，也就是从技术标准到轮子之上的轮子的。
在Web世界里，已经成熟到了原生JS用量很少的时代了，开发人员大量使用Vue等框架，并且在Vue的基础之上，又有更多轮子。
当中国的开发人员面临重头开始时，他们感受到效率对比的差距，既然时代已不可阻挡，那就拥抱它。勤劳的中国技术人开始蓬勃地建设起了小程式各种周边技术生态。
其中比较重要的是开发框架的迭代，我们看看每个小程式开发框架为什么会诞生、流行和衰落。
最初的微信小程式，一片荒蛮，一份文件 + 一个难用的IDE，很多效率工具比如npm、前处理器这些都不支援，而这些已经是大型专案离不开的工具。
于是，第一个标志性的框架出现了 ——WePY。
WePY紧随微信小程式在2017年释出，原本是腾讯其他部门的一个个人工程师的作品。在那个年代，WePY有效地解决了小程式不支援npm、前处理器的痛点，被引爆后，腾讯官方才把这个框架收编到官方的GitHub下。
不过WePY也面临很多问题，它使用了私有语法，这让它在生态建设上面临很大难度，IDE着色、语法提示、语法校验、格式化、人员招聘培训等各方面问题制约着它的流行和普及。
面对这些问题，人们开始思考，有什么更好的方式，可以复用现有技术生态来快速完善小程式生态？
这时候下一个重要框架借势诞生，美团前端在2018年初开源了MPVue。
MPVue采用Vue语法来开发小程式，通过对Vue.js的底层改造，实现了编译到微信小程式。
MPVue良好地借助了Vue的技术生态，周边工具如IDE、校验器、格式化等支援直接复用、人员招聘培训等生态建设压力大幅下降，受到了大量开发者的欢迎。
看着熟悉Vue的开发者终于有了趁手的轮子，那熟悉React的开发者怎会无动于衷？
京东团队是React的重度使用者，还自研了JDreact，于是他们开发了Taro框架，一款基于React语法编写小程式的框架。
但Taro并不是想简单做一个MPVue在 React世界里的翻版，Taro相比MPVue，想要解决更多重要问题。
Taro面世较晚，此时微信、支付宝、百度、头条都已释出或宣传了自己的小程式，开发者面临一个多端开发和适配的问题。
于是Taro率先支援多端开发，它甚至还能释出到H5和 app。
图片来自：京东凹凸实验室
当时小程式领域还有一个重要变化，微信开始支援小程式自定义元件。
元件是一个成熟框架不可缺的东西，不管是Vue还是React都有丰富的元件生态。
在过去，MPVue时代，是把Vue元件也编译成页面模板，这带来一个很大的效能问题，在复杂页面里（比如长列表）使用元件，更新元件状态会导致整个页面的资料全部从JS逻辑层向检视层通讯一次，大量资料通讯会非常卡顿。
注意：小程式的逻辑层执行在V8或 JSCore下，和检视层是分离的，通讯阻塞很容易引发效能问题。
于是Taro把 React元件编译为新出的微信小程式自定义元件，这种元件在资料更新时，只会更新元件内部的资料，而不是整个页面更新资料，从而大幅减少了资料通讯量。
这一轮的后浪推前浪很猛，Taro在效能和多端支援上，都超越了MPVue。
看着React阵营取得如此成绩，Vue阵营自然会继续追击。
我们基于Vue开发了uni-app，它实现了自定义元件编译模式，并在算法上做了很多优化。另外，之前MPVue对 Vue的语法支援度不太完善，比如过滤器等不支援，在uni-app中我们进行了解决。
同样，uni-app也看到了前浪的其他问题：Taro虽然迈出了多端的第一步，但多端支援能力比较弱，每个平台仍然各自开发大量程式码。核心原因，是Taro在 H5端和app端，并不是一个完整的小程式技术架构，无法保持最大程度的统一。
于是uni-app在 app端，使用了一个技术架构相同的小程式引擎，本身就可以直接执行小程式应用，这个引擎搭配小程式程式码打包为app，开发者一行程式码不用改，可以同时释出小程式和app。
当然，其app引擎从Hybrid应用起家，它提供的API要比小程式多很多，因为app的需求会比小程式丰富，它还支援把WebView渲染引擎替换为Weex渲染引擎。
之后uni-app又释出了H5版的小程式引擎，原理与小程式的PC模拟器相同，实现了良好的跨H5版的释出。于是uni-app比较完美地实现了开发一次，7个平台释出。
第一层轮子就这样迅速发展了起来，Web世界里最成熟的Vue、React技术生态被汇入了小程式开发生态中。然后轮子之上的轮子开始如火如荼的建设。
以UI库为例，之前的UI库，有Vue库、React库，有PC库、H5库和小程式库，种类繁多，甚至说混乱。
比如在Vue阵营中，Vant和 iView这两个UI库，都是同时维护两个版本，它们即有H5版，又有小程式版。
不止框架作者麻烦，开发者想在多端使用这些UI库时，会发现在不同端还需要引入不同的UI库，写法都不一样，这让开发者很崩溃。
既然已经可以多端开发应用，于是在多端开发的领域里，开始出现轮子之上的轮子，多端UI库。
首先是Taro推出了Taro UI，实现了H5和小程式UI库的统一，不过可惜Taro UI不支援app端。
然后uni-app推出了uni UI，这个UI库同时支援多家小程式、H5、app。
由于uni-app和 MPVue同属Vue阵营，它们的元件是互通的。于是这两家联合举办了一场外挂大赛，建立了外挂市场。
在中国的前端开发者领域，有很多和国外不一样的地方：一个是国内有小程式，第二个是国内Vue的开发者体量远超过React和 Angular。这里面很大的原因，是Vue.js的作者尤雨溪，是中国人。
Vue和 React百度指数对比
在庞大的Vue使用者体量支援下，uni-app和 MPVue的周边生态迅速发展起来，开发工具、周边轮子、教育培训等生态快速完善。目前在Vue阵营下，开发者在Web生态下所需的轮子，在多端开发下基本也都有了。
短短两年时间，小程式开发生态里几拨迭代，轮子之上的轮子不断涌现，快速进入了成熟期。
5. 结语
产业还在继续发展，每当底层有重大技术变更时，上层框架世界就会发生新机会。
当年HTML5标准不统一，浏览器相容性问题严重，诞生了jQurey的机会。而在移动互联网下半场，浏览器相容已经不再是核心问题，jQurey的地位被更适合移动互联网的Vue替代。
我们不知道未来还会有什么新的框架出世，但我们知道方向：
对于开发者而言，总是会向着更高的开发效率、更高的效能、更高的投入产出比前进。
对于开发商，目前的小程式，虽然发展了2 年，但流量增长空间仍然巨大，微信之外，很多超级app的势能将逐渐释放，整个小程式产业的日活总量有数亿的提升空间。
如果开发商能追上这拨红利，就能获得更多增长。而多端框架的出现，可以帮助开发商更好的把握这拨红利。
