MINA一个最主要的核心概念是Page，一个Page是应用内可以导航到的最小粒度的界面。而如何构建Page是与大家过去猜测差别最大的地方。微信并没有使用HTML5，而是提供了一套新的设计。新的设计要求每个 Page由3个文件构成：
index.js :包含Page的逻辑处理代码，其中比较重要的就是定义Page的数据(wxml可以通过数据绑定机制直接访问)
index.wxml : Page的布局文件。随便从demo中选一个布局文件来看，其整体结构非常简介清晰，即使没有提供任何资料也大概能看出来表达了一个什么样的页面。
.wxml不算是完全的静态布局文件，还支持条件渲染和列表渲染。.wxml使用{{}}语法来简单直接的支持数据绑定。可以通过template的方法进行复用
index.wxss: 样式表。决定了在wxml中定义的各种组件最终应该如何显示。官方文档并没有列出wxss的selector语法和支持的style，只是说“具有CSS的大部分特性”，wxss样式表里也扩展了一些微信小程序专用的样式是属性。
Page的整体设计上有比较明显的“反应式”编程风格，相信有vue.js,angularJS，reactive.js开发经验的同学可以很快上手。由于没有内测资格所以没法在手机上测试性能，不清楚小程序的这套框架有没有反应式编程常见的性能问题。这个等公测后写个有10万条数据的列表，看看滚动流不流畅就知道了。
目前demo没有使用ES6，所以看起来没那么“现代化”，这也可能是因为小程序这个项目立项比较早的缘故吧。不过ES6是大势所趋，相信未来小程序会支持使用ES6开发。
一个基于MINA的小程序最后是如何跑起来的呢?
官方这么说：
开发者写的所有代码最终将会打包成一份 JavaScript，并在小程序启动的时候运行，直到小程序销毁。类似 ServiceWorker，所以逻辑层也称之为 App Service。
网上已经有不少人通过琢磨开发工具的实现的方法，做了比较深度的研究了，推荐阅读：微信小程序「官方示例代码」剖析【下】：运行机制
简单的总结一下：
wxml文件通过编译会得到html，wxss 文件通过编译会得到css，分离的各个页面的JS和App的主JS文件最终会打包在一起得到App Service。 开发状态下运行小程序，基于blink内核，每个html会加载一些moko js用来支持框架功能。生产环境在手机上估计是运行在一个专用，定制的浏览器内核中。
为什么是MINA?
业界对目前微信使用的UI框架，有两种截然相反的观点：
微信“小程序”带动HTML5发展 数据波来助力
“微信小程序的本质说来就是一个HTML5应用”
“以后互联网的发展方向可能更偏重于HTML5”
而有的人又认为
我们真的需要“小程序”么?| HTML5老兵如是说
“微信虽然用了 HTML5 技术来做应用号(正式名称：小程序)，但是它并没有真正用到 HTML5 的精髓——开放、互联，也就决定了它可能无法实现“微信OS”的最终野心。”
这两个观点是矛盾的，那么，到底那种观点是正确的呢?首先简化一下问题，微信小程序是基于HTML5开发的么?
通过分析小程序的运行原理，这个答案是明确的：小程序的开发过程会用到大量HTML5相关的技术,但并不是使用HTML5开发。有 HTML5经验的前端工程师学习微信小程序的开发相对会更容易一些。微信小程序的运行并不需要一个完整支持HTML5特性的标准浏览器内核，但也可以通过添加一些辅助设施，让小程序在个完整支持HTML5标准的浏览器上运行起来。
“由于框架并非运行在浏览器中，所以 JavaScript 在 web 中一些能力都无法使用，如 document，window 等。” 也就是说，一个已存在的HTML5页面，并不能通过自动转换工具变成一个合法的Page，而需要有工程师根据HTML5页面的功能，使用MINA框架再实现一次。
搞清楚MINA和 HTML5的关系后，我们还是没有搞清楚为什么微信要提供一个新的MINA框架 。事实上这个问题是一个讨论设计的问题，所以要回答这个问题，需要具备一定的设计能力，而不是只是停留在研究MINA实现的层面。而设计能力，是一种比较稀缺的能力。
想要系统的提升自己的设计能力，简单的来说就是“多看+多想”，那么如何多想呢?我有一套还算完整的方法的，简单来说有如下几步：