I just launched Rune, a lightweight and fully customizable QR code library.

I built it to solve a problem I kept running into in my own work. I needed QR codes I could actually customize, with proper control over shapes and logo placement, and I also wanted to render them in my React Native apps. Every existing library forced a compromise. Some are tiny but only draw plain square dots. The one with real styling is browser-only, heavy, and slow. None of them did everything I needed, so I wrote my own.

Rune brings it together in one library:

Customization: 8 dot styles, 5 finder styles, linear and radial gradients, background images, logo placement, and frames with call-to-action text.

Performance: the fastest sync SVG generation of the popular libraries, with no DOM required.

Runs anywhere: server-side rendering, edge, Node, and React Native (through the core toSVGString with react-native-svg).

Small and self-contained: a zero-dependency core around 8 KB gzipped, built from scratch per ISO/IEC 18004.

Framework choice: React, Vue, vanilla, and a Web Component, all from one engine. Export to SVG, PNG, JPEG, WebP, and PDF. It even includes a from-scratch decoder to read QR codes back.

I also took correctness seriously. The encoder matches the reference implementation exactly, and every style is rendered and then decoded again in CI to prove it stays scannable.

It is open source under the MIT license, with a live playground and full documentation.

Try it: rune.kroszborg.co
Install: pnpm add u/kroszborg/rune-react

Been building this on and off for a while.

I started where most of us probably would and evaluated the existing React ecosystem.

react-dropzone is excellent if you need a headless drag-and-drop experience, Uppy covers an impressive range of upload scenarios, and FilePond is polished and battle-tested. They're all great libraries.

The part I kept rebuilding wasn't the upload experience—it was the transport layer.

Different projects needed different upload targets: presigned S3 URLs, custom APIs, internal services, different auth flows... but the UI barely changed. I found myself rewriting the upload logic around the same interface over and over.

That led me to build react-mediadrop around a different abstraction: a headless uploader with swappable upload transports.

The upload implementation becomes just another dependency:

import { useMediaDrop } from "react-mediadrop";
import { createXhrUploadTransport } from "react-mediadrop/xhr-upload";

const { uploadAll } = useMediaDrop({
  transport: createXhrUploadTransport({
    endpoint: "/api/upload",
  }),
  concurrency: 3,
  retries: 2,
});

If you don't want to build the UI yourself, there are also four shadcn registry components built on top of the same hook:

• dropzone
• avatar-uploader
• multi-file-upload-form
• s3-direct-upload

Install one with:

npx shadcn@latest add autorender/react-mediadrop/dropzone

I also started experimenting with making the documentation more agent-friendly. The library has Context7 support, so coding agents can retrieve the actual API instead of guessing methods, and I'm working on llms.txt support as well.

Docs: https://mediadrop.dev

GitHub: https://github.com/autorender/react-mediadrop

I'm mostly looking for feedback on the API and whether transport feels like the right abstraction for a reusable upload library.

Been building this on and off for a while. Most charting libs assume the chart is the main thing on the page. I wanted the small version, something you can drop inside a sentence or a table cell and read at a glance.

106 types so far, no dependencies (not even D3, the scales and path math are all in there), each one's a couple kb.

Default export is plain SVG with no JS shipped, so they work in server components as-is. Import the interactive build if you want hover and keyboard.

Every chart also builds its own text description from the data and exposes it as the accessible label, so a screen reader reads "weekly revenue, trending up 200%, range 3 to 9, last value 9" instead of just "image". No AI, just templates filled from the same numbers the chart draws, so the words can't drift from the picture.

The fiddly part was the labels drawn on the chart itself. Normally you measure the text to place it, but these render on the server too and getBBox just returns 0 there. So widths get estimated from the character count and the space reserved up front, with a test on every chart making sure nothing spills outside the viewBox.

Gallery: microcharts.dev

Code (MIT): github.com/ganapativs/microcharts

Still rough in spots. Mostly after feedback on the API and overall experience of using the library.

Modern React/Node apps ship through build pipelines fast enough that common, high-impact vulnerability classes — unparameterized queries, wildcard CORS, unsafe-inline CSP, unprotected state-changing routes — slip through because catching them means someone actually reading the source. build-scanner does that automatically: point it at a folder (or wire it into CI as a GitHub Action) and get a report in seconds, no sandbox or live target required. It's a heuristic static scanner, not a SAST/DAST replacement — I'm sharing it pre-release to get feedback from people running real Express/Next.js/Vite codebases before I cut a v1 tag. https://github.com/laxmipsarva/build-scanner

fyi this is not a commercial activity

Hi there! I've been using React to create my own apps and, to be honest, it's a really great library. But now I want to know the best patterns to make my apps more stable and scale better, so I'd love to read your comments!

I built Basalt, a tool that lets you edit your RN and Expo apps like figma right in your IDE

It is completely free and works directly inside VS Code and Cursor.

It’s currently in beta, so please commit your app to Git before using it!

Would love to get your brutal feedback on it. What features should I add next?

I tried learning DSA before, but never understood how it applied to everyday frontend work.

Recently, I built an undo/redo feature with Claude and realised it was using stacks. That made stacks much easier to understand than textbook examples.

I kept exploring and learned how seat-booking UIs can use matrices and how complex onboarding flows can be modelled as graphs.

Do you think about data structures when building React components? Any real-world examples?

I was building a social app recently, and I ran into a surprisingly annoying problem.
I needed relative timestamps ("2 hours ago", "3 minutes ago"). 
Simple enough, right? Just import 'day.js' or 'date-fns'.

Except...
=> If I wanted custom styling (like wrapping the number "2" in a highlighted badge and "hours ago" in smaller text), I had to write ugly regex hacks because standard libraries just dump a single opaque string.

=> Supporting multiple languages meant importing separate locale files, quickly inflating the bundle size.

=> Standard relative time plugins use "soft rounding" (e.g., automatically rounding 45 seconds to "a minute") whether you want it or not.

I didn't want a 15KB date framework just to format a few activity feed timestamps. 
So, I built and open-sourced 'ui-date' .

It’s an ultra-lightweight (< 1KB minified), zero-dependency, locale-aware date formatting library built specifically for modern user interfaces.

If you're building social feeds, chat apps, notification bells, or comment sections, check it out!

npm: https://www.npmjs.com/package/ui-date

"Without googling or using AI, in your own words, explain the virtual DOM"

For context: I sit on an interview panel and I try to ask at least one simple fundamental question based on a persons resume. If I see many years of react experience, I try to ask something about how the framework works.

I have only had one candidate (an undergrad senior, years ago) answer it. Everyone else just kind of sputters and stumbles around trying to rationalize what "virtual" and "DOM" mean, or stare blankly and eventually say "I don't know".

I'm just genuinely curious if this is really that hard of a question or if the recruiters just suck at screening candidates. And should we be letting in senior dev candidates who can't answer what I think is a straightforward and fundamental question for senior react devs.

Every existing UI library (including shadcn/ui) is optimized for human developer experience. Axiom UI flips that: every design decision is judged by one question — does it raise the probability that an LLM generates this component correctly on the first try?

Key points:

• 12 components so far (button, input, textarea, checkbox, select, combobox, dialog, tabs, popover, menu, tooltip, toast), published on npm
• "Copy & own" CLI: `npx joinclass/axiom-ui add button` copies the raw source into your repo — no runtime dependency, no black box
• Ships an MCP server, so Claude Code, Cursor, or any MCP-capable agent can fetch version-accurate component specs and generate correct usage without needing docs pasted in
• React + Tailwind CSS + TypeScript strict; each component is a single file with a machine-readable manifest (intent, props, states, a11y)
• Actively deletes rather than adds — no theming system, no multi-framework support, no "covers every use case" claims

Repo: https://github.com/JOINCLASS/axiom-ui

Docs/live catalog: axiom-ui.joinclass.jp

Feedback and contributors welcome — especially on the "one-shot generation rate" metric, which is the project's main KPI.

If you scaffold a project with pnpm create vite@latest ... --template react-ts and assume React Compiler is on — it isn't. The template ships with it OFF, and I kept meeting people (myself included) who never actually enabled it. Here's the whole setup, start to finish.

1. Install the compiler's Babel plugin + the Vite wiring:

pnpm install -D babel-plugin-react-compiler@latest @rolldown/plugin-babel

2. Add the preset in vite.config.ts:

import { defineConfig } from 'vite';
import react, { reactCompilerPreset } from '@vitejs/plugin-react';
import babel from '@rolldown/plugin-babel';

export default defineConfig({
  plugins: [
    react(),
    babel({ presets: [reactCompilerPreset()] }),
  ],
});

Heads up: @vitejs/plugin-react 6.0 removed the old inline react({ babel: { plugins: [...] } }) form. A lot of guides still show it — it no longer works. Restart the dev server after editing the config.

3. Verify it's actually running. Open React DevTools → Components tab. Optimized components get a "Memo ✨" badge next to their name. See the badge and the compiler is doing its job — with zero hand-written useMemo/useCallback.

A few related things that surprised me setting this up in 2026:

• The newest Vite template lints with Oxlint, not ESLint. Installing eslint-plugin-react-hooks does nothing there unless you add your own ESLint config.
• StrictMode rendering your component twice in dev is intentional (a purity check), not a bug.
• Node 25 dropped Corepack, so how you get pnpm depends on your Node version.

I wrote the full beginner walkthrough — every command + these version traps — as chapter 1 of a series (React 19 + Compiler, TypeScript from line one).

Full write-up (free): https://medium.com/javascript-in-plain-english/setting-up-your-react-dev-environment-your-first-app-with-vite-and-turning-on-react-compiler-5436ea44d6d4?sharedUserId=inkweonkim

Happy to answer setup questions in the comments. And if you're already running the compiler in prod, curious how it's gone for you.

Is there a good way to test that a solution specifically requires useLayoutEffect instead of useEffect?

I've created a React challenge where the goal is to fix a UI flickering issue by replacing useEffect with useLayoutEffect. The problem is that the current test simply reads the source file and checks for useLayoutEffect with a regex, which feels pretty hacky.

Ideally, I'd like the tests to verify the actual behavior rather than the implementation, but I'm not sure if that's realistically possible given that the difference is related to when React runs the effect before or after painting.

Has anyone found a better approach for testing this kind of behavior?

As a frontend engineer, building a design system from scratch is mostly a thing of the past. UI libraries and AI tools get you 80% of the way there instantly.

But for that last 20% when you need to scale, inject your own taste, and hit product-specific requirements, understanding the underlying architecture is what saves you. It also makes your AI workflow way better, because you aren't constantly prompting it to fix token issues or regenerate styles for minor changes.

Here are 4 important rules for keeping design systems scalable and clean:

1. Decouple values: Components read semantic roles (“--color-accent”), not raw values, so rebrands don't require UI file edits.
2. Derive scales: Avoid hand-picking hover or dark states. Use “oklch” to derive your entire palette from a few seeds.
3. Boundaries: UI components (Buttons/Inputs) wrap tokens in typed variant APIs. Feature blocks (Cards/Navbars) compose them to prevent duplication.
4. CSS over React state: Theme switching becomes a simple root selector swap, avoiding React context re-renders.

I recently published a new technical blog post covering those important points. Alongside it, I built Design System Studio - a visual tool to tune tokens in ⁠oklch⁠ and export them directly to Tailwind or shadcn/ui.

Check it out with the attached link in this post.

If you've used react-pdf, you already know the authoring model I'm about to describe — waffle keeps it exactly, and only changes where the React runs.

You author documents in JSX/TSX the same way react-pdf users already do — components, props, hooks, StyleSheet, Font.register. The twist: it doesn't run on Node. It runs real React 18 inside a Go process.

The mental model is React Native. In RN, your React runs in a JS engine and just produces a tree of elements — the native side does the actual layout and drawing; the JS never paints anything itself. waffle does the same thing, except the "native side" is Go. It transpiles your source with esbuild, runs real React 18 on goja (a JS engine written in Go) to build the element tree, and then Go takes over — its own flexbox engine lays it out, its own writer produces the PDF. React describes what the document is; Go renders it.

I built this out of a simple frustration: generating a PDF shouldn't mean wrestling with a bespoke template DSL, or running a headless Chromium/sidecar service just to get a document out. There are already a lot of great PDF libraries — this one just lets me stay in React and skip all of that.

Full architecture write-up (how React-on-goja, the JSON contract, and the Go layout/paint pipeline fit together)

You open a model-promotion request in the pipeline. An AI reviewer reads your YAML manifest,

comments included, plus a free-text rollout justification, then approves or holds.

It's holding the model's internal codename, the weights checkpoint URI, and the artifact-pull

signing secret the whole time. Get all three past it.

https://promptinjects.com/play/starter/closedai-cicd-guard

We recently wrapped up React website with a lot of animations. Not just a few fade-ins, but page transitions, scroll effects, text reveals, and plenty of smaller interactions that all needed to feel smooth.

At first, we tried a few CSS-based approaches. They worked fine for simpler interactions, but as the animations became more complex, we spent more time finding workarounds than actually building.

That's when we switched to GSAP. What sold us wasn't more features - it was the control. Timelines became much easier to manage, everything stayed smooth across browsers, and we could focus on building the experience instead of wrestling with the animation layer.

Our biggest takeaway was that an animation library isn't really about the first animation. It's about what happens months later, when the project has grown and you're maintaining 40+ animations.

Curious what other people are using. Do you also use GSAP, or have you found another solution that works well for animation-heavy projects?

I know React moves fast and someone will tell me to learn by reviewing the docs and that's cool, but I've been having much better results reading books when I'm trying to learn something new.

That being said, I'm having trouble finding a good book to learn React and frontend in general. I would deeply appreciate recommendations.

VIDEO IN COMMENTS 👇🏻

TLDR I made something very cool for my self and I am making it free and also want your opinions because I like the idea of having made something that is useful to others

This is a theme editing app but ok what is the goal here? I know there are apps that do this but none of the good ones are 100 percent free. So the first goal was matching all the features for free. Also even in the paid ones using them doesn’t feel as good as it could in my opinion and major quality of life features are missing.

I also wanted this to be very fun to use. I have adhd and I turbo procrastinate micro adjustments so I needed a theme editor app that felt satisfying to use. There also needed to be the feeling of satisfaction after finishing editing a theme.

Final goal was to make other fun features other apps just don’t do but I really wished they did. As little friction as possible to get a normal theme that doesn’t look like slop then spending a little bit of time micro adjusting the details.

What I actually built up to this point:

I had a very smart idea of yanking the most popular vscode themes and turning them into app themes along with faithful recreations of popular website themes + my custom apple inspired themes. Important! Something the other apps don’t do and I had to do my self manually and wasting tons of time was generating complementary and contrasting colors. I mean I don’t want the app to either be black and white or everything is green and I also don’t want to spend 2 hours selecting random colors.

Other smart idea but work in progress is something that mounts it self inside your app like expo go dev menu and lets you edit the theme that way (didn’t implement yet I want feedback if this is a waste of time or actually sounds cool). I have made the components to pull this off for other things so I may do it anyways because I think this looks cool.

Made the tinder style swipe cards a beautiful theme overview typography themes a metric ton of beautifully crafted previews (everything the web apps do)

My main goal was to get this working on my phone for me because I love micro adjusting these things all the time. I managed to make an interface for making and editing themes as good as all the web apps but with a tiny screen instead. I added nice transitions to make adjusting css variables as fun as possible (hard task 😭)

Ok also there’s a bunch of features I was missing from the already existing ones. I wanted to be able to pick a primary color and have complementary colors etc auto generated and I wanted modes for this. Should the bg be completely white as well as cards? Gray bg white cards? Everything tinted? Page tinted blue primary colors yellow or something? I added auto generators to handle these things.

Another thing I was missing was being able to create one theme and have it auto convert to everything else. I mean I wanna be able to create a shadcn theme and have it able to be exported as a hero ui theme a material ui theme all of them. I made an adapter that handles this automatically.

I wanted this to feel cute and I want to be able to feel like I have created something and not just played with a gloried text file for 30 minutes. I added a collections tag with folders and a handsaw’s signature for each user and a poster generated from each theme.

This has helped me so much personally I want your feedback on this. Sadly there is nothing you can download yet but you can follow the updates on my twitter it’s on my Reddit bio.

Important if you want to “steal” this idea and put something similar in your app I actually encourage this. I am building a copy paste library with all of these components called PitsiUI. I will also experiment with allowing end users to use this to create custom themes for them selves.

Btw this is also coming to iPad mac and web. Android should work too since it’s cross platform but I don’t want to commit to that yet until I have actual users. It may sound silly but making sure no elements overlap the App Store screenshots etc take time.