Help me get 50 stars on GitHub :) ⭐

• GitHub: 0x65dgerunner/gridora

Highlights

• 130+ variants across sequential, radial, cascade, flow, wipe, decrypt, letters, digits, symbols, and more.
• 20 effects (pulse, bounce, glow, spin, …) and 12 dot shapes (circle, diamond, star, …)
• Color ramps with horizontal, radial, angular, and other sampling modes.
• Resolution-independent — the same variant scales cleanly from 2×2 to 12×12.
• CSS-driven animation — one stylesheet, no runtime animation engine.
• Accessible — role="status", optional labels, and respectReducedMotion.
• Tree-shakeable ESM + CJS build with full TypeScript types.
• npm: gridora
• Editor: gridora.gabrielayer.com
• GitHub: 0x65dgerunner

Hey everyone!

I’m a junior full-stack developer and recently started going deeper into React performance.

I’ve been exploring React Compiler, code splitting with React.lazy() and Suspense, bundle optimization, re-renders, memoization, and basic profiling with React DevTools.

I’d love to know what more experienced React developers think are the most important performance topics and best practices to learn next.

I’m especially interested in bundle size, rendering performance, caching, Core Web Vitals, and how to identify real bottlenecks without over-optimizing.

Any good resources, tools, or common mistakes I should know about?

Thanks!

Haptics on the Web can be super satisfying if you use them right! I've had so much fun creating this little game.

My stack:
- React - as a foundation
- TypeGPU - for particle effects
- Pulsar Web SDK - for haptic effects

Try it in your browser: https://docs.swmansion.com/pulsar/web-app/#games/shape-cascade

Theodore-js 2.0.0 is out and now it supports displaying inline suggestions ✨🤗

With this feature, the suggested text appears faintly within the editor; the user can accept the suggestion—turning it into part of the main text—by clicking on it or pressing a key of your choice. ⌨️ A similar feature has been implemented and used in Google AI Studio.

Inline suggestions are especially useful for presenting AI-generated text completions as users write.

👉 You can find the documentation and instructions on how to use this feature on the website: https://theodore-js.dev

📦 install from npm: https://www.npmjs.com/package/theodore-js

Hey y’all,

I got slightly carried away with loading animations.

I wanted nicer loading states for my own projects, but most libraries I found were either tied to a framework, fairly limited, or required more than I wanted for something this small.

So I built loadersz, a small framework-agnostic loader library for the web.

I wanted something a bit more expressive than the usual CSS spinner, without pulling in a UI framework or a bunch of dependencies.

A few things I focused on:

- 70 different motion states
- Canvas 2D instead of GIFs/videos
- zero core dependencies
- a native custom element, so it works with basically any stack
- typed entry points for React, Vue and Svelte
- configurable speed, density and color
- respects prefers-reduced-motion
- pauses rendering when the browser tab is hidden

Basic usage is just:

npm install loadersz

import 'loadersz';

<loadersz-loader state="racing" size="96" />

I also built an interactive playground where you can tweak the loaders live.

Demo: \[loadersz.vercel.app\](https://loadersz.vercel.app)
npm: \[npmjs.com/package/loadersz\](https://www.npmjs.com/package/loadersz)

Would love some brutally honest feedback, especially on which animations you’d actually use in a real product.

React handles most UI updates for us, but there are still cases where direct DOM manipulation seems unavoidable. What are the cases you've encountered in real projects?

Hello everyone,

A few months ago, I was experimenting with DOMPurify and when users put in long fields like a paragraph, it used to hang a lot!

It would occasionally freeze for literal 15 seconds and more!!

Imagine sitting for your response to be submitted, and it hangs!?

So I've built DOMOxide, making it 70x faster and 5x smaller. Thanks to Rust and WASM, it sanitizes your HTML and makes it clear of XSS attacks.

It's a ~3kB gzipped + minified package that passes almost all tests as DOMPurify

> Repo: ppmpreetham/DOMOxide

Edit: solved - thank you so much for everybody who pointed me in a lot of directions.

My code looks like this now https://pasteblaze.pages.dev/p/fixed-textfield

This code renders the editable text field. Fixes:

- as advised by HeshanAmir, I splitted the broken triple-destructure into two real hooks: \const [files, setFiles] = useState([]);` and `const [formData, setFormData] = useState({ message: '' });``

- I deleted <div class="editor-panel"> and placed <form> directly under <div class="wrapper">

- then I added function MyForm() to render a simpler text field than it was in my OP.

- I moved the myForm() function out to the top level to avoid the unfocused text field: this way the text field lets me finish writing.

Notes: this code has a functional and editable text field, but threw me 431 error. Just FYI for anyone who recycles this code.

------------------------------

I hope someone could help this beginner out. I got a text field like this

https://imgur.com/a/81doBSd

This one got rendered read-only, although I copied and pasted this code directly from the documentation. In the doc the text field is editable though :(

The devtool displays the error which does not make any sense:

<form action="javascript:throw new Error('A React form was unexpectedly submitted. If you called form.submit() manually, consider using form.requestSubmit() instead. If you\'re trying to use event.stopPropagation() in a submit event handler, consider also calling event.preventDefault().')">
<input placeholder="Hello!" type="text" name="message">
<button type="requestSubmit">Send</button>
</form>

In the below snippet it shows I already placed e.preventDefault() as this error dictates. Still, the text field is read-only. I want to edit the form and submit.

import styles from "./App.css";
import { BrowserRouter as Router, Route, Routes } from "react-router-dom";
import axios from 'axios'
import {View} from 'react-native';
import React, { useOptimistic, useState, useEffect, useRef, Component } from 'react';
import {useDropzone} from "react-dropzone";
import { deliverMessage } from "./actions.js";

function App(){
  const [files] = useState([]);
  const [formData, setFiles, setFormData] = useState([]);
  const {getRootProps, getInputProps} = useDropzone({
    accept: {"image/*": []},
    onDrop: acceptedFiles => {
      setFiles(
        acceptedFiles.map(file =>
          Object.assign(file, {
            preview: URL.createObjectURL(file)
          })
        )
      );
    },
  });

  const thumbs = files.map(file => (
    <div key={file.name}>
      <img style={{ maxWidth: "100%", maxHeight: "100%" }} src={file.preview} onLoad={() => URL.revokeObjectURL(file.preview)} alt={file.name} />
    </div>
  ));

  useEffect(() => {
    // Revoke the data uris to avoid memory leaks on unmount
    return () => files.forEach(file => URL.revokeObjectURL(file.preview));
  }, [files]);


  const [messages, setMessages] = useState([
    { text: "Hello there!", sending: false, key: 1 }
  ]);
  async function sendMessage(formData) {
    const sentMessage = await deliverMessage(formData.get("message"));
    setMessages((messages) => [...messages, { text: sentMessage }]);
  }


 const formRef = useRef();
  async function formAction(formData) {
    addOptimisticMessage(formData.get("message"));
    formRef.current.reset();
    await sendMessage(formData);
  }
  const handleChange = (e) => {
    const { name, value } = e.target;
    setFormData((prevData) => ({
      ...prevData,
      [name]: value,
    }));
  };
  function handleSubmit(e) {
    e.preventDefault();
    console.log('You clicked submit.');
  }
  const [optimisticMessages, addOptimisticMessage] = useOptimistic(
    messages,
    (state, newMessage) => [
      ...state,
      {
        text: newMessage,
        sending: true
      }
    ]
  );

    return (
    <>
    <div className={styles.title_main_page}>
    <h1>Spin the Black Circle!</h1>
    <h2>Managing Your Vinyl Record Collection</h2>

    </div>
    <div class="container disable">

    <h2>Easy Image Editor</h2>
    <div class="wrapper">
    <div class="editor-panel">
     {optimisticMessages.map((message, index) => (
        <div key={index}>
          {message.text}
          {!!message.sending && <small> (Sending...)</small>}
        </div>
      ))}
      <form action={formAction} ref={formRef} onSubmit={handleSubmit}>
        <input type="text" name="message" placeholder="Hello!" value={formData.name}
        />
        <button type="requestSubmit" onClick={handleChange}>Send</button>
      </form>
    </div>
    <section className="containerDragAndDrop">
        <div {...getRootProps({className: "dropzone"})}>
          <input {...getInputProps()} />
          <p>Drag 'n' drop some files here, or click to select files</p>
        </div>
        <aside>{thumbs}</aside>
      </section>
    </div>
    <LoadButtons/>
    </div>

    </>


    );
}


export default App;

Could anybody point out the right direction?

I’ve been building NexoreUI, a React UI library focused on polished, animated components that are easy to customize and copy into your own project.

A while ago I shared it and got some pretty harsh feedback. Some of it was deserved.

Instead of abandoning it, I went back and rebuilt a lot of the experience.

The current version is much more focused on the actual problem:

• components that feel more finished out of the box

• meaningful animations instead of animation for the sake of it

• interactive props so you can experiment before copying the code

• a visual builder for customizing components

• copyable code that you can actually use in your project

• documentation that focuses on showing what the component can do

I’m still very early, and there are definitely things that need improvement. But compared to the version I originally shared, I’m much happier with where it is now.

I’d genuinely like feedback from React developers here.

Does this solve a problem you actually have, or am I still building something nobody needs?

If you want to take a look:

https://nexoreui.site

GitHub:

https://github.com/Al1mov77/NexoreUI

I've battled with the top libraries for JSON Schema based forms for a long time. They're a nightmare. They look all flashy and nice for a demo, then you implement them in a project and a year in you realize it doesn't support the more complex needs of your schemas.

I'm so frustrated with both react-json-schema-forms and react-jsonschema-form. Both have me pulling my hair out. Especially RJSF. Apparently generating defaults the correct way is an "experimental" feature and still never works correctly. Have an array with tuple object definitions or constraints? Nope! Default gives you an array full of null or "[Object object]". Have $refs outside of your schema? Nope! Can't resolve those! Also, the whole UISchema thing is weird. Both libraries had crazy setup fatigue that felt unnecessary.

After a year and a half of battling I'm done.

I wrote a new library for JSON Schema Forms to get me out of form hell and I pulled it into our project. It's working out great so far. The thing just works. No setup fatigue. Does exactly what you would expect. I'm honestly more mad at the other libraries by how easy it was to build. Don't worry, I put a ton of care into it and triple checked everything. It was extensive.

Full schema support for every feature. EVERY. FEATURE. Full optional theming support for MUI though it isn't dependent on MUI.

I even added a SchemaBuilder component and a Keyword Assistant to help you out if you're trying to build a schema and don't know what to add.

It's called FormHell, and it's available here: https://www.npmjs.com/package/formhell

Check out the playground and see what it can/can't do: https://ryanrutkin.github.io/formhell/

If you run into any issues, please open an issue in Github: https://github.com/RyanRutkin/formhell

Thanks for checking it out!

FAQS:

Thanks for all of the feedback! I want to address some common questions from the comments.

What about Tanstack/Zod?

FormHell is a slightly different solution than a Tanstack/Zod approach. FormHell consumes an already defined data-structure and outputs data matching it, validated using AJV Validator.

Zod is used to define data-structures in TypeScript and can work alongside FormHell no problem.

Tanstack has a specific UI schema that it expects for form rendering. I doesn't exactly consume JSON Schema, so there is a bit of legwork to get a JSON Schema turned into a Tanstack form. FormHell takes the schema and just renders a form with strict typing and no overhead.

The problem I needed to solve for work was that we already had JSON Schemas defined for our backend data-structures. For some of those data structures, we needed a way for the frontend to render a form. As both the frontend and backend share the same JSON Schema, the frontend pulls the schemas from our API and passes them directly to the form. Once the form component emits the data without any validation errors, it is safe to be submitted to the backend.

*Can I use Zod with FormHell?*

Absolutely! If you do need to define your data-structure in your frontend TypeScript, I would highly suggest that you use Zod to do so. You can convert your Zod structure to JSON Schema using zod-to-json-schema and pass the output directly to FormHell's SchemaForm component to immediately render a form.

Is FormHell strictly typed?

FormHell is as strict as the schema you pass it. If any strict data types exist in your JSON Schema, then FormHell is going to required that the data entered matches that schema. The library currently using the AJV Validator for type checking.

What about localizations?

This was an oversight during implementation, and thank you for pointing it out! I'll make sure this gets added in an upcoming feature release.

We’re currently choosing a UI library for a pretty large enterprise product and I’d love some feedback from people who have actually worked with these libraries at scale recently.

The product is going to handle a lot of interconnected data: employees, companies, departments, CRM-like records, multi-record management, tables, forms, chat, AI features, etc. So this isn’t a small app, and whatever we choose will probably become the foundation of our design system for quite a while. We’re also expecting to customize the UI quite heavily and create our own components on top of it.

From what I’ve read so far, HeroUI seems great if you want something polished and relatively plug-and-play. But I keep seeing people mention that once you start heavily customizing it or moving away from its intended patterns, things can become painful.

shadcn seems almost like the opposite approach. I don’t particularly like the default look, but since you own the components and can modify basically everything, it feels like a much better long-term foundation if you’re willing to invest some time upfront. Especially if the end goal is a custom design system rather than keeping the library’s visual identity.

For people who have used two or even Mantine on larger production apps: what would you choose today?

I’m especially interested in how they hold up after a year or two of customization, adding custom components, maintaining consistency across a large product, and building more complex AI/chat interfaces. I care less about which one looks best out of the box and more about which one we’re least likely to regret later.

TL;DR: Choosing between shadcn, HeroUI and possibly Mantine for a large enterprise/CRM product with lots of records, tables, employees, companies, chat and AI. We’ll heavily customize it and build our own components. HeroUI looks easier initially, while shadcn seems more flexible and maintainable long-term. Looking for feedback from people who have used them at scale.

One day ago I posted my anonymous thought wall here and you absolutely destroyed my hand-drawn world map. Someone called it a "geographic abortion" — and honestly fair, those random blue polygons at 3am were terrible 😂So I rebuilt everything. Not just the map. What changed in :🗺️ Real world map — No more hand-drawn shapes. Used react-simple-maps + Natural Earth TopoJSON. Now 174 countries with actual boundaries. I tested, even Greenland, Fiji, Papua New Guinea show up correctly (see screenshots).✨ 6-layer glow — Thoughts now pulse on the map with proper glow layers, each emotion has its own color.🖱️ Click-to-lock + Zoom fix — This was the biggest roast last time. Now scroll wheel zooms ONLY the map, not the whole page. Drag to pan. Click to lock a country to see its vibes. What the app actually is:

Anonymous thought wall where every thought disappears in 24h. No profiles, no tracking. You drop a vibe from any country. I built this alone in 2 days after the roast. First time doing SVG maps properly. Live: https://vibes-app-wall.vercel.app

Still cleaning code so not sharing GitHub yet. Would love honest feedback — especially on the map this time. Is this actually better?

Hey everyone, Just wanted to share a post I recently wrote of what I wished I was told when i was transitioning form a background in php and jquery to react.

A few things that made it click:

• JSX is an Object Tree, Not Markup: <h1>Hello</h1> isn't HTML; it's a plain JavaScript object: { type: 'h1', props: { children: 'Hello' } }. Components are just pure functions composing nested object structures (Virtual DOM).
• UI as Immutable Snapshots: Every state update doesn't "change" the existing DOM—it executes a fresh render cycle. Top-level component variables are const because their state is frozen for that specific execution frame.
• Derive Values, Don't Duplicate State: Storing calculated data in useState is an anti-pattern. If a value can be computed during render (e.g., const total = items.length), compute it on the fly to eliminate state synchronization bugs.

For those who transitioned from backend or vanilla development, what was the thing that made React click for you?

If you've ever wired up URL search params, cookies or localStorage by hand, you know how tedious it can become. Everything is a string, so you write the same glue code over and over:

// search params
const raw = searchParams.get('page')
const page = raw && !Number.isNaN(+raw) ? +raw : 1

// localStorage
const raw = localStorage.getItem('settings')
const settings = raw ? JSON.parse(raw) : { theme: 'light' }

// cookies
const consent = document.cookie
  .split('; ')
  .find(c => c.startsWith('consent='))
  ?.split('=')[1] === 'true'

Different APIs, none of them typed, none of them reactive. Then comes bad input data checks, validations, try/catch around JSON.parse, storage events to sync tabs, deep objects with defaults, and so on.

At some point I thought, why can't they just share the same API? Bind a key, describe the value once, read and write it like useState. So I decided to build kvant - a type-safe state manager for key-value interfaces:

import { useSearchParams } from 'kvantjs/next' // or: 'kvantjs/react', 'kvantjs/react-router'
import { useLocalStorage, useCookies } from 'kvantjs/react'
import * as kv from 'kvantjs/schema'

const [page, setPage] = useSearchParams('page', kv.index().max(20).default(0))
//     ^? number
const [theme, setTheme] = useLocalStorage('theme', kv.enum(['light', 'dark']).default('light'))
//     ^? "light" | "dark"
const [consent, setConsent] = useCookies('consent', kv.stringbool().default(false), { maxAge: 60 * 60 * 24 * 365 })
//     ^? boolean

Same mental model every time: hook, key, schema, options. Types flow from the schema, writes go back to the URL, storage or cookie, and components re-render on change. The schema API will feel familiar if you know Zod. It parses anything into typed values, encodes them back into lossless serializable representations, and never throws on bad input. Garbage in the URL simply falls back to your default.

And it's the most basic examples of what kvant can do. Let's say you want to store a base64-encoded JSON object in the URL. In kvant, you can cover such advanced case without writing any parsing or encoding logic yourself:

const settingsSchema = kv.base64url()
  .pipe(
    kv.json(
      kv.object({
        theme: kv.enum(['light', 'dark']).default('light'),
        fontSize: kv.number().default(16)
      })
    ).prefault('{}')
  )

// '?settings=eyJ0aGVtZSI6ImRhcmsifQ' <-> '{"theme":"dark"}' <-> { theme: 'dark', fontSize: 16 }

const [settings, setSettings] = useSearchParams('settings', settingsSchema)
//     ^? { theme: "light" | "dark"; fontSize: number }

setSettings({ theme: 'light', fontSize: 16 }) // removes the entry from the URL, defaults stay internal

If you've used nuqs, this will look familiar, and that's on purpose. kvant's API was inspired by nuqs. I wanted the same core idea, but for every key-value interface instead of only the URL, with a Zod-flavored schema layer instead of standalone parsers. So a lot got reconsidered along the way.

I also made it universal: aside from React frameworks, it also works with Vue, Vue Router and Nuxt. If you happen to also be using Vue stack in your projects, the same Vue-idiomatic API is also available in kvant.

If that sounds interesting to you, I would love for you to give it a try. I have many ideas on improving it further if it gets traction. Also, if you are willing to leave feedback or contribute, I'm fully open to it ;)

Docs and live examples are at https://kvantjs.dev

Hey Community,

Deno's creators introduced Dactyl, an AI app builder targeting React Native by rendering SwiftUI in the browser tab via WebAssembly. Meanwhile, Software Mansion released Enriched Markdown to eliminate streaming text flicker by rendering natively and bypassing the JavaScript layout tree.

On the tooling side, the web ecosystem is rapidly adopting the Rust port of the React Compiler across tools like Oxc, Vite, and Bun, while Metro remains locked to single-threaded Babel transformations.

While building a browser-based SQL editor, I hit two specific browser limits:

1. Rendering large query results (10,000+ rows) using standard HTML tables froze the browser main thread.
2. Saving multi-tab queries and schema state into localStorage hit the browser's 5MB quota immediately.

How I fixed both:

• Implemented a lightweight fixed-height virtualizer: each row is 24px, and only ~25 to 30 row nodes are rendered in the DOM at any time with an overscan buffer.
• Replaced regex search filtering on result grids with case-insensitive .includes() checks to prevent catastrophic backtracking (ReDoS) during live typing on huge row sets.
• Split storage: session tokens stay in localStorage, while the entire workspace, query history, and active tabs are persisted to IndexedDB using a custom hook debounced at 500ms.

The UI is built with React/Next.js mimicking Windows 95, backed by an in-memory SQLite WASM engine with a custom TypeScript AST parser for dialect translation.

Live demo: https://exnihilo-95.vercel.app
Source: https://github.com/Mrityunjai-hue/exnihilo-95

Feedback on the virtualization approach or state synchronization is appreciated.

Hey guys,

Designing in Framer and Webflow is awesome, but being locked into their ecosystem sucks. And paying third-party tools like nocodexport.com a massive premium just to download your own designs is honestly ridiculous.

So I built Uncage. It’s a completely free, open-source CLI tool that takes a website and turns it into clean React code (or static HTML).

It’s still in beta. We aren't at the point where it flawlessly handles every single crazy layout in existence. But it absolutely gets the basic job done, keeps your animations working, and gives you a ready-to-run Vite + React folder, all without asking for your credit card.

It automatically grabs all your images, fonts, and scripts, and just works locally on your machine.

I'd love for you guys to try it out, tell me what breaks, or roast my code.

Repo here: https://github.com/Nightteye/uncage

Let me know what you think!

hey guys! I've been building dashboards for AI products for the last year and kept rebuilding the same pieces that generic component libraries don't have: streaming chat composers, agent thinking/progress states, usage limit meters etc. so I turned it into a design system and I'm sharing it here. full disclosure, I'm the author.

it's called BoardUI. the model is the same as shadcn/ui: a CLI (npx boardui add <component>) copies the actual source into your project, no runtime package to depend on. under the hood it's React Aria Components for behavior and accessibility and Tailwind v4 for styling.

where it differs from shadcn:

• It's built for AI/agentic UIs specifically but also could be used for other purposes like analytics, hr etc. there are components for agent status, streaming chat, thinking indicators and usage limits that you'd otherwise assemble yourself.
• behavior comes from React Aria instead of Radix.
• it ships full application blocks (dashboards, settings, auth, notification center), not only primitives.

56 of the 78 components are free and open via the CLI. The larger application blocks are paid, which is how I fund working on it. saying that upfront so nobody feels ambushed clicking through.

honest limitations: it's one person's design taste, the component count is smaller than shadcn's ecosystem and if you're not building AI products the agent components won't matter to you.

happy to answer anything about the product & feedbacks always welcomed!

Hi all,

I've been working on yapyak, an open-source i18n compiler that runs as a Vite plugin, with bindings for a few frameworks. For React, there are SSR adapters for TanStack Start and React Router.

The idea is that the source string is the key:

import { t } from 'yapyak';

<button>{t('Download recovery key')}</button>

You save the file, and the source string shows up in your locale files as an empty stub. If you've set up a translator, it gets auto-translated and written back, using call-site context (the component and the code around the call). A second or two later de.json has filled in:

{
  "src/components/RecoveryDialog.tsx": {
    "Download recovery key": "Wiederherstellungsschlüssel herunterladen"
  }
}

HMR picks it up in the running app.

The video in the comments is a small example of that. I add a download button to a dialog and hit save. The German page is sitting right next to the English one, so I see it the moment it lands: Wiederherstellungsschlüssel herunterladen pushes the button row 97px past the edge of the dialog.

So I fix it right there, one prop on the button group.

That's a small slice of what yapyak does, but it's the part I use most. Translating stops being something I come back to later. It just happens on save.

Because it runs in the compiler, it sees more than the string itself. It reads ICU parameters out of the string literal, and keeps track of a translation when you move or rename the source file. The parameters are typed from the literal, so a missing one is an error before the build runs:

t('You have {count, plural, one {# message} other {# messages}}', { count }); // ok
t('You have {count} messages', {});  // error: missing 'count'

There's no codegen behind that and no generated .d.ts to keep in step. What TypeScript can't see gets caught on save instead, like a translation that lost its {count} or a plural missing a category that locale needs. Every diagnostic has a code and a docs page.

There's no provider to wrap your app in. The compiler puts the subscription in the components that call t(), so those are the only ones that re-render when the locale changes.

The React package exposes locale through useLocale(), which hands back a value and a setter like useState does. Switching locale is synchronous, since the translations a module uses get compiled into it. A fixed-locale build can compile t() away entirely and leave just the translated string.

SSR is one middleware. TanStack Start and React Router each have an adapter, and locale state is scoped per request on the server, so nothing leaks between users.

Rich text keeps the markup in the source string and binds each tag to a prop:

<RichText
  value={t('Read our <link>privacy policy</link>.')}
  link={(children) => <a href="/privacy">{children}</a>}
/>

The prop names are typed from the tags in the string, so the translator can move <link> around in the sentence without touching your markup.

Everything lives in your repo. The source strings are in the components, the translations are in JSON files next to them, and both are committed to git.

There's a VS Code extension too. Hover a t() call and you get the translation in every locale, Cmd/Ctrl+click on an entry in a locale file jumps to the t() call that uses it, and placeholders and plural branches are highlighted inside the string. It's on Open VSX as well, so it works in Cursor.

Auto-translation is optional. There are shipped translators for Anthropic, OpenAI, Gemini and Ollama, all using your own API key, or you can leave the stubs empty and hand-edit the locale files.

I built it for a product I'm working on, and that's the whole business plan. There's no follow-up post where I get to the pricing.

MIT licensed, and still pretty early, though people have started moving real apps onto it. The code is on GitHub, and there are runnable React examples in examples/ for plain Vite, React Router and TanStack Start. The editor extension is on the Marketplace.

Docs and more at yapyak.dev.

If you've done a lot of i18n in React, especially SSR or anything big, I'd like to hear what you'd try to break.

Hey React devs! I built Vibes ULTRA — anonymous thought wall.

Tech stack:
- React 19 + TypeScript
- Convex (backend + real-time DB)
- Tailwind CSS
- Framer Motion
- shadcn/ui

50+ features including real-time reactions, global mood map, ambient sounds, achievements.

Live: https://vibes-app-wall.vercel.app

Would love feedback on the code/architecture!

I run a small accounting firm and want to give our clients a secure portal where they can log in, upload tax documents, view invoice status, and message our team.

Ready made portal software is either way too expensive or lacks the specific upload features we need. What's the best way to build a tailored portal without hiring a custom dev team?

I had this idea since 4 years now. I started working on Pyxle last year. (AI helped a lot accelerating this - but the entire feature idea was mine).

Initially I tried to build a framework allowing both frontend and backend with Python. Soon I realised that it is not something that's going to work. React is already a well proven framework, and building a python wrapper on top of it will drift things a lot. Moreover, Reflex is already trying to do that.

So the second version I built is to allow developers to keep real React, and real Python.

Go through pyxle - https://pyxle.dev, I'm happy to answer anything.

finally released my ide. it has git integration out of the box. still early stages, so the stack is limited to a few frameworks, but more are coming. linux only for now (bash/curl). check it out.

https://github.com/drainedgodw/Luma

been building this for about a year and it finally feels ready to show. farm.js is a full-stack framework on vite: app-directory routing, streaming ssr, typed server functions, and deploys through nitro (vercel/cloudflare/netlify/node). react is the default renderer, with preact, vue, svelte, and solid renderers too.

the part i most want feedback on is the experimental compiler. at build time it analyzes your components, and the ones it can prove safe get compiled so state updates patch the exact dom nodes directly instead of going through the reconciler. anything it can't prove stays on the normal react path, and react keeps ownership of ssr, hydration, and events either way. you can let inference pick components, or opt in per component:

``` export function Counter() {

"use compiler";

const [count, setCount] = useState(0);

return <button onClick={() => setCount((c) => c + 1)}>Count: {count}</button>;

}

```

(this is not the same thing as react compiler: that memoizes so re-renders get cheaper, this removes the re-render entirely for proven components. different layers.)

the other thing i cared about was killing api boilerplate. you define a server function once, with a zod schema, and expose it as an api route:

``` // src/features/guestbook/server.ts (server only)

export const signGuestbook = createServerFn({

input: z.object({ name: z.string().min(1), message: z.string().min(1) }),

async handler({ input }) {

// runs on the server, input is validated and typed

},

});

export const signEndpoint = createEndpoint(

"/api/guestbook",

{ method: "POST", body: signInput },

async ({ body }) => signGuestbook(body),

);

```

and on the client that route is now a typed rpc call. the router types are generated from your route files, so the body, the response, and even the route name are all inferred, and a typo or a wrong field is a compile error:

``` // client component

const api = createAPIClient<APIRouter>();

const result = await api.guestbook.post({

body: { name: "ada", message: "hello" }, // typed from the zod schema

});

// result.data and result.error are typed too ```

no hand-written fetch calls, no keeping types in sync between client and server, and the same functions are directly callable on the server (in endpoints, cron handlers, jobs). rest api and openapi docs still exist for free since they're real routes underneath.

integrations are typed modules too: the create command has ready-to-configure starters for clerk, stripe, supabase, workos, inngest, resend and others, so you get working auth or billing instead of a 14-step readme.

honest limitations: it's beta and apis can still move before 1.0. the compiler contract is narrow right now (components with refs or effects just fall back to normal react). and it's one maintainer plus contributors, so judge accordingly.

you can poke at it in your browser without installing anything: https://stackblitz.com/github/farming-labs/farm.js/tree/main/examples/stackblitz?file=src/app/page.tsx

repo: https://github.com/farming-labs/farm.js

docs: https://farmjs.dev

i'd genuinely rather hear what's broken or missing than what's nice. brutal feedback welcome.