今天尝试了下 Vite，用它提供的案例来构建一款 React 应用的脚手架。它基于 RollUp，这个也是我此前用 Svelte 框架时所使用的默认打包工具。Vite 的优点在于 Dev 启动很快，热更新迅速，它分离了依赖库和用户编写的代码，因为在绝大多数情况下，前者几乎无需反复构建。
我这个搭配 Vite 的新项目同时使用的有 React + TypeScript + Material UI，其中 Material UI 和 Antd 两者可谓是“竞争激烈”啊。
Material 的组件相较于 Antd 较为平庸，但是提供了很高的定制模块（但读文档的成本和快速实现难度也就高了），使用其内置的 makeStyles 可以使用类似 Less 的语法编写（覆盖）组件样式。也是作用域隔离，属于 CSS in JS，不会影响到其他相同组件。
Material UI 的优势是外观，Antd 在 UI 方面是弱项，很难二次高度定制除了颜色以外的东西。后台的业务操作逻辑较多，Material UI 内置的组件很难快速实现业务，为了使页面引入模块少量清晰，只能自己做二次封装，且部分功能需要完全自己编写，无法依赖于 Material UI。我认为还是应当结合项目实际情况做决定较为合理。
我个人主张的做法比较中立，既然用 Material UI 想要体现的是设计感，那还不如就自己做一套设计感，直接用 Less 或 Tailwind 实现界面框架，Antd 的组件去做业务逻辑，不使用 Antd 的界面组件去做界面。这个是目前来说，实现成本较低，库依赖少，业务输出较快的折中做法。
毕竟前端 UI 框架是业务逻辑主要涉及的地方，更换成本高。这也就是为什么 DA 这个项目至今还有很多地方在使用 Shopify 的 Polaris 框架。
关于构建器 Vite，虽然它还比较新颖，可能会有坑，但构建工具毕竟只是项目的其中一环，如果 Vite 实际表现仍有欠缺，依然可以以较低成本迁移成 CRA。
你可能会问，NextJS 不是挺好的么，为什么要用 CRA？不得不说 NextJS 确实是个很优秀的框架，但是它更适合于需要 SSR 的环境下（门户这种），后台我还是觉得 CSR 比较合适。当然 TypeScript 还是得有的，一个好的 TS 项目，确实可以很好的做成前端版本的 API 文档。