Picking The Right Library

Picking The Right Library matches a frontend task to Emil Kowalski's curated library list. It starts with the job that needs doing, such as displaying a dropdown, showing notifications, or supporting drag and drop. The recommendation should be one library with a sentence explaining its role when the list has a clear answer, rather than a menu of alternatives.

Copyright Emil Kowalski; the MIT license is retained in LICENSE.

The lookup first checks package.json. If a listed library is already installed, the skill should use it. If the project uses a competing library, it should flag the curated recommendation without replacing that dependency unless asked. A request naming a library still needs to be understood as a UI task: a dropdown belongs to UI primitives even if the user initially mentions a different tool.

Use it when a concrete frontend requirement needs a library choice within the curated set. The choices are deliberate, opinionated starting points rather than universal requirements. User needs, project conventions, keyboard alternatives, and accessibility take precedence. When the task falls outside the list, the skill can recommend from its own knowledge but must clearly identify that departure.

A simple hover or fade should use plain CSS transitions. Motion becomes relevant for springs, layout changes, exit animations, or gesture-driven values. Likewise, chart selection depends on the data flow: points arriving live while a chart scrolls with time point to Liveline; general static or interactive dashboard charts point to recharts.

The input is a task description together with the project's installed stack and requirements. An invocation without a specific question returns only the readiness message and waits for a task. A concrete request produces the matching recommendation and its rationale. Installation or wiring belongs to the workflow only when the request authorizes it; library advice alone is not permission to change dependencies.

Before shipping changes, verify current APIs against the installed versions and official documentation. Limit edits and installations to the authorized task, use development-only fixtures for experiments, and check final visible states and reduced-motion behavior.

For UI primitives, the list maps unstyled accessible components to base-ui, command menus to cmdk, toasts to Sonner, and verification-code inputs to input-otp. Customizable control panels map to Leva, with dialkit named as an alternative. The skill flags hand-built dropdown or dialog focus handling as a case for base-ui's accessibility, focus trapping, and dismissal behavior.

For motion and visuals, it maps general animation to motion, animated numbers to NumberFlow, animated text to torph, globes to Cobe, dynamic OG images to Satori, and syntax highlighting to shiki. NumberFlow addresses digit transitions instead of simply rerendering number text. Satori covers dynamic image generation from HTML and CSS to SVG or PNG.

Interaction and performance choices include dnd kit for drag and drop and Virtuoso for virtualization of long lists or large tables. The common-mismatch guidance points to virtualization before pagination workarounds when a large list is being rendered directly.

For shared state, the listed choice is zustand, including cases where component-local state has become a web of props. Styling choices distinguish clsx for ad hoc conditional className construction from cva for typed variants such as size, intent, or state in Tailwind. They compose because cva accepts clsx-style inputs internally. Theme switching and dark mode map to next-themes, including avoiding a flash on load.