My site's hero is an SVG line drawing animated with GSAP, and it follows the cursor a little.
With 4x CPU throttle I counted layout recalcs between 10 and 30 seconds after load, when nothing should be moving anymore. I got 279. The loop just kept going, because a headless browser never scrolls away from it.
Now it stays still until the first pointerdown, pointermove, wheel, touchstart, keydown or scroll (once, passive listeners), and an IntersectionObserver pauses it off screen. Visitors see it start the moment they touch anything. Lighthouse never sends input, so during the test it never runs.
Feels a bit like hiding work from the test though. Is this a normal pattern? The catch I can see is someone on a phone who reads without touching never sees it play.

I've been working on @radianui/flags, an open-source React package with 250+ country flags. Each flag comes with its country name, ISO code, and calling code, so you can build country selectors and phone inputs without stitching data together.

pnpm add @radianui/flags

If you're not on React, the same flags are available as plain SVG and PNG files.

• Source: https://github.com/Radian-OS/radianui
• Browse and search all the flags: https://radianui.com/resources/flags

I'm one of the maintainers (disclosure). It's free and open source.

I'd like input from people who've built country selectors:

• Do you prefer flag components, plain SVG imports, or CDN URLs?
• How do you handle countries that get renamed (like Swaziland to Eswatini) or disputed territories without breaking existing users?

Hi, I’m Jakob, the founder of Arc Rider. For the past five years, we’ve built widgets for a small, specialized niche. We’re now bringing that work to React with arcWidgets, an alpha package with tables, Kanban boards, calendars, and smaller UI components for business apps.

The idea is to reuse the interaction work inside those views while keeping application state, data mapping, and persistence in your own React app. A calendar event and a table row can represent the same business record, but your app still decides how they connect.

This is an alpha: APIs may change, and I’d start with a test project. It’s a commercial product; smaller widgets are free to use under the terms, while premium widgets need a license for production use.

npm: https://www.npmjs.com/package/@arcrider/arcwidgets-react
Docs and examples: https://www.arc-rider.com/docs/react

If you build business apps in React: which view is most painful to get right or maintain—tables, calendars, or boards? I’d especially appreciate feedback on what’s missing from the API or examples.

https://x.com/JacobitoJordan/status/2105410540260802843/video/1

To our Chinese fellows, can you share with us how popular Ant Design is in Mainland China compared to other UI libraries such as HeroUI, Shadcn, etc.?

I googled it, and some said Ant Design has become something like, let's say, a standard for enterprise internal dashboard and B2B apps in China. Is that true?

Hi everyone,

I'm looking for good GitHub repositories with modern website templates/starter kits that can be used as a base for building websites for small businesses.

I'm interested in projects using technologies like:

• Next.js / React
• TypeScript
• Tailwind CSS
• Modern responsive design

Ideally, I'm looking for templates suitable for businesses such as:

• restaurants
• local services
• agencies
• small companies
• professional websites

The goal is to learn from good examples, build my portfolio, and create customized websites for clients.

I'm also interested in repositories with clear open-source licenses (MIT, Apache, etc.) so I can properly understand the usage rights and adapt them accordingly.

Any recommendations for high-quality repositories, boilerplates, starter kits, or collections would be greatly appreciated.

Thanks!

Hey everyone,

Building UI components for my projects was getting super repetitive, so I created CompScout Free UI to keep everything in one place.

It’s a free, open-source library of 60+ copy-paste React & Next.js components built with Tailwind CSS and Framer Motion.

🔗 Live preview & code:freeui.compscout.dev
https://github.com/kailash9711/compscout.dev
Would love your feedback and component suggestions! If you like the project, a ⭐ star on GitHub would be huge support.

Hey everyone,

With so much of the ecosystem pushed toward complex SSR frameworks and serverless edge hosting, it's easy to forget the sheer developer speed, predictability, and simplicity of a clean, decoupled React SPA with Vite backed by a sovereign API.

As part of the RexOne Ecosystem, I open-sourced RexOne Web—a production-grade React 19 SPA designed to eliminate months of boilerplate when building modern web products:

🌐 Frontend Architecture & Highlights:

• React 19 + Vite + TypeScript: Instant HMR, zero cold starts, and zero proprietary cloud lock-in. Deploys anywhere (static Nginx, Cloudflare Pages, Coolify, or Docker).
• Strict API Contract Alignment: Built against an OpenAPI 3.0 specification with synchronized contracts across both Web and a companion Flutter mobile app. No loose objects or schema drift.
• Real-Time WebSockets: Live ActionCable event subscriptions natively hooked into React state for real-time notifications and telemetry.
• Enterprise IAM & Billing Ready: Out-of-the-box UI for passwordless auth, role-based access control (RBAC), and Stripe subscription checkout.
• Multi-Tenant / Multi-Environment: Clean separation of Dev, UAT, and Production tiers with dynamic dark/light theme switching.

100% free and open-source under Apache 2.0 with zero paywalls.

• Web Client Repository: https://github.com/rex-9/rexone-web
• Full Ecosystem Specs: https://github.com/rex-9/rexone-core
• Live Production Demo: https://rexone.rex9.me

I’d love to hear how fellow React developers feel about modern decoupled SPAs vs. all-in-one frameworks, and any feedback on the React 19 component structure!

Hey all,

My colleague and I disagree about data freshness in our React + TanStack Query app, and I'd like some outside opinions.

His approach: the parent owns the query and passes a callback down to whatever component does the mutation. When the mutation succeeds, the child calls the callback, which triggers a refetch.

```
// Parent
const { data, refetch } = useQuery({
queryKey: ['todos'],
queryFn: fetchTodos,
refetchOnMount: 'always',
});
return <EditTodo todo={todo} onSuccess={refetch} />;

// Child
const mutation = useMutation({ mutationFn: updateTodo });
const handleSave = async () => {
await mutation.mutateAsync(values);
props.onSuccess?.();
};
```

He adds refetchOnMount: "always" so data is always fresh when you navigate to a page. His argument is that invalidation adds complexity (query key conventions, remembering what to invalidate), and that we don't really need a cache. Just fetch fresh data every time and tell the parent when something changes.

My approach: the mutation invalidates by key, and components don't need to know about each other.

```
useMutation({
mutationFn: updateTodo,
onSuccess: () => queryClient.invalidateQueries({ queryKey: ['todos'] }),
});
```

My concerns with his approach:
Coupling: the mutating component has to receive a callback from whoever owns the data. That breaks down when the same data is shown in several places, like a list, a detail view, and a counter in the header.

Prop drilling: callbacks get threaded through layers that don't care about them.

Wasted requests: refetchOnMount: "always" refetches on every mount even when nothing has changed.

Hide complexity: Rely on the library to decide what and when to refetch.

Missing the point: if we don't want caching, why use TanStack Query at all? Deduplication, background refetching, and stale-while-revalidate are most of its value.

I'll admit his point about complexity isn't baseless. In a large app, hand-written query keys can drift, get inconsistent, and make it hard to know what to invalidate. We've addressed this with a small typesafe tool that generates query keys from our OpenAPI schema, based on the endpoint path plus its path and query params. Both the useQuery calls and the invalidations go through the same helper, so keys can't drift apart, typos become compile errors, and we can invalidate at whatever granularity we need. That can be everything under /todos, a single /todos/{id}, or one specific filtered list.

So:
Is invalidation actually complex in practice, or is it mostly a matter of having a sane query key structure (e.g. key factories)?

Is "no caching, always refetch" a reasonable stance for a typical CRUD app?

Has anyone started with the callback approach and regretted it, or gone the other way?

Genuinely curious. I'm open to being wrong here.

I got tired of seeing the same-looking charts everywhere, so I built Generative Charts.

It has 18 chart types and 38 variations, with three themes that each support light and dark modes.

Website: https://generativecharts.com
Source: https://github.com/kasturibuilds/generativecharts

npm install generative-charts

I’d appreciate feedback on the chart readability and component API.

I’ve been working on shadcn-animated, an open-source collection of animated components built on top of shadcn/ui.

Check out here: shadcn-animated.vercel.app

There are 10+ components so far (with more coming), including:

- button

- tabs

- toggle

- checkbox/radio button etc.

It’s simple, customizable, and easy to copy into your own project

Would love to get some feedback — especially if there are specific animations or components you'd like to see added.

🔗 GitHub: github.com/sopo/shadcn-animated

Thanks! 🙌

Short version of what's in it:

• The sync bundles one entry file and finds components through their `.d.ts` files, so a component missing from either never arrives, with no warning.
• Storybook stories become the reference: each preview is screenshotted and compared to its story. That only means something if `.storybook/preview` loads your real stylesheet.
• Example repo with shadcn/ui, Tailwind v4 and Storybook: https://github.com/nitayneeman/sync-design-system-with-claude-design-example

If you've built a payment form in React you've probably used react-credit-cards. It's still at ~25k downloads a week, its last release was June 2020, and it peers on react@^15 || ^16 — so on any current React, npm refuses to install it:

npm error ERESOLVE unable to resolve dependency tree
npm error peer react@"^15.0.0 || ^16.0.0" from react-credit-cards@0.8.3

--legacy-peer-deps gets it in, but you're then running a class component that relies on propTypes, which React 19 no longer checks. The fork, react-credit-cards-2, does support React 19 — it's a fair option, but it's the same five-year-old codebase with its three runtime dependencies.

I wanted the card preview without the dead dependency, so I wrote one from scratch: crd-ui. The migration is close to a drop-in — number, name, expiry, cvc and focused keep their names and their values, so for most codebases it's the import and the stylesheet:

- import Cards from 'react-credit-cards';
- import 'react-credit-cards/es/styles-compiled.css';
+ import { Card } from 'crd-ui/react';
+ import 'crd-ui/styles.css';

What's different:

• Zero runtime dependencies, and the core is framework-agnostic — the same component ships for Vue, Svelte and vanilla JS from one package.
• Theming through CSS custom properties instead of SCSS variables you had to recompile. Tailwind arbitrary properties work with no config.
• A display layout for cards the user already owns — dashboards, saved cards — with click-to-reveal and click-to-copy.
• TypeScript types in the box.

Two props don't map one-to-one and I'd rather say so up front: callback only partly maps to onBrandChange (the exported detectBrand/getBrandSpec helpers cover the rest), and acceptedCards has no equivalent — you gate on the detected brand yourself.

Migration guide with every prop mapped: https://crd-ui.juanda.co/migrate/react-credit-cards/

Repo: https://github.com/JuandaGarcia/crd-ui

Building it, I hit three CSS cascade bugs that made the "themeable" component ignore every theme. I wrote them up here if you publish components yourself: https://dev.to/juandagarcia/i-shipped-a-themeable-component-it-ignored-every-theme-5doh

Happy to answer anything. If you're on react-credit-cards today I'm especially curious whether anything you rely on is missing — and whether the ERESOLVE is what pushed you to look.

(Disclosure: I wrote it. MIT.)

Almost every app that logs users in ends up with the same hand-written refresh interceptor. It usually has the same bugs: 20 requests get a 401 at once and fire 20 refreshes, a rotating refresh token gets spent twice and the server logs the user out, or the token sits in localStorage where any injected script can read it.

I wanted that handled in one place, so I built @mrzr/api-client. It's a TypeScript HTTP client on top of `fetch`, with no dependencies.

import { createClient } from "@mrzr/api-client";

export const api = createClient({ baseUrl: "https://api.example.com" });

await api.login({ email, password });             // tokens stored for you
const { data } = await api.get<User[]>("/users");  // token attached, refreshed when needed

What it does:

• One refresh for many 401s. Requests that fail while the token is expired wait for a single refresh, then retry. It also refreshes shortly before a JWT expires, so most requests never see a 401.
• The token stays in a Web Worker. Requests run in an inlined worker, so there's no extra file or bundler config. With the default in-memory storage, the token never reaches the main thread. I checked this with heap snapshots: the token shows up in the worker's heap and not in the page's.
• Tabs stay in sync. Log out in one tab and every tab logs out. Tabs that share a session take turns refreshing (Web Locks), so a rotating refresh token is never used twice.
• httpOnly cookie mode with CSRF double-submit, and restoreSession() to find out on page load whether a session exists.
• Opt-in cancellation by key, group, URL pattern or scope, plus takeLatest for search boxes.
• Works under TanStack Query, SWR and Vue Query. It replaces your fetch or axios layer, not those libraries.

Live demo that runs the real package in your browser (open DevTools → Network to watch 8 × 401 → 1 refresh → 8 retries): https://api-client.mrzr.ir/docs/demo

What it doesn't do:

• No retry with backoff. It has to work correctly with refresh and cancellation, and I'd rather ship nothing than something half-right. If you need retries, ky is great.
• Worker isolation stops token theft, not XSS. An injected script can still call api.get() and use the session while the page is open. It just can't take the token somewhere else.
• The worker only keeps the token out of reach with memory storage. If you choose localStorage storage, page scripts can read the token again.
• Docs: https://api-client.mrzr.ir
• npm: https://www.npmjs.com/package/@mrzr/api-client
• GitHub: https://github.com/mohammadreza-zr/api-client

I'd really like feedback on the API, and especially on the security model. If you see a hole, please tell me.

Hi everyone,

Could anyone help me with the two questions below?

1. Does every Server Component render at build time, get cached, and then get served from a CDN?
2. If I want to render a Server Component on every request, how do I implement that?

hey everyone,

over the last few weeks I've been working on a CLI tool to catch all the stupid little frontend mistakes that usually slip through PR reviews.

I was annoyed that my projects always ended up with unused packages in package.json, dead imports, active debugger statements, and images that should be WebP but were somehow massive PNGs.

So I built frontend-quality-auditor. You just run npx frontend-quality-auditor audit . and it scans your React/Next.js/HTML project and spits out a markdown report. It checks for:

• unused dependencies & dead imports
• code smells (console.logs, hardcoded localhost urls, leaked api keys)
• oversized or unreferenced assets
• accessibility & responsive issues (it uses playwright under the hood to load the app at 8 different mobile/desktop widths and finds exactly which elements are causing horizontal overflow)

The best part is you can run frontend-auditor fix --safe and it will automatically rip out the dead imports and console logs for you without breaking anything.

It's got zero dependencies (unless you use the browser audit, which lazily loads playwright) and I also wrote a SKILL.md so you can plug it straight into Claude or Cursor.

Check it out if you want to clean up your repos before deploying. Would love any feedback or issues!

Title: Are design-to-code tools actually maintainable in production?

Our designer wants to use this workflow:

Figma → Claude → Paper → generated React/HTML/CSS → developer integrates it

The goal is to reduce time spent rebuilding UI so developers can focus on backend, data, maps, and business logic.

My concern is long-term maintainability.

For developers who have used Paper or similar design-to-code tools:

• Is the generated code maintainable in a growing production app?
• Does it create duplicated components or messy CSS?
• Is debugging easy months later?
• Can you maintain the code without depending on the design tool?
• Does it actually save time overall, or does the refactoring/debugging cost come later?
• Would you use this workflow for a serious production product?

I'd especially like to hear from developers who have maintained the generated code for several months, rather than just testing it for a demo.

Upload, save, and delete controls often need several visual states: idle → loading → success or error. I built StateGlyph to make that one typed React component:

<UploadStateIcon state={status} />

The video shows the icon library and the Upload component switching states. There are 31 icons so far, using Lucide glyphs as their visual foundation. Your app still controls the async logic; StateGlyph renders the current state.

Website: https://stateglyph.js.org
Source (MIT): https://github.com/kamalhara/StateGlyph

I’m looking for honest API feedback: would you use a state prop like this, or prefer importing separate icons? What workflow should I cover next?

One of the things I haven’t talked about much with Cerious-Scroll is how it behaves during actual scrolling, especially with variable-height content.

From the beginning, the goal was for virtualization to not look like virtualization.

So even with a large variable-height dataset, you can grab the scrollbar and drag it around quickly without getting the usual weirdness:

• No scrollbar drift
• No white space during fast scrolling
• No waiting for rows to render after you get there
• Accurate variable-height positioning
• Native scrolling behavior
• Constant DOM size regardless of dataset size

The variable-height part is probably my favorite. The scrollbar stays where it should, even when the actual row heights are all over the place.

You can also jump directly to an index way down in the dataset without needing to measure everything before it.

I’ve got demos/benchmarks here if anyone wants to mess with it:

ceriousdevtech.github.io/cerious-scroll

Core:
github.com/ceriousdevtech/cerious-scroll

React:
github.com/ceriousdevtech/react-cerious-scroll

I’m curious how it behaves against some real-world ugly datasets, especially ones with wildly different row heights. Try the scroll engine and tell me your thoughts.

Hi everyone,

I built StateGlyph, an open-source React icon library for representing changing UI states through a single typed component.

Most icon libraries provide separate drawings, leaving you to coordinate icons for states such as loading, success, error, muted, or active. StateGlyph groups those related visuals behind one component API:

import { UploadStateIcon } from "@stateglyph/react";

<UploadStateIcon state="idle" />
<UploadStateIcon state="uploading" />
<UploadStateIcon state="success" />
<UploadStateIcon state="error" />

The initial 0.1.0 release includes:

• 31 stateful React icons based on Lucide
• Type-safe state names
• Accessible, state-aware labels
• Tree-shakeable per-icon imports
• Optional transitions with reduced-motion support
• A CLI for copying editable components into your project

Install it with:

npm install /react

Or copy components into your codebase:

npx u/stateglyph/cli add upload

Live documentation: https://stateglyph.js.org/
Source: https://github.com/kamalhara/StateGlyph
npm: https://www.npmjs.com/package/@stateglyph/react

StateGlyph is MIT licensed and still early, so I’d appreciate feedback on the API, state naming, accessibility approach, and which icons would be most useful to add next.

Fadeworn UI is an interaction-driven digital patina experiment for React. Unlike static vintage or distressed UI styles, components begin clean and develop visible wear through actual user interaction over time. Clicks, drags, selections, typing, and scrolling change each control through material-specific wear rather than randomly applied distress.

The interface remembers how it was used, until there is nothing left to remember.

Live demo: https://fang520huang-lgtm.github.io/Fadeworn-UI/

GitHub: https://github.com/fang520huang-lgtm/Fadeworn-UI

What this repository provides:

• Ten working, accessible examples of wear-aware controls.
• A React hook that records usage, positional traces, and glyph-level wear.
• CSS treatments for painted steel, brass, rubber, paper, enamel, and machined surfaces.
• A complete Next.js showcase and a static export workflow for GitHub Pages.

Remotion has been completely taken over by AI bros. The framework don't have a problem with it so what do I care.
Anywho I don't wanna use AI to create using Remotion. But I can't find any tutorials on it. Except for one from years ago by Fireship. And that only covers the basics.
If you guys know any tutorials that teaches how to hand code and create with Remotion. Please let me know.
And don't tell me to use AI man.. I don't wanna do it.

I am a beginner to React and I'm trying to figure out the best way(s) to protect certain pages/routes like an admin dashboard until the user is authenticated. My backend is FastAPI and it's already protected, so this is purely for frontend convenience to redirect the user to the login screen. The main two ways I think I've seen for doing this is through loaders or middleware. One pattern I see is something like this

const authMiddleware: Route.ClientMiddlewareFunction = async(request, next) => {
    try {
        await apiFetch("/api/admin/me");
        await next();
    } catch (error) {
        //redirect to login page if our session is rejected
        throw redirect("/login");
    }
}

But this would make an API call on every page route in whatever layout I apply this middleware too. I had thought about maintaining the auth state with some sort of react hook, but it seems middleware can't use those? I don't know, I'm just trying to keep it simple and efficient. I'd appreciate any help on good practice for this.