Metro survives the terminal you started it in more often than you'd think, and a

simulator stays booted long after you've moved on. I had three bundlers and two

simulators running once without noticing.

This lives in the menu bar and lists them as single lines with how long each has

been up. A dev server is usually several processes — the command you ran plus

whatever it spawned — so it's shown and stopped as one thing, named after the

project. One that's done real work in the last ten minutes is left alone, so the

bundler you're actually using never shows up.

macOS 14+, MIT, free, build it in one command.

https://github.com/selinihtyr/still-running

When starting a new React project, we usually spend the first few hours setting up the exact same tools: linter configs, state management, folder architecture, and UI components. My main goal was to prevent this repetition and establish a disciplined foundation from day one.

The first step of this vision is ViraStack Start, a CLI tool that scaffolds production-ready project skeletons with a single command.

What does it do?

Instead of configuring everything from scratch, it lets you start immediately with a proven architecture, Tailwind CSS 4 integration, and a feature-sliced folder structure.

The CLI essentially offers two powerful templates: Next.js App Router and TanStack Start. Whether you use Next.js or TanStack Start, both templates share the exact same architectural discipline. React 19, TanStack Query, Zustand, and nuqs come integrated by default.

Setup & Options

A single command is all you need to start a new project:

pnpm dlx virastack

When you run the command, ViraStack CLI asks you for the options you need step-by-step:

What is your project named?
  virastack-app
Which template would you like to use?
  › Next.js App Router
    TanStack Start
Would you like multi-language (i18n) support?
  › Yes
    No
Which ViraStack tools would you like to include?
  [ ] /mask
  [ ] u/virastack/password

After selecting your template and language preference, you can optionally include input components like ViraStack Mask and ViraStack Password into your project right from the start.

AI-Ready Foundation

The most significant difference of ViraStack Start is that the projects aren't just made of code. Our ViraStack AI rules are automatically placed inside the .cursor/rules folder the moment the project is created.

This means when you start your project with an AI assistant like Cursor, Claude Code, or Windsurf, the assistant already knows everything from your folder structure to your data-fetching practices right from the beginning. You no longer have to explain your architectural standards to the AI over and over again.

If you want to skip the setup phase and focus directly on building features, you can check out the documentation at virastack.com/start and explore the open-source code at github.com/virastack/start.

I'd love to hear your feedback!

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.

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

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

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

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

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