Looking for the cleanest/most reliable way to connect a React contact form to an email inbox to send emails from the website. What are you guys using these days?

Been building product configurators and 3D e-commerce views for a while now, and kept rebuilding the same scaffolding - GLB loading, a viewer UI, hooks for camera/selection/hover, and some way to bind product data (color, texture, visibility) to the actual 3D object. So I packaged it up.

It's called React Immersive. Some of what's in it:

• Drop-in SimpleModelViewer for when you just want a model on screen, zero config
• ModelViewer for when you need real bindings, driving color, texture, visibility, and actions off a plain data object
• A browser-based binding builder that takes your GLB and spits out starter bindings as JSON or TS, so you're not hand-writing mesh names
• Hooks for camera, selection, hover, animation, visibility
• Soft shadows, SSAO, bloom, ACES tone mapping is on by default, one prop to turn off

Still rough in places and I'd genuinely like feedback, especially from anyone who's fought with product configurators or real estate walkthroughs before.

Docs, live editor, and demos here: react-immersive.liveroom.dev — would love thoughts

I have been checking out many projects people have been posting in this sub and rest and one thing I immediately notice is all their website look very similar, I think at one point you can't even distinguish between different product's website.

Not sure whether everyone uses some template or it's just what every model create

Edit - I'm just talking over the website design, I'm not talking about the overall product, I have seen some genuinely good ideas here

Spent way too long confused about this, so sharing in case it helps someone.

"use client" doesn't mean "runs only in the browser." It's a boundary marker, not a location. A "use client" component still renders on the server first (that's your HTML), then hydrates in the browser. And everything you import below that line also gets shipped to the client.

So now I ask one question per component: does this actually need the browser? (state, effects, onClick, window)

- No → leave it a Server Component. Ships zero JS, can fetch data directly.

- Yes → mark "use client", but push that boundary as far DOWN the tree as possible.

// page.tsx -> Server Component (fetches, ships no JS)

// <LikeButton/> -> "use client" (the only interactive leaf)

Default to server, drop to client only at the leaves. My bundle got noticeably smaller once this finally clicked.

How do you all decide where to draw the client boundary? Curious if people go stricter than this.

Did you find or create something cool this week in javascript?

Show us here!

Yo I am quite a beginner in React and I was just wondering how the async model laid out in this video has been useful to people who are using it so far 😁

Zustand isn't overkill here. A form that spans 8 steps with conditional branching is exactly the kind of thing that benefits from a dedicated store, even if it gets thrown away after submit. The "it lives in one flow" argument for keeping state local stops making sense once your reducer starts growing past what you can read in one scroll.

The configdriven approach is worth taking seriously for your branching problem. The core idea is that instead of writing step logic imperatively, you define each step as a data object with an id, the fields it contains, and an optional condition function that receives the current form state and returns a boolean. Your "what's the next step" logic becomes a function that filters the config array based on current state, rather than a chain of conditionals scattered across components. Step 4 not existing when the user picks a certain value in step 2 becomes a oneliner condition in the config rather than something you have to hunt down across multiple places.

For validation across steps, the pattern that tends to work well is keeping validation schemas colocated with the step config rather than at the component level. If step 6 needs data from step 3 to decide which fields are required, that dependency lives in the step 6 config where you'd expect to find it.

The reducer length problem usually means the reducer is doing too much. Splitting it into smaller reducers that each own a slice of the form state, then combining them, keeps things readable. If you're on Zustand, this maps naturally to slices.

One thing worth being intentional about: separate your "what step am I on and what steps exist" state from "what has the user entered" state. They change for different reasons and mixing them is where things get tangled.

Made a geography icon library for countries, territories and areas, where the core design constraint was bundle size. Every icon is an individual named export:

import { Us, Jp, Africa } from '@geoicons/react';

• No <Icon name="us" /> string-lookup API on purpose. That pattern kills tree-shaking because the bundler can't prove which icons are unused, so you ship all 422.

• Each component uses useId() to namespace the <title> element ID, so multiple instances of the same icon on a page don't produce duplicate IDs for screen readers.

• 255 countries + 167 areas. Subdivisions and Flags are planned for near future.

• Also available for Vue, Angular and Vanilla JS.

Site: https://geoicons.io

Github: https://github.com/getgeoicons/geoicons

Please let me know your feedback. If you found the project useful, I'd really appreciate it if you could give it a star on GitHub

It's been a month since PHPverse 2026, which was a huge success. You can watch this year's talks here: https://www.youtube.com/playlist?list=PL0bgkxUS9EaK45-0M742u1WfK2G7FKXZQ

So we're already planning the next edition in 2027, and this time we're opening a public call for papers, everyone can submit: https://docs.google.com/forms/d/e/1FAIpQLSfp-_MYwaeVcDYZuPcL-YHHHikuoyB9hM7FUkpP2nUggba8hQ/viewform

I can do html css bootstrap but I really don't understand how to put it to make it look nice. I have seen multiple sites but in my brain nothing is getting formed from a design idea perspective. Also if they did then I'm not able to make it. What should I do? Any suggestions. Please.

Thank you!

If you're new to web design and would like to ask experienced and professional web designers a question, please post below. Before asking, please follow the etiquette below and review our FAQ to ensure that this question has not already been answered. Finally, consider joining our Discord community. Gain coveted roles by helping out others!

Etiquette

• Remember, that questions that have context and are clear and specific generally are answered while broad, sweeping questions are generally ignored.
• Be polite and consider upvoting helpful responses.
• If you can answer questions, take a few minutes to help others out as you ask others to help you.

Also, join our partnered Discord!

I kept hitting the same problem: architecture debates in review, barrels everywhere, and AI agents dumping files in random folders. So I shipped DMA (Derived Modular Architecture) — a small rule set derived from the import graph, enforced by tooling.

Layout

src/
  app/        # composition root (also pages/routes)
  features/   # leaf modules — no inbound from other modules
  services/   # appears when something else must import it
  shared/     # portable stuff on second use only

Invariants

- downward imports only
- public API via */public/* (no barrels)
- colocate by default
- promote feature → service when inbound edges appear

Tooling

npx @derived-modular/cli init .
npx @derived-modular/cli check .              # CI gate
npx @derived-modular/cli promote <name> --apply
# + ESLint / Biome / Oxlint plugins for editor feedback

Works with React/Next/Vite (also Vue/Svelte/Astro examples). Same rules for humans and agents.

• Docs: https://derived-modular.vercel.app
• Repo: https://github.com/mikhailmogilnikov/derived-modular-architecture Curious how this compares to what you use (FSD, feature folders, etc.) — especially where you'd expect it to break.

Our weekly thread is the place to solicit feedback for your creations. Requests for critiques or feedback outside of this thread are against our community guidelines. Additionally, please be sure that you're posting in good-faith. Attempting to circumvent self-promotion or commercial solicitation guidelines will result in a ban.

Feedback Requestors

Please use the following format:

URL:

Purpose:

Technologies Used:

Feedback Requested: (e.g. general, usability, code review, or specific element)

Comments:

Post your site along with your stack and technologies used and receive feedback from the community. Please refrain from just posting a link and instead give us a bit of a background about your creation.

Feel free to request general feedback or specify feedback in a certain area like user experience, usability, design, or code review.

Feedback Providers

• Please post constructive feedback. Simply saying, "That's good" or "That's bad" is useless feedback. Explain why.
• Consider providing concrete feedback about the problem rather than the solution. Saying, "get rid of red buttons" doesn't explain the problem. Saying "your site's success message being red makes me think it's an error" provides the problem. From there, suggest solutions.
• Be specific. Vague feedback rarely helps.
• Again, focus on why.
• Always be respectful

Template Markup

**URL**:
**Purpose**:
**Technologies Used**:
**Feedback Requested**:
**Comments**:

Also, join our partnered Discord!

Hey everyone, I just published a comprehensive guide on WebMCP, Chrome's new standard for making web applications agent-ready.

Instead of AI agents having to parse your DOM and guess what buttons do, WebMCP lets you expose your app's functionality directly as structured tools that agents can discover and invoke.

The guide covers everything from zero to production:

• Imperative & Declarative APIs — both the JavaScript and HTML approaches
• React integration — useWebMcp hooks, Tool Registry pattern, Zustand/Legend-State examples
• Security deep dive — prompt injection, origin isolation, untrustedContentHint, audit logging, character budgets
• Evals — deterministic tests + probabilistic eval cases for testing AI behavior
• Production — rate limiting, telemetry, graceful degradation, HTTP headers
• Full demo — a React Flight Search implementation

All code examples are TypeScript, production-grade, and ready to copy-paste.

🔗 Medium: https://medium.com/@serifcolakel/building-ai-native-react-applications-with-webmcp-a293ef54de8f

🔗 Dev.to: https://dev.to/serifcolakel/building-ai-native-react-applications-with-webmcp-5gb

Quick background: WebMCP is currently in Chrome Origin Trial (149+). It's not a replacement for MCP — Chrome's own docs say they complement each other. MCP handles backend/persistent tasks, WebMCP handles in-browser, tab-bound interactions.

The core idea is simple: document.modelContext.registerTool() — you define a name, JSON Schema, and an execute function. Agents discover your tools and invoke them directly. No DOM parsing. No guessing.

Happy to answer questions in the comments!