Use familiar style objects, get full TypeScript autocomplete, ship static CSS, and keep overlapping atomic declarations predictable instead of hoping global utility order works out.
PikaCSS is strongest when your team wants the ergonomics of typed CSS-in-JS without paying runtime styling costs in production. It is not trying to be a runtime styling system, and it is not pretending dynamic expressions can always be optimized away.
Its most practical advantage is that it does not treat atomic reuse as more important than correct cascade behavior. When declarations overlap, PikaCSS keeps later author intent local and predictable instead of letting the final result depend on whichever shared utility happened to be emitted later in the global stylesheet.
That tradeoff is the whole point. If you accept statically analyzable inputs, PikaCSS can generate deduplicated atomic CSS, complete autocomplete, and predictable output. If you need arbitrary runtime styling, you should know that before you adopt it.
What to read first
Do not skip Static Arguments. Most incorrect first impressions of PikaCSS come from assuming pika() behaves like a runtime function.
The primary docs path is intentionally user-first. If you are extending the engine instead of only consuming it, jump to Plugin System Overview.
