微信小程序(应用号)价值是什么? 财富值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 (二维码自动识别)
公众号原文：微信小程序来了!!!程序猿们你们路在何方? [前端篇]家清妍 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数据驱动开发，因此an优艾设计网_PS交流gular2和vue开发经验的同学基本可以秒上手。个人观点欢迎吐槽
edmondchan888#p 优艾设计网_Photoshop论坛 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的优势不过将运行的环境要求更多从用户端移动到了服务端，对于用户而言，并没有带来体验上质的提升。同样，微信应用号的获客成本低原因在于微信应用号目前是一个空优艾设计网_PS百科白领域，数量少的关系导致的获客成本低，数量多了获客成本必然升高。你要知道，windows 应用商店现在获客成本也不高，但是靠这种起点低带来的短暂优势去挑战一个成熟的平台，成功的可能性能有多大？
当然，并不是说微信应用号就没有优势。做为一个有巨大流量的渠道，即便被分流了很多，带来的流量依然会比创业公司的流量大很多。但是就跟微信引入广告一样，第一次进入微信做广告的宝马被大家刷屏记住了，但是后面微信的广告被用户点击浏览的效果会越来越差。因此微信应用号从短期来说，是一个中小型创业公司抢占流量的机会，但是长期来说，微信应用号是一个业务成熟公司警惕、弃用且被用户遗忘的角落，前提是苹果不封杀这个。
加载中,请稍侯......
精彩评论