Kya koi muje bta sakta hai ki apni portfolio website bnane k liye UI kese choose kre

Not the stack, not the libraries — the architecture or code organization decision you regret the most.

Hi all,

Sharing a project I recently finished and open-sourced: LaunchPad Lite.

It’s a clean starter template built around the Next.js 15 App Router ecosystem with a focus on type safety and modern auth:

- Better Auth: Handled via Server Actions and route handlers, avoiding legacy NextAuth quirks.

- Drizzle ORM: Minimalist schema setup designed to connect effortlessly with Supabase, Neon, or local Postgres.

- Tailwind CSS v4 + Radix UI: Fast UI primitives without CSS bloat.

GitHub: https://github.com/BZDevelopments/LaunchPad-Lite

For anyone who eventually needs full Stripe subscriptions, AI SDK v5, or multi-layout support, I also maintain a Pro version, but Lite is 100% self-contained and free forever. 

Take a look at the repo structure and let me know what you think of the architecture!

Hi, I made an free english learning app site

it has ipa (rachel english) and speech rules with annotations to study connected speech

give it a try and use the flag button to report issues which im sure there are a lot since im not a native speak and rules are generated with ai.

thanks !

Hey everyone 👋

I recently finished building PDFForgeLib, a project I started to explore the challenges involved in building a web application around PDF processing.

Tech stack: typescript+next.js + Python/FastAPI + supabase+vercel+render

The project focuses on common PDF operations such as:

• Merging and splitting PDFs
• Compressing PDFs
• Converting files
• Working with different PDF utilities
• Handling file uploads and processing
• Responsive UI for desktop and mobile

Project: [https://pdfforgelib.com/](https://)

One of the things I found interesting while building it was that PDF processing becomes quite different once you start thinking about larger files, processing time, browser limitations, error handling, and keeping the user experience simple.

I'm interested in hearing from developers who have worked with file processing, document systems, or similar web applications.

A few things I'd like to discuss:

• What problems would you expect with this type of architecture as usage grows?
• What are the important security considerations when processing user-uploaded PDFs?
• Would you handle PDF processing primarily on the client or server?
• What performance issues should I be looking out for?
• Are there better approaches for handling large files?
• What functionality would you consider essential in a PDF utility?
• Is there anything about the UX or workflow that feels unnecessarily complicated?

I'm still improving the project, so I'm particularly interested in technical criticism, alternative approaches, and things I may have overlooked.

Would be great to hear how other developers would approach the same problem.

Thanks!

We’ve gone full-Rust with our build pipeline at Outlyne.com and it feels like the React Compiler has really arrived. The last time I posted about using React Compiler here, I talked about how good it’s been for us overall, but also about all its limitations, the biggest of which was that it would bail out on compiling any component or hook that had a try/catch with conditional logic of any kind (if/else, ternary, ??, ||, optional chaining). Another big one was that it would bail on computed object keys, which bit us a few times with assembling classes using clsx (e.g. className={clsx({ [`item-${props.index}`]: props.isItem })}).

Both of those are fixed now. The oxc team shipped official support for the Rust React Compiler on August 4th, and that support includes all of the fixes to the compiler since the v1.0 release of the Babel-based compiler. In our codebase, seven more functions the compiler had been skipping are now compiling, five from the try/catch fix, two from computed keys. And that’s lower than it would be if I hadn’t gone through and contorted eight components to keep conditionals out of their try/catch blocks, including adding a @ts-expect-error from having to drop an optional chain and extracting my auth flow into an async run() that’s immediately awaited inside the try, for no reason but to move the value blocks out of it. All of those workarounds have been rendered obsolete.

There are still bailouts, most notably logical assignment operators (??=, &&=, ||=), but far fewer, and now actively being addressed. A couple weeks ago, oxc shipped a version bump that prevents a bail out from reassigning a destructured prop that then gets read in a nested closure.

Going Rust is also, of course, much faster. The compiler step on our 1,036 files dropped from 14.3s to 0.81s (~17.6×), and the build overall from 22.1s to 9.3s. And we verified parity with the Babel compiler. Across all 1,036 files, there are zero functions the Babel compiler memoizes that the native one doesn’t. The only difference in the built JS before and after are the seven extra compiled functions.

I wrote a blog post with all the details and before/after configs both for folks using @vitejs/plugin-react and for those who use an alternative plugin (React Router framework mode’s plugin in our case): https://blog.master.dev/react-now-rusted-all-the-way-out/

Hi r/reactjs! We just shipped v1 of webmcp-react after quite a few beta versions to work out the kinks. It is MIT licensed and we're hoping to find some more contributors!

What it does AI agents currently have to parse through 1000s of HTML tokens to browse a website. They essentially scrape the DOM and guess where the buttons are. WebMCP is a new web standard that fixes this. It adds document.modelContext to the browser, where a page registers typed tools an agent can call. Chrome shipped it in Early Preview in February, and since companies like Shopify and Codex support it fully. The spec was barebones, and there was no clean React-like way to integrate it into modern UIs, so we made one!

webmcp-react gives you a provider and one hook. The hook registers a tool when the component mounts and removes it on unmount.

```tsx import { WebMCPProvider, useMcpTool } from "webmcp-react"; import { z } from "zod";

function SearchTool() { useMcpTool({ name: "search", description: "Search the catalog", input: z.object({ query: z.string() }), handler: async ({ query }) => ({ content: [{ type: "text", text: Results for: ${query} }], }), }); return null; } ```

It ships with Zod and JSON Schema inputs, a built-in polyfill, SSR support for Next.js and Remix, StrictMode safety, execution state, and cancellation through AbortSignal.

WebMCP is early and we're looking for contributors. Chrome changes the API between releases, and only a few people track it. We are a small team and we don't intend to productize this since we made it mainly to add WebMCP support to our core website. The library works, but a standard needs many hands and many real sites. We'd love any bugs / feedback. If you want to help out with the project please DM me!!

Links:

• Repo: https://github.com/agentcathq/webmcp-react
• Playground: https://agentcathq.github.io/webmcp-react/playground/
• Install: npm install webmcp-react zod

If you're working on a React project and need some avatars for profiles, dashboards, user lists, comments, or mock data, here's a collection that might be useful.

There are 200+ free, open-source UI avatars that you can use in your projects.

There's also a UI Avatar Guide on the page if you want to learn more about using avatars in interfaces.

🔗 https://radianui.com/resources/avatar

Sharing it in case it's useful for anyone working on a React project!

Here is my honest question:

What's the actual problem with the useEffect hook? All over the X/twitter, I see a lot of negativity about this hook. It seems like a buggy thing in React.

My opinion is that developers blame useEffect because it's often used for data fetching as the primary use case. As we deal with various states like loading, data, error etc… synchronization of these causes bugs.

Also, a misunderstanding of the rendering cycle in React, such as where useEffect gets called could introduce additional misuses and bugs.

Hence, just saying useEffect is evil, may not be the right assumption is what I think. But, there could be cases that I'm missing.

What's your take or opinion about it?

Curious how people handle this in practice. Take something like a form field whose value is technically "derived" from a couple of other pieces of state (say, a computed total, or a filtered list) but where computing it is expensive enough or async enough that it doesn't feel right to just recompute it inline during render.

The "official" answer is usually "compute it during render, memoize with useMemo if needed," and I get why - it avoids the classic bug where a useEffect writes to state and triggers an extra re-render, plus it keeps the value always in sync by construction. But in practice I keep running into cases where the derivation genuinely can't happen synchronously during render (it depends on a ref, a DOM measurement, or an actual async call), and at that point it stops feeling like "derived state" and starts feeling like its own piece of state that just happens to be initialized from other state.

Where do you personally draw that line? Is there a rule of thumb beyond "sync and cheap = compute in render, anything else = its own state + effect"? And for the async case specifically, do you reach for a library (React Query, SWR, etc.) even for small in-component derivations, or is that overkill below a certain complexity threshold?

I put together a list of React problems I kept seeing come up in interview prep — mix of core hooks, a couple of classic "build this component" asks, and a few that companies like Meta/Airbnb/Flipkart actually use. Figured I'd share instead of just keeping the list to myself.

Didn't want to just describe them — you can open each one and actually write + run the code against real tests in the browser, no setup. Links go straight to the problem.

1. Build a counter with three buttons. The classic warm-up — but the interesting part is making sure rapid clicks never lose an update.

Practice counter problem

2. Delay a value until the user stops typing. You've used this in every search box you've ever built — now write the hook yourself.

Practice this problem

1. Track what a value used to be, one render ago. Small hook, but people trip over when it actually updates.

Practice usePrevious hook

1. Model a shopping cart's add/remove/update-quantity logic. A good test of whether you reach for useReducer or keep fighting with useState.

Create shopping cart

1. Build a traffic light that cycles red → green → yellow on its own timer. Looks simple until you have to get the timing and cleanup exactly right.

Create traffic light

6. Build a search box where slow responses can't overwrite fast ones. This is the one that trips almost everyone up the first time — asked at Airbnb.

Create search box

7. Render a comment thread with infinite nested replies. Recursion inside JSX — asked at Meta.

Build nested comment

8. Stop a long list from re-rendering every item on every keystroke elsewhere on the page. A real performance debugging exercise, not just a memo() one-liner.

Practice memoization

9. Give a callback prop a stable identity across renders. Sounds trivial, isn't — especially once a child component is memoized.

Stable callback

10. Build a modal where keyboard focus can't escape it. Accessibility question that separates "I use libraries" from "I understand the DOM."

Practice this problem

11. Write a fetch hook that won't re-request data it already has. Basically: build a tiny cache layer from scratch.

Build usecatche

12. Manage state for a multi-step form wizard. Back/next/jump-to-step, without the state turning into spaghetti.

Multi-step form

13. Build an autocomplete search with keyboard-navigable suggestions. Filtering logic plus a surprisingly fiddly amount of UI state.

React auto-complete practice

14. Add undo/redo to a stateful app. Command-pattern state history — the kind of thing that's easy to describe and annoying to actually implement cleanly.

Undo/Redo Functionality

15. Build a month calendar grid that handles real date math. Leap years, month boundaries, the works — asked at Flipkart.

Build calendar grid

Hi everyone,

I'm looking for a fully open-source spreadsheet component for React.

I do not want a paid/commercial library or a library where important spreadsheet features require a paid license.

I need something closer to Excel / Google Sheets, rather than just a data grid.

Main requirements:

• Fully open source and usable in a commercial project
• React + TypeScript support
• Import .xlsx Excel files
• Export to .xlsx
• Preserve Excel formatting as much as possible
• Formulas and calculations
• Multiple worksheets
• Cell formatting
• Merge/unmerge cells
• Copy/paste
• Sorting and filtering
• Data validation/dropdowns
• Freeze rows/columns
• Undo/redo
• Insert/delete/resize rows and columns
• Good performance with larger worksheets
• API for programmatically reading/updating cells
• Custom toolbar/components
• Extensible enough to implement drag-and-drop elements/components into spreadsheet cells

I've already looked at Univer and FortuneSheet, but I'm trying to find the best option with strong Excel import/export support.

My ideal flow is:

Import existing .xlsx → Edit in React → Export back to .xlsx

without losing important formulas, formatting, worksheets, merged cells, etc.

What is the best fully open-source React spreadsheet library in 2026 for this?

If you're using one in production, I'd really appreciate hearing about its limitations, especially around Excel import/export.

Thanks!

Introducing a new major update for the "Electron React App" desktop app's starter kit.

Let's talk about the worst part of building Electron apps. You want to minimize a window from a button. So you write a handler in main. Then invent a channel name. Then add a preload bridge entry. Then declare the types. Then finally make the call in the renderer. Five files for one button, and the whole thing silently rots the day you rename something.

v13 throws that out. You define the feature once in main, and the renderer just has it. Typed, auto-completed, React hooks attached. No channel strings anywhere.

Read more about the new changes in the Repository page:
https://github.com/guasam/electron-react-app

Feature Highlights:

- Type-safe IPC: queries, commands, streams, and events, inferred end to end
- Cross-window state owned by main, synced live, with opt-in persistence
- Sandboxed renderer with a two-line preload
- Custom window frame, titlebar, and menus with keyboard shortcuts
- Light and dark theme
- React error boundary with detailed dev reporting
- Import path aliases for app, lib, conveyor, and resources
- Shadcn UI on Radix, styled with TailwindCSS
- Vite HMR, with ESLint and Prettier preconfigured
- VS Code debug configs for both main and renderer
- electron-builder packaging for Windows, macOS, and Linux

If you were starting an Electron app tomorrow, what would you want already handled for you?

I've been working on HonestUI, and I wanted a real project to test the components against instead of making more isolated demos.

So I built this Next.js analytics dashboard starter and open sourced it.

It uses HonestUI for the UI and charts, with ECharts underneath the chart components. The starter has working date filters, revenue views, customer search and filtering, retention data, responsive navigation, loading states, and dark mode.

There is no auth or backend wired in. The data is static on purpose so the repo stays easy to clone and change.

I also tried to avoid the usual dashboard template where everything is a separate card with a number in it. I wanted it to look closer to an actual SaaS product.

Demo: https://dashboard-template.honestui.com

GitHub: https://github.com/honestui/honestui-dashboard

I'd be interested in feedback on the starter itself, especially anything you'd expect to be included before you'd actually use something like this for a new project.

Hi everyone!

For a while now, I have been working with React and Storybook libraries. react-docgen and react-docgen-typescript libraries are the supported libraries by Sitecore to extract metadata and populate the arg table with jsdoc comments and types.

As components' types grew more complex, react-docgen and react-docgen-typescript stopped giving me enough. They're good libraries, but they often fail to parse jsdoc comments and interfaces correctly, forcing me to manually override ArgTypes — which means duplicating information in both the type files and the Storybook files.

I was looking for some ideas to implement with AI, and it pushed me to build a new docgen parser. My main goals were parsing union types more accurately, making sure JSDoc comments always show up and letting me see the full structure of an interface without leaving Storybook.

Part of the motivation is also that the two main tools we have - react-docgen and react-docgen-typescript — haven't been updated in 6 months to a year.

This is my first open source project. I plan to keep improving it and maintain it long-term if people find it useful and see a future in it.

Link: https://www.npmjs.com/package/react-props-parser

I'd like you to test whether you are using Storybook and TypeScript, and share your feedback if the output is better for you compared to the default parsers.

If you let me know what breaks, what's missing, or what you'd want changed, I can turn around fixes quickly. Many thanks beforehand!

Hello, I'm a nextjs(react) fullstack developer, currently working in a company as a single developer on this position.

---

In the near future I want to transfer to a big company / team to work on big projects and as we all know most of the worlds big softwares aren't made with js, so i want to learn a mew programming language and follow a new path.

---

I'm trying to make a choice between: Java, Python or going into mobile development with React Native.

-

I was also thinking about RUST, but the market doesn't seem that big for it.

-

I'm not that good with math and I also know that python is often used in companies for data analysis.

---

I would appreciate any advice from you guys on helping me choose my next path.

Thank you!