小程序开发框架对比(小程序基本框架)

小程序开发 1971
今天给各位分享小程序开发框架对比的知识,其中也会对小程序基本框架进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!本文目录一览: 1、移动APP开发框架盘点2:Web移动前端框架大全

今天给各位分享小程序开发框架对比的知识,其中也会对小程序基本框架进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

本文目录一览:

移动APP开发框架盘点2:Web移动前端框架大全

开源项目其实有一个成熟周期,这个周期大概是三年左右,自React框架在2013年发布并引爆了前端框架的大潮,这个属于前端的周期就此开始了。

之后在2015年5月开源的React Native又开启了属于Web移动前端的周期,15-16年,18-19年,21-22年正好就是属于移动前端的三个爆发点。

三年前,在第一个成熟收获期,我盘点了移动开发框架。在这第二个成熟收获期,理所当然要来盘点一波。

不过,当我点开github项目的code-frequency时,还是被这个准到吓人的周期猜想惊呆了,先给你们看一波,剩下的自行验证。

1、

2、

再来说第二个比较有意思的发现,停止维护的项目绝大多数是Vue框架项目。

盘点开始的时候我还觉得React框架处于绝对劣势,到完成时我发现React无论在选择面还是成熟度上都超过了Vue。

原因我这里就不分析了,反正大家都有自己的看法。

网页类框架就是前端组件框架,这一次虽然有大量项目停止维护,但是也有很多项目坚持了下来,而且还涌现出了一批新项目。

大厂占了主导,因为这些年大厂在移动开发上的需求,远高于其它方面。个人项目要坚持确实不易。

本来是想要做一个验证项目,把所有框架都试用一遍并给出推荐度的。由于进度太慢,还是下一次再发吧。

这次的重点是渐进类框架,就是所谓多端同构框架(小程序框架)。这几年国内的重点的各种小程序平台,所以多端框架的需求很是旺盛。

不过大多数先行者都没挺过来还是让我很意外,只有Taro成功了,想想还是有很多让人唏嘘的东西。

在这里还是先预测一波吧,因为这一类框架最变化最大,最终还是有很多框架要出局的。

渐进类框架是一个过渡性的产品,最终会变成桥接类框架的一部分,所以,与桥接类框架协同才是框架的出路。

这个赛道基本全是大厂了。

腾讯新一代跨端开发框架Hippy

Hippy一看就是淘宝Weex的对标项目,Kpi功能全面压制。所以官方支持 React 和 Vue 两种主流前端框架。在Weex2019年实质停更后发布,要不要这么卷?

Hippy 2.x 架构主要分成三层,UI(JS) 层 Hippy-React 和 Hippy-Vue 负责驱动 UI 指令生成;中间层 C++ HippyCore 负责抹平平台差异性和提供高性能模块;渲染层 Android 和 iOS 负责提供终端底层模块、组件,并与布局引擎通信。

对Weex惨遭遗弃,我上次就说过:「ReactNative提供工具,Weex提供框架,将平台差异化屏蔽(Write Once, Run Everywhere)。所以Weex则注定功能相对弱小,并且坑比较多。」Weex最终下马也是必然的,淘宝又发布升级版北海,为了实现(Write Once, Run Everywhere),它采用自绘,而且是基于Flutter自绘。

所以Hippy3.x就一如既往的Kpi功能层层加码,很有腾讯风格。在未来的 3.x 中业务与渲染层中的具体实现可根据用户实际场景进行切换:业务层上不再局限于 JS 驱动,还可选择(如:DSL/Dart/WASM 等)其它语言进行驱动;在渲染层中,渲染引擎除了支持现有原生(Native)渲染之外,还可以选择其他渲染 Renderer,如 Flutter(Voltron) 渲染。

「Kraken 北海」是一款高性能Web渲染引擎。底层基于 Flutter 进行渲染。

Kraken 不限制上层开发者使用的框架,无论你是使用 Vue 、Rax 还是 React 都可以开发 Kraken 应用。

Kraken 的 runtime 通过 JS Engine Binding 的方式提供了一系列 Web 标准的 API 接口,调用相应 API 会执行相关逻辑并创建一系列需要发送给 Dart 层处理的指令。

Kraken 其实就是一个小程序平台,而且追求全平台完全一致。我虽然认为各平台不一致是很自然的事情,但是也表示理解,毕竟别人吹牛有当真的传统(KFC表示认同)。

Kraken 现在也是一个小号浏览器,所以它的主要工作就是抠标准,毕竟它是一款基于 W3C 标准的高性能渲染引擎。

最后,我劝淘宝领导定Kpi要理智些,毕竟Hippy4我还蛮期待的。

滴滴出品的超轻量级动态化跨端开发框架,主打轻量和实用。

Hummer 以 JS 引擎为基石,目前已支持 JavaScriptCore、Hermers、QuickJS 等业内知名 JS 引擎(这里本来还有个V8的,我删除了,源码里面没有,Kpi需要)。再配合经过调优的 Yoga 布局引擎,抹平了两端视图布局差异(性能更佳的自研布局引擎开发中)。顺便提一下,Hippy采用V8(功能更强)自研布局引擎(性能更佳)。

Hummer 的特点是抛弃了业界其他动态化跨端框架普遍使用的DSL层和VDOM层,因此原生 Hummer 不具备前端开发常用的响应式编程的能力,但同时换来的是接近原生开发的体验和性能。再以原生 Hummer 为基础,在此之上开发了一套基于MVVM架构的开发框架 —— Tenon ,通过 Tenon,可以把使用 Vue/React 编写的代码,转换成原生 Hummer 的代码。

Hummer也是一个小程序平台,而且超轻量。如果想要无限提升自己APP的能力,可以考虑嵌入Hummer。

Web移动前端框架正在迎来第三个高速发展期,各类框架得到极大繁荣。

个人在具体项目的贡献已经微乎其微了,创新、架构创新是唯一制胜的手段,这也是我看好React的根本原因。

最后,还是想做点微不足道的 探索 ,现在前端组件库层出不穷,更换组件库带来的代价有点大。想创建一个框架,来实现上次说的组件公约数和公倍数,无缝切换组件库。理论上支持所有组件库 ,也能为后来者提供弯道超车的机会。我想大厂可能没有需求,也不会愿意发布这种框架,毕竟都是平台部门说了算。

这个库就是useMobile,当然分为useMobileReact和useMobileVue。下次先发布useMobileReact。等我发布后,再来填上面表中缺的推荐度。

原文地址:

嵌入已有的 Web 页面的「Web」小程序和使用微信小程序框架开发的「原生」小程序相比,有哪些区别呢?

在这之前,如果有人问我,在微信中做一个产品,是用小程序还是 Web 页面 (严谨,既不是 HTML5 更不是 H5…) 的时候,我会这么说:

产品上,Web 上能做的,小程序中大部分都能做。小程序上能做的,Web 上不一定能做。

营销上,Web 能用到的入口,除了朋友圈以外,小程序都可以用。小程序能用到的若干入口,Web 不能使用。

关于后一点,朋友圈分享现在普遍会用海报来做,在这点上 Web 和小程序的能力其实是一样的,都是只能帮你保存图片到相册,再请用户手动发送到朋友圈。而小程序独有的发现 - 小程序、搜索框快捷方式等对用户回访特别重要的入口,Web 页面是不能使用的。

那么,昨天的发布意味着什么?简单地说,小程序的开发成本有了很大的下降。

微信小程序刚刚上线的时候,由于小程序使用类似 HTML、CSS 和 JavaScript 等 Web 语言的方式进行开发,让一些媒体误以为小程序就是 Web 开发,欢呼将「迎来 Web 开发的春天」。我自己的第一份工作就是 Web 开发工程师,Web 开发入门确实比较容易;可是尽管小程序使用了 Web 语言,那只是语法上的一致,整个开发模式完全不同,更接近于原生 App 的开发而不是 Web。打个比方,对在看这篇文章的大多数人来说,读中文要比读英文更容易,但假如你看不懂英文版的《量子力学导论》,翻译成中文版你也不一定能看懂。开发小程序,需要有专门的、独立于 Web 团队之外的团队,按小程序的规范重新设计、重新开发,不能将已有的产品直接迁移过来。

可以理解微信当初做这个决定,是希望开发者按照微信的要求,为微信的用户重新去思考、设计一套全新的用户体验,而不是将已有的 Web 页面搬进来。历史上,包括 Microsoft 的 Windows Phone 平台、Google 的 Chrome Packaged App 都冒过类似的险,而其实 Apple 也做过类似的决定——Steve Jobs 2010 年 4 月亲笔写过一篇文章,解释为何 iPhone 不支持 Flash (Thoughts on Flash),其中最重要的原因是,Apple 不希望第三方开发者将已有的产品直接搬过来,而是希望开发者能直接在 iOS (当年还叫 iPhone OS) 进行开发,为 iPhone 的用户提供最好的体验。这些决定赌的是,新平台 (小程序或 iOS) 带来的商业上的好处,最终会让开发者们愿意付出这个成本。

那时候的 iPhone 还很弱小,但后来的历史证明 Steve Jobs 赌对了——Adobe 公司今年 7 月宣布,将在 2020 年最终停止 Flash 的更新和分发。

微信,则在昨天支持了开发者直接嵌入已有网页。

所以,如果你已经有一个网站,可以直接在小程序中套个壳,把网站中的 Web 页面摇身一变成一个小程序。至于这和直接分发 Web 页面有什么区别——

产品上,Web 上能做的,小程序中大部分都能做。小程序上能做的,Web 上不一定能做。

营销上,Web 能用到的入口,除了朋友圈以外,小程序都可以用。小程序能用到的若干入口,Web 不能使用。

细心的你可能已经注意到了,上面这两条并没有任何变化… 对,在小程序的用法上其实没有任何变化,只是开发成本下降了。

那么,在今天之后,使用微信小程序框架开发的「原生」小程序,和嵌入已有的 Web 页面的「Web」小程序,在用户感受上会有什么区别呢?

「原生」小程序,整个小程序是提前下载的,不会有 Web 页面打开时的页面加载感。我们过去的可用性研究表明,这是用户对一个界面是「Web」还是「原生」的最主要判断标准。对于偏工具型的小程序,「原生」的感受应该会更好。

「原生」小程序对体验的控制更完整,自己要做的事情也更多。例如 Web 页面中用户可以选择页面上的文字复制,而在「原生」小程序界面中,这是需要单独添加的功能。

「原生」小程序提供了一些专属的控件和 APIs(接口),如展示群信息、发送推送等,这些只有使用小程序框架开发才能使用。

所以,如果需要和微信生态整合得更紧密,可以使用「原生」方式开发;如果追求快速迁移已有 Web 产品,嵌入 Web 页面更快。

小程序开发用什么框架

小程序的开发都是通过各自的开发工具进行开发,有它独有的语法规则。没有什么框架,不过可以使用ui框架来改变页面样式 例如:Mintui Wux WeApp iView WeApp

微信小程序开发和APP开发的区别?

1、开发技术的区别 APP:APP开发模式有三种分别是原生APP、WebAPP以及混合APP,它的操作系统分别是Android和ios。开发技术难度较高。 小程序:微信小程序就是基于微信里面的开发框架,开发技术难度也是很低的。【点击查看APP开发的真正报价】

2、下载和安装的区别 APP是需要在商店进行下载的,下载完毕之后还需要将其安装在智能手机内才可以使用。会占用手机内存。 小程序不需要下载,它只需要在微信里面直接搜索就能用了,不会占用内存。

3、开发成本和周期的区别 APP:因为APP软件开发相对来说内容和功能是比较复杂的这就会导致APP的开发成本高、开发周期长。 小程序:它是比较简洁的,只具备比较核心的功能,那么成本投入就少,周期也会缩短的。

4、使用的区别 APP:在应用商店或者浏览器内搜索下载到手机上,会占用手机内存,但是在手机桌面上可以直接进入。 小程序:在微信里面直接搜索小程序或者扫码进入,直接使用,很方便。

想要了解更多有关APP开发的相关信息,推荐咨询猪八戒网。猪八戒网有千万服务商为企业、公共机构和个人提供定制化的解决方案,将创意、智慧、技能转化为商业价值和社会价值。2011年猪八戒网获得IDG投资并被评选为中国2011年度“最佳商业模式十强”企业;专业性值的信赖。

小程序开发框架对比的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于小程序基本框架、小程序开发框架对比的信息别忘了在本站进行查找喔。

扫码二维码