小程序对WebView限制多多的意义在哪里？支持纯H5小程序才是超越微信的必由之路

近期对一个H5的专业应用切换到微信小程序的过程，失望不已，包括： 1、对npm等社区的疏远(小程序框架不能使用的常用npm包清单) 2、自创MVVM框架相比React、Angular、Vue的不足 3、“原生”页面的渲染性能不如纯H5(这篇对小程序的期待里面有分析)

本想看看支付宝小程序如何，却发现居然与微信一个样。

按我理解，微信自造一套车轮，无非以下原因： 1、对游戏的支持：原生控件，对游戏渲染有价值，但阻碍了Web应用的开发，且性能反而差H5一大截； 2、对加载体验的追求：小程序代码统一上传到微信服务器； 3、对安全性的追求：只支持https访问指定域名。

而支付宝小程序几乎完全模仿微信小程序的API，难道是为了 降低**“微信小程序切换到支付宝”**的难度吗？ 支付宝并没有游戏渲染的需求，第1点原生控件带来的问题，要远远多于其收益的；第2、3点与支不支持H5并不冲突。

只支持自成体系的原生控件开发，不支持H5带来的问题： 1、很难借用V8或者通用浏览器引擎带来的广泛支持与改进； 2、与npm生态渐行渐远； 3、从开发、调试到打包的工具链都要独立开发

如果支付宝小程序的定位，是高于微信小程序的，我觉得完全应该拥抱npm生态的H5开发者： 1、通过WebView或新的控件，全面支持npm生态，支持纯H5应用的接入： 最重要的包括npm依赖管理、Webpack打包框架、MVVM三大框架(React、Angular、Vue)及生态、WebStorm消息框架，以及一系列优秀的js组件)； 2、为纯H5小程序提供JSSDK，连接支付宝API； 3、研发工具链的兼容：通过浏览器插件，来实现小程序环境的模拟，让开发者可以用自己喜欢的工具链。

说完了，我的第一个小程序最后完全就嵌套在WebView里，但是即使这样还是避免不了一个尴尬的问题，让我不得不继续寻找小程序能否在对npm的有限支持下，做到： 通过环境变量来配置后台地址