本文只谈技术框架，在开发文档中所不能触及的点来聊聊应该怎样看待小程序开发。  

    Web or Native？  

   大家对小程序框架第一个猜测就是这到底是基于 Web 还是 Native ？其实如果看过开发文档的框架设计，并且稍微思考一下，则会发现完全不需要去理解视图层到底是什么渲染机制。

  来看看框架最本质的部分：View（视图层）的展现完全是由框架来做渲染，与 App Service（逻辑层）只能通过数据与事件的形式进行交互，是典型的MV*模型，但又和现在主流的MV*模型有不一样的地方，因为 App Service 没办法操作 View 的任何视图元素。

  基于这点，相信大家就可以明白为什么就算理解了渲染机制，也不会对开发小程序有任何帮助。并且现在 View 是由我们团队设计的 WXML 和 WXSS 所编写，我们可以选择以 Web 或者 Native 来展现，并不能以纯粹的 Web 或是纯粹的 Native 去理解。

  所以大家就不用再猜测这到底是 Web 还是 Native 了，就算将来出现了 HTML 和 Native 之外的渲染方式，框架也会帮助开发者出色地完成渲染，开发者开发小程序的时候将不需要去考虑跨平台的问题。  

   是否基于其他框架？

  还有一点猜测是小程序基于哪个现有的前端框架实现，把 Vue，ReactNative，Angular 都猜了个遍。  只能说这些出色的前端框架我们有借鉴其优秀的设计，但实际上并非是基于某个框架来实现的。

  如果要说相似度，不能光看代码表现层相似度，内在相似度最有异曲同工之妙的就是 PWA(Progressive Web App)。

    与其他 web 框架的兼容性？ 从上文得知，App Service 完全没办法触及到视图层，所以和其他任何前端框架是无法做兼容的，并且也不需要去做兼容，因为本身就是个框架。虽然目前框架还无法和现有的优秀前端框架比肩，但是使用这个框架可以完成大部分场景。我们也会不断对其进行完善。  至于 webpack，gulp，babel 等完全可以用，只需要构建出的文件目录符合配置文件中所定义的就行。

  一个简单的脚手架（非官方推荐编写方式，并不兼容所有npm库，慎用）。

   前端、客户端开发者何去何从？  

小程序推出后就有笑谈称：『HTML5 程序员涨价啦』，『iOS、Andriod 程序员要失业啦』。不谈产品形态，只以技术角度出发也并非如此。

  抛开后端不谈，小程序是由 WXML、WXSS、以及运行在 JsCore 的 JavaScript 所构成，也就是说两个非常简单的描述语言加一个只需要处理数据的语言，这对任何开发者而言都是没有门槛的。

  并且框架完全是以 App 的思想来设计，如果开发时带入 Web 的思想有时反而会适得其反。所以不要携带前端的思维来开发小程序。

  ifanr团队花了一个上午基本就搞定了一个小应用，侧面论证了开发的便捷性，就连我们对技术不是那么精通的产品经理都能快速地开发出一个简单的小程序，所以这应该是一个更加大众的开发方式。可能将来有一天说『我有一个颠覆性的想法，但是就差一个程序员』的人就可以自己开发小程序了。

   开源 & 社区  

   一些开发者在一接触框架就发现一个关键点：这套框架只能跑在微信的体系中，这种形式的框架很难在社区中一直保持活跃。  由于框架本质使然，和客户端有着千丝万缕的联系，所以目前并不考虑将框架开放，而是以某种形式来让开发者不必重复造轮子。  在将来可能会以另外一种形式跑在其他体系当中。