回复内容:
感觉是广告题呢,大概看了下,所谓 html5+ 不就和 Cordova 差不多么... 流畅度什么的无非就是用 CSS transform 呗,也不用装那么神秘... 虽然 CSS transform 用得好确实可以做出媲美原生的 UI,但要说得仿佛一定要用贵产品才能做到就不厚道了。
和 ReactNative 的对比槽点太多,唯一赞同的一点就是长线来说 RN 的意义是逐步下降的。
---
嗯,又仔细看了看,5+ runtime 在性能方面确实有一些特别的考虑,我收回上面 CSS transform 那一段。基本上总结起来一句话,就是多个 webview。在一些特定的地方,比如列表、下拉刷新,利用一些低版本 Android 上 webview 的滚动性能优于单个元素 overflow: scroll 的性能这一点,用多个 webview 来规避滚动性能问题。这个确实解决了国内 hybrid 开发的一些痛点,但是 webview 方案并不是从本质上解决了 hybrid 性能的问题,难道切屏、滚动、下拉刷新就囊括了所有的『动画效果』了?这也太小看交互设计师了吧。在 webview 内部 5+ 其实和普通的 hybrid 没有什么区别,原本会卡的 HTML5 动画并不会神奇地就不卡了。另一方面来说,这些性能问题其实大部分只在低版本 Android 上面存在,所以这些所谓的性能增强的意义其实也是随着手机硬件的提升在下降嘛...
我觉得 5+ runtime / Native.js 和多 webview 方案思路还是不错的,但是在文案上... 可以少一些『吊炸天』的即视感,语气更平和实在一些。
至于 MUI 框架,设计思路实在是比较滞后了,开发体验比较捉急,楼下有人提到了。不过 5+ 并不一定要用 MUI 框架吧,其实我觉得主推 runtime,做 Cordova/RN/NativeScript 的竞争者就好,上层 UI 框架这种东西变化很快,保持灵活性更好。
谈谈dcloud这一套,rn没有接触。
接触较早,
被html5+和mui两个demo吸引,
然后走上了开发之路。
mui不仅仅是ui框架,
包括了ui,js操作,native封装,
mui的ui方面,
像是bootstrap+amazeui+framewor7的糅合,
js操作,
简直就是对jquery赤裸裸的抄袭,
native方面,
对nativejs做了些封装,
优点
简单易上手吧,基本会用bs的上手无压力
缺点
ui,适合在它这套ui中可以做出来的app,如果app有太多不同就没戏了
js,当真是画虎不成反类猫,坑很多
nativejs,封装了一部分,还好
舍弃
直接壮士断腕,砍掉mui,
让用户自行选择ui层用am还是bs还是f7还是自己写,
js层也自己选择原生js还是jq还是zepto等
对nativejs那一点点封装也没必要保留
专注
专注于nativejs的开发,三方插件的集成,性能的优化,文档同步,更多示例,更多宣传。
试想
bootstrap,amazeui,framework7,metrouicss当ui,
seajs,requirejs,es6当js模块化,
gulp,fis,webpack,coolie前端构建,
sass,less预编译css,
vuejs,angularjs,mvvm双向绑定,
如此多前端技术自由选择,开发者肯定更多,而dcloud只需要做好nativejs和云打包的事情。
个人感觉就不会像现在对dcloud来说精力分散,对开发来说技术选择比较少,束手束脚。
题外话,
流应用这东西感觉方向有点偏了,
必须是android外加集成了h5+基座的360手机助手才有可能实现所谓的秒级安装的流应用。
方向太窄太偏,ios一天不放你过去,这个一天也没有前途~
---------------
以上都是说的mui,
稍微说下hbuilder+mui+nativejs这套开发app,
优点是入门容易,上手容易,
熟悉后,开发app很快,而且大部分app都可以开发出来,只要不是有太多自定义动画的就好。
也就是说找些刚毕业会写html js css的人就可以开发app,对比原生开发的价格,着实节省一大笔钱。
性能问题,ios上很流畅,android这个趋势,千元机已经很牛逼了,所以也不需要太顾虑。
可能还是生态的问题,一个是基于标准开源的生态,一个是基于各家不同的runtime的生态,就会比较小众了
他们除了那个简单的神似framework7的移动端UI框架mui,还有个叫HTML5+的,可以想象这家公司宣传的真是不到位。 正好曾经接触过这个mui和HTML5+,和rn是完全不像,但是确实挺像cordova的一个手机端浏览器壳子,不过这个产品还是优化了不少东西,比如有人提到的webview里超长长列表的滚动
承载列表webview单独拆分出来,用移动webview的方式来滑动。
还有个比较好用的就是native.js,可以很方便做二维码扫描,推送,第三方登录这些,开发效率还是很不错。
利益相关:两个都用过,都开发过中等大小的应用
————
先下结论:MUI是国内优秀的跨平台开发框架,或许是最优秀的
曾用它做discuz论坛通用的app,包括读帖,发帖,评论等一系列内容
优点:简单到不能再简单了,遇到不懂的再看文档完全没问题(都是现成组件)
最符合人习惯的开发方式是什么,就是一个标签一个标签地写页面,这也是web开发最初的形式,哪像现在,我在项目里写了三个月js还不知道它是干嘛的
对于页面不多,交互简单的移动端,我是提倡这种方式的
拿一个简单的页面跳转为例,分别看看两者怎么实现
MUI
<code class="language-text">mui.openWindow({
url:'info.html',
id:'info.html',
extras:{//页面间传值
name:'mui',
version:'0.5.8'
}
});
</code>
是不是广告贴我不知道,我们就用mui做了一版app
坦白的说,熟悉了5+和mui后,做一个app确实快。
开发方面,扫码定位分享这些常用的5+都集成好sdk可以直接调用,mui就是bt+简化版jq,做页面很快,打包还能在线打包下载。
总的来说,入门快,开发速度快
尤大大说是css3,其实他的页面切换是多个webview之间截图动画,所以窗口切换的效果还好
因为iphone的描绘优先级最高,所以做出来的app在苹果上体验还不错,安卓上就不怎么样了,尤其是长列表+低端机了,没有官方宣传的那么好
最后要吐槽的就是,这玩意儿对官方的依赖太大,如果你要集成一个官方没做的插件,你就得自己学他的插件开发,插件开发好后再离线打包,享受不到在线打包的便利了~
文档也跟不上,经常需要自己看源码知道有哪些黑方法可以调用-- 好在不难,然后他们好像人手也不太够,有的bug和功能在他们一句评估后就只能干等着,也不知道啥时候能好。。
如果是展示型,时间和人手又紧张,可以用一下这个,有能力的话还是上原生吧!
用mui做了一些app,技术选型前研究了很久,用mui担心其他网友说的卡顿等性能问题,用rn明显要重新培训团队。
最后在这里找到了一些信心,决定用mui。那时候是2015年
现在项目已经上线了,开发过程遇到的坑不多,毕竟只是简单app。
但是卡顿真的是太折腾人了,预加载也处理不了了,毕竟页面多了之后就卡。
导致最后把所有切换页面动画全删,没动画还能忍
而且html就是html,那些控件和原生比起来差很多,不如原生看起来漂亮。
和上面某哥的意见一致,如果重新选,我选rn。
现在rn已经出了很多的案例开源程序组件库,虽然官方还在不断更新,不断挖坑,但是网友的填坑能力更好。原生组件看起来更舒服。
泻药
偶是看都没看
因为光看描述就觉得这就是两种东西
H5+的意思肯定是H5+(Native) 之类的
plugin 啥的它也说了
无非就是套壳的
但要做的好还得有点底子才行
H5 现在能力不足
+ 这部分得起码会点 Native 开发
而 React 做成这样就是为了快速开发常见场景用的
JS HTML 什么的写一起
跟学前端入门时候一样
所以它的意义在于降低开发的门槛
毕竟前端入门容易
这样搞入门的前端也能开发常见场景了
所以他们面对的开发人群就不一样
只有共同点是APP开发
其它么
纯粹俩玩意
风马牛不相及
说个题外话 半年前我们原本用HBuilder 后来都改webstorm或sublime 实在卡出翔 完全没宣传的行云流水 不知是不是使用方式不对