前言(可跳过)
我是一个十多年经验的java(为主)工程师，当然架构、管理都做，因为热爱编码，所以一直没有放弃过编码，自认为是Maven、Spring MVC、Docker等当前流行技术的最早一批国内实践者。最近小半年用Kotlin+Spring做后台，Vue+js做前台亲手做了两个项目，一个涉及机器学习的服装项目，另一个是涉及专业运动知识的羽毛球比赛裁判软件。
Kotlin做后台应该算是比较新的事物，当然Vue虽然是目前最年轻有为的前端MVVM，但已经不算新鲜，当这两者结合的时候，我突然感觉焕发青春，爆发出了巨大的生产力，做机器学习项目+Saas平台，功能开发基本只用了两周时间，剩下又用了两周时间兼容百度识图API(我做的是百度的竞品)、测试、算法调优、上线。这其中Kotlin相比java的简洁高效，(时隔六年重新接触前端)Vue框架本身及生态的优秀让我非常享受写代码的过程。

小程序开发的痛点
让我们开始今天的主题——微信小程序。由于微信小程序是由微信拉起运行的，所以我做运动互联网项目时，做到一个移动端轻应用时，自然而然地想到了小程序，它相比原生App有几个巨大的优势：
1、 一套代码，跨手机(主要是iPhone和Android两大阵营)；
2、 省去了IOS、Android应用发布的各种繁琐的上架过程和成本；
3、 用户安装成本低——扫一扫或者打开一个微信链接，就可以开始使用了。
做微信小程序，不得不说说它背后主要的开发语言和技术：javascript
回想六年以前，我做完后台去支撑前端小伙们去优化较复杂的前端逻辑，那时NodeJS才刚刚起步，在浏览器开发领域jQuery如日中天，Bootstrap正崭露头角，面对前端大量重复的代码和逻辑结构的混乱，除了RequireJS这样一个模块化库，还没有什么比较趁手的工具。为了重用代码、进而简化代码结构，我强行使用了RequireJS，并初步实现了一套纯前端的模板化开发模型以实现视图与逻辑的分离，过程中也解决很多不曾有人解决过的问题，但是遗留了几个很重要的问题：
1、 代码拆分成模块后html或者业务代码中有很多RequireJS声明，由于RequireJS是纯浏览器端的模块化工具，不得不声明每个模块相对于html或js入口的相对路径；
2、 由于异步加载，调试时，并不能很容易地找到源代码，也很难分析一个页面到底会下载多少文件。
六年以后，再次较认真地接触js生态，发现变化是巨大的，我发现我当时遇到的问题，都已经不再是问题：
1、 NodeJS+Webpack打包已经更好地解决了代码模块化和重用的问题；
2、 浏览器的进步，以及.map文件已经成为后台打包提供了良好的调试支持；
3、 React、Angular、Vue已经良好地支持了视图层与业务层分离的问题，交互复杂的页面代码结构可以异常清晰——当然对国人来说最有意义的当属中文资源丰富的Vue。
甚至java一直在梦想、从未被实现的目标，眼看就要被javascript实现了——跨平台的PC端应用开发(Electron框架了解下)
当开开心心做完了两个Vue的项目之后，再回过头来要把H5应用翻译为同样是“基于js”的微信小程序的时候，发现我又几乎回到了刀耕火种的时代：
1、 小程序很大程序模仿了Vue框架，但是除了js代码结构有那么一点相似以外，一切都不一样；
2、 已经开始做npm兼容，但是lodash、async-validator、jsencrypt等等大部分本不依赖浏览器环境的常用组件都不支持，浏览器相关的组件就更别想了，原有的JS资产基本不能继承；
3、 视图、业务逻辑也有模仿Vue做了分离，但是相对于Vue来说，模板语法太弱了，要多写太多双向绑定的代码，watch与计算属性也有诸多限制不敢多用;
4、 抛开框架，原有的html标签全部不能用(尤其table还没有对应的标签可替代)、less、scss不能用都得改写为css，甚至css也有部分不兼容(稍复杂点的选择器)；
5、 微信开发者工具相比VSCode和WebStorm的差距，我觉得目前功能上的差距暂且不表，见仁见智，但是后两者“插件”的扩展性，会让差距越来越大，微信开发者工具很难有超越的可能。
其它诸如网络请求方式不一样、不支持cookie的问题，拿适配器模式封装一下，用Storage实现Cookie以兼容服务器Session这类能一劳永逸解决的问题，在我眼里都已经不是问题了。
之所以说是几乎，是因为微信小程序确实支持数据双向绑定、模块化，已经比只有jQuery可用的时代有很大的进步。
原本半天、一天开发出来的功能，搬到小程序里，在有代码可复制的情况下，得双倍甚至更多时间，遇到不支持的npm组件，还得找替代品或自己重新实现、甚至不得不放弃一部分功能(RSA加密)。
让我更郁闷的是，一个原本流畅的页面，搬到小程序里面，居然会卡顿

图1 小程序代码

图2 Vue代码
就是上面这样一段代码，没有网络请求，写法也没有什么差别，只是按用户选择的条件对一个几十条数据的Array进行过滤，然后再渲染到页面。如果大家都使用的是V8引擎，造成性能差别的可能有两个：
1、 微信小程序页面渲染的效率不如Vue的虚拟DOM，甚至不如html标签的渲染效率(列表因为key的不一致，在Vue里面也不会重用DOM结构，虚拟DOM并不比html原生标签高效)；
2、 微信每次setData都是数据复制、页面与逻辑之间又存在一次跨线程的数据复制，但是几十条数据的复制，绝对造不成一两秒的卡顿，至少不是主要因素。
按照微信小程序框架的设计，很多页面组件都使用了(iOS或Android)原生组件，这当然是为了提高效率，但是实际效果令人汗颜，我只能说浏览器这么多年的发展，不是微信小程序一朝一夕能超越的，如果生态跟不上，那差距只会越来越大，除非不差钱往里砸，请一些顶级人才来做设计开发(像.net早年对抗java那样，但即使.net本身比java优秀，还是败在生态)。

曙光
当经过痛苦的一周多切换，我的H5应用搬迁接近尾声，也是交互逻辑最复杂的页面的时候，我实在忍受不了代码的大量改造和重复了，于是尝试了下用微信小程序的WebView来嵌套我的H5应用，居然发现可以完美运行，并且上面说到的卡顿问题，在小程序WebView里面也是不存在的！！Vue单页应用的页面切换速度，也明显快于微信小程度的页面切换
同时为与微信对接，做了两点改造：
1、 对于微信登录的问题，依然在小程序里面调用登录，然后把code拼到url中通过WebView传给H5应用，再去后台做微信绑定登录的操作；
2、 对于页眉导航，通过环境探测，在微信中不显示页眉，并将导航功能显示为半透明的浮动按钮，来兼容小程序中打开与浏览器中打开两种场景。

至此，我的H5应用搬迁到小程序，痛苦重写了一周多，最终以嵌入WebView的两天兼容性开发、测试工作结束。

思考
功能是开发完了，但是微信小程序开发文档里面对WebView限制的描述，总是让我担心有一天我的小程序不能再运行，以及WebView不支持与微信更深度的集成。我想对微信小程序团队说：如果微信小程序能兼容浏览生态，会有无数的H5应用可以直接或者经过少量改造(这些改造甚至可以做成组件，进一步减少改造的工作量)，各个开发团队，也将以更快的决策速度和开发速度，将移动端实现为小程序+H5应用。
对于如何实现浏览器生态的兼容，并且不影响已有的小程序，我的思路如下：
1、 扩展Page或Component的类型，使Page或Component支持本身就是一个纯WebView，开发者可以直接使用开发H5的方式开发应用，用自己想要的打包机制打包html、js、css等资源 ，并将页面本地化地引到Page或Component中——之所以不提在现有的WebView组件基本上扩展，是Page是本地运行的，而现在的WebView组件是用来运行远程页面的(而且不能在微信中调试)，本地会有本地的优势；
2、 前端页面本地运行之后，带来的问题是CSRF的问题，解决方案可以是让开发者去改造自己的后台代码，但是依赖开发者能力水平，会真地引入CSRF问题；所以对内核的改造是取合适的，其实只要在网络请求上做一点小改动，通过DNS或者直接修改http包头，让浏览器内核认为本地的代码是运行在配置好的后台安全域名上就好了，既然限制后台地址可以做到，这也可以按限制后台地址的方法实现；
3、 对于小程序API，可以像公众号那样，提供JS-SDK；
4、借用微信网页版的已有资产，很容易推出基于浏览器的调试插件，甚至网页版微信同时也能拥有打开部分小程序的能力(就看微信想不想了，这点基于CSRF的限制很容易控制)；
5、 放开WebView或浏览器化Page的限制(尤其是针对个人开发者的)，如果已经限制了后台地址，WebView还有什么好限制的呢，为何不拥抱广大的H5开发者，让应用更丰富呢？
以上思路，充分考虑了对原有小程序框架的兼容(我相信像游戏、视频类的小程序确实需要原生组件)，不降低小程序安全性，并且实现上也没有超出现有框架的技术难度，甚至更简单——微信很容易依托npm已有生态资源，不用事事亲为，很容易整合小程序与公众号的资产和团队。
小程序兼容浏览器生态之后，对开发者的好处也是显而易见的：
1、现有或未来的H5代码资产和能力可以继承，技术团队会更快地下决心使用H5小程序来实现自己的移动端，并不断积累跨H5与小程序的能力；
2、现成的优秀框架和其生态可以继续使用，H5小程序可以做得更复杂，功能、性能和体验都强大到足以抗衡原生应用——H5应用本身已经走到了这个节点上；
3、现成的优秀DevOps工具链可以直接应用在小程序上，加速小程序成熟；
4、微信小程序框架本身不提供的能力，会有更多开发者会提供自己的(开源)方案——目前的生态条件下，npm生态开发者能力和数量肯定是强于小程序的，像我这种java程序员都在拥抱npm
5、微信小程序团队有与npm社区协作进步的可能，对npm社区的未来会形成影响，微信小程序可能会成为一个重要的浏览器、npm标准或重大分支。
总之，融入浏览器生态从技术上来说，优点和前途不可限量