39. 页面搭建工具盘点

[funfish]

中后台近几年的发展，已经不满足于简单的手脚架，比如 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 完善了再看。

[zronghui]

现在呢，推荐使用哪一个，我看百度的 amis 不错，其他的还没有了解