We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
中后台近几年的发展,已经不满足于简单的手脚架,比如 vue-cli 和 create-react-app,从 ant-design-pro 到 vue-element-admin,提供了各种开箱即用的体验。这些方案可以直接套用,自己需要做的只是写业务代码就可以了,其他的整体架构,包括菜单和权限都帮你搞定了,甚至还有很多很多可以选择的业务模板,一顿微调,一个中后台系统就有模有样了。全套下来比自己从头开始搭质量要高很多,而且至少可以节省一两天开发成本,后期的扩展维护也很方便。
到如今这些开箱即用的解决方案已经显得有些不够用了,中后台的前端,大部分都不需要和移动端一样有严格的 GUI,布局,更多的是日常业务,而这些业务写多了以后,就变成一个个表单,一个个列表,一个个图表,写来写去,给人一种搬砖的感觉,重复劳动,成就感低。
WYSIWYG 为 所见即所得,是 github 上面的一个分类。可以追溯到 dreamweaver,只是后面随着前端的发展没落了。一个可视化的页面搭建工具,毫无疑问是可以解放生产力的,只是为什么以前没有大热门的开源产品出来,实在原因实在太多,可以看看侯老师的 前端服务化——页面搭建工具的死与生。
只是现在不同于以前,前端越来越繁华,虽然还要持续的不断学习新的内容方向,但是前端的三大框架基本定下来,更多的是新特性新版本。于是在中后台基础设施完善下,做了一个中后台系统,再做下个,再做一个,这种重复的问题,不在是大厂才会面临,小厂的前端员工自然也会有同样的困扰,需要解决效率问题。well,大厂一般都有这样的工具,只是看大厂开不开源罢了,比如支付宝的 金蝉/凤蝶,代替传统前端开发模式的一站式研发系统,都可以让非前端人员开发了,只是是要收费的好像,虽然金禅说是今年会开源,只是没有排期都是骗人的。
自己在写业务的时候也有这样的困扰,重复的组件,能提用公共的逻辑都抽离出来了,但是组件上实在是每个组件都需要定制,需要自由度非常高。于是开始探索有没有可以提高生产力的工具。
飞冰从去年就开始开源了,结合 umi.js,ant-design 和 ant-design-pro,基本上 react 的中后台开发有这一套就很棒了,加上自己的设计,按照同事的说法,是一套闭环的生态。
飞冰最大的特点,在于其海量的物料,以及杀手锏般的桌面工具,开发体验是非常友好的,没有什么复杂的操作,想要什么物料,在 iceworks 上面点一点就能安装好了,自己只要修改一些字段,再增加对应的交互和接口调试,就差不多了。飞冰提供的物料是以区块来的,而不是组件级别,而且基本布局是从上到下,按照选择的区块顺序生成页面。对比传统的开发模式,可以归纳为飞冰给你提供了更多可以复制粘贴的代码,而且质量还不低。
使用一阵之后,觉得其离高度自由化,还是差了点,解决了部分开发效率问题,但是区块级别依旧有点粗糙,缺少组件以及拖拽布局,美中不足。可视化的编辑区域至今也是规划。
iceworks 这样客户端的体验还是非常友好的。
百度的 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#" 的格式;
"$schema": "https://houtai.baidu.com/v2/schemas/page.json#"
看 QCON 上面的介绍的 ppt 是挺好的,只是一看仓库文档,好像资料有点少,关于这个特定的 JSON 配置,在 github 里面是有明细的文档的,只是感觉构建的文档站点有点不好用,示例看不了代码,下面的教程文档倒是挺充足,只是更多的是 api 和一些字段的定义,没有教人怎么去用,而且整体的组件风格偏 bootstrap,和 antd 的设计相比,觉得差了不少。
关键是这个 AMis 只是开源了其 JSON 配置部分,渲染器的部分,其他的可视化编辑器没有开源出来,这样前端写 JSON 开发真的好吗?诚然 AMis 设计理念是很棒的,抽象出 UI 组件的逻辑,形成 JSON 的形式,减少前端的冗余开发,提高生产力,只是前端居然要写 JSON,路走歪了。所以其 可视化编辑生成页面 开源就好了,可惜还没有排期的消息,而且开源的 AMis 总觉得有点赶工的嫌疑,还是先不用,免得进坑。
这个所见即所得工具使用起来体验是很好的,只是其更多的是面向用户的产品,而不是面向工程师的产品,其支持的组件需要自己提供,也就是可以用 antd 的那一套加一个中间层就可以用上了。生成的 editorState 对象也可以实现根部注入的方式,实现后端数据动态渲染。只能给用户画画原型什么的而已,其对前端的生产帮助少之又少。
看了一圈其他开源产品页面搭建工具优秀的少之又少,最后看到这个 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表单解决方案
这个是最近出现的中台后系统的解决方案,结合了状态(mobox和reduce)、表单和接口请求,解决复杂的组件联动带来的问题。给的 文档里面,看起来挺香的,只是对应的使用说明和知乎上面写的实在有点看不出所以然,最后还是有 demo 什么的吧。或许这就是百度的风格?
期待百度系列 AMis 和 RCRE 接下来的表现,尤其是前者,在百度内部应该是非常成熟的方案了,可惜不够开源。目前能看得着,能使用的上的,就是阿里的 UForm 了,期待其可视化编辑器。然而最后基于业务的原因还是用上了 react-page 先,等 UForm 完善了再看。
The text was updated successfully, but these errors were encountered:
现在呢,推荐使用哪一个,我看百度的 amis 不错,其他的还没有了解
Sorry, something went wrong.
No branches or pull requests
中后台近几年的发展,已经不满足于简单的手脚架,比如 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 完善了再看。
The text was updated successfully, but these errors were encountered: