页面搭建工具盘点

March 24, 2021

中后台近几年的发展,已经不满足于简单的手脚架,比如 vue-cli 和 create-react-app,从 ant-design-pro 到 vue-element-admin,提供了各种开箱即用的体验。这些方案可以直接套用,自己需要做的只是写业务代码就可以了,其他的整体架构,包括菜单和权限都帮你搞定了,甚至还有很多很多可以选择的业务模板,一顿微调,一个中后台系统就有模有样了。全套下来比自己从头开始搭质量要高很多,而且至少可以节省一两天开发成本,后期的扩展维护也很方便。

到如今这些开箱即用的解决方案已经显得有些不够用了,中后台的前端,大部分都不需要和移动端一样有严格的 GUI,布局,更多的是日常业务,而这些业务写多了以后,就变成一个个表单,一个个列表,一个个图表,写来写去,给人一种搬砖的感觉,重复劳动,成就感低。

WYSIWYG 为 所见即所得,是 github 上面的一个分类。可以追溯到 dreamweaver,只是后面随着前端的发展没落了。一个可视化的页面搭建工具,毫无疑问是可以解放生产力的,只是为什么以前没有大热门的开源产品出来,实在原因实在太多,可以看看侯老师的 前端服务化——页面搭建工具的死与生

只是现在不同于以前,前端越来越繁华,虽然还要持续的不断学习新的内容方向,但是前端的三大框架基本定下来,更多的是新特性新版本。于是在中后台基础设施完善下,做了一个中后台系统,再做下个,再做一个,这种重复的问题,不在是大厂才会面临,小厂的前端员工自然也会有同样的困扰,需要解决效率问题。well,大厂一般都有这样的工具,只是看大厂开不开源罢了,比如支付宝的 金蝉/凤蝶,代替传统前端开发模式的一站式研发系统,都可以让非前端人员开发了,只是是要收费的好像,虽然金禅说是今年会开源,只是没有排期都是骗人的。

自己在写业务的时候也有这样的困扰,重复的组件,能提用公共的逻辑都抽离出来了,但是组件上实在是每个组件都需要定制,需要自由度非常高。于是开始探索有没有可以提高生产力的工具。

飞冰 ice

飞冰从去年就开始开源了,结合 umi.js,ant-design 和 ant-design-pro,基本上 react 的中后台开发有这一套就很棒了,加上自己的设计,按照同事的说法,是一套闭环的生态。

飞冰最大的特点,在于其海量的物料,以及杀手锏般的桌面工具,开发体验是非常友好的,没有什么复杂的操作,想要什么物料,在 iceworks 上面点一点就能安装好了,自己只要修改一些字段,再增加对应的交互和接口调试,就差不多了。飞冰提供的物料是以区块来的,而不是组件级别,而且基本布局是从上到下,按照选择的区块顺序生成页面。对比传统的开发模式,可以归纳为飞冰给你提供了更多可以复制粘贴的代码,而且质量还不低。

使用一阵之后,觉得其离高度自由化,还是差了点,解决了部分开发效率问题,但是区块级别依旧有点粗糙,缺少组件以及拖拽布局,美中不足。可视化的编辑区域至今也是规划。

iceworks 这样客户端的体验还是非常友好的。

百度 AMis

百度的 AMis 其实很早前就有踪迹了,在 吴多益 的描述里面 前端服务化-通向零成本开发之路,就提到 AMis 作为中后台解决方案。然而时隔多年,终于开源了。大厂的好处还是显而易见的,至少这种基础建设的水平要领先外面一到两年。这次 QCON 大会上 AMis 又再次露脸。

AMis 采用的是特定格式的 JSON 配置,这个特定的格式,指的是其自身 baidu 的一套 JSON Schema,这一套 JSON Schema 用的不同于 社区 的 JSON Schema,估计是结合自身的业务定制的,毕竟 16年就有 AMis,那会社会可能都还没有成熟。其自身的 schema 为: "$schema": "https://houtai.baidu.com/v2/schemas/page.json#" 的格式;

看 QCON 上面的介绍的 ppt 是挺好的,只是一看仓库文档,好像资料有点少,关于这个特定的 JSON 配置,在 github 里面是有明细的文档的,只是感觉构建的文档站点有点不好用,示例看不了代码,下面的教程文档倒是挺充足,只是更多的是 api 和一些字段的定义,没有教人怎么去用,而且整体的组件风格偏 bootstrap,和 antd 的设计相比,觉得差了不少。

关键是这个 AMis 只是开源了其 JSON 配置部分,渲染器的部分,其他的可视化编辑器没有开源出来,这样前端写 JSON 开发真的好吗?诚然 AMis 设计理念是很棒的,抽象出 UI 组件的逻辑,形成 JSON 的形式,减少前端的冗余开发,提高生产力,只是前端居然要写 JSON,路走歪了。所以其 可视化编辑生成页面 开源就好了,可惜还没有排期的消息,而且开源的 AMis 总觉得有点赶工的嫌疑,还是先不用,免得进坑。

react page

这个所见即所得工具使用起来体验是很好的,只是其更多的是面向用户的产品,而不是面向工程师的产品,其支持的组件需要自己提供,也就是可以用 antd 的那一套加一个中间层就可以用上了。生成的 editorState 对象也可以实现根部注入的方式,实现后端数据动态渲染。只能给用户画画原型什么的而已,其对前端的生产帮助少之又少。

阿里 UForm

看了一圈其他开源产品页面搭建工具优秀的少之又少,最后看到这个 UForm 是表单解决方案,似乎和前面提到的都不是一个东西,前面是通过页面编辑可视化,来提高效率,而这只是个 react 的表单解决方案。

这个 UForm 和百度的 AMis 其实是有点类似的,都可以通过特定的 JSON 规范来配置生成代码,只是 UForm 是专门针对表单的,而 AMis 是通用。 UForm 采用的 JSON Schema 是和社区保持一致,同时和 Mozilla 的 react-jsonschema-form 有点类型,在社会的 JSON Schema 之上增加了 UI 组件相关的信息。另外其字段状态分布式管理和 React EVA 的方式很大程度的提高 form 表单的性能和可维护性。对于 JSON Schema,UForm 采用了自己的 JSchema 描述语言,不再是单纯的写 JSON,可以通过 Field 等组件来描述,避免前端写 JSON 的尴尬情况。可以看出其整体的设计理念很赞。

并且其可视化编辑工具,说是要在端午后开源,表示万分期待。如果真是如此,那就可以进一步实现动态化了,用可视化编辑工具生成想要的 JSON 数据,最后通过后端返回数据注入到根组件,直接回显就可以了。前端要专注的只是 form 表单的交互和接口的调试,以及测试部分。感兴趣可以看看其介绍 UForm表单解决方案

百度 RCRE

这个是最近出现的中台后系统的解决方案,结合了状态(mobox和reduce)、表单和接口请求,解决复杂的组件联动带来的问题。给的 文档里面,看起来挺香的,只是对应的使用说明和知乎上面写的实在有点看不出所以然,最后还是有 demo 什么的吧。或许这就是百度的风格?

总结

期待百度系列 AMis 和 RCRE 接下来的表现,尤其是前者,在百度内部应该是非常成熟的方案了,可惜不够开源。目前能看得着,能使用的上的,就是阿里的 UForm 了,期待其可视化编辑器。然而最后基于业务的原因还是用上了 react-page 先,等 UForm 完善了再看。