loading-ui is opinionated about one thing: a loading state should help the user understand what is happening, not just prove that animation is possible.
A loader is useful when it answers a question quickly:
The animation itself is secondary. The job is communication.
Pending UI is not filler between real screens. It is part of the experience users actually see while saving, searching, uploading, and navigating. That means loading states should be designed with the same care as buttons, forms, and navigation.
This project stays narrow on purpose. Instead of shipping a giant library of opinionated patterns, loading-ui focuses on a handful of primitives that are easy to install, inspect, and rewrite. The goal is to reduce repeated work without locking teams into a preset brand aesthetic.
A flashy animation can be useful in a landing page. In product UI, it often becomes noise. loading-ui favors components that:
Every installed component becomes part of your codebase. You can tune the animation curve, swap SVG paths, adjust accessibility text, or merge a loader into a bigger component. That ownership model is a core part of the project, not a side effect.
The docs should help you evaluate and install components fast. That means straightforward setup steps, realistic examples, and language that reflects how teams actually ship UI.