再看微信小程序

2016年9月微信小程序内测后不久，我在我的知乎专栏中写下了一篇《换个角度，再来看看微信小程序的开发与发展》。文中从一个开发者和产品经理的角度提出了一些对小程序的看法。2年过去了，相比于各种蹭热点的媒体文章，我当初的判断还是比较理智和准确的。很庆幸当初写这篇文章时，我并没有站在一个纯技术开发者的角度来看待小程序，这是这篇文章分析比较准确的主要原因。

文中我谈到微信会逐步淡化企业号；谈到小程序由于开发的低成本必定成为产品试水的最好形态；谈到小程序的成功必定是依赖于微信的生态与微信资源的逐步倾斜；也表明了我的观点，对于任何一项技术或者是产品，先看看别急着下结论。

我是一个对于成功定论非常保守的人。但如果你问我，快两年了，微信小程序成功了吗？毫无疑问，成功了。来看看数据：

微信最新发布的数据显示，目前已发布小程序数量为 100 万 +，小程序开发者已达 150 万 +，小程序日均打开次数 4 次，主动访问的用户量为 54%。

但有时候我们总是很愿意相信自己的感觉，并不愿意相信数字，特别是在这个互联网时代，数字的堆积已经让我们麻木了。所以，罗列数字并不能代表小程序的成功。

但在我看来，最能够直观反映技术实用度的是外包市场。无论从我的感觉，还是我爬取的一些数据分析来看，微信小程序的确已全面占领了外包市场。

也就是说，即使你无法从商业的更高角度来看待小程序，但至少作为一个技术开发者，外包开发小程序也已经让你能够有一份不错的收入了。

这算是成功吗？你我皆凡人，商业规模上的小程序是否成功的分析，我拿不出来，我分析的也不准确。但只从外包这块来看，大量小程序的开发需求至少从经济学的角度来看，它确实刺激了消费，刺激了产品的更新换代。

这就够了，根本无需去谈论小程序对于商业2.0，消费升级等等这些离我们很远的概念。

我们做技术的人，总是在潜意识里会以技术的标准来判断一个产品是否能够成功；或者说，我们在骨子里崇拜的是更酷的技术，人为的为每个技术打上一个标签，形成一个以自我感觉为中心的diss链条。

早期的时候，diss链条是这样的 汇编 > c > c++ > java > php ，搞服务器的看不上搞前端的，搞系统底层的看不上做web的，搞算法的看不上做应用的。

相信我，我也是个做技术的人，在我内心深处，我也有这样的认知。在我看来小程序确实在技术上没有太多创新，它真不“酷”，也没什么逼格。和现在的热点机器学习、AI，流行的微服务、高并发等等概念相比，它简直就是个土拨鼠。

但真实的世界不是这样的，技术真的只是占很小的一个部分，你不能永远活在纯技术的世界里，在技术之外，更重要的是生态、是商业、是模式。

没有人关心你用的是什么框架，你用的是什么技术，什么语言，能出东西，能解决问题，能提高效率就是王道。一个产品的前端用jquery来写和用vue来写有区别吗？对于你来说有区别，但对于那些产品的决策者，对于用户来说，没有区别。

但可惜的是，在我们看来，jquery就是low，VRA这些MVVM就是豪华版顶配，就是酷；Go就是未来，Java、PHP就是落后，要挨打，没前途。

早点跳出这种思维，你会有不一样的格局，也能比其他人多出更多的机会，同时这也是一个技术人成熟的重要标志。小孩子才分对错，大人只看利弊，这话我并不喜欢，因为用它来描述人的处世观太过于残酷。但对于技术，这话perfect。

微信小程序的成功不是技术上的成功，而是模式与生态的成功。微信有10亿MAU（月活跃用户数量），在这个体量下，任何微小的动作都会对业界和市场产生举足轻重的影响。用户数多就是微信的尚方宝剑，就是小程序赖以发展的基石。

有时候我也对小程序有很多怨言。bug多、文档差、API变动频繁，反馈bug后解决问题的速度太慢。在技术这个层面上，小程序相对于国外的技术或者框架，确实有很多不严谨的地方，技术上没有太多创新也是事实。

但如果我们跳出技术的思维来看，微信小程序确确实实是解决了用户的痛点，连接了线上和线下，给了无数创业者一个可以以低成本起步的机会，同时也提供了强大的推广渠道。

2年前，我做第一门《微信小程序入门与实战》时，其实也只是抱着试一下的心态。但2年过去了，我越来越看好小程序。看好的原因不仅仅在于微信又向小程序倾注了更多的资源或者加入了更多功能，更多的是在技术层面上，我突然发现小程序已经具备了替代APP的潜力。我们简单来看看微信小程序这2年来一系列比较重要的更新动作：

1.  微信小程序同公众号强绑定

2.  微信小程序获得了分享的能力，可以分享给好友和群聊

3.  新增微信首页下拉打开小程序以及新增“我的小程序”

4.  ES6几乎完美的支持

5. 卡券功能的支持

6. 自定义组件的支持（五星功能，极为重要）

7. 微信小程序新增广告功能（极为重要，互联网最直接的盈利模式）

8. 开放微信小游戏（小游戏是一种特殊的小程序，依然归属于小程序）

再看看7月份微信公开课上公布的小程序未来技术规划：

1. 自定义组件2.0

2. npm的支持（极为重要）

3. 官方自定义组件

4. 小程序云

5. 可视化小程序编程

其实你不需要具体了解每一项计划的真正意义，但其实你可以明显感觉到，小程序是具备未来的。现在是什么样子并不重要，重要的是他还在发展，他还有更多的可能性。

2年前，我对于会不会出现独立的小程序开发工程师一直是不敢肯定的，我认为这个职位由前端工程师兼任即可。但2年后，我认为极有可能会出现类似于Android和iOS开发工程师的专业小程序开发工程师。

小程序并不是你想的那么简单，虽然语言层面上通用于Web开发，但其实小程序是分为两大部分的，一部分是”前端“，另外一部分是小程序的“开放能力”。小程序的前端开发对于绝大多数前端工程师而言，并不难，无非还是组件+CSS+JS。但小程序真正难的是对于开放能力的应用。从小程序文档上看，生成二维码这个能力，只不过是寥寥一页文字，但带参数的二维码以及入口场景值在应用层面上是可以演化出很多营销和推广能力的。一个小程序开发工程师不是只去做前端样式，还需要对这些开放能力有比较深入的研究。

17年4月我上线了课程案例《零食商贩》小程序，当时我自信满满的说，这是现有小程序中体验第一的小程序。但1年多过去了，我已经看过太多体验和设计远超《零食商贩》的小程序，随着时间的流逝，越来越多优质的小程序已经跃然纸上。而且这些小程序的功能之多，功能之复杂，已经在向APP看齐了。

如果你能够跳出偏见，全面梳理一下小程序从开始到现在的发展历程，你会发现，它的确是拥有光明的未来。

最后聊聊制作《微信小程序实战》这门小程序新课程的初衷。主要原因还是我非常看好小程序，而距离上一门小程序课程上线到几年7月，已经有1年零4个月没有制作小程序课程了。没有制作的原因主要是因为，我认为小程序之前所迭代的功能并不足以让我产生做新课程的冲动，它确实多了很多API，但如果只是多了API，在开发模式上没有任何改变的话，这是不值得去做一门新课程的。

我一向认为老师讲课应该讲思维、讲方法、甚至可以讲技巧，但就是应该尽可能少的讲具体API的调用。因为API每天都在增加，都在变化，一个程序员如果不能掌握思维和方法，每天都在学习API如何调用，恕我直言，这太累了，投入和回报的比例也太低了。

所以我的课程基本上是很少去讲API调用的。《微信小程序入门与实战》这门课程虽然少了很多最新的API，但它依然是小程序入门的经典课程，尤其适合前端初学者。至于新的API，你翻下文档就能知道是怎么回事儿。

但小程序更新了自定义组件，这是我做新课程最大的意义。基本上每个前端框架都会提供组件技术，所以大多数同学也对组件习以为常了。但来听听我对组件的看法。

大多数情况下，我们对于组件的理解是停留在“可复用”这个层面，而实际开发中，其实组件的可复用这一点并不是太实用。因为封装一个及其灵活的组件成本是非常高的，我想，除了那些技术很强的团队，大多数团队都会选择封装一个组件，但是在复用时，拿来改一下，不会完全遵守不去更改组件源码的原则。

但我看待组件的观点不同。我认为组件最实用的价值还是在于代码的分离。微信小程序已不再是我们印象中简简单单的功能了，现在的小程序大多数都是商城类小程序，除此之外还附带社区功能，已和APP没有太大的差异了。

功能增多，必定带来维护成本增高的问题，对小程序结构良好的规划已经是一个很严肃的问题。组件是一个解决问题的手段，另外一个手段是需要引入服务器常用到的业务层的概念。业务层Models，相信很多同学都知道，但真正应用到项目里，它到底是怎样的一种写法，你是否真的做到了通过引入Model和组件来解决代码混乱的问题？还是只是听人家说MVVM，MVVM，让这些好的架构流于一种概念？这是值得大家思考的。

另外一点是关于前端开发的细节问题，先给出课程案例小程序:

简单吗？我想绝大多数同学在看到这个小程序时会认为很简单。但你真的去做的时候，当你真的考虑到用户的时候，你会发现他真的不简单。

比如首页期刊在来回切换的时候，你是否做了缓存？如果每一次导航都要去服务器去加载数据，其实是没有必要的，因为期刊的内容最多1天更新一次，不会频繁变化。但在加入缓存机制后，程序的代码复杂度是要增加很多的。

再比如，对于点赞数量的显示，也许我们写代码的时候直接就显示一个数字，但你需要考虑到如果数字很大比如10000+的时候，直接显示这个数字是不合适的，应该显示成10k+。还有很多数据在提交的时候，是需要考虑到本地更新的，不能等服务器返回后再更新前端数据。这些细节对于我们前端开发来说非常重要，可以说一个产品注重细节和不注重细节，开发成本和技术难度是有天壤之别的。

最后，新课程启用了全新的课程模式，提供标准的在线API，供前端开发者调用，不再使用fake的假数据。API文档地址：http://bl.7yue.pro/dev/index.html

。在真实的开发中，与服务器交互数据、阅读API文档的能力，也是我们前端开发者必须要训练的一项能力。

新课程依然是训练编程的思维，辅以详细讲解小程序中最重要的布局方式flex弹性盒子与ES6的重要知识应用，没有太多小程序API的讲解。

性格如此，着实难以改变。