微信小程序虽然有着众多的无可比拟的优势，但是毋庸讳言，它也有着一定的劣势。对于武汉微信开发者而言，我们应该充分的认识到这个问题。今天，武汉微信开发公司就带大家一起看看微信小程序的劣势。
微信小程序为了简化复杂性，做了一些UI上的设计规范，确实方便了很多对UI要求不高的应用，但这也限制了那些对UI要求极高的产品发挥。
微信小程序很遗憾地不支持现有的HTML
DOM结构，而是自己给出了一系列的组件，造就了一个封闭的开发环境，这直接导致了现有的经典JavaScript框架、类库都无法使用。微信小程序现在的生态几乎是荒芜一片，等待着开发者们去耕耘（挑战与机遇并存，正因为没有，才有机会）。如果你想用微信小程序实现一组图形来展现股票或者天气的曲线，目前来看，相当烦琐。你无法使用经典的echart或者highchart，你只能自己用Canvas来一点点地绘制。
微信小程序还不支持WebView，这是相当头疼的一个问题。现在很多新闻类型的应用，都是将文章数据静态化成HTML存储在服务器或者是CDN中，然后再利用WebView直接加载这个HTML来显示。不支持WebView直接导致了很多内容型应用没办法加载已存在的大量HTML页面。内容型应用现在大量的静态化页面需要被转化（已有一些第三方的组件实现了HTML转WXML，基本思路是用正则表达式替换HTML，但效果并不能让人满意）。
至于微信会不会官方支持，这个很难抉择。不支持WebView对现在的静态化HTML页面是致命的打击；但兼容WebView就意味着在小程序里你还可以运行WebApp，而WebApp很难去监管，性能体验也不够好，这对于微信小程序的发展是不利的。也许开放一个只解析CSS不允许运行JavaScript的WebView可能是个不错的选择，微信如何平衡这个问题，我们拭目以待。
微信小程序只实现了模板化并没有实现自定义组件，这是最令人不满意的地方。如果我们想实现一个自定义逻辑的组件，通常希望把这个组件的标签、样式以及业务逻辑打包在一起，然后可以放在项目中多个地方使用。外部客户端调用组件时，只需要传入组件所需要的参数，由组件自己来完成数据获取、转化、绑定并和UI层通信等操作。
但微信小程序里的template只能将标签和样式（WXML和WXSS文件）提取出来作为一个“模板”，却无法把组件的业务逻辑（js文件）放在一起。也就是说，组件的业务逻辑不能够写在组件的模块儿中，只能写在“调用”组件的业务代码中，这就无法很好地复用组件的业务代码。
