VivekUI vs MUI and Chakra: What Zero Runtime Dependencies Buys You

MUI and Chakra both style components at runtime through a CSS-in-JS engine. That engine is real JavaScript that ships to the browser, parses your style objects, generates class names and injects stylesheets while the page is running. It is a genuinely clever solution to scoping, and it is not free.

VivekUI has no styling runtime at all. Styles are a static stylesheet and CSS custom properties, so nothing computes styles in the browser. The trade is that you cannot generate arbitrary styles from props at runtime the way `sx` lets you — you get the variants the component exposes plus your own CSS.

Runtime CSS-in-JS libraries have historically struggled with React Server Components, because generating styles during render requires client-side execution and often React context. That is why these libraries commonly need a client boundary or a special provider setup in the App Router.

A static stylesheet has no such problem. There is nothing to execute, so a component that does not need interactivity does not need a client boundary. That is the mechanism behind 49 of 91 VivekUI components being server-safe — not cleverness, just the absence of a styling runtime.

Measured with `size-limit`, minified and brotlied, React excluded: a lone `Button` is 771 B. `Modal`, including focus trap, scroll lock and portal, is 2.9 kB. A whole landing page built from `Hero`, `FeatureGrid`, `Pricing`, `FAQ`, `CTA` and `Footer` is 2.7 kB. Every component imported at once is 47.6 kB. All six charts are 8.3 kB.

Now the part that is not flattering: `styles.css` is 192 kB raw, 27 kB gzipped, and it is a single stylesheet. An app using five components still downloads all of it. That is the direct cost of 'one import, no build configuration' — there is no build step to tree-shake the CSS. Chart CSS is at least split out separately. If your priority is the absolute smallest CSS payload, a Tailwind setup that purges unused classes will beat this.

Every runtime dependency is an upgrade path you inherit. When React ships a major version, you wait for Emotion or styled-components to support it before you can move. With zero runtime dependencies there is nothing in that chain — the package supports `^18 || ^19` directly and there is no third party to wait on.

This also removes a class of duplicate-instance bugs. Because React and react-dom are peers and never bundled, you cannot end up with two copies of React and the invalid-hook-call errors that produces.

MUI and Chakra are mature, enormously widely used, and have component surfaces far broader than any solo project. They have accessibility teams, years of edge cases reported and fixed, and commercial support options. MUI's ecosystem alone includes data grids and date pickers with a depth that takes years to build.

You also give up the `sx` prop and its equivalents — the ability to write one-off styles inline against the theme. Some teams build their whole workflow around that. If yours does, the absence will feel like a downgrade regardless of what the bundle numbers say.

If you are building a large enterprise application with a long lifespan and a team that needs vendor maturity, MUI is the lower-risk choice and I would say so plainly. Its breadth and production exposure are not things a newer library can claim.

If you are shipping a product where the UI should not dominate the bundle, where Server Components matter, and where you would rather not adopt a styling runtime, the zero-dependency approach is worth the trade. Measure both against your own app rather than trusting any library's headline number, including mine.