以上均为个人汇总，如有不对欢迎指出！

小程序个人看法（跟技术无关，可跳过）

可能今天在很多人眼中，小程序已经成为别人印象中的app，功能齐全，且可以完成各种功能以及业务。但是个人从小程序的诞生使用至今，在我眼中他依然是个轻量级应用，虽逐步的壮大，一些功能还是有所限制，但是从功能上的角度却无法与app相媲美。以微信小程序为例，也许今天大小限制8M，页面栈已经是15层，大小可开发约50~70个页面，的确已经很好的支持业务的开发以及功能的扩张。但是在小程序开始之初，页面栈仅为5，包大小限制1M，很多业务的确无法扩展。小程序也因业务的扩展，逐步逐渐支持工程化，如当前支持npm包。但我们从小程序的产品整体设计上，还是不能忘记这个限制，无止境的叠加页面以及业务。

小程序的运行机制

简单的借助大神的思路，描述一下小程序的编译原理。 我们都知道，小程序页面由View（视图层）,App Service(逻辑层)组成。它们在两个线程中运行（我们传统的h5,是单线程运行）。他们之间是由系统的JSBridage（常用于原生与h5交互的工具，可自行百度）进行交互的。

视图层使用 WebView 渲染，iOS 中使用自带 WKWebView，在 Android 使用腾讯的 x5 内核（基于 Blink）运行。 逻辑层使用在 iOS 中使用自带的 JSCore 运行，在 Android 中使用腾讯的 x5 内核（基于 Blink）运行。

以上原理借鉴来自大神yck。

看到这里，是否明白，为什么小程序不支持直接获取dom跟bom了吧？因为不像h5在同一个层级，在逻辑层时间上压根没有dom，只有通过官方的写法，通过系统层去操作dom。

如有兴趣具体代码，可直接参考yck:juejin.im/post/5b8fd1…

小程序的常用第三方框架

原生

官方概念：官方自带

笔者观点：只有原生代码，才能在对应的小程序环境跑起来。任何第三方框架，都是经过自己的bable编译成原生支持代码才能运行。因此，在不考虑多端的情况下，强烈推荐使用原生，这样可以绕过第三方的坑。

Taro

官方概念:官方命名解释为多端统一开发解决方案。京东研发

笔者观点：这在多端中的需求中，相比原生的优势。此外，个人实践的应用中，taro是个人觉得为数不多兼容性较好的，坑相对较少。此外，官方还提供了taro-ui，ui从性能还有从外观，个人都是觉得写得非常的不错。 此外，他是利用React的方式开发小程序的框架。 使用 React的方式开发小程序的框架，同时支持生成多端应用，此外还支持转换rn等，如果同一项目需求有多个终端的要求。可以建议使用。

kbone

官方概念：Web 与小程序同构解决方案，腾讯研发。曾有这么一句话：kbone，十分钟让 Vue 项目同时支持小程序

笔者观点：如果有当前vue项目，急需支持微信小程序的话，可以考虑。这是一个求快不求精的选择。为腾讯官方出品，但是时间上的沉淀并不长，坑位估计不会少。有兴趣继续深入可查看：wechat-miniprogram.github.io/kbone/docs/…

mpvue

官方概念：基于 Vue.js 的小程序开发框架，从底层支持 Vue.js 语法和构建工具体系

笔者观点：小程序第三方中较早起家的框架。这是曾经vue开发者非常喜欢的框架，无成本的从vue的开发者，成为小程序开发者。植入了很多vue的概念，重写了babel，支持vuex，vue常用api等。不过貌似已经停止迭代了，使用慎重。

uni-app

官方概念：使用 Vue 语法开发小程序、H5、App的统一框架

笔者观点：历史悠长，从hridyapp的时代就有了uni至今。将微信的api二次讽刺，用自己的uni-对象替换了wx对应去转移成对应的api。目前还是有部分使用者，部分培训机构也有提到（毕竟培训的都是重点）。

WePY

官方概念：支持组件化的小程序开发框架，腾讯原生框架

笔者观点：只是略有了解，身边以及个人无人使用，不评论。

chameleon

官方概念：一套代码运行多端，一端所见即多端所见，滴滴研发

笔者观点：同上。

megalo

官方概念：基于 Vue 的小程序开发框架，网易考拉研发

笔者观点：同上。

小程序如何工程化

我们都知道，当前前端项目都有自己的脚手架，可随时更改自己的编译，如create-react-app，vue-cli等都自带webpack。而小程序的编译器属于内置编译器，我们没法对进行编译处理，当我们需要对整个项目进行编译或者工程化处理的时候，就会遇到瓶颈。这时候我们只能考虑自己嵌入工程化。

实际上，今天的小程序工程化的意义不是特别大。我们曾经有很多需要工程化小程序的需要，比如：支持npm包，支持es7，支持代码压缩，支持自定义指令，支持typescript等。

但是，小程序在长达几年的迭代中，也逐步支持着一些（但是总是慢前端架构一段很长的时间，比如es7到2019年才支持，前端早几年就可以用）

那当前工程化可以解决什么问题呢？

1)我们前端框架是否都用了css预处理。如less，sass。小程序由于自身定位是一个“小”项目，所以，官方可能认为不需要。但是我们实际业务中，或者手写代码的习惯，都习惯了less或者sass。

2)植入eslint 等代码检查工具

可能当前从这两个角度出发意义不大。但是，就跟上边所说，如再有什么新的技能点，是否还是要慢个几拍等官方支持？我们可提前做好准备。

使用gulp支持多页面打包到对应的位置，相信对前端来说不是很困难吧？晚点可上传demo。

小程序的优势（相比web）

1.支持服务通知推送。
2.支持缓存数据推送。
3.开放能力
4.支持云端开发
5.无需考虑兼容性
6.成本较低，体验较好（相比web）
复制代码