常年搞Unity, H5也接触过,
游戏UI特点是简单干净、量大。
web的搞法显然不适合，Unity的 UI Toolkit Runtime 要想推广开，也够呛。
建议别瞎整，精力花在刀刃上。
我认为前段开发那一套有一定的借鉴意义，但常年开发游戏的人都知道，前端开发和游戏开发是极其不同的，完全搞成那一套没有必要，费时又解决不了痛点，当然适当的借鉴一些也挺好，主要还是性能方面要跟得上，同意楼上的说法，把精力花在刀刃上，整出自己的杀手锏
简单直观，无bug，低学习成本不用天天查文档就是好东西。
游戏UI需求五花八门，做通用组件会累死自己。
关于弹性布局，我的感觉是做的挺好挺强大，但也鸡肋，我不会用游戏引擎做app做网页，所以不太找得到必须用弹性布局的场景，现在大多数的UI方面需求用引擎自带的一套也是完全足够的
专业的人做专业的事，个人感觉插件市场没有太多的刚需，建议置顶一个【编辑器扩展需求留言】贴，精通Electron、Web前端、又有兴趣、开发效率高的伙伴自然会开发，质量也有保证，能在置顶的帖子中曝光自己的杰作一定很有成就感，放到store也有收益。
另外，如果真有需求了，完全可以脱离编辑器开发（启动编辑器时自动注入脚本），不依赖编辑器扩展UI的规范
3赞
引擎做好自己的性能，稳定上的事，不要搞这些花里胡哨，游戏中没几个用的功能。浪费时间。留给爱做插件的人去做，让他们赚点
5赞
性能什么时候赶上cocos-js 再来整这些五花八门的吧 不然人都跑完了
3赞
引擎性能好 稳定bug少 你控件再少 我也可以全部给你码出来 主要是稳定和性能
这倒是，源码一个版本一个样
我觉得原生优化再多点,ui不好调我还能慢慢弄,性能问题直接是扼杀
基于官方提供的基础组件自己改改弄成个库不就行了，搞一堆组件反而要记一堆东西，不如按自己的习惯去开发自己用的东西更舒适。
只要是我觉得官方写的可以在编辑器ui上面立马反馈出布局来。而自己写的估计做不到这种可视化的布局的
组件不是本来就直接可以在editor中可视化么？就是因为这个特性所以我很喜欢自己写组件，看着就有成就感。：）
是吗？能随机发我个示例看下吗？我真不知道自己写的组件可以立马在编辑器中看到的。，。，，
一般用set 方法写property，触发的时候修改UI的展现就行了。比如自己写个selector（label + layout），你可以写个item array，array修改的时候更新layout里面展示的label 就相当于效果直接可见了。不知道是不是你说的可视化的意思。
引擎要做的是基础，把基础打好就好了，至于用mvc还是mvvm或者微模块化，不同的业务会有不同的需求，这些系统模式都是为了解决一部分需求而设计的，做不到通用化，都属于业务需求，不要越界去做一些看起来利于开发者快速开发，实际上是业务需求，只能满足部分人使用的功能，而且我觉得目前的基础ui组件能够优化好，目前的状态我个人觉得只是可用，远没有达到省心无脑用的地步，把ui组件api兼容性设计好，操作界面更符合人性化，性能优化好我觉得已经是非常费时间的事情了，引擎组资源也是有限的，这些基础组件能设计的更通用，留给开发者更多的扩展空间，剩下的交给开发者去做就好了，太多繁琐的组件和api反而会困扰开发者自己去构建适合需求的框架，现有的web组件其实很多都是特定需求的组件，使用概率非常低，而且使用成本非常大
而且cocos是三端跨平台的，维护组件的成本非常高，尽量只提供基础，频率高的就可以
我的诉求是稳定的接口，可用省心不需要优化的ui基础组件，升级的时候能够多考虑版本兼容性，三端表现一致性和提供的基础ui组件功能完整性