首先，在研究一个新东西以前，先想想这个新东西，是为了解决什么样的问题出现的。问题要多提，往深了提，反复提炼，最后得到几个好问题。或则从一个问题，引申出一些子问题。很多时候只要问题提对了，设计就明白了大半。
下一步就是试着自己解决一下，回答一下自己提的问题，并比较不同的解决思路的优劣，形成一个对问题解的标准。比如说问题是“如何在一个超长文本中查找子串?” 那么对问题的评价标准就可以是查找速度，以及查找过程中的内存占用。
接下里就是看别人是如何解决这些问题的了。如果和自己的设计差不多，一边窃喜一边开始按自己预先设计的评价标准对别人的设计的好坏进行判断。如果是自己完全没想到过的解法(这通常会出现在第一次接触某个领域问题)，可以按图索骥的补充一些基础知识，再回来看。如果这个领域或解法非主流到不是常见范式，那么可以安下心来好好搞清楚，想明白。 这样带着问题研究设计，才能有效的提高自己的设计能力。
介绍完套路后咱们回到正题：我们如何来评价微信小程序选择MINA框架?让我来持续提问吧。
第一个问题：“为什么微信小程序不使用HTML5而是使用MINA来构建Page?”
不用HTML5我可以提供一个非技术答案：微信需要通过这种方法来转化开发者，这些开发者未来会逐渐演变成“微信OS平台”的忠实开发者。其实开发者通常都有患有“斯德哥尔摩综合症”，一旦在一个平台上投入了智力资源进行学习，就会开始下意识的维护这个平台(比如看不到平台的缺点，只看到平台的优点)。如果使用HTML5作为开发方式，那么现在小程序聚拢的开发者都是为了流量来的，并没有投入额外的学习成本，对平台不够忠诚。而微信要成为OS是一个长期的演变过程，那么现在就要通过要求学习一个新的开发框架的方法开始多转化一些忠诚的开发者。
当然是不是这个原因也只有张小龙自己知道了，这是一个揣摩动机的答案，所以没有评价标准。问题终结。
为什么不用HTML5的技术答案可以是非常庸俗的。毕竟业界对于HTML5技术的优劣讨论已经持续了一段很长的时间了。但基本上，大家认为HTML5的主要缺点集中在性能上：同样的交互，用HTML5实现需要更多的系统资源，也可能会不够流畅。同时，应用还需要集成一个非常巨大的浏览器内核。
这个答案尽管能让大部分人满意，但实际上是非建设性的(这些对HTML5性能的结论，是别人告诉你的)。大家一边相信HTML5的美好前景，一边把对性能问题的解决寄托于几家传统的浏览器厂商。按我们的套路，这个性能问题再往深了问是这样的：“渲染指定页面最少需要多少资源?”，“在当前硬件水平下，渲染指定页面最快需要多少时间?”，“实现一个完整支持HTML5标准的浏览器内核，需要大概多少代码?”。
要回答这些问题就需要了解浏览器的实现了，这不会是一件容易的事情，在阅读浏览器的实现的时候，肯定会持续提出针对HTML的设计问题。最终你会对浏览器厂商什么时候能解决性能问题，得到一个更合理的预期：至少在5年内，HTML5的性能是不够的。
虽然SAY NO的理由，有一条就够了。但如能从其它角度思考一下为什么不是HTML5,可以得到一些更有建设性的答案。
第二个问题：“MINA作为一个新框架，为什么会设计成现在的样子?”
可以肯定的是，这是MINA的架构师在综合了多个因素后，拿出来的一个自己最满意的答案。所以这是一个非常有建设性的问题，思考这个问题的时候，就开始逐步代入MINA的架构师视角了。
让我们一起进入MINA架构师的角色，首先在否决了HTML5后，要设计一个什么样的框架来支持小程序的交互开发?第一步就是要给这个新框架提一些基础性的目标与需求。
这是一个现代化的框架，在最终表现力上要足够好。
小程序跑在微信里，所以必然是和android,iOS的具体平台特性无关的。
要面向更多的非专业开发者，所以学习门槛要低。
大规模的专业团队进行团队开发时，能有足够的工程支持。工程支持包括：
模块化
代码易于长期维护和修改。这意味着基于框架的实现具体需求的结果要足够清晰，好读。
可复用性设计。
小程序不需要安装就可以快速开始使用，只需要加载必要的资源就可以尽快展现用户需要的页面。