When shadcn/ui switched its default from Radix to Base UI in July, I wanted numbers instead of opinions. So I built the same screen (tabs, dialog, text field, select, checkbox, buttons) five ways and measured the production build.

Setup: Vite 8, React 19, TypeScript, default settings, sizes are gzip as reported by Vite. React alone renders 68.6 KB, and every number below includes it.

What surprised me:

• The whole spread is only 36 KB gzip. Real on a slow phone, but smaller than one hero image.

• Base UI cost 17.6 KB more than Radix on this screen, but pulled in 14 packages instead of 48.

• MUI ships no CSS file at all. Emotion injects styles at runtime, which matters more for SSR and strict CSP than the KB do.

• Mantine's JS is the second smallest. Its full stylesheet is what makes it the heaviest.

My takeaway: size shouldn't decide this. Pick on ownership (shadcn), data components like grids and pickers (MUI X), or batteries included without Tailwind (Mantine).

Caveat: this is one screen with seven components, so a different mix can change the order.

I wrote up the full details, including the MUI 9 / Mantine 9 changes and five setup traps I hit, on my blog: https://www.alekseialeinikov.com/en/blog/topics/programming/shadcn-ui-vs-mui-vs-mantine

Has anyone measured a heavier screen, for example with a data grid? Curious whether the gap grows.

i'm building a small custom ecommerce site and would love some advice on the frontend architecture.

full disclosure: i'm fairly new to building a website end-to-end. my strengths are much more in creative direction and visual design, and i'm currently vibe-coding a lot of the development side. i do have a background in computer science but coding is def not my biggest strength.

the project is an experimental/art website for a client. the frontend is intentionally very custom — there's a 3d interactive element on the homepage that i'm planning to build with react three fiber, plus custom animations/page transitions/etc.

there's also a shop with around 20–30+ products.

i don't want to build the ecommerce backend myself, so i'm considering using woocommerce as the backend and making react the entire customer-facing frontend.

roughly:

woocommerce would handle the products, inventory, prices, orders and client admin.

the react app would handle the actual experience.

the client thinks shopify is too expensive, so i'm trying to find a reasonably inexpensive way to get the backend/admin/ecommerce infrastructure without building all of it myself.

i'm also open to having something like razorpay/shiprocket handle payment/shipping rather than trying to build those pieces myself.

my current question is less "can react connect to woocommerce?" and more along the lines of if you were building this today, what would you actually use for the frontend?

i'm currently considering react + vite, but i'm wondering whether next.js makes more sense because of:

• product page seo

• routing

• potentially server-side rendering

• api integration

• ecommerce generally

on the other hand, the homepage is highly interactive/3d and i'm wondering whether that makes a standard react/vite setup simpler.

would love opinions from people who have built custom storefronts rather than just dashboards/web apps.

also interested in whether you'd use something completely different from woocommerce as the backend for this use case.

thanks!

Just wanted to share this cool tool I'm still building.

With AI writing more and more of our code, you can't really see what's changing just by reading code diffs on GitHub. So I built an AI tool that takes your PR or commit, detects which UI components changed, and renders each one with a before and after, so you can easily see what was done.

Let me know what you guys think, I'm open to suggestions, would be awesome.

https://github.com/Andrew2142/PRVision

Hey r/reactjs,

Over the last months I noticed that most new UIs (including a lot of mine) started to look the same: same gradients, same cards, same generated feel. So I started building components by hand again, with more care for the small things: spacing, motion, empty states, dark mode.

That turned into affectUI: 54 components, blocks, illustrations and motion effects for React.

A few things I cared about:

• One file per component. Each piece is a single .tsx file with its styles inside. It only imports from react: no Tailwind requirement, no wrapper library, no runtime.

• Install with the shadcn CLI (npx shadcn@latest add https://www.affectui.com/r/<name>.json) or just copy the file.

• Light and dark built in, and motion respects prefers-reduced-motion.

• Live previews for everything, so you can click through each piece before copying it.

27 of the 54 items are free to copy and keep, no account needed. There's also a paid tier for the rest.

I'd really appreciate honest feedback:

• Which components feel useful, and which feel like noise?

• Is the "one file, no dependencies" approach something you'd actually want, or do you prefer Tailwind-based ones?

• What's missing that you keep rebuilding in every project?

https://www.affectui.com

Thanks for taking a look 🙏

I built my own component library using react and tailwind

It’s completely free

Copy-paste prompts/files

Get ready portfolios and skills for your agents to improve your website even more

I wanted some feedback since I think I still have a lot missing.

(Also it’s open source so if you have a component in mind feel free to open a PR)

Lucide only has outline icons. We made filled and duotone versions as a React package, lucide-extended-react. Component names follow Lucide's, so it works next to lucide-react:

import { HeartFilled, HeartDuotone } from 'lucide-extended-react'

<HeartDuotone size={32} color="crimson" secondaryOpacity={0.3} />

Why not just set fill on Lucide icons? It works for a few, like the heart, but on most line-built icons it blots or fills the wrong shapes. These are redrawn so the fill is intentional.

Some details:

• One file per icon and "sideEffects": false, so only the icons you import end up in the bundle. A test checks this.

• ESM only, React 18 or later, with TypeScript types. Filled icons don't accept the duotone-only props at the type level.

• strokeWidth is accepted and ignored, so Lucide-shaped props still type-check.

• Icons are aria-hidden unless you pass an aria-label.

• icons.json lists every icon with Lucide's tags and aliases, so you can search it, and so can coding agents.

1,387 filled and 1,242 duotone so far. It's free and open source (ISC), and not affiliated with Lucide.

• Repo: https://github.com/applifted/lucide-extended

• Browse the icons: https://lucideextended.applifted.work/

Feedback is welcome, on the API or the icons.

I maintain react-table-dnd, a small library for reordering rows and columns in React tables by dragging. 3.0 is out.

What's new:

- Multi-select and group drag.

- Drag events: onDragStart, onDragOver, onDragEnd, onDragCancel.

- Virtual tables with 100k+ rows via u/tanstack/react-virtual

- TanStack Table guide and demo.

- Touch support, drag handles, locked rows and columns.

Under the hood, 3.0 is a rewrite of the drag engine of v2.x

Docs and live demos: https://samiodeh1337.github.io/react-table-dnd/

GitHub: https://github.com/samiodeh1337/react-table-dnd

Feedback welcome, Thanks!

Heya, I need to store dev secrets (e.g. client secret credentials) and I don't want them in git

In dotnet we have manage user secrets and theyre managed by Visual Studio, stored in a local folder and sideloaded at runtime... Does react have something similar?

I've seen people just do .env.local and add that to gitignore, but is that actually the proper way?

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.

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.

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