mrkeyoor.com_
Sat 05 Sept 17:03 UTC
Webevaluationupdated 05 Sept 2026

Libraries.dev review

Libraries.dev is a monorepo of React components for animated borders, liquid motion, agent status orbs, metallic frames, and image-generation effects. It packages polished visual treatments that would otherwise take substantial CSS, canvas, SVG, or WebGL work to reproduce.

trackingstars / 7d
Verdict

Our Libraries.dev run installed 266 packages in 20 seconds, but the root exposed neither a standard build target nor a test target for the lab to verify. Pick an individual package when its exact effect earns the 487 MB contributor setup and you can test it in your browser and accessibility matrix. Skip the monorepo as a general UI foundation; it is a focused effects shelf with uneven packaging and verification across its 5 libraries.

We ran it

Lab card: what happened when we ran Libraries.devScreenshot of Libraries.dev (libraries.dev)
Install✓ · 20s266 packages · 487 MB
Buildn/ano build script
Testsn/ano test script
Known vulns00 critical · 0 high · 0 moderate · 0 low (npm audit)
Repo1003 files~47,567 lines of source · 138.1 MB · 3 CI workflows

Answers from our run

Does Libraries.dev build from source?

Dependencies installed in 20 seconds (266 packages), and the project has no separate build step. We cloned commit 999866f into a clean Debian container with 3 CPUs and no project-specific setup.

Does Libraries.dev have tests you can run?

Not through a standard command: the project exposes no test script or target that our harness could run.

Does Libraries.dev have known vulnerabilities in its dependencies?

npm audit found none in the dependency tree at the time of our run.

Who should not use Libraries.dev?

Vue teams expecting a supported adapter: the public packages are for React, and Vue 3 support remains an open request.

What are the alternatives to Libraries.dev?

Magic UI, Motion, shadcn/ui. Our Libraries.

Setup3/520-second install; builds require a package-specific command
Docs4/5Deep package READMEs, with some root catalog and backend gaps
Community4/52,914 stars and active August and September 2026 work
Maturity3/5Published packages exist, but the root has no test target

Who it’s for

React teams that need one distinctive effect rather than a full component system.
AI product designers who want legible animated status indicators for agent states.
Front-end engineers prepared to test canvas, SVG, and WebGL behavior in target browsers.
Teams willing to own reduced-motion behavior where the package leaves it to the consumer.

Who it’s NOT for

Vue teams expecting a supported adapter: the public packages are for React, and Vue 3 support remains an open request.
Projects that require a standard automated test gate: our checked root had no test script or tests directory, so the lab had nothing to run.
Teams expecting every animation to handle reduced motion internally: the border-beam README says rotate variants depend on the consumer's implementation.
Mobile developers who need registry-ready native packages: the root README says the React Native and SwiftUI ports are not published, and issue 9 reports that the Swift manifest sits below the repository root.
Buyers expecting the whole libraries.dev service in this checkout: the README says its account and Pro backend lives in a private repository.

Setup reality

Our sandbox installed 266 npm packages in 20 seconds and used 487 MB. The root had no standard build target, so the build step was skipped. It also had no test target, so tests were skipped. Npm audit reported 0 known vulnerabilities.

One root install covers the npm workspaces. Development and production commands are package-specific, such as build:beam or build:site-orbs; Node 20 is pinned for the hosted demos. The public component packages need no credentials, while the account and Pro backend for the umbrella site is private.

The monorepo holds 5 library packages and several demos, so you must choose the right workspace command. Our scan found 3 CI workflows, no Dockerfile, and no tests directory. Browser requirements vary: two effects use WebGL, thinking-orbs uses 2D canvas, and liquid-gooey mixes DOM with SVG filtering.

Five effect packages share one npm workspace

The checked monorepo contains 5 React libraries: border-beam, liquid-gooey, thinking-orbs, metal-fx, and img-fx. They solve narrow visual problems. Border Beam wraps an element with traveling or pulsing light, Liquid Gooey merges moving surfaces, Thinking Orbs depicts agent states, Metal FX draws a shader-based ring, and Image FX reveals images through animated mosaics. This is a shelf of effects, not a button, form, and dialog system.

That focus is useful when the design already exists and one treatment is missing. Each package owns its README, license, build, and demo. The root uses npm workspaces, so a single install connects the source libraries to their demo sites for hot reload. Consumers still install the packages separately. Taking only thinking-orbs does not require shipping the WebGL code used by the 2 shader packages.

Three packages get top billing while the tree contains five

The root README's opening table lists 3 packages: border-beam, liquid-gooey, and thinking-orbs. The checked package tree also contains metal-fx and img-fx, and the root package description names all 5. That mismatch makes discovery less tidy than the individual documentation. Read the package README before choosing because the rendering method, peer dependencies, browser behavior, and control surface differ considerably.

Thinking Orbs is the cleanest small component here. It has 9 named agent states at 2 tuned sizes, uses a 2D canvas, pauses outside the viewport, caps device pixel ratio at 2, and supplies labels. Border Beam provides 5 motion presets and 4 color palettes. Liquid Gooey is far more involved, measuring DOM geometry and combining live content with SVG effects. The libraries share an aesthetic, though their operating costs are not interchangeable.

What happened when we ran it

Our sandbox installed 266 npm packages in 20 seconds and left 487 MB on disk. The checkout at commit 999866f contained 1,003 files, about 47,567 lines of source, and occupied 138.1 MB before installation. Our measurement setup used a fresh unprivileged Node 22 container with 3 CPUs, 8 GB of RAM, and no secrets. Npm audit found 0 known vulnerabilities across all severity levels.

The root package did not expose a standard build script or target recognized by the lab, so we skipped the build. This does not mean the packages cannot compile. The root defines named commands such as build:beam, build:gooey, build:orbs, and several site builds. It means there is no single default build result for the 5-package workspace. A release gate should call the exact library and demo commands it intends to publish.

There was also no test script or target, so we skipped tests. Our scan found 3 CI workflow files but no tests directory or Dockerfile. Type checking has a root command, and package source includes careful implementation details, yet neither substitutes for a test result. Visual effects need screenshot checks, keyboard and screen-reader checks around wrapped controls, reduced-motion verification, and failure cases for missing WebGL or blocked image access. The checked repository did not give our harness one command covering those outcomes.

Reduced-motion behavior differs between the packages

Thinking Orbs documents a static frame under prefers-reduced-motion and keeps its accessible label. Border Beam's pulse variants include a reduced-motion block, while the rotate variants rely on the consuming application. That split is easy to miss because both variants come from one package. If a product has a strict motion policy, add an application-level media query and verify every variant rather than assuming the wrapper handles all 5 presets.

The decorative layers in Border Beam ignore pointer events, which preserves access to the wrapped control. Liquid Gooey says the real DOM stays above its visual silhouette, retaining focus rings, hit targets, ARIA, and handlers. These are sound design choices. They still need testing inside your layout because the effects measure child size, border radius, motion, or neighboring elements. A transformed parent, clipped overflow, or theme system can change the result without producing a TypeScript error.

Two packages make WebGL a runtime requirement

Metal FX and Image FX use WebGL, while Thinking Orbs uses 2D canvas and Liquid Gooey relies on DOM and SVG techniques. Metal FX shares one WebGL context across mounted instances and pauses copies outside the viewport. Image FX also shares a renderer, caps its default animation at 10 frames per second, and pauses offscreen cards. Those decisions reduce obvious waste, but they are implementation claims rather than measurements from our sandbox. We did not benchmark rendering speed.

Image FX also needs same-origin or CORS-enabled images to sample a revealed image's palette. When access is blocked, it falls back to the preset colors. This is a graceful visual fallback, but a product team should test CDN headers and browser privacy settings before building a branded transition around sampling. Server rendering receives special handling in Metal FX, which mounts the WebGL path after hydration. Again, test the actual framework because the repository covers React components rather than every React server stack.

Native ports exist in source but are not published

The root README says Thinking Orbs carries React Native and SwiftUI ports under its package directory, kept in step through shared vectors, but neither is published. The checked tree also contains native port material under Border Beam. Open issue 9 describes the practical Swift problem: GitHub cannot add the repository directly as a Swift package because Package.swift is in a subdirectory. Mobile adopters are taking source and packaging responsibility today.

Release v1.3.0 arrived on July 2, 2026 with tuning hooks for Border Beam's pulse-outside variant. GitHub recorded another push on September 4 and listed 7 combined issues and pull requests when fetched. The queue includes Vue 3 support, custom colors, Swift packaging, and a Liquid Gooey fix. That is current activity around a young, small project. It supports trying a specific effect, while the missing root test target argues against adopting all 5 packages by default.

Alternatives

ProjectWhat it isPick it when
Magic UIA larger collection of animated React components distributed as copyable source.pick this instead when you want many page sections and effects that become part of your own codebase.
MotionA general animation library for React and JavaScript with primitives for custom motion.pick this instead when you need to design the interaction itself rather than install a finished visual effect.
shadcn/ui gh↗An open component distribution system centered on editable application UI.pick this instead when accessible interface components matter more than decorative shaders and loaders.

What people are saying

  1. [github-trending] Jakubantalik/Libraries.dev

Sources

  1. Libraries.dev README
  2. Libraries.dev repository facts
  3. Libraries.dev package tree at commit 999866f
  4. Border Beam package README
  5. Thinking Orbs package README
  6. Swift package layout issue
  7. Libraries.dev v1.3.0 release

More web reviews

FckSignups · mantine · handsontable · Web-Dev-For-Beginners · react-bits · tdesktop · the whole board →