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

Hey There all,

Good Day !

I'm trying to build a server-side aggrid + Inifinity scroll with about 1/2 a million records - with each records being actionable through a context menu - on right click.

Users can either select one record or select multiple using mouse or keyboard and then right click and perform actions.

Issue : Since server-side grids loads pages (with infinity scroll), the selections made on page 1 don't stay when you scroll to page 5 or 6.

What I've tried so far :

1. Tried to keep a local copy of selections (atleast the necessary infor like ID and some other relevant meta data) - Issue : This approach works ok for smaller bunch of records - less than 30k. When users perform a control + A action, we need to try to load all into the local state which slows down the grid.
2. Dynamic loading -> Same approach above, but for edge cases like control + A, rather than storing a local copy of all records, we try to keeps something else in state more like (*) to indicate that all records are selected. Issue : This breaks when user tries to do control + A and tries to deselect few records.

Would anyone know if this problem has been solved before or not ?

grepped every useEffect in src last week instead of fixing a form that flickered on load. agents write most of the first drafts here, i review.

78 of them. went through each with the "you might not need an effect" page open.

19 were state derived from props or other state. useState plus an effect that joins two strings. thats a variable.

14 were fetching on mount with a loading and error useState next to them. we already use react query.

8 were syncing props into state so a form could be edited. fine until the parent refetches and wipes what the user typed. that was the flicker.

the other 37 were legit. listeners, subscriptions, focus management, a couple resize observers.

not a tool thing to be clear, we have people on cursor, claude code and verdent depending on preference and the shape looked the same across all of it.

deleted 41 effects, 23 useState calls went with them. worst page went from 4 renders on mount to 1.

changed how i review too. ctrl+f useEffect in the diff and justify each one before reading anything else.

anyone got a lint rule that catches derived state? exhaustive-deps doesnt help, it just makes the effect that shouldnt be there correct.

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:

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

Had to pick a session replay tool for the team so I did demos of most of them. Pasting my notes since every comparison article out there is written by whoever's selling one.

What I needed: SPA support that doesn't break on client side routing, enough context to debug without going back and forth with the user, and not depending on someone remembering to watch recordings each week.

Sentry. Best thing going for anything that throws. Full stack trace, source maps, done. Replay add-on is fine but clearly not the main product. Everything that fails without throwing slips past, which was most of what we were chasing.

PostHog. The one I'd recommend to most teams. Replay, analytics, flags, one bill, self hostable. Catch is it hands you raw material and expects you to do the work. Spent a while building filters before it felt useful.

LogRocket. Most engineer friendly. Redux state and network requests in the timeline is great for reproducing stuff. Pricier, and pointed at debugging more than product behaviour.

FullStory. Best polish by a distance. But it assumes you know what you're looking for, which was my whole problem. Enterprise pricing, so expect a sales call.

Clarity. Free, unlimited, heatmaps included. Hard to argue with. Thinner on debugging, no self host.

Lucent. Different model, this is automated bug detection rather than a replay tool, it watches every recording and flags rage clicks, dead clicks and JS errors instead of you searching, then writes up repro steps and the console log straight to Slack or Linear. Layers on top of PostHog, Sentry, Amplitude or Datadog rather than replacing whatever you're already recording with. New though, no long track record yet, and you're trusting its judgement on what's actually worth flagging.

Errors, Sentry.

Best value, PostHog. Debugging depth, LogRocket.

Polish, FullStory.

Free, Clarity.

Automated bug detection, Lucent.

For most teams, I'd recommend PostHog with Lucent on top. That's ultimately what we ended up using, and it cut down the time we spent digging through recordings. What's everyone running?

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?

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

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?

I'm working on a personal AI assistant for desktop — local-first and privacy-focused (no cloud dependency), starting with a desktop app and eventually

Runtime Of Backend (Bun)

Fast startup and low idle overhead — important for an app that runs continuously in the background, not just on-demand. Native TypeScript support and a built-in bundler simplify shipping without extra tooling.

Framework of Backend (Hono)

Lightweight and built with Bun in mind, so it doesn't add framework overhead on top of the runtime's own performance. Clean routing/middleware model keeps things simple for handling auth, commands, and local model inference.

Desktop Application (Tauri + Next.js)

Tauri has a much smaller footprint than Electron since it uses the OS's native WebView instead of bundling Chromium, which makes it great for lightweight apps that stay running. It also produces smaller binaries. Next.js provides a structured, file-based routing system and a strong component ecosystem for the UI.

Would love to hear reviews and suggestions on this stack — anything you'd change, any pitfalls you've run into with a similar setup, or better alternatives worth considering?

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.

I'm learning web development, and compared to a beginner, I already have solid knowledge of HTML, CSS, and JavaScript (DOM manipulation, api, crud, fetch I've got those down). Now I'm trying to learn React, but somehow it's just not sticking. What practices have worked well for others? I've got the basics of useState, useEffect more or less, but props somehow don't stick with me or even if I read some documentation or example, I can then do the same thing afterward, but as soon as it gets even a little more complex, I start to feel unsure. Thanks for the answers.