border-beam, liquid-gooey and thinking-orbs: a monorepo of React effect components

Three separate npm packages, one repository

The repository is a workspace root, not a product. Its package.json is marked private and named @jakubantalik/libraries, and it declares workspaces for packages/* and sites/*. The published artefacts are the individual packages: border-beam, liquid-gooey and thinking-orbs. Each has its own directory under packages/, its own README and its own LICENSE, because npm renders the readme from the package directory rather than the repository root. That detail matters more than it looks: if you read the root README expecting API documentation, you will find build scripts and deploy topology instead. The root file lists the install commands as npm install border-beam, npm install liquid-gooey and npm install thinking-orbs, and points each one at a demo site on a jakubantalik.com subdomain. The root description also names two further packages, metal-fx and img-fx, which have build scripts (build:metal, build:image) but no row in the README's package table and no documented install command. Treat them as present in the tree and undocumented for consumers.

What the effects actually are, and what the repository does not say

The README names each package in one line. border-beam is an animated border beam. liquid-gooey provides liquid Morph and Move effects. thinking-orbs renders dotted thought-orb loaders. The repository topics repeat the same vocabulary: beam, design, effect, glow, motion, product. That is the whole of the public description. There is no props table, no list of supported browsers, no note on whether the animation runs on the main thread or a compositor layer, and no accessibility guidance for users who have asked their operating system to reduce motion. For a visual effect library this is the gap that will cost you time, because the questions you need answered before shipping (does it respect prefers-reduced-motion, does it degrade on low-end Android, does it leak a requestAnimationFrame loop on unmount) are exactly the ones the README does not address. The demo sites exist to answer them by inspection, which is a slower path than reading a spec. The one structural hint about correctness is in thinking-orbs: it carries golden vectors in a spec/ directory that keep its web renderer and its native ports in step, which suggests the authors treat pixel output as something worth pinning down.

Installing border-beam and running it in a React app

Start from the package, not the monorepo. The README gives the install line as npm install border-beam, which fetches the published package rather than the workspace source.

npm install border-beam

If you want to work on the library itself rather than consume it, the root README describes a single npm install at the repository root that covers every workspace, followed by per-site dev servers. The three commands it lists are npm run dev -w @sites/beam, npm run dev -w @sites/gooey and npm run dev -w @sites/orbs. The README states that both sites alias the library to its source, so editing a library hot-reloads its demo site with no rebuild. That is the fastest way to see what a change does.

npm install
npm run dev -w @sites/beam

Building is also per package. The README lists npm run build:beam, npm run build:gooey and npm run build:orbs for individual libraries, and npm run build:site-beam, npm run build:site-gooey and npm run build:site-orbs for a library plus its site as CI does it. npm run typecheck runs across every workspace. Publishing is per package and triggered by a GitHub release through publish.yml, which runs npm publish -w <package>. What you should see after the dev command is the demo site for that effect served locally, with the library loaded from source. The README does not give a component import example, so read the package's own README under packages/border-beam for the actual API.

The thinking-orbs subtree problem, and why git log misleads you

One package has a history that does not behave the way you would expect. The README states that thinking-orbs arrived by git subtree, so its full history lives in this repository, but those commits touched src/... rather than packages/thinking-orbs/src/.... The practical consequence is that git log -- packages/thinking-orbs stops at the merge commit and tells you almost nothing. To read the real history you have to start from the commit the merge names. The README gives the example of logging from 9c6d5c3 against a path under ports/ios, and also shows git log --follow packages/thinking-orbs/src/index.ts. If you are trying to find when a rendering bug was introduced, or whether a particular change was ever reviewed, the plain path log will give you a false answer. This is a repository-layout problem rather than a library problem, but it affects anyone who vendors the package or files an issue against a specific behaviour.

Where it is the wrong choice

The repository is a personal collection of effects with a contributor-facing README, and it should be judged that way. First, it is React-only on the web side. The thinking-orbs package carries native ports under packages/thinking-orbs/ports, described as a React Native package and a SwiftUI package, but the README states plainly that neither is published yet. If you are building for iOS or React Native, you cannot install them today. Second, the release history is thin: v1.2.0 and v1.3.0 are the only releases listed, roughly a month apart, and there is no documented deprecation policy, no changelog linked from the root README, and no stated support window. A component you adopt could change shape between minor versions without a migration note. Third, the root description mentions metal-fx and img-fx while the README's package table omits them, so the set of things this repository produces is not fully described in one place. If you need a component library with a documented API surface, semantic versioning guarantees and an accessibility statement, this is not that, and no amount of visual polish substitutes for it.

Alternatives and the difference in approach

The obvious alternative is to build the effect yourself with CSS, SVG or a canvas, and for a single border animation that is often the right call: you control the reduced-motion behaviour, the frame budget and the bundle cost, and you avoid a dependency whose API is documented only in its package README. The trade-off is that you own the animation maths and the cross-browser quirks. The second alternative is a general-purpose React animation library such as Framer Motion or react-spring, which gives you a documented, widely used API for orchestration, layout animation and gesture handling, but not these specific effects. The difference in approach is scope: a general animation library gives you primitives and expects you to compose the look, while these packages ship the finished look and leave the composition surface thin. If the effect is the product, the finished look is worth more. If the effect is one detail among many, primitives will fit your codebase better. A third option is copying the demo site's implementation directly, which the MIT licence permits; the README's note that both sites alias the library to its source means the demo code and the package code are the same code, so there is no hidden difference between what you see and what you install.

Licence, maintenance and the cost of upgrading

The repository is MIT-licensed, and the root README states that each package owns its own LICENSE because npm renders the readme from the package directory. In practice that means the licence you are bound by is the one in the package you install, and you should read it there rather than assuming the root file governs. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be preserved. This is a description of the licence text, not legal advice. On maintenance, the last push to the repository was on 2026-09-10, and the two most recent releases listed are v1.3.0 on 2026-07-02 and v1.2.0 on 2026-06-09. The repository is not archived. What the README does not give you is a support commitment, a deprecation policy or a changelog, so the upgrade cost is not something you can estimate from documentation. The practical mitigation is to pin the exact version in your lockfile and read the package's README diff before bumping, because the root README will not tell you what changed.

Editorial conclusion

Install it if you need one specific animated effect in a React app and would rather pull a small npm package than build a canvas or SVG animation yourself. Do not adopt it if you need a documented component API, a stable release cadence you can plan around, or anything outside React: the two native ports under packages/thinking-orbs/ports are explicitly not published. Before you commit, read the README inside the package directory rather than the repo root, check the package's own version history on npm, and confirm the effect renders at the frame rate your page needs on the devices you support. The repository's own README does not document browser support, accessibility behaviour, or a rollback path.

Frequently asked questions

Official sources

1. Jakubantalik/Libraries.dev on GitHub
2. License: MIT
3. Project website
4. README
5. Releases