微信开发者工具是基于 Node.js 和 Chromium 的应用程序实时运行环境，以 node-webkit 开发的。其中，MINA ( MINA IS NOT APP ) 正是其在微信中开发小程序的框架，MINA 为开发者提供了自己的视图层描述语言 wxml 和 wxss，以及基于 JavaScript 的逻辑层框架，并在视图层与逻辑层间提供了数据传输和事件系统，同时小程序也为开发者提供 UI 组件库和底层 API 。后端开发者可以基于此微信开发者工具，在开发期间增强网络调试的体验，提高开发效率。
但正如 Bug 只会越调越多，微信开发者工具也并没有想象中的那么完美，内测中的微信小程序只能在工具内进行调试，而且不支持热更新。并且，对于已习惯了其他编辑器的开发者，当时的工具也并没有想象中的那么“顺手”。
从「微信公众号开发」这件事儿来讲，其开发成本之高、开发难度之大基本上得到多数认可。道衍天机认为主要有以下几点原因：
首先，往往一个很简单的功能需要反复修改，在研发过程中也可能会不断推翻之前的设计想法。因为，一款用户体验好的软件不仅要平衡用户满意度，同时也要引导用户，提高用户活跃度和留存率。尤其是大公司的应用软件，每隔一段时间都在不断优化和迭代，也是为了提高用户留存率。
此外，移动设备不同、操作系统不同，甚至版本号也各异，如果你是小公司的产业研发团队成员，那么功能代码写完可能仅是此次项目的其中一款内容，如何解决好不同移动设备的兼容新问题仍是不小的挑战。
再者，诸如有些无法独立实现的功能如消息推送，就需要跟第三方移动设备厂商进行合作，同样也需要投入一定的资金成本。
还有一点非常重要的是，在庞大用户基数的情况下，必然要处理高并发问题。从微信 2017 年 8.89 亿月活用户，1000 万公众号的数据可以看到，微信并不只是一款前端的 App，它的正常运转需要后端大量服务器的支撑，需要存储空间的支持。
对此，李明阳的回答发人深思：“很多东西的难度，是随着需求变化的”，正如小白用户需要的仅是便宜好用，而成熟用户已从功能需求上升到战略层面，如何获得与自身业务快速增长相符合的后端系统支撑？如何满足用户更加复杂的业务场景需求？如何处理高流量下的负载均衡？
如果说是 IT 产业的溢价太高，不如换个角度思考，高投入换回来的是高价值回报，“只要能成交，就是合理的价格，有价无市才叫溢价。
树状结构的展示
每一个库都有一个树状的知识结构，大家请看这个例子。每个层级展示的方式是一样的，所以正常情况下，我们都会选用递归的方式来使展示。比如在这张图里，当我们判断这个节点拥有子节点，就想再次调用同样方法显示。但是很遗憾，小程序里，不论是使用模板，还是使用include的方式引用文件，都没有办法做到自己调自己。
幸运的是我们知道我们层级最深有多少，这样我就可以写几个同样的文件和模板，加上不同的命名，来调用。如果是未知层级的树状结构，就会非常难以处理。在这里可以建议大家将树状结构变成数组的形式，加上层级标识，在wxml文件中可以使用循环的方式来处理层级的显示。
Html页面在微信小程序中展示
这是一个非常难处理的问题，微信不支持html页面的展示，所以需要把所有html的标签转化成小程序内允许的标签。我们使用了一个名叫wxParse的应用，这个应用的功能就是通过正则表达式将html页面转化成json形式，再用模板的方式展现出来。在这里面规定了各个标签的样式（wxss）。遗憾的是他也有层级方面的问题，同样是重复写了很多完全一样的模板。
顺序调用。如果html的标签层级结构超出了模板个数，那么超出部分将无法显示出来。这个应用是在微信中运行的，建议大家把数据转化放在服务器端来进行，将转换后的数据发给小程序。另外小程序setData()一次不能超过1024k,如果你的json格式数据超过这个限制，就会很难再拼接。
冒泡事件
一个组件上的事件被触发后，该事件会向父节点传递，网络请求接口 wx.request() 没有携带 Cookies，如果服务器端有通过获取cookies处理的逻辑没办法和小程序结合，只能为小程序单独开发新的接口。
小程序在运营上的优势在于微信用户量大，适合推广，某些功能单一的APP可以在小程序中实现，不用再下载APP。开发者不用考虑平台，开发成本低。但同时不适合开发逻辑复杂界面丰富的程序，受到框架限制，随意性小，无法满足所有功能。
