← Back to list

The JavaScript Tax: What Your Design System Is Costing Your B2B Users

B2B internal tools are not e-commerce storefronts. Nobody is buying anything. Nobody needs a smooth hover animation on a button that…

Matheus Lacerda · 2026-06-11 19:54 · 0 claps · 4.4 min read
#design-systems #javascript #web-development #software-architecture #python
Open on Medium ↗
Wiki topics: PRD · Product Design 🌐 · Web Development 🎬 · Film & Television 🏛️ · Architecture

The JavaScript Tax: What Your Design System Is Costing Your B2B Users

B2B internal tools are not e-commerce storefronts. Nobody is buying anything. Nobody needs a smooth hover animation on a button that submits an inventory form.

Yet the industry default is to ship 3MB of JavaScript to render a data table. We are paying a massive JavaScript tax for client-side reactivity that B2B applications don’t actually need.

To prove this, I built fifteen applications: three B2B workloads running against five design systems each. An ERP inventory dashboard, a financial dashboard with live charts, and a server console with streaming logs — tested against Ant Design, Chakra UI, Mantine, Material Design (MUI), and Logical Brutalism, the server-driven system I built from scratch. Same features, same data, different stacks.

Here’s what the numbers say.

The Bundle Problem

This one isn’t close.

Design System JS Bundle (avg) & Total Transfer (avg)

Logical Brutalism 7 KB & 348 KB

Mantine 1,193 KB & 1,773 KB

Ant Design 1,699 KB & 1,934 KB

Chakra UI 1,904 KB & 2,431 KB

Material Design 3,356 KB & 3,670 KB

Logical Brutalism ships 7KB of JavaScript. Chakra UI ships 1,904KB. That’s a 268x difference in JS payload before a single line of application code runs.

The reason is architectural. React-based systems ship a virtual DOM engine, a component runtime, a state reconciliation layer, and the component library itself to the browser. Every user, on every page load, downloads all of that before the interface becomes interactive.

Logical Brutalism uses HTMX and Alpine.js. The browser receives HTML from the server and swaps fragments in place. There is no client-side rendering engine to ship.

In the Finance app, the gap is even wider: Logical Brutalism transferred 297 KB total. Material Design transferred 7,896 KB for the same interface. On a 4G connection, that is the difference between a 300ms load and a 3-second one.

The Dependency Audit

Design System Total Dependencies (avg)

Logical Brutalism 275

Material Design 513

Ant Design 531

Chakra UI 541

Mantine 816

Every dependency is a supply chain attack surface, a version conflict waiting to happen, and a maintenance burden for whoever inherits the codebase next year.

Logical Brutalism averages 275 total dependencies. Mantine averages 816. The Finance build of Logical Brutalism shows an anomaly at 694 — that number is inflated by Tailwind’s build pipeline, not runtime packages. The actual runtime footprint is 65 packages in the ERP and ServerConsole builds.

The Performance Tradeoff (The Honest Part)

Here is where the numbers require context rather than just a table.

Design System Widget Update (avg)

Chakra UI 41 ms

Mantine 140 ms

Ant Design 165 ms

Logical Brutalism 442 ms

Material Design 12,853 ms

Logical Brutalism is slower at widget updates than Chakra, Mantine, and Ant Design. That is real and it needs an explanation.

React-based systems update widgets in client memory. When a value changes, the virtual DOM patches the relevant nodes locally. Chakra averages 41ms because the update never leaves the browser.

Logical Brutalism’s updates are server round-trips. HTMX sends a request, the server processes it, returns HTML, and the browser swaps the fragment. The 442ms average reflects network latency plus server processing time — not the rendering engine.

In a B2B context, this tradeoff is usually the correct one. A financial dashboard showing live positions, an ERP table reflecting inventory state, a server console streaming logs — all of these require a server call to get fresh data regardless of your frontend stack. The question is not whether to make a server request. It is whether you make one (HTMX, receives rendered HTML) or two (React, fetches JSON, then renders client-side).

The Material Design number is a different conversation entirely: 12,853ms average, driven by a single ERP test where MUI’s re-render cycle hit 34,224ms updating a dense table. That is the virtual DOM reconciliation algorithm trying to diff hundreds of rows simultaneously and stalling. The system did not slow down. It failed.

The DOM Depth Problem

One metric that rarely appears in design system comparisons: how deep the component tree actually goes.

Design System Max DOM Depth (avg)

Logical Brutalism ~10

Chakra UI ~16

Material Design ~17

Mantine ~18

Ant Design ~21

A Chakra UI button is not a <button>. It is a Button component wrapping an internal Box wrapping a span for the label. Each abstraction layer adds a DOM node. Across a dense B2B interface with hundreds of components, this creates trees twice as deep as they need to be.

Logical Brutalism’s HTML is close to what you would write by hand. A button is a <button>. A card is a <div>. There is no abstraction layer generating intermediate nodes.

Shallower trees mean faster layout calculations, simpler debugging, and predictable behavior under DevTools. When something breaks, you find it immediately. You are not hunting through six layers of component wrappers to locate a margin that should not exist.

What the Numbers Don’t Tell You

The benchmark captures payload, dependencies, update latency, and DOM structure. It does not capture ecosystem size, component variety, or developer onboarding speed.

React’s ecosystem is mature and enormous. Complex date pickers, rich text editors, drag-and-drop interfaces — all of it exists, tested and maintained. Logical Brutalism has none of that. You build what you need or integrate vanilla JS libraries manually.

For internal B2B tools, that tradeoff is usually acceptable. The components you actually need for a monitoring dashboard are tables, charts, forms, and status indicators. None of those require a 2MB JavaScript runtime to function.

If your product is a consumer-facing application with complex interactions, rich animations, and a need for rapid component iteration, React is probably the right call. This benchmark was not designed to dispute that.

It was designed to ask a simpler question: if your data lives on a server, why are you shipping a rendering engine to the browser?

The Conclusion

The industry default for B2B frontend is a React-based component library built for developer experience and component coverage. That is a reasonable choice for many teams.

It is not a reasonable choice when the cost is 1.9MB of JavaScript to display a table that a server could render in 5KB of HTML.

The benchmark does not say React is wrong. It says the JavaScript tax is real, it is measurable, and for applications where the data lives on the server anyway, there is an architectural path that does not require paying it.

Logical Brutalism documentation: Download Logical Brutalism

pip install logical-brutalism | npm install logical-brutalism


메타데이터
post_id
e52bdaf52bce
slug
the-javascript-tax-what-your-design-system-is-costing-your-b2b-users-e52bdaf52bce
url
https://medium.com/@matzx/the-javascript-tax-what-your-design-system-is-costing-your-b2b-users-e52bdaf52bce
canonical_url
https://medium.com/@matzx/the-javascript-tax-what-your-design-system-is-costing-your-b2b-users-e52bdaf52bce
author_url
https://medium.com/@matzx
status
ok
fetched_at
2026-06-12 07:40:50