微信小程序(应用号)价值是什么? 财富值37？
球球的猫 2022-08-11 09:28 我从技术角度聊聊小程序.先来个开发界面截图.工程项目,编辑开发,运行调试,打包部署...开发模式一条龙,完整的IDE.再看看使用的语言,技术规范...虽然借鉴了react,vue等前端理念,但事实上他是一套完全封闭的技术体系,这套体系只能用于开发小程序.啊!!!场景何其熟悉...android开发借鉴了java的技术理念和规范,但却是完全独立封闭的技术体系,只能用于开发安卓OS下的app...说到这里,大家明白了.微信已经是个OS.有自己的开发模式,有自己的开发语言,有自己的API.比起安卓更可怕的是,微信是个云端OS.所有的开发,部署,接口,数据流转都是基于微信这么个超级云服务上.======================下完定义的分割线=====================Q : 小程序真的是用H5开发吗?A : 答案显然是NO.小程序用的是一套全新的技术规范和技术架构,它是微信自有的,它借鉴了许多前端开发的技术理念,例如他用react实现"组件",例如用vue实现标签式逻辑与数据绑定,甚至用CMD的require作为面向对象的js引入.你可以说它用javascript语言和标签语言和css语言来写程序,你可以说它90%跟web前端开发一样,你也可以说任何一个有经验的web前端只需要花费十分钟时间就能快速上手小程序开发,但他依然不是标准化的H5+css3+javascript,也就是说小程序其实和w3c规范的那个html5+css3没半毛钱关系.我这么说,论据有以下几个:小程序中没法使用dom,而且页面也不是基于window,document这些内置对象来做编程.这意味着现有前端领域的绝大部分第三方框架如Jquery,Zepto都是不能用的,就更不用提其他UI类的框架了(例如各种滚屏框架,chart图表框架,富文本框架等).另外,小程序的javascript上下文中自带了wx对象,也就是原来公众号开发中js-sdk的主对象.小程序的标签不是html,它是借鉴react理念定义出来的一整套新的标签库,它只能运行在微信的浏览器下.这意味着我们以往在服务号,企业号或者通过浏览器访问的前端项目代码,无法直接移植到小程序.参考以上代码,小程序的页面以page为主体对应html的body,以view标签对应html的div做区域布局,以各种form,input,silder等标签对应html中各种组件标签.理念很相似,但细节相差巨大.html+css+js 和 wxml+wxss+js .如上图,官方demo中一个标准页面对应的代码是这些.微信小程序定义了自己的一套模型,理念上学习了主流前端开发中数据/样式/控制分离,并且省去了各类繁琐的关联配置,而是从规范上规定了每个"页面"需要有同名的三个文件,各司其职.目前从观察上发现,.js文件采用的依然是标准的javascript语法,wxss中采用了标准的css语法(我相信只是部分使用,因为css本身也是基于dom的选择器语言),而wxml与html的区别则比较大.小程序的页面是基于本地的,无需通过服务端请求.任何页面跳转都可以不通过服务端交互.这无疑比起服务号/企业号等基于h5的模式拥有更佳的用户体验,或许接近原生app的体验.如上图,我在demo中点击页面跳转时network栏中都显示没有任何http交互.Q : 原有做服务号/企业号开发的工程师如何切换到小程序开发?A : 前面说过由于小程序采用完全独有技术架构而非h5,所以原有的服务号/企业号应用是无法直接迁移到小程序的.小程序的开发也不是采用h5+css3+javascript的模式.不过从技术理念和开发模式上看,有经验的前端开发人员可以快速切换到小程序开发.下面简单列一下一个前端开发工程师开发一个小程序的顺序:创建一个模块(页面).前端开发是以"页面"为单位,我身边的工程师在谈论自己工作量很重的时候喜欢说"我周末又得加班了,我还有X个页面没做...".同样的,小程序也是以"页"作为工作计量单位的.创建模块(test)即会创建出三个文件test.js,test.wxml,test.wxss.切图,还是得切图.UI给出的设计图,以前怎么切还是得怎么切,切完把html拷到wxml文件中,把css拷贝到wxss文件中,image也按照示例工程的规范放到对应位置.然后就是暂时我也不知道应该如何更高效处理的步骤,就是把html的div,form,input,select等等的标签替换成view,text,image等等的自有组件.把css修改成以class为主体的wxss.让小程序跑起来.js文件写入简单的初始化逻辑,直接用微信开发工具让小程序跑起来.OK,接下来就是根据设计图的细节,逐步调整小程序"页面"的美术效果了.绑入事件,加入交互控制的逻辑.和web前端开发一样,小程序的交互控制也是事件驱动的,也是绑定各种按钮的onclick事件(小程序里面用bindtap),然后,在test.js里面处理各种交互逻辑.绑入数据.数据哪来呢?也许是页面初始化的时候通过request(ajax)从服务端请求而来.目前官方的demo中只说了数据请求采用内置的request,但没有具体的交互示例.不过不用猜也知道应该是通过http+json的模式来走.相当于小程序内置封装了ajax交互的接口.请求回来的数据,通过标签式的逻辑和模板数据的方式填入页面,这个其实是借鉴了vue的理念,如下图.获取数据后,小程序通过对组件setData的方式将数据装入组件中.这是小程序开发和web前端开发最大的不同,小程序是基于组件的,web前端是基于dom的.最后列举一些小程序开发借鉴h5但可以发挥出比h5更强功力的功能. 1) 本地存储localStorage.这是h5的特色功能,但即将会在小程序身上发光发热.由于小程序的页面都是本地化存储,这意味着在没有网络的环境下也可以使用.那么结合本地存储,小程序可以满足暂时断网或网络情况较差的场景需求.这是做服务号开发所无法实现的. 2) 图形化canvas.小程序运行在微信上,微信不仅是一个web浏览器,它有能力向图像化功能提供更好的效果和更优的性能. 3) 服务端主动推送websocket.官方的demo中对于websocket功能的展望是说可以实现实时IM对话.呵呵.不难理解.展望吧. 4) 比服务号jssdk更丰富的原生能力.地理位置,重力感应,陀螺仪,本地文件...太多可以期待的能力了.(未完,待补...今天花太多时间写东西了,得赶紧去干活...)===================广告的分割线===================关注我的公众号,请搜索 : 全栈生姜头
http://weixin.qq.com/r/3TkOFovEXdYirc9192zP (二维码自动识别)
公众号原文：微信小程序来了!!!程序猿们你们路在何方? [前端篇]家清妍#p#花姐 2022-08-11 09:29 微信的想法：手机开机 —> 微信 —> （社交+购物+吃饭+金融...） —> 手机关机 —> 循环以上步骤别的公司的想法： 微信 —> 小程序 —> 获得粉丝 —> 完整版请下载APP但凡智商正常的公司决策人，会被微信捏着蛋么？
MidoriSuki 2022-08-11 09:29 先贴一个小程序开发新鲜教程https://my.oschina.net/wwnick/blog/750055?from=timeline&isappinstalled=0看完教程先写写我的直观体验:1.微信小程序做法应该和react native一致，因为体验为原生控件，微信采用XML标记语言而不是HTML，所以你在XML写HTML标记是没有用的。微信自己利用XML去解析渲染。2.开发工具，果然很人性化。但是应该是初期，有一些如自动刷新没加入。3.不支持npm安装第三方依赖，微信应该有忧虑，但是目前情况来看，第三库是用不了了。学好原生JS才是王道。4.感觉模仿vue数据驱动开发，因此angular2和vue开发经验的同学基本可以秒上手。个人观点欢迎吐槽
edmondchan888#p 2022-08-11 09:30
关于微信小程序。从安卓机器的生态环境角度来看，未来可期：
原因
1现在国内的安卓上面各种app毫无顾忌的拿各种隐私（比如通讯录，短信权限，地理位置，麦克风，摄像头，照片），有时候一个搞天气的都需要读通讯录和短信，受不了。
2大量毫无顾忌的强占后台资源（死不退出内存，随时后台复活），最后导致机器卡的要死
3更别说有的不良APP自动或被动的背后乱搞流量或其他灰色动作等。
讲的严重一点，国内安卓APP市场有点失控。给用户带来的最大的压力感受的就是卡，其次是安全隐忧，反正不管多好多高端的安卓手机，安装多了APP，最后都是卡的很。（反面也促进了360腾讯管家这种程序的活的很滋润）
等小程序来了，如果用户使用体验上（这一点非常重要，是一切的前提）能够和原生app在ios上那种使用体验无差。那么将会有大量的安卓机用户为了机器流畅性，把相当一部分中低频的app拿掉然后换位使用小程序。
至于小程序在微信的位置路径等等，我觉得都不是问题。大不了微信将来允许小程序弄一个快捷图标丢到手机桌面上来，然后你一点就打开微信中对应小程序即可，体验还更好。
关键的关键还是小程序里面的使用体验能否做到类似在iOS上的同款APP的使用体验？
能，未来可期。
9859 2022-08-11 09:32
Lcy牛牛 2022-08-11 09:37
早上被微信应用号（官方称为微信小程序）的消息给刷屏了，似乎一个颠覆性的时刻又要来临。做为这个世界一部分，有着丰富的被改变经验，对这一切已经产生免疫了。在所有人都对微信应用号看多的时候，持着一些看空的观点，不吐不快。
在微信应用号之前，其实之前腾讯做过一款应用平台性质的东西，叫Qplus，不知道大家还记不记得。我想当时Qplus怀着一颗并不比今天微信平台更小的野心，但时至今日，不知道多少人还记得这个东西。当然，相比较Qplus，微信应用号依然有着不少进步的地方。如，无需手动安装程序，所有功能全靠H5实现，对用户端的操作和要求更轻；同时，微信的体验比QQ更好，应用号的体验当然也会比Qplus更好。
在这么多种种利好的基础上，大家当然有看多的基础，微信是一个成功的平台吗？当然是。但微信应用号也会如大家期望的那样，成为取代APP的未来应用生态吗？纵然微信有着开发门槛更低，获客成本更低优势，但是觉得可能性很小，会重蹈Qplus之路。理由如几下点：
1、 从竞争的角度讲，苹果会不会让载有微信应用号（叫微信小程序而不是微信应用号大概也是规避苹果的注意力）这个APP生态平台的上线我觉得是一个问号，这个是一个和APPstore有直接竞争关系的功能。且在微信应用号上发布的应用功能受微信审核不受APPstore审核，这种越级行为苹果真的能容忍吗？我看不能吧。且不说这种行为从根本上挑战苹果的监管，而且微信应用号这个生态是为挑战苹果APPstore生态的，是可忍孰不可忍。大家都忘了当初阿里云发布时谷歌的反应了吗？你想在我的平台玩你得守规矩，不然只能让你胎死腹中了。
2、 从商家和公司的角度讲，开发微信应用号纵然可以在短期内降低获客成本和开发成本，但是将公司的未来放在一家渠道商手里而不是自己手里真的明智吗？要知道微信有着经常系统抖动的历史，对于这样一家裁判经常下场帮运动员踢球的裁判，做为商家你真的敢在这个平台玩吗？
3、 从用户的角度讲，微信应用号带来了什么？更好的体验还是更便捷？我可以一边玩手机APP一边聊微信，那我可以一边玩微信应用号一边聊微信吗？好像我想边看文章边聊微信的痛点都没有解决掉。我打开一个APP手指滑动一下就可以了，那我打开微信应用号里的应用需要几个步骤，打开微信->找到应用号所在位置->找到具体的应用号，最少也要三个步骤，所以微信应用号在便捷性这个角度讲不会比打开管理一个APP更便捷。
4、 从生态的角度讲，即便让微信应用号发展起来了，最大的结果是什么？结果不过是另外一个APPstore，并没有颠覆谁，重复造轮子而已。H5相比较APP的优势不过将运行的环境要求更多从用户端移动到了服务端，对于用户而言，并没有带来体验上质的提升。同样，微信应用号的获客成本低原因在于微信应用号目前是一个空白领域，数量少的关系导致的获客成本低，数量多了获客成本必然升高。你要知道，windows 应用商店现在获客成本也不高，但是靠这种起点低带来的短暂优势去挑战一个成熟的平台，成功的可能性能有多大？
当然，并不是说微信应用号就没有优势。做为一个有巨大流量的渠道，即便被分流了很多，带来的流量依然会比创业公司的流量大很多。但是就跟微信引入广告一样，第一次进入微信做广告的宝马被大家刷屏记住了，但是后面微信的广告被用户点击浏览的效果会越来越差。因此微信应用号从短期来说，是一个中小型创业公司抢占流量的机会，但是长期来说，微信应用号是一个业务成熟公司警惕、弃用且被用户遗忘的角落，前提是苹果不封杀这个。
