← All articles

Skeleton Loading: Marmo UI vs MUI

How Marmo UI’s Skeleton component compares to MUI’s — shape variants, animation, and matching skeleton dimensions to real content so loading states don’t jump on resolve.

A skeleton loader is a small component with one job: hint at the shape of content that is about to appear, without causing layout shift when it does. Here is how Marmo UI’s Skeleton compares to MUI's.

Shape variants

MUI ships three variants — text, circular, and rectangular — with width/height set via sx or inline style, and a wave or pulse animation option.

Marmo UI's Skeleton uses the same core shape set (text/circular/rectangular) plus token-based sizing (matching the same size scale used across other components), so a skeleton for a component and the component's own default size stay in sync by construction rather than by manually copying pixel values between the two.

Avoiding layout shift

  • The most common skeleton bug in either library is a skeleton sized differently from the real content it precedes — the page jumps the instant data loads.
  • MUI: width/height are freeform, so keeping them in sync with the eventual real content is a manual discipline.
  • Marmo UI: because component sizing follows the same token scale everywhere, a skeleton built with size="md" matches a real component built with size="md" without hand-tuning pixel values.

Composing skeleton states for a whole page

For a dashboard with multiple cards, tables, and charts loading independently, you typically want a skeleton version of each real component, not one generic gray box. This is where Marmo's MCP-connected workflow differs most from copy-pasting MUI examples: an agent with access to Marmo's component APIs can generate a matching skeleton state alongside the real component in the same pass, using the same size tokens, instead of you writing loading-state markup by hand afterward.

Full props and examples on the Skeleton docs page.