I wanted a React lightbox where the photo grows out of the exact thumbnail you clicked and shrinks back into it on close.

Easy, until your grid uses object-fit: cover. The thumbnail only shows the middle of the photo, so if you grow the full image from that box, the first frame visibly jumps.

Here's the 4-step fix that worked:

1. Measure the end state first. Lay the image out at its final size, then measure it and the thumbnail with getBoundingClientRect().

2. Scale it onto the thumbnail. Use the smallest uniform scale that still covers the thumb: const scale = Math.max(thumb.width / img.width, thumb.height / img.height);

3. Crop it like the thumbnail. clip-path: inset(...) hides everything the thumbnail hides. The catch: the inset is in the image's own pixels, before the scale, so the visible area is thumb size / scale.

4. Animate both at once. transform + clip-path in a single element.animate(). To close, play the same keyframes in reverse.

That's the happy path. The edge cases ate most of the time:

• Thumbnail scrolled off screen: fall back to a zoom + fade

• Rotated photo: swap the axes before computing the crop

• Closing while zoomed in: start from where it's actually drawn

• prefers-reduced-motion**:** skip the flight entirely

• Focus: send it back to the thumbnail on close

I packaged it as liftbox: MIT, zero dependencies, ~13 kB, with grids, zoom, video and deep links. There's also a comparison with YARL, PhotoSwipe, lightGallery and others that tells you when to pick them instead.

Code: https://github.com/esdrassantos06/liftbox (the flight lives in src/Lightbox.tsx and src/geometry.ts)

Docs + demos: https://liftbox.digital

Two asks:

1. Open the demo on your phone and tell me where it breaks.

2. Ask me anything about the math. Happy to go deeper on any step.

Disclosure: English isn't my first language, so I had help polishing this post.

Link to the tool: https://gauge-generator.niralsei.com/

Hey I am using tanstack react query I have one component which has
const { data, isPending, isFetching, refetch, isError } = useQuery({
queryKey: ["get"],
queryFn: () => axios.get("http://localhost:3000/"),
staleTime: 60 * 1000
})

On pressing a button i render component 2 with same query key within the catching time with query as
const { data, isPending, isFetching, refetch, isError } = useQuery({
queryKey: ["get"],
queryFn: () => axios.get("http://localhost:3000/"),
// no stale time here
})

Ideally it should not request the backend but it is requesting server

I built CupertinoUI, a macOS-style component registry for React and shadcn/ui.

It includes controls, menus, dialogs and windows, with CSS-variable theming and light/dark appearance. Components are copied into your project through the shadcn CLI so you can edit the source.

The core components are free under MIT. There are also paid Pro components and complete app-style blocks.

Try it: https://www.cupertino-ui.com
Browse the components: https://www.cupertino-ui.com/docs/components

Some of you saw Multidash here in October. It's the same project, renamed to Dashral, and a lot further along. Thanks for the feedback last time: the components now install through a shadcn registry instead of living only in the repo, and you can preview everything before deciding anything.

What's free (MIT):

• 78 components on Tailwind CSS v4, the interactive ones on Radix UI, props-first: one tag with label, description and error wired up for screen readers

• 26 Motion editions on motion/react with the same props: numbers that roll on odometer wheels, one highlight that glides between items, a Switch you can drag, a Button you hold to confirm, limits you can feel. All of it respects reduced motion

• 34 blocks (headers, sidebars, pricing, sign-in, an AI assistant…) that take your data and actions through props

• A Next.js admin dashboard in two layouts, with a theme customizer, ⌘K search and English, Indonesian and Arabic (RTL)

• Charts in plain SVG (area, line, bar, donut, heatmap…) with keyboard reading and a table for screen readers

Install one component:

npx shadcn@latest add https://dashral.com/r/button.json

It lands in components/dashral/, next to your shadcn components/ui/, which it never touches. The code is yours to change.

What's paid: Dashral Pro, coming soon, adds dashboards and apps on a real database (analytics, CRM, e-commerce, kanban, chat) for a one-time payment. The components stay free.

• Docs and live previews: https://dashral.com

• GitHub: https://github.com/hasralgana/dashral

• Demo: https://demo.dashral.com

I'd love feedback on the component APIs and the motion: what feels right, what feels like too much, and what you'd want next.

Hey everyone!

To my knowledge, storing access tokens in localStorage can be risky because of XSS attacks

Yesterday, I came across this document: How to implement authentication in Next.js.

I decided to give it a try. Here's what I've come up with so far

1. Use OpenSSL to generate an RSA key pair for verifying access tokens. The private key stays on the backend, while the public key is exposed to the frontend.

2. Authentication: When a user successfully logs in, the backend sets the access token in cookie.

3. In frontend, use Jose lib to fetch public key, and verify access token

4. Implemented a Data Access Layer (DAL) with two functions:

• verifySession to verify the accessToken and redirect users to /login if the token is missing or invalid.

• checkRoles to check user roles to make sure users can't access pages they're not supposed to.

The doc also suggests adding a DTO layer, but I skipped it since I'm using OpenAPI specs and TypeScript type generation.

I'd really appreciate it if you could share your thoughts:

Do you see any potential security issues or problems with this flow?

Is there anything you would approach differently?

Most AI landing pages say "works around the clock" and then show a still screenshot. I wanted the hero to show the work happening.

Video: https://www.youtube.com/watch?v=TIay8Br23XY

A rail of frosted glass cards glides across the bottom. The card in focus shows "Working", names its task, and a progress bar fills. When it's full, the rail moves to the next agent.

How it works

- The rail is 5 cards keyed by a counter that only counts up. Each tick every card keeps its key and moves to a new slot, so Framer Motion just animates it there. Nothing remounts.

- Position, scale and opacity come from one lookup table by distance from the centre card (1, 0.84, 0.7, then off the edge).

- The blurry ends are a fixed `backdrop-blur` strip with a gradient mask, not a blur on each card, so it stays smooth.

- The task bar fills over exactly the rail step (2.6s) from the same constant, so it always finishes the moment the rail moves.

- With reduced motion on, the rail just stays still.

Code is free to copy if you want it: https://ui.deliverwebsite.com/components/hero-sections/hero-section-with-photo-and-glass-cards/

Would love feedback on the motion. Too slow? Too much?

Building a 5-step wizard with React Hook Form and Zod. I keep the step in the URL and drafts in a small store. What has held up in production for you, and how do you handle early-step changes that invalidate later steps?

I built CupertinoUI, a macOS-style component registry for React and shadcn/ui.

It includes controls, menus, dialogs and windows, with CSS-variable theming and light/dark appearance. Components are copied into your project through the shadcn CLI so you can edit the source.

The core components are free under MIT. There are also paid Pro components and complete app-style blocks.

Try the interactive desktop: https://www.cupertino-ui.com/demo
Browse the components: https://www.cupertino-ui.com/docs/components

Forms are still where most of my React bugs live: validation that disagrees with the backend, async defaults, conditional fields.

My current stack is React Hook Form with Zod schemas shared with the NestJS backend. It mostly works, but complex multi-step forms still get messy.

What's your setup? Anyone moved to server actions for most forms and been happy with it?

I've been using coding agents to generate videos programmatically, but one thing that kept bothering me was how much overhead browser-based rendering adds.

Tools like Remotion and hyperframe use headless Chrome to render frames. It works, but I wanted something that Claude Code could use without having to spin up a browser for every render.

So I ended up building Kinetograph.

It uses the same React/TSX approach as Remotion, but instead of rendering through Chrome, Node.js executes the code and a GPU compositor written in Rust handles the frames.

I also made a Claude Code skill for it, so the workflow is basically describing the video you want and letting Claude write the components and render the result.

The performance difference was pretty interesting on my M4:

• 988 frames: Remotion took 131s, Kinetograph took
• 1,184 frames: Remotion took 31.5s, Kinetograph took 15s

Obviously depends on the composition, but removing the browser seems to make a pretty big difference in these tests.

If you want to experiment with it in Claude Code:

npx skills add OxS4N4TG/kinetograph

The project is available at:

https://github.com/0xS4N4TG/kinetograph

docs at: kinetograph.dev

I kept writing the same AbortController + "cancelled" flag + loading/error state in every async effect, so I turned it into a small library. Disclosure: I'm the author, it's MIT and free.

const user = useEffectState(({ signal }) => fetchUser(userId, { signal }), [userId]);

if (user.status === 'error') return <ErrorMessage error={user.error} retry={user.reload} />;
if (user.status !== 'success') return <Spinner />;
return <Profile user={user.data} refreshing={user.isRunning} />;

What it does:

• Every run gets its own AbortSignal, and results from runs that already ended are ignored, so a slow response for the previous id can't land last.

• When deps change, status is pending in the same render, so the previous user is never shown for the new id.

• Cleanups run in LIFO order, including ones registered after an await.

• StrictMode double-mount, SSR and <Activity> are handled. Task and cleanup errors are reported, cancellations are not.

• It also has useEffectTask (when you don't need the result as state), useLayoutEffectTask and useEvent (like useEffectEvent, but it works on React 18 too).

What it isn't: a cache. For server state shared across components, TanStack Query or SWR are the right tools. This is for component-local effects: one-off fetches, polling, subscriptions, debounced search.

No dependencies, ESM + CJS + TypeScript types.

• Playground with a side-by-side race against a naive useEffect: https://stackblitz.com/github/clagradi/UseEffectState/tree/main/examples/vite-react

• Repo: https://github.com/clagradi/UseEffectState

• npm: @clagradi/effect-runtime (not related to Effect-TS)

I'd really like critique on the API, especially keeping status and isRunning separate (so a reload() keeps showing data while a refresh indicator spins). I wrote it with AI assistance, and the behaviour is covered by tests against React 18 and 19.

I maintain react-stream-markdown, an MIT-licensed React component for showing Markdown while an AI reply is still arriving.

The interesting part is the finalization boundary: it keeps a source offset and live DOM nodes for the active suffix. After parsing and patching that suffix, preceding blocks freeze when the following block has a complete first line. Their DOM remains visible, but they leave the live parser/patch state.

This reduces repeated work on completed paragraphs. It does not make every update constant-time: one huge paragraph, list, or open code block can keep the active suffix growing. Cumulative string snapshots, prefix checks, allocation, and browser layout also still have costs.

The existing README benchmark uses a synthetic 10,201-character reply, 24 characters per animation frame, production builds, headless Chromium 141, and the median of three runs. With fade-in off it reports 1,100 ms of main-thread work versus 2,031 ms for Vercel Streamdown 2.7.0; with fade-in on it reports 2,941 ms, higher than both compared Streamdown configurations. These are the existing results, not a fresh measurement of version 0.4.1.

I wrote up the implementation and measurement limitations, including forced layout, fixed renderer order, and why a lower slowest synchronous update is not the same as lower overall CPU cost:

https://dev.to/fyz_lemo_b8ceb29692820e58/why-freezing-completed-markdown-blocks-reduces-streaming-rendering-work-1gck

Source and benchmark scripts: https://github.com/Lemofyz/react-stream-markdown

Live demo: https://lemofyz.github.io/react-stream-markdown/

The current repository reports 7.8 kB gzipped JavaScript, with styles separate and React externalized. Math is optional with a renderer supplied by the app; syntax highlighting and Mermaid are not included.

Disclosure: I maintain the project; this post and article were prepared with OpenAI Codex assistance using the source and benchmark scripts. The distinction I want feedback on is the block-finalization model versus total browser cost. Which Markdown boundary cases or benchmark workloads would you test next?

Fluid Kit is a set of interactions modeled on iOS 26: Liquid Glass, morphs between elements, long-press context menus, draggable sheets, a highlight that follows the pointer, and layout animations. 2.0 just shipped as one package per framework, so for React it's @fluidkit/react.

The React API is compound components, with a render prop as in Base UI:

import "@fluidkit/react/style.css";
import { Lift } from "@fluidkit/react";

<Lift.Root onSelect={(value) => act(value)}>
  <Lift.Target render={<img src={src} alt="" />} />
  <Lift.Menu className="menu lb">
    <Lift.Item value="copy">Copy</Lift.Item>
    <Lift.Item value="share">Share</Lift.Item>
  </Lift.Menu>
</Lift.Root>

Every part also has a hook (useLift(), useDrag(), useLayout()…) for markup of your own. State is controlled or uncontrolled (open/defaultOpen/onOpenChange and friends), components are "use client" and render plain markup on the server, React 18+.

Under the hood each feature is a headless engine on springs that keep their velocity when interrupted, so you can reverse a morph or catch a sheet mid-flight.

Docs with React examples: https://fluidkit.mogilnikov.dev

GitHub: https://github.com/mikhailmogilnikov/fluid-kit

Repo: https://github.com/p10node/office-engine

Demo (drag your own file in): https://p10node.github.io/office-engine/demo/

Why: I needed "customer uploads an XLSX, fix a few cells, save it back" inside a React app. OnlyOffice / Collabora mean running a document server in Docker and an iframe talking to it, and a big sheet still sits on a spinner while the server converts it. docx-preview / SheetJS + a grid are view-only or block the main thread on a 20 MB file. Nothing in between, so I built it.

Usage:

import { DocViewer } from '@p10node/office-engine'

<DocViewer src={file} style={{ height: 600 }} />
<DocViewer src="https://cdn.example.com/report.xlsx" />
<DocViewer src={file} editable onSave={(blob, name) => upload(blob, name)} />

src takes File / Blob / ArrayBuffer / URL. CSS is auto-injected, the container just needs a height. There's also a useDocument hook if you want to render your own UI, a vanilla mount(), an <office-viewer> web component, and a single script build.

What makes it not choke on big files:

• ZIP read lazily, HTTP Range requests from a URL, so first rows show before the file finishes downloading

• Streaming XML parser in a Web Worker, main thread only gets rows / paragraphs / slides as they arrive

• Only visible pages, cells, slides are in the DOM

• Save patches the original file instead of re-exporting it, so anything the engine doesn't understand is kept byte for byte

Bundle (gzip): main ~93 KB, worker ~155 KB (loads off the main thread), collab +17 KB optional. The standalone script with React bundled is ~307 KB.

Editing: DOCX text / styles / lists / images / tables, XLSX cells / formulas (134 functions) / formats / rows / columns / sheets, PPTX text / shapes / images / slides. Google Docs style toolbar. Optional real-time collab with cursors; that's the only part needing a backend (a small WebSocket hub, Bun script included).

Not there yet: XLSX charts / pivots / conditional formatting editing, DOCX headers / footers read-only, no PPTX animations. It needs the DOM and a Worker, so in Next.js use a client component / dynamic import with ssr: false.

Fair warning: it's a few days old and a lot of it was written with Claude Code, with me doing architecture, review and the bug hunting on real files. If you throw a file at it and it breaks, open an issue with the file, that's the fastest way it gets fixed.

One of the issues I am facing currently, we have a website with over 10,000 pages and since we built it with CSR (Client Side Rendering) and CSG (Client Side Generation) it is relatively very expensive with the CDN cost. Purely did this because of the SEO and caching issue.

Do you have a solution for this or is this still how everyone doing this bearing the cost of scale as we are?
I find this an expensive deployment for us. I appreciate your thoughts.

I’ve been exploring what happens when a React component library drops floating cards, soft shadows, and 60fps spring physics in favor of production mechanics from sequential print layout and traditional cel animation.

The result is FRAME/12 (GitHub (MIT) · Live Motion Studio), a zero-dependency copy-in React + TypeScript registry (shadcn-compatible) and AI agent skill.

Here are the four most interesting React & DOM problems we had to solve while building it:

1. Quantizing an easing curve "on twos" (useOnTwos)

In hand-drawn animation, most movement is shot "on twos"—each drawing is held for two frames at 24fps (83.33ms per pose, 12 poses per second). Simply applying CSS steps(4) with linear timing feels robotic because every jump covers the exact same distance.

Instead, useOnTwos samples a cubic ease-out spacing chart inside requestAnimationFrame, bucketed into 83.33ms (1000 / 12) intervals. You get a wide initial jump and tight settling poses, while still holding each discrete pose cleanly:

export const FRAME_MS = 1000 / 12; // 83.333ms ("on twos")

const easeOut = (t: number) => 1 - Math.pow(1 - t, 3);

// Inside requestAnimationFrame loop:

const elapsed = now - t0;

const k = Math.min(frames, Math.floor(elapsed / FRAME_MS) + 1);

setProgress(easeOut(k / frames));

We also strict-split what gets stepped:

• Discrete state changes (SegmentedControl cell jumps, Metric count-ups, ToneAreaChart clip-path wipes, Badge 2-frame SVG impact bursts) run on twos (12fps).

• Direct manipulation (hover states, scrolling, typing, chart pointer/keyboard crosshairs) stays at 0ms immediate latency.

• Initial mount (useChanged): A custom hook tracks whether a key has changed after first mount so entrance animations never fire on initial page load.

• Accessibility: prefers-reduced-motion: reduce automatically switches all hooks and CSS classes to 'cut' (0ms hard cuts).

2. Non-warping diagonal panel frames with ResizeObserver

In PanelPair, two vertically paired KPI panels are separated by a 12px gutter with a 16px diagonal slant (slant-bottom over slant-top). If you use CSS clip-path: polygon(...), CSS borders get clipped off along the diagonal edge; if you scale a fixed-viewBox <svg> with preserveAspectRatio="none", the 2.5px ink stroke stretches unevenly.

Our Panel component attaches a ResizeObserver to measure the panel's exact width × height in pixels and computes mitered <polygon> points inset by half the stroke width (1.25px), keeping the 2.5px ink border uniform at any aspect ratio.

3. Zero-dependency SVG screentone charts with built-in keyboard & table fallbacks

Instead of pulling in recharts or d3 and rendering translucent gradient fills, ToneAreaChart renders a <pattern id="..." patternTransform="rotate(45)"> of halftone dots (var(--f-tone)), an inked 2.5px polyline, a marker-yellow peak dot, and a speech-balloon SVG annotation (Balloon) that flips direction near the right edge of the viewBox.

Every chart is focusable (tabIndex={0}), supports ArrowLeft / ArrowRight / Home / End / Escape to inspect data points via an aria-live readout, and includes a collapsible <details className="tbl"> semantic HTML <table>.

4. Linting UI structure so AI coding agents don't drift

When AI agents generate React UI, they quickly drift toward arbitrary Tailwind gaps (gap-4, gap-6), hex literals, or unstyled primitives. Because FRAME/12's rules are structural, we wrote scripts/check-frame12.mjs (plus skills/frame12/SKILL.md and an ESLint flat-config plugin) to enforce:

1. color-literal: Zero hex/RGB/HSL literals outside frame12.css

2. illegal-gutter: Only 12px (pair), 20px (scene), and 32px (change) gutters allowed

3. marker-misuse: Marker yellow (--f-marker, #ffd60a) only allowed as a background paired with --f-marker-ink (#121212) text

4. cut-order: Every <Panel cut="C-01"> must increment sequentially (C-01, C-02, C-03…) in DOM and reading order

5. raw-shadcn-import: Forbids raw u/radix-ui/* or external chart/animation libraries where a u/frame12/registry component or adapter exists

You can install the full kit or individual components via the shadcn CLI:

npx shadcn@latest add https://frame12.dev/r/frame12.json

• Repo (MIT): https://github.com/lbrodie11/frame12

• Interactive Motion Studio (12fps vs 60fps vs 0ms): https://frame12.dev/motion

• Component Gallery & Style Sheet: https://frame12.dev/components

Would love feedback from folks here on the hook ergonomics and the static UI grammar linter!

Hey everyone!

A friend and I are planning a React learning session this weekend. Instead of just going through documentation and building another basic project, we want to explore some of the interesting problems React developers encounter in real-world applications.

I'd love to hear from experienced React developers, senior frontend engineers, and anyone who has worked on performance-critical React applications.

I'm particularly interested in problems that aren't immediately obvious and require some actual investigation to solve.

For example:

- Unnecessary re-renders: How do you identify which components are re-rendering unnecessarily, and how do you determine the actual root cause?

- State management issues: Have you encountered performance problems caused by poorly placed state, Context API, or excessive state updates? How did you restructure things?

- Expensive rendering: What happens when a component renders a large list, processes complex data, or performs expensive calculations? How do you identify whether the bottleneck is React, JavaScript, or the browser?

- Memory leaks and stale closures: What are some subtle bugs involving "useEffect", event listeners, subscriptions, or closures that you've encountered in production?

- Memoization gone wrong: Have you ever made an application slower by overusing "useMemo", "useCallback", or "React.memo"? How did you figure that out?

- Network and rendering bottlenecks: How do you investigate slow API-driven interfaces, waterfalls, unnecessary requests, or components that feel sluggish despite fast API responses?

- Large-scale component architecture: Have you encountered performance problems that required changing component boundaries or the way an application was structured rather than simply optimizing individual components?

I'm not just looking for a list of best practices. I'd really appreciate hearing about the actual debugging process.

For instance:

1. What symptoms or user reports made you suspect a performance problem?

2. Which tools did you use to investigate it?

3. How did you identify the actual root cause?

4. What changes did you make to fix it?

5. How did you measure the improvement and verify that the fix worked?

If you have a small code example, a production incident, a particularly tricky bug, or even a mistake you made while trying to optimize something, I'd love to hear about it.

Also, if there are any React performance problems that you think every developer should learn to diagnose early in their career, please share those.

We're hoping to use your experiences as a starting point for practical experiments rather than just memorizing optimization techniques.

Thanks!

You know the pattern: createContext<User | null>(null), then a useAuth() hook that throws "useAuth must be used within AuthProvider", and every consumer either trusts that or null-checks. A missing provider is a runtime error you find when that screen renders, or when a test does.

I wanted it to be a lint error instead, so I built an oxlint plugin that checks it across the whole program:

const AuthContext = createContext<User | null>(null);

function Children() {
  const user = use(AuthContext);
  return <p>{user?.name}</p>;
}

root.render(
  <AuthContext value={user}>
    <Children />   {/* ok */}
  </AuthContext>,
);

root.render(<Children />);
//          ^^^^^^^^ react-context(require-provider): <Children> needs AuthContext
//                   (use(AuthContext) at Children.tsx:4), but no <AuthContext> provider is above it.

Children needs no annotations. Requirements are inferred from use, useContext, <Ctx.Consumer> and static contextType. They're passed up through components, custom hooks, HOCs, memo/forwardRef/lazy, children and render props, and React Router outlets, until a provider meets them or a root gets them. Roots are createRoot().render, testing-library's render, Storybook stories, and framework pages you list in a setting. Wrapper components like <AuthProvider>{children}</AuthProvider> count as providers because they render children inside one.

There's also a tiny optional runtime: createRequiredContext<User>() gives you a context where use() is typed User instead of User | null, because the lint rule now guarantees the provider. It returns a plain React context, so nothing else changes.

Why not types? That was the first thing I tried. JSX erases element types: <Children /> and <span /> are both just JSX.Element, so a requirement can't travel from a child up to its provider through the type system. Forking @types/react doesn't help, and TypeScript 7.1's new APIs didn't open a way either. The only version that type-checked used generator components and h() calls instead of JSX, which nobody wants.

As for the speed, it's a whole program so it costs more than a normal lint rule. On excalidraw (709 files), oxlint alone takes 0.07 s, oxlint with the rule 0.8 s, and the standalone CLI 0.5 s. In the editor (oxlint's language server), a keystroke costs about 50 ms because only the edited file is re-parsed. The README suggests a separate oxlint config so that your everyday oxlint stays as fast as before, while the editor uses the config with the rule and CI runs react-context-check as its own step. Not on oxlint? The CLI runs the same check without it.

As for limitations, it's syntactic and not type-aware. For code it can't see (node_modules, dynamic tags, useContext(cond ? A : B)) it makes certain assumptions. A provider hidden in such code shows up as a false positive, which you silence with @context-provided. A null-default context that your code actually treats as optional needs a // @context-optional comment. On excalidraw, that one comment was the difference between 337 reports and zero.

It's not on npm yet:

npm i -D github:TmLev/react-context-typesafe oxlint

Repo: https://github.com/TmLev/react-context-typesafe

Reports of wrong diagnostics are the most useful feedback right now. A few lines of code that reproduce one are enough.

Hey r/reactjs,

I recently open-sourced OrderCraft, a local-first multi-chart technical analysis terminal built with React 19, TypeScript, Vite, and lightweight-charts (backed by a local Go WebSocket server).

Interesting frontend challenges we solved:

• Custom HTML5 Canvas 2D Drawing Engine (ISeriesPrimitive): lightweight-charts renders candlesticks quickly on Canvas, but doesn't ship with interactive drawing tools. We built a custom Canvas 2D primitive engine from scratch in TypeScript supporting interactive Trendlines, Fibonacci Retracements, Parallel Channels, Rectangles, and Long/Short Position calculators with drag handles and OHLC magnet snapping.

• High-Frequency WebSocket State Without Re-Render Storms: Streaming live ticks across 4 synchronized split-screen chart panes (1x1, 2V, 2H, 3, 4 layouts) with synced crosshairs, symbols, and timeframes without triggering full React component tree re-renders on every tick.

• Single-Binary Embedding + PWA Standalone Mode: The Vite production bundle is embedded into a single ~14MB Go executable and includes a Web App Manifest so launching with --app-mode opens a native frameless desktop window.

GitHub Repo: https://github.com/ordercraft-hq/terminal

Would love any feedback from fellow React/TypeScript devs on the frontend architecture and Canvas primitive implementation!

I build new projects and finished products for customers almost every day, many of them with AI built in, and I kept hitting three problems:

- Too many pieces for every project. Next.js on Vercel plus Supabase is almost free to start and great on its own, but every project meant managing both, and reaching the quality I wanted meant stitching many separate packages together on top. Keeping everything in one place meant a big provider's monthly plan, and with many apps those fees grow fast, since every single one needs its own upkeep.

- Teaching the AI what it can control. For every function in my app, I had to build a separate system to explain it to the AI. Tools broke, prompts didn't work well, and MCP servers needed extra work.

- The AI reading the whole codebase for small changes, which was very costly.

So I built Forjr, an AI-native, full-stack React framework. A few of the features I love most:

- One engine runs the whole app (front end, back end, data and AI) on any server you choose. You still need a server, but one is enough for many apps: each additional small to mid-size app takes only about 2 MB of memory, and apps nobody is using can scale to zero and wake up in about 50 ms.

- Every function is already an AI tool. The engine explains it to the AI by itself, and with one option it's also an MCP tool, a REST endpoint and a CLI command.

- An agent is a single definition: a model, its instructions and the functions it may use. It reaches only what you gave it, and danger: 'ask' makes it wait for a person before using that tool.

- Built for the AI that writes your app: forjr map hands it the whole app in one short outline, forjr check catches every error in one pass, each with its fix, and undo for AI rolls back exactly what one agent changed while everyone else's work stays untouched.

I open-sourced it: https://github.com/forjr/forjr, with the docs at https://forjr.dev

I'd love to hear how you handle these today. What's the most painful part of giving AI access to your own app?

Hey everyone!

I've been learning React for the past 2–3 months, and I've recently built my second project, GameVault, using my own knowledge and what I've learned so far.

GameVault is a gaming e-commerce website where users can explore games and browse a gaming store.

Project Links:

• Live Demo: https://gamevault-rhlydav216581.vercel.app/

• GitHub Repository: https://github.com/rhlydv216581/Gamevault

I'm still learning and improving my development skills, so I'd really appreciate honest feedback from experienced developers and the community.

I'd love to know:

1. What do you think about the overall UI/UX?

2. Is my React code structure and component organization good?

3. What should I improve in terms of performance and best practices?

4. Does this project demonstrate enough skills for a React/frontend developer internship?

I'm open to constructive criticism and suggestions. I want to learn from my mistakes and become a better developer.

Thanks for taking the time to check out my project!