当你觉得时机合适可以进场的时候那已经没有时机了。

应该是q+的微信版

小程序不可能下载和安装系统本地代码，否则，微信等于部分阉割了 Appstore 。

Tim Cook 对于阉割的严重性，相信也应该很清楚。相信腾讯也不可能准备和苹果摊牌。

所以小程序通过 H5 ，利用腾讯浏览器的内核，开了口子调用微信的本地功能的可能性非常高。之前看过一个文章，提到实际上微信的部分功能就是这么实现的。（所谓 Hybrid App 技术应用挺广泛了，所以我对技术上的坑到不太担心）

这样作为技术人员就面临着一个不太友好的未来：
如果微信小程序很成功。。。
那么平台级超级 Apps 都会效仿，这意味着多个开发环境和语言。学习成本加剧。
而这种状态下，苹果仍然是被阉割的状态。一旦为此限制 H5 能力，那么就是业界悲剧了。（这里可以看到小程序和 H5 有一定竞争关系，封闭平台语言 vs 开放标准）

如果微信小程序不成功。。。
那么程序员就白白投入精力。

但是另一方面，微信的确是个超级平台。
而且，短期内为了扶持这个东西，微信一定会有倾斜性投入。

另外，腾讯下面的超级平台，一般培养的都是小玩家。赚个几百上千万的可以，想坐庄弄死你。

所以，个人的建议是：
1
把他看作一个短期行为。有明确的项目，可以盈利，最好有倾向性支持，就弄。

2
有机会参与项目可以试试，对拿非技术导向的 offer 有点好处。

3
长线赌身价，似乎真的没有必要。

总之，可以做外包，赚快钱，但是不值得在上面做品牌。

10月1日，微信客户端更新了6.3.27，能用手机查看官方的小程序demo了。

不得不说，还是有点卡的，甚至某些地方还没有html流畅。

建议观望，等正式版出来了再写也不迟。

国庆节花了一天半的时间，边看文档边捡起css，使用豆瓣电影API，以豆瓣电影 Andorid 版 App 为设计原型，搞了个简单的微信小程序版豆瓣电影，效果如下：

微信小程序版豆瓣电影 - 腾讯视频 http://v.qq.com/x/page/k03339axews.html

代码在：GitHub - David-Guo/weapp-douban-movie: 微信小程序版豆瓣电影

总的来说，就官方提供的文档来看，学习成本不是很大，几天就能弄出一个demo，所以可以提前玩玩。

可以早点进去开拓开拓，总觉得现在呼吁大家观望一波的，都是准备率先冲进去赚快钱的人。

小程序能够在多大程度上起到对苹果app store体系阉割的作用将会是最大看点。

html5或者其他的webapp技术尝试，主要就是因为平台（iOS / android）不肯就范，而始终无法调用底层内容。想要嫁接底层支持，从而扶正webapps的尝试都失败了。比如firefox os还有最早期的阿里yunos。特别是yunos，事实证明如果不兼容现在的android应用——不管他表面或实际是以什么方式实现兼容，就是死路一条。

之所以被锁死在native apps层面主要还是因为用户不争气，扶不起firefoxos 乃至winphone，但是如果用户都那么争气了，我们又上哪去骗用户的钱呢？所以这事儿都是相辅相成的。

如果你把腾讯当骑士，那么别忘了它并不是免费为你提供斩杀巨龙的服务，自己要夹带点私货的。而故意设置一个专有标准，不能使用第三方浏览器打开就是这个私货所在。可以说才出虎穴又入狼窝。

但如果小程序真的能够杀掉应用商店这条巨龙，那么前一条巨龙死后会带来一定混乱，这种群雄并起的局面，对于实现“写一次就到处运行”的革命先烈遗志，可能还是有点好处的。总比一潭死水要强。

回答问题本身，不要把所有的精力都放在小程序上面，要考虑它搅动市场之后，如何开发并推动遵循业界规范的webapps，复兴那个开放的web。

目前小程序开发的问题

“哇，我是不是可以轻轻松松就写出一个APP啊？”，这也许是许多开发者的第一感受，你的想法没错，这也是微信想要达到的效果。但是作为开发者，我个人认为用户体验并没有这么重要，“一个流畅的APP用起来比不断刷新的网页爽多了”不能作为我们投入到微信小程序开发中的理由。我认为开发者能到达的目的（速度、成本、回报、流量、收入等）比所谓的用户体验重要得多。

所以，我的建议是：“不要过高（盲目）地期待用户体验能给你带来的好处，应该多评估你所受到的限制，以及你能得到的回报”。下面说说我对小程序的看法（提醒，这是2016年9月写的，以后可能会显得不合适或不正确）。

• 小程序不是基于浏览器的，而是基于微信程序的，要开发小程序必须学习使用WXML与WXSS，代替HTML与CSS；

• WXML与WXSS没有完善的文档，如果遇到技术问题就会卡壳，可能会导致几天没有进展；文档中暗示了WXML、WXSS与HTML、CSS差不多，但是却没有明确说哪些HTML标签可用，哪些CSS属性可用，或者哪些不可用，这一切需要开发人员自己一遍一遍的尝试。对于设计师来说也是个困惑，万一根据Web开发经验设计出来的效果前端人员实现不了怎么办？

• 预感小程序不支持常用CSS库，小到一个button、一个icon都要自己处理，每一个像素都要亲自调整，又要重新造轮子了。对于设计师与前端来说，都是痛苦的体验；

• 小程序基于“数据绑定”的思路绑定了Model与View，看似自动化了数据的显示，但也同时也失去了对DOM的自由操作。小程序的JS不支持window对象，不支持jQyery等常用库，这就意味着你不能重复使用以前积累的前端代码；在思路上我们要保持“Less is more”，但在面对选择上我认为“能总比不能好”。小程序在保持简单的同时也让我们失去了许多选择；

• CSS与JS的选择器没有那么灵活，仅支持简单的选择器功能，对于有经验的开发者将会感到不便；

• 开发小程序，可以轻松调用以下微信的API（并且不用考虑机型问题）：上传、下载文件，拍照、选择、上传图片，录音、播放音频文件，播放视频文件（仅支持腾讯视频），本地数据缓存，获得地理位置与调用微信内置地图，监听重力感应与罗盘数据，Canvas绘图，微信账号登录，微信支付等（其他未列出的就是比较常见的了）。但是除了重力感应、罗盘、Canvas绘图以外，其他API在微信公众号的的JS SDK中也有，也许以后小程序会推出更多“APP才有的API”；

• 与公众号相比，许多功能小程序目前还没有，例如：摇一摇、扫一扫、主动向用户发消息、分享到朋友圈（以及其他分项功能）、卡券等（写到这里的时候发现小程序已经可以给用户发模板消息，但限制较强）；

• 目前不知道是否可以通过URL直接访问小程序，看样子好像暂时不可以，这就意味着你不能在“阅读原文”中引导用户访问某一篇文章的内容；

• 目前不知道是否可以在小程序中“按住二维码扫描”，文档里面没有提及，除非看见别人可以这样搞，否则就不要以为能通过在小程序内放一个二维码增加公众号的粉丝（但是网页可以）；

• 目前我不知道是否可以在小程序中使用a>链接跳转到普通网页去，如果可以那么用户体验就会打折扣，如果不可以那又怎么和其他网站合作呢？（我认为如果不支持浏览器必然会大打折扣，所以因该是支持的）；

• 小程序发起请求必须使用HTTPS协议，也就是说如果你要和其他第三方网站合作，调用他们的API，那么他们必须提供HTTPS协议，目前这会导致你无法与许多第三方网站合作；

• 小程序的推送功能目前远不如公众号，也不能从公众号底部直接进入小程序，还不如写一个HTML网站，引导用户（按住）扫码关注公众号，再从公众号菜单进入程序来得直接与实在；

• 有人说小程序可以用微信账号登录与微信支付，而订阅号不可以，其实订阅号也可以。注册一个订阅号，点击订阅号的菜单跳转到网页去，但是网页使用服务号的JS SDK开发就行了，一样可以登录、支付，钱入账到服务号中，此方法甚至不需要用户点击“同意”就可以得到用户的头像和用户名（可以关注我们的公众号“安顺US”体验一下，我已这样做已经快两年了，目前暂无限制）；

• 目前必须在微信IDE中调试，在微信APP中运行，如果这两个地方有Bug（或者更常见的是你怀疑他有Bug）的话怎么办？你没有文档可查，网上也搜索不到解决方案，你发邮件问微信的开发人员他们也不会给你回邮件（除非你是他们的合作伙伴）。

• 小程序的维护需要有小程序开发经验的人，传统Web开发人员需要花时间学习（更多的是练习）才能适应小程序的开发与维护，所以在招人上可能会更困难；

最后，我相信微信小程序会蓬勃发展，会有大量的开发者加入，会有完善的文档。我认为小程序将会大幅降低开发成本与分发成本，这远比提高用户体验更能拉拢开发者，未来会不会出现一个小程序开发大军现在还说不准，但是我看好小程序。我认为不要急于开发小程序，不如再观察观察。

​