Pluralsight's system, built for a cohesive design language and shared vocabulary across its learning products.
Why we like it
Pando started out as one of the few properly headless-first systems we could point to, and the reasoning behind it is as interesting as the thing itself. Its first foundation was a library of framework-agnostic functions that returned styles and accessibility attributes, built on Panda CSS, so the same logic could render anywhere JSX runs. Version 1 keeps the idea and changes the packaging: those functions now live as recipes in a Panda preset, @pluralsight/react is the one package teams install, and the preset ships inside it as static CSS, so teams don't have to learn Panda to use the components.
What makes it instructive is why it exists: the previous Pluralsight system was so tightly coupled that you couldn't change one component's style without affecting all sixty-five. Pando was rebuilt as an accelerator you adopt in pieces, a direct answer to that failure.
Where it fits
Pando is a useful reference for teams who want one styling source behind several surfaces, and deep customization over locked components.
One important note: the documentation is current and v1 is Pluralsight's recommended version, but the code has moved out of public view. The GitHub repo is archived, the v1 packages aren't on public npm, and the last public releases were 0.7.1 pre-releases in 2024, so we'd treat it as a reference architecture to learn from rather than a dependency to adopt.
Ideas to borrow
- 01.
Architecture
Deliver styling as recipes in a preset, separate from the component model, so teams can use the components or build their own from the same styles, then ship the preset precompiled inside the component library so most teams never configure the styling engine.
- 02.
Architecture
Name the specific failure you're fixing, here a predecessor so coupled that a single change hit all components, and design against it, rather than rebuilding on instinct.
