佛曰:前世五百次的回眸,才换得今世的擦肩而过?br/> 了解尊龙z6尊龙最新登录首页-尊龙备用网站官网-尊龙备用官方网站只要60秒,让我们不再错?br/> . . .

WEEX

当前位置:主页 > WEEX >

如何评价阿里无线前端发布的Weex?

来源:admin       时间:2020-11-12 17:02         责任编辑:admin

  Issues · amfe/article · GitHub 阿里无线前端抛出的 无线电商动态化解决方案 Weex.

  有人说不能水,其实技术上的大家都懂,就是个看法而已。我个人而言,很高兴看到 Vue 的 API 设计被大家认可采用,不过阿里这次直到发布之前我也是完全不知道,还是略有一种吃了苍蝇的感觉(事后勾股跟我沟通过了,所以也还好)

  确实如一些同学指出的那样,我们会担心阿里对于这个项目的长线支持如何,以及对于开源的 commitment 有多少。针对自家业务定制无可厚非,但是既然宣布要开源,希望阿里能有有足够的诚意给出一套大家都能用的方案。做好国际化,做好文档,做好开发者体验的各种细节,不要让它沦为 KPI 驱动的牺牲品。如果想和 Vue 做官方的合作,可以找我聊聊。

  首先说下我为什么要问这个问题(没错我就是这个问题的提问者),刚开始在微博上看到有技术连载觉得很感兴趣,所以就关注了。当@赵锦江(勾三股四)发布说一套代码能动态的运行在三端,我顿时觉得很牛X啊,既然说是无线电商动态化方案,那么其他场景呢,所以想问问大家的看法。问题从发布一个晚上就关注度到了1, 2百。估计跟邀请了一些大V有关。至今已经到了快800了, 让我这个小菜很是紧张。在此感谢各位的回答。

  Weex是什么?考虑这个问题我们先来看看Weex不是什么把,根据文章(对无线电商动态化方案的思考(三) · Issue #15 · amfe/article · GitHub)中声明的是:

  相信到这里可以大概了解了Weex其实一个整套的技术解决方案,并不是一个新的框架或者库,它是一些技术的整合。

  关于实现原理我下班路上收到的第一个答案我想应该是@寸志的回答把,其实一开始我觉得他调侃的成分多一些(所以一直没有点同意,待会补上,哈哈),之后@尤雨溪也跟答道:

  我开始觉得这不是在打哈哈的回答。所以我回到家认真看了下@寸志提到的那张图。附图如下:

  然后结合文章,再理解了一遍后觉得叫Vue-Native也不为过 (@赵锦江(勾三股四)提到内部开发时候代号就是这个),哈哈。下面先从Vue-Native角度来理解下:

  简单的在调侃这个名称上可以对比理解react.js & react-native 感觉这像是Vue.js推出的针对native端的一个框架(刚才我们说了它并不是框架)。认真的理解其实就涉及到Weex的真实实现方式了。整个简单的流程如下:

  组件的声明方式:可以看到Weex并没有采用Vue.js官方的声明方式,而是采取了跟标准更靠近一步的Webcomponents形式,但是在文中有提到Weex采取的数据绑定和依赖收集是复用了Vue.js的实现。

  在有了组件并且用组件搭建好了界面后,这里添加了一层transformer。把组件中的数据绑定,style等的解析提前到了在渲染真实dom之前,编译成json,或者js function。

  经过transform后,怎么一套代码对应到多端呢?这里可以看到Weex吸取了reactjs的virtual dom的思想。在web view& broswer中直接生成dom。在native中生成native控件。这里使用了JavaScript 引擎接收js bundle通过JS Bridge 和原生API交互。最终生成原生的控件或页面。

  这只是一个简单的流程,详细的技术细节还是看文章把。从上面的流程可以看见,是借鉴了Vue.js的mvvm + react的virtual dom。关于这个结合的创意 可以看到@赵锦江(勾三股四) 在对无线电商动态化方案的思考(三) · Issue #15 · amfe/article · GitHub文章总结的QA部分(没想到我一句评论勾起了@赵锦江(勾三股四)的心路历程,让我们有机会了解到当初这个项目的起因)。

  终于知道@Jinjiang为啥之前一直在研究 webcomponents & vue.js 了

  anywhere,既然人家取名叫Weex了,我们还是要尊重下别人的劳动成果。看到@尤雨溪修改了回答,还真说不定之后有可能跟Vuejs官方合作呢~

  关于使用场景和发展,从对无线电商动态化方案的思考(三) · Issue #15 · amfe/article · GitHub文章中透露的细节来看,还有一些技术问题还没有解决。

  因为移动设备的资源非常有限,所以就算同时打开多个 Weex 实例,也只能公用一个 JavaScript 实例,如何有效的让多个实例在 JavaScript 引擎中共存是个关键的问题

  如何优雅的设计动画和表单的语法并合理的实现,是否照搬 HTML Form 和 CSS Transition/Transform/Animation 是最好的选择?

  如何同一个 URL 或二维码,客户端请求到的是 JS Bundle,而浏览器打开的是一个 HTML5 页面

  还有SEO的问题(既然要开源,这个我觉得不应该以阿里的业务场景为前提。)

  以上是目前Weex的一些技术问题。但是,我觉得自从@winter抛出说这个是一个后KPI项目后。大家普遍关注于Weex之后的发展问题。觉得可能会是一个KPI的铺路石( 貌似Kissy这次躺的很彻底)。而且从其他的匿名回答来看,阿里其实有在研究基于RN的动态方案。所以之后阿里是推哪套方案目前好像阿里内部员工也比较搞不懂。我们只能说希望Weex能克服目前的困难,然后像@尤雨溪说的那样推出一套有诚意的开源作品。然后造福FE同学轻松hold住多端的问题。

  我根据@winter的回答,找了下Qcon的报道,据说是2016年中开源.(留给阿里同学的时间不多了)。

  我们并不是一个人在战斗,市面上已经有很多非常优秀的技术可供参考和使用,Weex 希望集优秀技术之大成,快速落地,解决业务上“最后一公里”的问题。

  虽然后来了解到这个是一个KPI的项目,哈哈,我还是非常认可@赵锦江(勾三股四)使用最后一公里 对Weex这样的描述。我佩服认真做事并且保持谦卑的人。

  第一次码这么长的回答,算是对这问题的一个总结(虽然可能没有人看),不对之处还请指正~ 最后谢谢大家的回答。

  大家好,不匿名,我认为这是一个从头到尾的KPI项目,我们团队2015年KPI非常重要的一条就是解决web动态性和Native体验之间的矛盾,所以我觉得@赵锦江(勾三股四)做的超棒,今年KPI肯定有所体现哒哈哈哈哈!

  2.为何不是React Native?答:这是个很长的故事,短的版本是,阿里各team(包括我们)一开始都是狂热的rn粉,然而至今已经基本都放弃了。具体内容大家如果有兴趣,我也可以请一线经手的同学来讲讲长的版本。

  3.造轮子?答:我们2013年开始搞的Weex的前身WeApp,如果不造轮子的话,就没有RN了,我坚决支持Facebook的创新和分享精神,走自己的路,让喷子们说去吧!

  前几位的观点基本同意,其实还是拿掉 dom-diff,造了个极简版的 rn 。

  weex 用来搭建双十一活动页面,就是些图片展示模块,模块内部几乎没什么交互,更别说模块和模块间的交互了。那么,复杂的页面应该怎么写,我觉得至少得有下面几个模块:

  weex 这些都不支持,距离开发一个完整的 app 还很远很远,和 rn 的差距还很大。

  另外,webcomponent 分离 HTML、CSS、JS 的方式一点也不科学,JSX 才是大杀器。

  囧... 我其实没黑的意思啊. 其实在大公司要把技术项目做下去, 能否要到资源是很重要的,我没有反对这个图啊。

  其实最终还是会回归到 webview + native的传统方式, 无论何种技术其实都应该思考它们设计的本意,和我们这边的一个类似的解决方案的主导者之一聊了下, 在这点上大家还是比较一致的,最终的性能等问题肯定都会被解决。

  阿里这些前端框架一贯的特点就是雷声大,雨点小,对外宣传各种高大上,实际使用满地是坑。

  这两天向阿里的同事了询问了下对 Weex 的看法,很多人表示并不知道这个东西,发了文档链接看了后也都表示没看出实际价值所在。去公司内网上搜,发现勾股那几篇文章也鲜有回应。我想大家可能可能是被坑多了都有点怕了,就像之前的 KISSY,宣传得很牛逼,实际上呢,难以使用就不说了,升个级 API 都不兼容,到处是坑一直在填,KPI 倒是赚了。说一大堆什么适用与阿里的业务、提供了一套电商前端解决方案之类的,其实比 jQuery 就多了一个模块加载器而已,CDN 支持 combo(性能好是阿里的 CDN 好),使用体验上比 jQuery 差远了。

  很担心现在的 Weex 跟以前 KISSY 一样,自己造了个倒退的轮子。因为看不到他的优势体现,write once, run everywhere 这种方案能靠谱我想大家也不会真信吧?微博上说已经在「双十一主会场」使用了,很多人一听「双十一主会场」,肯定就觉得高大上,这个东西已经在天猫核心业务做过检验了,靠谱。其实呢,「双十一主会场」只是名字高大上,并不是核心业务,并且那个页面极其简单,基本是展示图片的,点击链接跳转到新页面,根本没有什么 js 交互逻辑,最麻烦的部分可能是运营填数据的工作量。。。而一个 js 框架,用一个没有多少 js 交互逻辑的页面来说明框架没有问题,这本身就有问题。还有 rn 已经出来有段时间了,并且生态也更强大,现在都还有不少坑要填,Weex 离能使用(在 js 交互相对复杂的页面)不知道要多久,关键是这个方案没有让大家跟着去填坑探索的动力啊。。。

  希望不要又成为一个 KPI 项目,半路夭折,不说了,继续搬砖写代码去了。。。

  ---------------------------------------------------------------------------------------

  围观中,看到大漠发微博说在双十一主会场应用了 Weex,但是主会场的页面代码逻辑应该不很复杂,期望在更复杂的场景中能够应用

  对 native 这块很感兴趣,感觉可以和 react native 竞争,不过即便是已经出了这么久的 rn,现在依然有很多问题存在,所以 Weex 在 native 方面应该还有很多坑要填

  阿里的Weex,和React Native的关系。最直接的类比是Kissy、jQuery。

  。我们内部也有一部分人嗤之以鼻,说又在造轮子。目前在开发上也是两个方向:Weex与React Native。在手淘及手猫两个app里,都集成了这两套的开发环境。

  但是也不必神化,目前保持观望态度即可。阿里系的东西肯定是最适合阿里的业务,也许通用性不一定高。就像Kissy一样,最终用户也是阿里内部(话说现在好多团队在做去Kissy化的事情了,呵呵)

  ,这也是Weex最主要的价值之一。这也意味着,我们要舍弃非常多的web特性,提取Web与Native共同部分进行整合。简言之就是:

  * 是否在持续的维护。(主要担心Weex在阿里内部无法持续,沦为一部分人晋级的工具,晋级完了也就不维护了)

  * 是否有完善的生态体系。(RN目前有非常多的组件及文档,可以直接拿来用,遇到问题也可以搜到,提问有人解答。看看现在的Kissy,谁用谁知道!)

  还有一些手机淘宝常年的底层技术积累,如集团 Hybrid API 统一设计规范、底层的图片库、网络库等,都能够让我们能够快速实现自己的想法,快速在业务中完美落地,快速产生它的价值

  的时候,我觉得还挺虚的,我觉得开源项目要想真正不带着业务的味道就不能做任何关于业务的假设。说实话我个人并不相信BAT的开源项目就是因为这些项目都背负着沉重的delKPI压力/del业务背景。而且越是说“我们提炼了XXXX,并且淡化了XXXX”都觉得是越描越黑,此地无银三百两的感觉。

  从现在的信息来看,东西当然是好,很流弊,可是当年Kissy东西也是好,也说是通用的,也bla bla,希望不要成为下一个Kissy,呵呵。

  本来就是大量借鉴 Vue 的……每天在微博上看勾股和小右互动,还以为手淘要贡献 Vue 的生态圈呢,结果搞了这么一个牛逼东西出来还换了个不好听也不好记的名字 OTZ

  其实就叫 Vue-Native 挺好的,一眼就知道是个好轮子,大家都开心

  Weex = Vue + React-Native as Kissy = jQuery + YUI

  其实你不能说 KISSY 不好用,但是阿里系的框架都太太太“阿里业务定制”了:

  哎呀觉得 YUI 和 jQuery 都不错,来来来拼起来;需要 MVC 了,放一点 Backbone;哎呀 RequireJS 不错,抄一个 KMD;尼玛移动互联网的风潮来了,KISSY 太大了我们要瘦身,再搞个 Kissy mini

  现在 Kissy 过时了,MVVM 火了,React-Native 这种超越 Hybrid 的 JS 跨平台技术火了,Browserify/Webpack/Babel 这种 Bundler/Transformer 构建工具火了;怎么办技术开始拖业务/KPI后腿了:

  哎呀 Vue 和 React-Native 牛逼,来来来拼起来;哎呀 DOM 模版解析太慢了 Babel transform JSX 的思路不错,搞一个 transformer;哎呀要服务器端渲染要热更新要 SEO ,放一点 isomorphic;尼玛调试好麻烦送一个 debugger tool,最后还附带了一个“移动端专属”的没什么用的小轮子 v.js …

  好吧,最后还是要捧个场!如果我还在阿里这一定是我在阿里最喜欢的轮子了,不可否认有魄力造这么大一个大轮子还是很牛逼的,需要各栈高手配合才能搞定这个大作

  参考我理解的阿里无线前端“架构”(半鸡汤,少干货) · Issue #3 · amfe/article · GitHub中的某张图。

  GitHub - alibaba/weex: A framework for building Mobile cross-platform UI

  weex已经开源了,每个文件分为三大块,用很简单易懂的HTML做模板,里面的JS是es3方法写的,学习成本极低啊!