umi框架可以精简一下吗?太重了.

[wldos]

用了两年umi感觉用不动了,依赖太多.

其实,我项目的需求很明确:

1.前后端分离,然后前端可以实现原来jsp时代可以干的哪些事(比如SSR,模板化,静态化),这是网站应用场景;

2.然后可以具备分离带来的所有好处,比如借助react生态实现全终端的应用,这是app应用场景和中后端应用场景;

3.现在的前端过于复杂了,要取代Java? 还是成为 Java? 需要一个精简版的方案,在next.js的基础上再多一点点增强,最好是简单配置一下,就可以用.

4.相关官方文档不够清楚,比如运行时获取服务端路由怎么搞,照着配置不执行,不懂.

[LeoHuiyi]

你是前端吗？请找专业前端来？umi定位是企业级前端应用框架。你觉得复杂，可以自己搭一套。

[xiaohuoni]

@wldos 首先这个问题，我觉得在于对“重”的定义。说实话，用任何框架都是重，任何方案最根本的还是 html+js+css，但是为什么不用？对于我来说，仅仅是懒。

至于 umi 框架能不能精简一下，我觉得是可以的。一直以来也是一直在做这方面的努力。但是精简到一个什么样的程度，依旧能够支撑当前所有的业务场景，是一个很值得探索的问题。（全世界不是只有你一个项目，你们项目需求明确，对于框架来说只是部分需求，而不是全部需求。）

我觉得 umi 的插件化，已经把这些业务拆的很开了。我觉得你开始觉得它重的一个原因是，你用了不太合适的 preset。（我猜的，也可能不是）你可以考虑一下你的项目都需要哪些功能，都用了两年了，还对 umi 这么不了解？你这两年在干呢？像我们的应用场景，仅仅在移动端，我们的 umi 项目中就只有移动端相关的方案，pro 那一套中后台的方案，我基本上用不上。

回过头来讲，你试试，新建一个文件 src/pages/index.js -- export default () => <div>Index Page</div>;，然后 umi dev。 就能知道 umi 有多轻了。

其实我觉得如果你可以想想怎么让他更轻，然后，直接说，你觉得怎么样怎么样怎么样更好。我觉得才是真的能够改变 umi 的操作。毕竟是 umi 的老用户了。

[leftstick]

开源社区，友善讨论问题。大家不要激动。 至于重不重这种事情，得看问题。 如果你需要 all in 这种东西，那它就必然会有点『重』。

如果你希望 渐进式 这种东西，那它是有可能做成 『不太重』 的。

回到 umi 的问题上，umi 作为企业级开发框架，承载了很多常见业务需要的 依赖、配置、实现、优化。。。势必会让你觉得有点『重』。这种感受算正常范围，大家不必惊慌。

但说回来，你希望它轻一点，那么轻一点是指什么？

• 实现的功能少一点？我相信这种级别的『框架』就算找不到很好的开源，自己弄一个也不费劲，毕竟也就是 webpack 配来配去[手动狗头]。
• 依赖少一点？这个就有点复杂，涉及到 npm本身的设计问题了，如果大量内容都 由 umi 自行实现而不依赖现有资源，真的就一定好么？值得商榷

再来讨论一下，无论上述两点中的哪一项，少了之后会有什么样的好处？ 作为软件开发人员，我们『无利不起早』，他总归应该有点好处，不然我费那劲干嘛？ 所以这个问题要问你的初心了，你到底从 『轻』 了之后获得了什么好处？ 而这个好处是否真的值得你花费很大精力去研究，甚至输出一些内容。

还有是否 umi 想替代 java， 这个我觉得可能是措辞问题，umi 是前端开发框架，java 是主要应用于后端编程的计算机语言，它俩应该没啥可比性。

我猜你可能想探讨的是 umi 是否在借鉴 spring？然后你会发现，spring 如果要做小而美，那么其内容可能也只有一个 DI ， 但仅仅那么一个功能对你又有什么用呢？最后要完成一个企业级应用，你不还是的乖乖的spring-xx 全家桶挨个上嘛。

umi 以及 其插件系统，如果做类比，我更倾向于 spring-boot，他没有提供『很多』新功能，而是通过配置和约定帮助你更从容/优雅的使用 已有的开源工具。

你之所以感受 『重』，实际我觉得还得是 npm 设计的锅，库作者们把一大堆乱七八糟的文件都 publish上去（这并非指库本身质量不好，而是说缺乏这部分的规范，硬性规范，导致很多人上传了不少无用内容），下载依赖时，当然看到的也是牛鬼蛇神。任何人看着都难受

[wldos]

@All，诸位好，今天才收到回复推送，非常感谢大家的热情！

我们是阿里云的一个客户，关于这个“吐槽”的反馈，起源于使用了Antd Pro，起初只是用来做管理端，从2.0就开始了，很perfect，直到几个月前开始开发网站了，遇到了seo问题，我们的前端比较菜，所以才会用antd Pro，因为她开箱即用，我们在antd Pro上做改动，发现实现SSR太难了！！！这里必须承认，我们前端很菜，可能对问题认知和描述得都不够到位和不恰当，但确实是卡住了。

相关SSR、CSR同构的网络资料都太老了，next.js虽然支持，但是缺乏umi整合的一揽子方案，另外，umi有没有比较新的基于SSR同构的案例或者方案（我们可能不知道），对于互联网公司这块需求还是比较多的，比如类似企业中台的应用如何结合umi、antdpro和其他的什么方案实现一个toC+toB的架构方案，这里面在前端层面有很复杂的问题。

如果没有seo的问题，就不存在上面的问题了，或者说，百度不支持SPA的seo（ps.百度不可能没有这个技术能力）。

我们的问题，可能不是问题，只是对前端懂得太少，还请各位技术大拿不吝赐教，非常感谢！！！

[leftstick]

不脱离SPA 的范畴，只是实现做企业中台之类的『表单』丰富的应用，那umi 结合antd 怎么做都不为过，都能帮你解决问题。

因为SPA 进入web 应用开发界太久了，而且概念相对简单，挑战不大（除非你的业务里有一些屌炸天的 UI 组件诉求）。

但 同构SSR不同，这个玩意和 SPA 我个人认为不是一个重量级的产物，他对开发人员的理论基础、工作经验都有比较高的要求（不得不承认，多数前端工程师不具备丰富的后端理论知识和经验，这里这里我说的是后端， 而不仅仅局限于 java）。 这种情况下，框架/工具 帮你做的越多，遇到问题时你的开发人员就会越懵逼。

我猜你可能是java后端，所以咱们就以 spring-boot 举例。 用过各类 starter 你肯定有体会，譬如：我要想接入一个 基于 SAML 的外部鉴权服务（比如：okta），如果用了spring-boot-starter-security，只要 几行配置就能启动使用了。 可是一旦某个环节出了问题，你就是可能一脸懵逼，因为这里涉及了 Open SAML 的协议规范、spring-security 的实现逻辑、各种配置对应在 SAML 协议使用中的效果/结果。。。。 其中哪一项你都必须搞清楚，不然『别看就是一行配置填错了，你就是无法知道怎么改正』。

同理，同构 SSR也有相似的问题，背后涉及的问题太多、太广。一开始空架子给个helloworld直接启动没问题，但后面需求越做越多，其中不知道哪根『神经』没搭对，程序挂了但你完全不知道因为啥。

我个人比较倾向于务实，技术选用还是得看 天时(技术储备)、地利（公司认可）人和（团队有激情），缺一不可。如果你的团队前端实力较弱，而后端（做 java或者py 等非 node 技术）的同事也没办法在这个地方（同构SSR部分的问题主要发生在 node 端，即：后端）给前端同事补位的情况下，我就倾向于把需要 SEO 的页面，单独拿出来，直接以 jsp、php、py等传统方式直接从服务器端输出就好了。

理由有三条：

1. 同构 SSR 适合经验丰富且有技术储备和技术热情的团队使用。并不是所有团队都适合，虽然它的概念听上去很牛x，貌似能够拿来做招聘 『特点』
2. 从 SEO角度来说，同构 SSR的 效果 并不比 传统 服务器直出更好（甚至还差一些）。 它的好处在于 工程化上的复用和维护，并非结果牛逼。所以如果团队本身不具备在这个层面做复用/维护的能力，那就别瞎搞，意义不大
3. 需要SEO的页面通常具备 多内容、少交互等特点，传统直出方案更容易实现

一家之言，随便看看，不要过分当真

[wldos]

不脱离SPA 的范畴，只是实现做企业中台之类的『表单』丰富的应用，那umi 结合antd 怎么做都不为过，都能帮你解决问题。

因为SPA 进入web 应用开发界太久了，而且概念相对简单，挑战不大（除非你的业务里有一些屌炸天的 UI 组件诉求）。

但 同构SSR不同，这个玩意和 SPA 我个人认为不是一个重量级的产物，他对开发人员的理论基础、工作经验都有比较高的要求（不得不承认，多数前端工程师不具备丰富的后端理论知识和经验，这里这里我说的是后端， 而不仅仅局限于 java）。 这种情况下，框架/工具 帮你做的越多，遇到问题时你的开发人员就会越懵逼。

我猜你可能是java后端，所以咱们就以 spring-boot 举例。 用过各类 starter 你肯定有体会，譬如：我要想接入一个 基于 SAML 的外部鉴权服务（比如：okta），如果用了spring-boot-starter-security，只要 几行配置就能启动使用了。 可是一旦某个环节出了问题，你就是可能一脸懵逼，因为这里涉及了 Open SAML 的协议规范、spring-security 的实现逻辑、各种配置对应在 SAML 协议使用中的效果/结果。。。。 其中哪一项你都必须搞清楚，不然『别看就是一行配置填错了，你就是无法知道怎么改正』。

同理，同构 SSR也有相似的问题，背后涉及的问题太多、太广。一开始空架子给个helloworld直接启动没问题，但后面需求越做越多，其中不知道哪根『神经』没搭对，程序挂了但你完全不知道因为啥。

我个人比较倾向于务实，技术选用还是得看 天时(技术储备)、地利（公司认可）人和（团队有激情），缺一不可。如果你的团队前端实力较弱，而后端（做 java或者py 等非 node 技术）的同事也没办法在这个地方（同构SSR部分的问题主要发生在 node 端，即：后端）给前端同事补位的情况下，我就倾向于把需要 SEO 的页面，单独拿出来，直接以 jsp、php、py等传统方式直接从服务器端输出就好了。

理由有三条：

1. 同构 SSR 适合经验丰富且有技术储备和技术热情的团队使用。并不是所有团队都适合，虽然它的概念听上去很牛x，貌似能够拿来做招聘 『特点』
2. 从 SEO角度来说，同构 SSR的 效果 并不比 传统 服务器直出更好（甚至还差一些）。 它的好处在于 工程化上的复用和维护，并非结果牛逼。所以如果团队本身不具备在这个层面做复用/维护的能力，那就别瞎搞，意义不大
3. 需要SEO的页面通常具备 多内容、少交互等特点，传统直出方案更容易实现

一家之言，随便看看，不要过分当真

您说的很有价值！

关于同构SSR我们也做了一些功课，发现不仅仅是技术问题，基于我们的产品架构存在不能兼顾的需求场景，比如要实现SaaS版多租和一租多域的需求 在SSR-node-server端会遇到挑战，所以我们基本上要放弃在umi上实现SSR同构的念头了，只是我们之所以老抱着umi不放的原因之一是为了更方便使用Antd的UI组件，问题有2个：

1. 如果采用了传统模板技术实现toC的应用，可能没法使用Antd组件了；
2. 我们是基于umi做的web前端，传统技术实现的独立应用在前端层面和umi的无缝衔接，登录验证、路由啥的 是不确定的地方。

[wldos]

@leftstick 您说的很有价值！

关于同构SSR我们也做了一些功课，发现不仅仅是技术问题，基于我们的产品架构存在不能兼顾的需求场景，比如要实现SaaS版多租和一租多域的需求 在SSR-node-server端会遇到挑战，所以我们基本上要放弃在umi上实现SSR同构的念头了，只是我们之所以老抱着umi不放的原因之一是为了更方便使用Antd的UI组件，其中的问题思考有2个：

1. 如果采用了传统模板技术实现toC的应用，可能没法使用Antd组件了；
2. 我们是基于umi做的web前端，传统技术实现的独立应用在前端层面和umi的无缝衔接，登录验证、路由啥的 是不确定的地方。

[sandmanman]

我觉得可以换个思路，也没有必要把开发模式绑在umi上。

[303394539]

说说我自己的感受， 这只是使用者和架构设计者的视角不同。 从我自己搭建集成框架给别人使用的反馈来看，往往所有的框架的初期使用者的第一个反应大概率都是怎么这么不好用、这些XX设计者到底是怎么想的，处理这么简单的问题要搞那么多弯弯绕绕。都是或多或少有一些被害者思维。但是当用久了，只要不是真的框架垃圾，基本都逃不过真香理论。因为每个框架都有自己匠心独运的点，而当使用者接触到这些点并理解到这些点考虑的场景以后，往往都会接受并去学习。也许当这个使用者接触下一个框架以后还是会循环反复的这么思考，因为自己往往突破不了自用方便到他人用都方便的视角限制。 当然，框架设计者也有局限性，没有哪个人或者集体设计的东西会直接完美的，都是通过自我反思或者是吸收反馈不断的演进。初心都是一致的，就是希望他越来越好，给使用他的人带来好处。自己的孩子晒朋友圈当然是觉得他最帅最美，但是朋友圈的人怎么看他我们不得而知，只希望初心不变，推己及人。 回过来说，希望umi简单并没有错，因为觉得按自己的想法自己用起来肯定最简单。不过设计者是不能这么想的，当然如果设计者愿意为了特殊个人喜好这么干，其他使用者也是不可能认同的。框架设计者更应该是符合大部分使用者的利益，向大家学习，促进大家学习。 其实大家都说了很多方案，要简单最简单了，自己搞一个完全自己配置的复合需求的就是最简单的。只要自己愿意拥抱变化，拥抱新人的积极去维护，当然最合自己心意。如果这种维护的工作本来就是交给umi了。自己就应该多读读他的源码，多理解他的模式，多多学习其他使用者的经验，在实际业务使用中不断完善就行了。umi既然能帮助大部分人完成他们的个人需求，你也不会例外。

[zhangyuang]

https://github.com/ykfe/ssr 专注于 ssr 的框架

@wldos ssr 可以看看这个方案，直接用 antd 没问题。用 antd-pro 就算了。pro不支持 ssr

[hdyusf]

用了两年umi感觉用不动了,依赖太多.

其实,我项目的需求很明确:

1.前后端分离,然后前端可以实现原来jsp时代可以干的哪些事(比如SSR,模板化,静态化),这是网站应用场景;

2.然后可以具备分离带来的所有好处,比如借助react生态实现全终端的应用,这是app应用场景和中后端应用场景;

3.现在的前端过于复杂了,要取代Java? 还是成为 Java? 需要一个精简版的方案,在next.js的基础上再多一点点增强,最好是简单配置一下,就可以用.

4.相关官方文档不够清楚,比如运行时获取服务端路由怎么搞,照着配置不执行,不懂.

这个框架是真的越来越卡

[18394526727]

这个框架是真的越来越卡

[maxid]

最主要只有过一段时间不用，再用时就会起不了，唉