layui是不是该做大的变更了

讨论 未结 11 861
minimu
minimu VIP3 2019-10-7
悬赏:20飞吻
我应该算是lay的老用户了,从最早的layer用起,也有几年了。也购买了admin和IM的授权。

(1)layui的设计,从一开始就没有把核心(事件等)和UI组件分开,别说该源代码自己打包,作为一个组件,从原生支持剥离也许是更好的
(2)UI部分,感觉还在拼凑html的阶段,给予的封装度不够,没有一个统一的编程或者说组件模型
(3)从完成度来说,并不高。举个例子,进度条组件,真的要在项目中用起来,基本上需要做很多事情。但是有能力做这些的团队,自己DIY一个难度并不大。
(4)从一个项目管理者的角度,我觉得layui的团队也许遇到瓶颈了。最近1年的事件,其实大的改动就是一个tree一个穿梭组件,而一个tree组件因为bug的问题貌似还回滚过一次版本。也许layui的组织者需要认真去思考了。
(5)扩展组件,去年开了个三方组件专区,说实话,质量真的堪忧;多数的组件基本经不起推敲。我们尝试使用了其中的3、4个,除了一个继续使用外,其他基本都放弃了。bug太多;而且太多从设计上就有很大的缺陷。

用Lay的这段事件,也陆陆续续在10来个项目中使用了layui。不过除了一个项目,其他全部把layui当成了基础样式库,使用的组件基本全部全新封装了一次:
(1)修改了一些layui的bug,当然很多也是坛子里面挖出来的
(2)集成了跨域、权限等基础设施
(3)抽象除了一套布局模版,其实就是些html片段了
(4)完全封装了一套form的组件,用了layui的基本样子,实现了统一的事件模型
。。。
当然,没做的事情还太多,bug也是一堆一堆的。但是最重要的是:(1)足够简单,基本不用关心html和dom,甚至js,全是OO;(2)我们封装的是可以很容易从layui剥离出来的,迁移到其他的基础框架上。
实际上,我不止一次动过完全重构的想法,但是每次都自己按住,冲动是魔鬼,冲动是魔鬼,前端团队还不够强不够强不够强。

说说我们最初选择layui的理由吧:
(1)相比Ext、easyui等框架,其默认风格稍微现代点
(2)IE8的兼容,应该是需要的(数据来自浏览器统计)
(3)table组件可以最右侧列锁定
当时选用的时候,团队里面才1个UI,一切为了进度。但是layui最近2年基本没给什么惊喜了。。。。

对于前端UI,我个人觉得比较理想的:
(1)基础设施一定要剥离
(2)能提供高质量的基础UI组件
(3)能提供多个层次的调用者需求:
(a)最简单的调用,能否让调用者能在1个小时内上手作出一个还不错的页面。忘却dom和js。毕竟全家桶熏陶下的新一代前端,多数只能做到这个程度了。
(b)能否提供高级定制的接口,有能力的团队能定制属于自己的组件
(c)提供统一的组件模型,其实可以参考当年VB、Delphi这些“古老”开发工具的控件是怎么设计的,怎么做到展现和逻辑分离的。
(d)提供高质量的生态,质量优于数量。一个组件的发布者都只有不超过6个月的热情,是很难作出优秀的产品的。
回帖