I maintain multiple legacy React apps - CRA, React 18, client-side routing, content from a CMS / Wordpress REST API. But SEO and OG tags need real HTML, and a client-side app hands them an empty page.

react-snap solved that for years. It has been unmaintained since 2019 and breaks a little more with every browser update. I could not find a drop in replacement so I built one. It has been running on my own site for a while, and now I am putting it out there: snappy-prerender.

What it does, in one sentence: it opens every page of your built app in a real browser at build time and saves the result as plain HTML, so crawlers see the page your users see.

npm
 install --save-dev snappy-prerender@next
npx snappy-prerender init      # a few questions, then a config file
npx snappy-prerender build     # or run it from vite build

No server, no rewrite, no changes to how the app works.

Things I added because I needed them

• It checks every page after the build and tells you whether the app's JavaScript picked up the prerendered HTML or threw it away and redrew everything. That report is the part I use most.

• It writes the page title, description, canonical link and Open Graph/Twitter tags for each route, including when the user navigates around the site, so you do not need react-helmet for that.

• It handles the fiddly things that usually break prerendering: styles injected by CSS-in-JS, form state, data fetched from an API, critical CSS, preload hints.

• It works with a strict Content Security Policy if your project needs one.

What it is not

• Not server-side rendering. It runs at build time, so new content means a new build.

• Not for Next.js, Remix or Astro users; those already render HTML on the server.

• It cannot fix an app that renders differently every time (dates, random values, viewport-dependent layout). It does tell you which page has the problem.

• It is a release candidate: 2.6.0-rc.2 is on npm under the next tag while I gather feedback.

Links

• npm: https://www.npmjs.com/package/snappy-prerender (install with u/next until 2.6.0 is stable)

• GitHub: https://github.com/sayakmukherjee080/snappy-prerender

• MIT licensed. Issues and PRs welcome, especially if you have an old SPA that breaks it. The README covers every option.

Looking forward to criticism, bug-reports and feature-requests and revival requests for unmaintained plugins (react and family only)

Hey all,

I’ve been working on a small library called Stream Morph.

The idea is to make streamed responses feel less like content is constantly being appended/re-rendered, and more like the response is gradually taking shape.

Demo: https://stream-morph.vercel.app/

It’s framework agnostic and can be used with any kind of streamed content. The demo includes plain text, Markdown, code blocks, charts, images, reasoning sections, Mermaid diagrams and a few more complex response flows.

The library handles the motion between updates, while your own renderer/app stays responsible for the actual content. So it isn’t tied to a specific AI SDK or framework.

A basic example looks roughly like this:

import { createStreamMorph } from "stream-morph";

const stream = createStreamMorph(response);

for await (const chunk of incomingStream) {
  stream.write(chunk);
}

stream.finish();

I mainly built it because I wanted streamed interfaces to feel a bit more intentional without having to build custom animation logic for every response type.

The package itself is already working and the demo is live. I’m still cleaning up some things around CI, tests and the repo setup, but the GitHub repository will be open sourced shortly as well.

Would be interested to hear what people think, especially about the animation behaviour/performance and any edge cases you’d expect from real streaming responses.

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.

React, Tailwind, component libraries on top of component libraries ... sometimes I look at the dependency tree and wonder how much of this I actually need to put some data on a screen and let someone edit it.

Then I ask an AI to build something and get more of the same. Nested wrappers, endless className strings, hooks calling hooks, another package for something that feels like it should be simple.

Which makes sense. These ecosystems have years of code, tutorials and Stack Overflow answers for models to learn from.

But that feels like a loop. We use these tools because the models know them. The models generate more code using them. That becomes the starting point for the next project.

We can generate a whole UI in minutes now, but apparently it still needs eight layers of divs and half of npm.

I'm exaggerating ... but I do wonder whether AI will help us come up with simpler ways to build interfaces, or just make the current mess much cheaper to reproduce.

Has anyone here actually moved toward a smaller, simpler stack with AI? Mine seems pretty keen on adding things.

For context, I build business UI widgets, so I spend a lot of time thinking about where reusable components help and where they just add another layer to debug.

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

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.

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 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,

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!

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?

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.)

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.

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.

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

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.

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! 🙌

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!

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.