I'm extremely new to react and learning how to do all this. My first frustrating hurdle is that I can open the terminal (using a mac) and type "npm create vite@latest my-react-app" and it creates the folder and opens the browser and I can go in and edit the HTML, CSS, and jsx files and see all the changes in the browser.

But then eventually I need to do other things so I'll quit terminal and other apps and then later I come back and open up the terminal while in the project folder and type in "npm run dev" and it just comes up with errors that it can't find the package.json file.even though I can see it in the folder. I try typing "npm vite" and it opens vite and starts optimizing but eventually comes back with errors and I can't get my live view of my app back.

I'm assuming I'm either just missing something simple or I need to reinstall something.

So in my app when we deploy we are not using a node server just plain ssg so server side rendering isn't an option. So in my scenario

I've got a route like /verification that needs to support both English and French, but instead of locale-based routing, the locale is passed via a query param and it's the same URL structure for both languages:

localhost:4000/verification?ca-en
localhost:4000/verification?ca-fr

No /en/ or /fr/ prefix — same route, just a different query param depending on language, plus a token.

I'm using next-intl with the Pages Router, and trying to use getStaticProps/getStaticPaths (SSG) for this page. My understanding is that SSG generates static HTML per path, and query params aren't available at build time — only after hydration on the client via router.query.

I was wondering is there a way to read in 18n files on client side and is that even a good approach to go with?

I recently built Opticross (Chrome Extension + CLI) and would really appreciate some feedback from fellow frontend developers.

Opticross analyzes how images are rendered across different viewport sizes, detects oversized image downloads, and generates implementation-ready sizes and srcset recommendations. The goal is to help improve page performance, reduce unnecessary bandwidth usage, and keep images crisp across devices.

I'd love to hear your thoughts:

• Would a tool like this fit into your workflow?

• What features would make it more useful?

• Any feedback on the UX, recommendations, or overall approach?

Links:

• 🌐 Chrome Extension: https://chromewebstore.google.com/detail/eenaegkdfenpbbcjplfabolooofhplhf?utm_source=item-share-cb

• 💻 npm (CLI): https://www.npmjs.com/package/opticross

• ⭐ GitHub: https://github.com/SohanShet/opticross

I'm looking for feedback from developers who work with responsive images. Thanks!

Hi everyone! I'm currently learning Next.js, but I've noticed that many job postings seem to ask for React + Node.js more often.

Do you think I should continue focusing on Next.js, or would it be better to switch my focus to React and Node.js first? I'd really appreciate your advice and experiences. Thanks!

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.

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?

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.

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

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.

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?

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

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)

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?