👑 [一点建议]antd是国内react的标杆，请不要越跑越偏

[galileo303]

umi和pro原先我还觉得不错，现在越来越觉得群魔乱舞。

完全不考虑开发者和使用者。越来越远离初衷了。

框架本质本来就应该提升开发体验，提高开发效率。
现在的pro和umi开发体验没体验到啥好处，配置倒是越来越繁琐，不是这里出错就是哪里出问题。升级就要去翻源码看。文档也不会及时更新。升级不会不做任何兼容，或者提示。

走了一大圈，不能立马写业务不说，还要重新去学习哪些所谓自己发明，自认为牛x的插件，写法确实牛逼，但是这些重型插件，百分之90都是不能用的，需要重新改造。而且改造起来还不如重新写一个组件。适用性太弱。可能写这个组件的人感觉不到，但是对于百分之90的使用者来说，都是哗众取宠。

越来越觉得pro和umi在沉浸在自己的世界里面，自己感动自己。认为自己的组件价值观是“伟大的”，而忽略了中国大部分react开发者的开发体验。当打开pro给的案例的时候，ohshirt～！�react是这么写的吗？大段大坨恶心的群魔乱舞的代码，个现聪明。结果成了一个乱糟糟的代码页面，没有任何思想的硬怼的业务代码。就像初级程序员开发一个紧急需求一样。

越来越华而不实，反而是带偏了react开发者们的思考方向。越来越觉得react乱七八糟。本来的初衷是为了取代cra，智能化的配置。现在看来，配置成了群魔乱舞，相反还不如cra自己配置一个反而比umi快很多，自有很多。

我觉得应该值得思考

[yutingzhao1991]

但是这些重型插件，百分之90都是不能用的，需要重新改造。

具体什么问题？插件应该都是直接可以用的，不需要改造。

[xiaohuoni]

其实这个问题，简单的说，就是越和蚂蚁内部的设计越吻合的方案，用 umi@3 就会越舒服。越偏离设计的方案，就会觉得越复杂。举一个具体一点的例子，umi 把握了 route，plugin 掌握了 layout。给用户的操作空间非常小，也许在内部项目，或者团队内有强制规范的项目中使用会觉得省了很多事情。但是不少团队有自己的开发习惯时，就会有晦涩难懂的感觉。拿我这边的情况来说，所有的设计都遵从蚂蚁对外的规范，只有路由采用了约定式路由，这一点的差异，但是需要做的工作就会多出很多。

[chenshuai2144]

你的问题因为我们内部没有人用过 约定路由，根本没人提 bug， 也没有动力优化

[xiaohuoni]

你的问题因为我们内部没有人用过 约定路由，根本没人提 bug， 也没有动力优化

举个详细点的例子而已，我觉得采用强约束必然会导致现在这样的局面。毕竟在一个团体中，要达成约束是比较容易的事情，但是我觉得把这些强约束的方案，放到社区，不一定是一个好的行为，虽然内外一致能较少大量的维护工作。

[phoema]

umi@3在多入口、build静态文件时的编译性能、调试debug方面是不是能尽快提升一下啊。

[chenshuai2144]

@sorrycc 老师最近有点忙，已经有方案了，推进得比较慢

webpack@5 得速度有很大的提升。冷启动 3s 以内

[chenshuai2144]

框架本质本来就应该提升开发体验，提高开发效率。
现在的pro和umi开发体验没体验到啥好处，配置倒是越来越繁琐，不是这里出错就是哪里出问题。升级就要去翻源码看。文档也不会及时更新。升级不会不做任何兼容，或者提示。

主要是人力不够，ant design pro 主要就我一个人维护，我还要做内部的业务，还要做插件，还要做procomponents，所以pro 收窄了使用范围，专心服务中后台。

如果能接受我们的模式是可以很快的实现一个 crud 的页面，各种 xxx 管理后台可以很快的搭建起来。

越来越觉得pro和umi在沉浸在自己的世界里面，自己感动自己。认为自己的组件价值观是“伟大的”，而忽略了中国大部分react开发者的开发体验。当打开pro给的案例的时候，ohshirt～！�react是这么写的吗？大段大坨恶心的群魔乱舞的代码，个现聪明。结果成了一个乱糟糟的代码页面，没有任何思想的硬怼的业务代码。就像初级程序员开发一个紧急需求一样。

需求催生产品。我们主要满足内部的需求，所以就会变成现在的样子。社区的思路也会吸收，但是社区的使用方式维护力度需要非常大，一个产品能用很简单，要好用至少需要不少于一年的迭代。

越来越觉得react乱七八糟。本来的初衷是为了取代cra，智能化的配置。

我们的本来的初衷就是因为 用 antd 搭建一个后端管理控制台，太复杂了需要拼接各种代码。不是取代cra，我测试某些页面的时候也会用 cra，cra 适合所有 react 的项目，那 pro 只适合中后台，干别的也可以，但是设置起来很麻烦。

你说的文档问题的确存在，文档更新不及时，更新的日志没有写，这其实是因为精力的问题，维护一个开源项目是非常苦难的事情，我们因为可以内外结合，所以已经算是相当有维护力度的，你可以看我们相关同学的 timeline。但是我们也不可能全职的搞开源，尤其是文档，文档真的很难。我宁愿写很多的代码都不想写文档。文档要花费超级多的精力，密集的开发过后一般都会进行文档的改进。但是进入维护期后一般都会懈怠，同时也顾不上每日的维护。

但这也是开源的意义所在，我们之所以愿意把代码放出来，还投入不小的精力修复内部不会碰到的bug，添加一些社区呼声比较高得功能，就是因为社区是自驱动得，有很多小伙伴可能随手就改动了文档，或者随手修个小bug，日积月累也会让我们的项目变得更好。

你吐槽的很合理，但是这个对产品变得更好意义不大，如果你觉得不好用得地方可以提炼以下，想一想是不是可以作为需求。如果你提得电子帮助到了更多的人，开源就会变得更好。

[hucc]

本人不是前端，但是老早就关注了ant design，很成功，但是最近半年感觉停滞不前，反而ant design vue 进展不错，最近一两个月特别关注了下ant design pro，总的感觉有两点不妥：1.急需完善和定型v5代码和文档，时间太长了，需要发个正式版稳定军心。2.吸引外面的人员参加项目，目前只是蚂蚁内部一个人贡献，无论精力和方向都不利用项目的长期发展，注：本人前端新手，说得不对，还望谅解~

[kulame]

其实我觉得还是开源生态建设的问题， 一个好的开源产品不能只依靠一个人 需要建设社区

[laosandegudai]

真是震惊，竟然是一个人维护的。索然平常也看到了你快速地响应问题，但是真是没想到真的只有你一个人维护。再加上自己的工作，感觉太难了，理解了。

[1057105012]

开源精神不值得被批判， 况且作者反馈也很及时， 开源本就是社区共建， 觉得不合理要提出具体的点， 而不是说我感觉不好用， 我不管， 反正你们要优化。 大家一起想办法， 提出意见， 然后一起评估， 这才是正确的社区开源交流方式

[aixgeek]

没意义的吐槽不如留下issue和pr

[fanhualei]

越来越多的人贡献代码，就好了。光使用，不贡献，就给antDesignPro很大压力。

[chenshuai2144]

你提的问题都不错，有空了就可以做你的需求，有些还提供了解决得思路

[fanhualei]

一些不成熟的建议。

抛弃把antDesignPro作为一个大组件，拿来就能使用的想法，这样不现实，众口难调。
antDesignPro就是一个用来学习的最佳实践的案例，但是为了适用更多的应用场景，里面做了很多配置型的代码，反而从学习上增加了难度。

一旦项目确定下来，整个UI界面就固定下来了，直接从antDesignPro拿到代码来用，感觉繁琐很多。
由于procomponents的出现，我现在基本上是在umi基础上，从0开始搭建项目，如果遇到问题，把antDesignPro打开看看怎么实现的。例如antDesignPro里面的登录、注册这些页面也都自己写了，因为antDesignPro考虑的场景多造成代码也多，同时很难完全与项目需求一致，在原有的基础上改起来麻烦，不如自己重写的简单。

我觉的antDesignPro定位有两个：

• 初学者：学习umi+ant+procomponents的案例。
• 爱好者：如果有好的实现方法，可以修改代码然后提交一个PR。

antDesignPro可以像区块链开源组织一样，做一些类似的事情。

• 成立一个委员会、定期讨论antDesignPro的相关事项。
  ** 未来有哪些新功能要实现。
  ** 网友们提出的需求那些要修改。
  ** 定期将网友实现的不同版本中的好用的功能合并到主干上。
  ** 完善文档。

• 创建一个利于提交演示代码的环境
  ** 统一的后台API接口，把现在antDesignPro的mock数据，全都变成一个可以远程调用的API.这样大家就只用关注前台了。
  ** 有没有那种免费的空间，让一下爱好者上传自己代码作为演示环境，供其他人参考。
  ** 让网友定期评那个网友的代码实现的比较好，然后组织人合并到antDesignPro主干中。

[my9988]

@chenshuai2144 我也是从jquery转的，太有同感了，感觉不是在学编程，是在学如何配置系统，一个参数不知道，就能难死，有些问题也不清楚该看哪个文档，到处封装。文档有的有英文有的没有，乱乱的，我的团队很多外国人，想推荐使用这个学起来有点难。

[chenshuai2144]

现在文档很分散的确是个很大的问题，需要到处找

[phoema]

pro这边还好，1个人顶3个人，umi好像更严重。
使用国产中发现问题也是一种贡献，并不一定是提交代码。

[Solomonqoo]

使用ant design pro 2.2.0开发内部需求，开发完打包上线，在打包部份就出现问题，後面没办法了，直接试著2.3.1版，看看打包完後nginx可不可以顺利的执行而不出错。确认2.3.1打包後可以让nginx顺利执行，就立马搬迁开发好的程式，结果悲剧再次发生，前端传送到後端springboot controller params不能解析.................原因是utils\requst.js使用的元件将与2.2.0不同，除非後端controller代码调整，想了想，试试看2.2.0的request.js档案能不能直接给2.3.1使用，看来可以，这才临时解决了上线时程压力。

确实，版本的更新是好事，但ant design pro内部使用的重要util不能稳定下来，这实在不是一个好的现象。而且2.3.1这个版本在github上也不见了。虽然很喜欢使用ant design pro，但一直不稳定，实在不是一个好事情

[zooPanda]

作为一个自学的人，能看到有antd pro的这个这么好的开源项目感到很幸福。
但是因为文档的问题，学起来很吃力，不过还是很感谢愿意花时间开源维护。

[wkylin]

把antd 搞好就可以了，不要封装过度了，只知其然，不知其所以然....

[tnngo]

我个人并没有觉得antd pro 现在的模式有何不妥。你完全可以只用antd UI，antd本身并没有过渡封装，你完全可以用其他的组件来实现request、部署、调试等，或者自己造。

antd pro 不是UI框架，它是基于antd ui库提供了一套解决方案： ——方便用户基于antd pro快速实现业务。

antd pro能让我一个后端对前端知之半解，对react毫无了解，更别提webpack、路由等等的情况下就能快速开发一套很漂亮的企业级系统。那是相当优秀了，对于这一点，现其他UI框架都是望尘莫及的。

所以对于我个人来说，antd pro已经是国际标杆了。

[jkiss]

@galileo303 首先，这么diss一个开源库，我觉得你的私心有点重了，在用任何一个库之前，都要调研清楚是否符合自己的需求。当你最后说：“...相反还不如cra自己配置一个反而比umi快很多，自有很多。” 的时候，我就觉得你做的技术选型不是很合理，是不是一开始就使用CRA更好？为什么现在反过来 PUA antd pro呢？如果你想让antd pro变得更好，就提PR，或者成为Sponsor；如果有使用的问题，就提issue。

“跑偏”？你知道正确的方向？而且，你说了也不算。

我最近用antd pro v5做了一个后台系统，也是第一次用，说说我的感受吧：
复杂度：还好，文件夹结构比较清晰合理，过一遍文档就能看懂；
效率：i18n，loading，page as route，modal，pro components等很方便，最后改改样式就好；
坑：有，比如路由配置单级深嵌套会出问题；开启mfsu样式错乱；但都解决了，没有遇到影响项目上线的bug；
是否推荐：自行判断

[zjxpcyc]

也说出了部分我们团队的痛点。

因为入坑比较早，对 dva, umi ，pro 都是有点感情的，很多话，不敢讲，因为怕被喷。

我们团队，小，技术菜，只有一个诉求，能不能支持 JS ，现在的版本，你说你不会 TS，干脆就别选。

[zjxpcyc]

中台这种概念，在小团队里面是不存在的。技术人员的追求肯定要有，但是需要时间跟经验。比如我们团队，小，现状是，入职是新手，入职一年就离职，因为薪资能力不对等了。这种尴尬的情况，我们怎么去考虑换 ts 的成本。小微企业真的活得不容易。

[chenzheio]

作为自学小白，我很依赖ts的提示，这次4.0的更新好些地方ts的提示有问题，但是还是可以自己摸索解决一些问题的。还是希望团队能够加快进度的完善一些ts类型的标注。
不过好像这个开源项目就大佬一个人在维护，估计也够呛。

[jkiss]

其实还是回归到技术选型问题，antd pro是最合适的吗？如果说团队小，入职是新手，就要考虑技术迭代的频率了，而且成熟的系统贸然升级大版本也有风险。何不考虑迁移到cra+antd？

[zjxpcyc]

cra + antd 肯定不会考虑，相当于要自己整全套，起码也是 umi + antd 。umi 也是只有 ts 。说到底是想选一套成熟，效率高的，可以降低开发成本的

[jkiss]

说实话，虽然ts出来好多年了，我也是这几天才开始看的😄，因为之前一直是写交互特效的，也不太喜欢ts。新项目用的antd pro 6.0，看了2天ts教程就能上手写业务了，如果是迁移旧项目，就要慎重了，总的来说6.0还是推荐用的，体验更好了

[lanmingle]

许久没有折腾前端了，以前用过 NG，自己的项目需要自己开发前端，又重新学NG17，发现强大，齐全，好了！发现需要折腾大量的UI，看了好久，没有好的方案，看 antd 这么齐全（有pro），又重新学 react（以前是会class的方式），基础学完了，用 Pro 还需要学这个 umi ，这个 umi 基本搞明白了，发现一堆过时或不维护的库如：数据流、模型、dva 等等，还存在依赖耦合，一个 http 请求让我看一两天选什么（最新ahooks？umi不兼容，需自行按需用，我就想简简单单用http呢，过时不维护的不要），真是乱七八糟花里胡哨，再认真看 pro 用一堆过时，说好的是大厂呢，维护力呢。。。

如今有两种让我继续折腾。
1、放弃 react ，重回NG，折腾UI完事。
2、继续用 react，看看 umi 是否有替代方案（这个项目太乱了，耦合太多了，一堆过时的）
2.1 、关闭哪些默认的插件，只用部分插件功能（微前端、antd等，布局我都不想用了）
2.2、不用 umi，有啥好替代方案？

[mrdulin]

直接用webpack, webpack-dev-server, Redux Toolkit, react-router或者CRA, vite等，按需使用，少一层封装，少一层麻烦，尤其是封装不好，没人维护，社区不行，维护人员水平有限的东西。有些东西可能开箱即用，但是后续遇到问题要么社区搜不到，要么提issue没人解决，要么问问题没人回答，要么回答也是草草了事，答非所问。这样的话，这个东西就有KPI项目，面子、品牌项目的嫌疑，就像OP说的，这东西是用来吹牛逼，涨粉用的，设计是否合理，API是否好用，是否建立社区，根本不再考虑范围。

[doovemax]

哎，我只能说这开发这个项目的人很牛X，但是如果你是给中后台的研发人员使用就很难了。大多数中后台的开发前端知识不是很好，有很多还是后端顺手把前端干了，你搞这个组件哪个组件的有啥用，他就知道用个 http 请求后端，没这么复杂。目录层次分明就行，见名知意。本来学 react 感觉不怎么复杂，看了这个项目我感觉 react 我没学过，你就说你的项目神奇不神奇吧

[AburronKing]

作为一个普通开发者来说，最近才刚刚开始使用react。。。。。在使用react-pro搭建项目，�element-plus-admin做的相对就比较适合大多数人使用。或者因为我太菜了吧

[AburronKing]

而且项目down下来 一安装 全是各种报错 还要各种去网上查用什么版本 真的不友好