流量之困
　　现在《微信》里依靠订阅号吸引百万粉丝的自媒体，构建了自己商业模式的公司比比皆是，但依靠服务号做起来的创业项目却为什么几乎看不到 我们把其中的原因剖开来讲，其实就在于流量的导入—订阅号可以每天发一篇，可以在“首屏对话列表”这个主要的入口瓜分到一定的首次流量，每天一篇的量也足以在朋友圈转发中找到足够的存在感，进一步瓜分《微信》的二次流量。而服务号每周才能发一篇，分不到多少首次流量，在朋友圈分享中的存在感则更低。
　　而对于这次的小程序来说，最主要的问题也在流量上。不可否认的是，小程序可以在《微信》里面以全屏的方式显示，也多了很多API，但目前尚无法获取《微信》内部的流量。

　　小程序目前的主要入口有两个，一是外部流量导入—通常以扫二维码为主要方式，二是《微信》内置的搜索，这也折射出小程序的两个问题。第一，小程序现在还不能像公众号那样，通过给订阅用户群发的方式主动提高使用率。第二，小程序还不支持分享功能，你不能把小程序的内部页面分享到朋友圈，获取二次流量。虽然现在已经有消息称《微信》可能会为小程序开发额外的流量入口，但这样的决定是不是来得有些晚了？
　　从《微信》对小程序的功能和定位来看，其非常强调“工具性质”。《微信》似乎是想改变目前公众号以文章为载体的单一交互方式，因此增加了以工具为载体的小程序，因此不要指望小程序能够具有很高的传播性，如果《微信》不让其在流量入口上占得先机，那么它就只能活在一个小圈子里。
　　用户体验又如何？
　　当我们在讨论小程序的时候，往往会遇到一个终极问题：小程序能否达到与原生APP一样的“用户体验”？
　　的确，要让大家去相信几百kB的小程序能够在用户体验上做到与几百MB的原生APP一样好，就如同你买了一部300元人民币的手机，却想用出iPhone 7的体验是一样的。但是问题在于，小程序和原生的APP虽然都能够被称为“移动应用”，但从开发框架、开发语言等技术层面上来看，二者应当是两种不同的产品。
　　其实，在《微信》官方最初宣称小程序能够做到原生APP一样的体验时，外界的质疑是无可厚非的，毕竟早几年HTML5“摔死”在体验上的教训还历历在目。但是在体验之后，很多人都表示被惊艳到了。从上手操作上来看，很多小程序的表现趋于完美，几乎分辨不出哪个是小程序，哪个是原生APP。
　　大家都知道，过份的轻度化是HTML5技术始终没有成长起来的“阿喀琉斯之踵”。Web开发几年以来的血泪史教育我们，轻度的Web应用是没有未来的。所以，从在《微信》内全面封杀HTML5小游戏，到将《微信》的浏览器全面升级至X5 Blink内核，再到主推Web 的小程序，《微信》的每一步都在逐渐完善其在Web领域的布局，而小程序将是其中重要的一步。
　　小程序的机会在哪儿？
　　对于这个问题，我们可以从两个角度来考虑：一是创业者的角度，一是从业者的角度。
　　对创业者来说，小程序极有可能从移动互联网创业的效率和体验上带来颠覆，让低成本试错成为可能，同时改变移动产品的应用场景和推广方式。从效率上看，小程序产品在《微信》Web 框架下的开发速度是远比原生应用更快，跨平台的适配性更高。而开发速度的加快，必然将带来了开发成本的降低，效率因此获得提高。所以，对创业者来说，小程序或许会是投身于移动互联网创业的最好选择，当对市场情况和用户需求并不十分确定的情况下，它让快速与低成本的试错成为可能。
　　而对从业者来说，小程序确确实实的拓展了Web技术的商业化边界，让Web不再只局限于营销页面和小游戏。
　　可能并没有太多人知道，《滴滴出行》与《今日头条》这样的产品其实都是用HTML5做出来的。既然相对复杂的产品都能够通过Web技术来实现，那么更简单产品又有何不可？另一方面，小程序出来之后，在《微信》能够提供优秀的底层框架的基础之上，只要是在小程序的框架体系内，我们完全可以把一个Web产品就当成是一个原生应用让人去开发，这时前端开发人员的能力就显得尤为重要。基于Web的小程序给前端开发从配角成为主角提供了可能性，市场上已经有公司在重金招聘小程序开发人员。未来，会不会有一些公司出现小程序开发这样一个专门的岗位？一切皆有可能。