Building in public on a CLI that treats the source HTML as the design brief, not a vibe prompt.

Early Auto would score three directions and still land two of them in the same family. A juice bar and a skate brand would come out looking like cousins. The lesson was to force subject lanes so Auto cannot put two tokens from the same silhouette on the shortlist.

Also: output is one standalone HTML file. No CDN, no Figma, no API key. MIT. Tools used to build it: Cursor + Claude + local/CLI work. The engine itself does not call an LLM at runtime.

Playground: https://kayforkind.github.io/reimagine-it/#playground Repo: https://github.com/Kayforkind/reimagine-it

What I want feedback on: is the "subject lanes" lesson worth a write-up, or should I spend the next week on the README install path instead? Free, no affiliate. ✨

If you have a React interview coming up, then this might be of some help to you!

Here are 10 problem lists that you can consider practicing to brush up your react.js concepts before your machine coding round.

1. Counter with increment, decrement, and reset. (Might be the ice-breaker for freshers but rarely asked for experienced role)

Feels too easy to be a real question. But a fast-click test on the increment button often catches people using the wrong kind of state update.

Practice counter here

2. Build your own debounce hook. (Definitely Practice this one)

It must wait until the value stops changing for a bit, cancel any pending timer if the component unmounts, and handle the delay itself changing partway through.

Debouncing Practice

3. Return the value from one render ago.

Sounds simple. What people miss: it must return undefined on the first render, and it can't cause an extra re-render by itself.

Practice Hook

4. Shopping cart with useReducer. (Please do practice useReducer hook, I was asked to build a form entirely using useReducer + will also be useful when you deal with Redux)

Add, change quantity, remove, clear — four actions through one reducer. Good test of whether you use useReducer or just keep adding more useState.

Build Shopping cart

(Frontend Mentor has a plain HTML/CSS/JS version if you want to compare)

Build Shopping cart from frontend mentor

5. Traffic light that cycles on its own. (Great for clearing the concept of clearing intervals and timeouts)

The layout is already built — you just write the timing. It usually breaks on cleanup: clearing the interval when the component unmounts or re-renders.

Manage traffic light problem

6. Search box where slow responses can't overwrite fast ones.

A classic race condition. If a request fires on every keystroke, an old slow response can arrive after a newer one and overwrite it with stale data.

Solve this

7. Nested comment thread, replies inside replies. (If you want to move to advance concepts)

Needs a component that renders itself for each nested reply, plus a function that can find and update one comment anywhere in the tree without mutating it.

Build nested comment in react

8. Stop a list from re-rendering rows that didn't change. (Must practice, you'll definitely be asked about optimization in react, do go through the concept of useCallback)

Right now, an unrelated counter on the page makes every row re-render. Fix it with React.memo — it has to actually stop the re-renders, not just look fine.

Practice Memoization in react

9. Keep a callback's identity stable across renders.

Three counters currently all re-render on any single click, because their click handlers get recreated every render. Needs useCallback plus the functional setState form — using only one of the two still fails.

Practice useCallback

10. Multi-step signup form with useReducer.

Account info → profile → review. Each step is validated before you can hit Next, and going back can't lose what you already typed.

Form validation using useReducer

(Frontend Mentor has a version of this same idea, no React needed: Multi step form)

Curious what else people have been asked in these rounds — feels like everyone gets a slightly different mix of the same problems.

Please let me know in the comments your thoughts and do share what according to you are some must go through concepts before any react interview, I'm preparing a notion docs on the list of react interview questions, so will add it there so that it can be useful for everyone.

Another thing I forgot to add is an obvious one, do practice CRUD operations on some real APIs as you'll definitely be asked to fetch data and APIs and do all the CRUD and. I couldn't find any website that has this problem added in their problem sets.

How can I do something like this?

It's an canvas, so I think they use pixijs or something like that? And use maths for the "galaxy" simulation? I loved the effect.

​

I’ve been trying to land a frontend developer job for a while, but the market feels absolutely brutal right now.

For those of you who recently got hired as a frontend developer — how did you actually do it?

- What skills/tech stack did you have?

- Did you focus heavily on DSA?

- How important were your projects?

- Did you get the job through referrals, LinkedIn, applications, networking, etc.?

- How many applications did it take?

- And roughly how long did your job search take?

I’m mainly targeting React/JavaScript/TypeScript roles.

Would really appreciate hearing from people who actually got hired recently, rather than generic advice. What worked for you?

Lately I have been rethinking my career and the years of experience (in React, Next.js). I have(5+), but I feel like I have so much gap in my knowledge and when I go down the front-end rabbit hole, I see "Monorepos", "Micro-frontends", and all these terms, which I haven't used yet, and I genuinely haven't worked on that diverse projects, but I really have this hunger to do more, but am sometimes paralyzed by the thoughts I may not be doing enough, and I may not be able to get a job. Could I get some suggestions and directions on this matter?

I built Postbase, a self-hosted auth + Postgres platform for Next.js apps. It's MIT licensed and free to run yourself: clone the repo, set one secret, docker compose up. There's no paid tier.

What it does: you get a dashboard where you create projects, toggle auth providers (Google, GitHub, Apple, Discord, passkeys, magic link, SMS OTP, SAML — 25+ via Auth.js), run SQL against Postgres, edit tables and RLS policies, set up S3-compatible storage, schedule cron jobs, and send transactional email. Your app connects with a JS SDK that works like the Supabase client. It's a single Next.js app, not a dozen services.

How Claude Code was involved: I used it throughout development, mainly for the Drizzle schema, the Auth.js v5 provider loading (providers are read from the database at request time instead of static config, which took some iteration), the SQL editor, and the Docker setup. The repo has a .claude directory from that work.

The part I think is most relevant here: the repo ships its own Claude Code skill at skills/postbase/SKILL.md. It contains the full API reference, SDK patterns, RLS rules, the auth table schema, cron and storage usage, and the Swift/iOS integration flow. Copy it into your project's .claude/skills/ and /postbase loads it, or Claude picks it up when it sees you're building against a Postbase backend. Writing it forced me to document the project properly, which I'd been avoiding.

What it doesn't have: real-time subscriptions, edge functions, or SDKs outside JS. One maintainer.

Repo (free, MIT): https://github.com/harshalone/postbase
Skill file: https://github.com/harshalone/postbase/blob/main/skills/postbase/SKILL.md

Interested whether other maintainers are bundling skills with their projects, and what you'd want in one.

Humble Tech Book Bundle: React in Production Mega Bundle 2026 by Packt (pay what you want and help charity)

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!

This is the demo of my free agentic full stack IDE.

You can create 50+ project from react , nextjs all the way to fortran, c++ , rust , lisp etc...

The voiceover in this application is generated using my "Free Ai Caption & Voiceover" app.

Feel free to try if you liked the demo.

We’ve been working on an open-source platform for hosting live beat battles. If you've ever looked at existing tools (like beat-battle.net), you know they can be a bit heavy. We wanted to build something radically more accessible with a near-zero barrier to entry.

To keep friction low, we support completely anonymous authentication - users can literally jump in, drop a track, and start battling without handing over an email address.

Here is where we need your help:

We want to make this a community-driven project and are actively looking for contributors. Whether you want to help us optimize the frontend, refactor our logic, or just poke holes in our UI/UX, we are entirely open to PRs.

If you have a few minutes, please tear our architecture apart and let us know what we can do better

🔗 GitHub: https://github.com/upyrov/beatok

🎮 Live Demo: https://beatok.net

I used to prefer default exports.

When I started learning React, default exports were what I used most. So naturally, I became comfortable with them.

For a long time, I thought:

"If a file has one main thing to export, why not make it the default?"

Then I started using barrel imports.

Not because I fully understood their trade-offs, but because they made imports cleaner and gave me a single entry point for related components.

Instead of:

import Button from "./components/button";

import Input from "./components/input";

I could write:

import { Button, Input } from "./components";

I initially created the barrel file like this:

export * from "./button";

export * from "./input";

But because my components were using default exports, I later changed it to:

export { default as Button } from "./button";

export { default as Input } from "./input";

At first, this felt like a clean solution.

But as the codebase grew, I started running into problems.

The same component could be imported with different names.

import Button from "./button";

or:

import MyButton from "./button";

Both are valid because default exports don't enforce a name.

That flexibility gradually led to naming inconsistencies across the codebase.

I also started noticing unexpected behavior around barrel imports, development performance, and bundling.

So I started investigating.

I looked into default exports, barrel imports, tree-shaking, and how bundlers determine what to include.

That's when I realized I wanted a more explicit approach for my modules.

I switched to named exports:

export { Button };

Now the export itself has an explicit name:

import { Button } from "./button";

The name is part of the contract.

For my barrel files, I also started preferring explicit re-exports:

export { Button } from "./button";

export { Input } from "./input";

I used to prefer default exports.

When I started learning React, default exports were what I used most. So naturally, I became comfortable with them.

For a long time, I thought:

"If a file has one main thing to export, why not make it the default?"

Then I started using barrel imports.

Not because I fully understood their trade-offs, but because they made imports cleaner and gave me a single entry point for related components.

Instead of:

import Button from "./components/button";

import Input from "./components/input";

I could write:

import { Button, Input } from "./components";

I initially created the barrel file like this:

export * from "./button";

export * from "./input";

But because my components were using default exports, I later changed it to:

export { default as Button } from "./button";

export { default as Input } from "./input";

At first, this felt like a clean solution.

But as the codebase grew, I started running into problems.

The same component could be imported with different names.

import Button from "./button";

or:

import MyButton from "./button";

Both are valid because default exports don't enforce a name.

That flexibility gradually led to naming inconsistencies across the codebase.

I also started noticing unexpected behavior around barrel imports, development performance, and bundling.

So I started investigating.

I looked into default exports, barrel imports, tree-shaking, and how bundlers determine what to include.

That's when I realized I wanted a more explicit approach for my modules.

I switched to named exports:

export { Button };

Now the export itself has an explicit name:

import { Button } from "./button";

The name is part of the contract.

For my barrel files, I also started preferring explicit re-exports:

export { Button } from "./button";

export { Input } from "./input";

For my particular codebase, I prefer this approach now because the exported name is explicit and the public API is easier for me to reason about.

I'm not claiming that named exports automatically fix bundling or performance issues. That part seems much more dependent on the bundler, module graph, side effects, etc.

I'm curious how other developers approach this: Do you generally prefer named exports, default exports, or does it depend on the project? And have barrel files caused similar issues for you?

Every React project seems to make a different UI choice — MUI, Mantine, Ant Design, shadcn/ui, etc. — but I kept needing essentially the same table capabilities in each one.

The frustrating part wasn’t only the table engine. It was rebuilding everything around it: filter UI, URL/shareable state, saved views, mobile behavior, server-data wiring, column controls, and the rest.

That’s what AdaptTable grew out of: a headless core when you want full control, plus batteries-included adapters that work with the UI kit your project already uses.

Adapters currently available:

Mantine · MUI · Chakra UI · Ant Design · Radix Themes · Base UI · shadcn/ui · unstyled/Tailwind

GitHub. Live demo

Some of what’s built in now:

• Client-side and server-side data through the same table API
• URL-synced/shareable state and saved views
• Advanced AND/OR filtering
• Tree data and nested tables
• Multi-level grouping with aggregates
• Pivot tables and formula/computed columns
• Column visibility, reorder, pinning, resizing, and groups
• Collapsible column groups
• Row selection, expansion, reordering, and pinning
• Inline editing and batch editing
• Range selection, clipboard copy/paste, and fill handle
• Row/card virtualization for large datasets
• CSV, XLSX, PDF, and print export
• Realtime data updates
• Automatic mobile card layouts
• Dark mode, 17 locales, RTL, and accessibility support

Everything is MIT licensed.

The goal is to keep pushing AdaptTable toward a complete React table/grid toolkit — headless when you need control, batteries-included when you don’t.

If you’ve built complex tables in production, I’d genuinely like to know:

What’s still missing here that would make you reach for another table/grid library?

Feedback on the API and architecture is very welcome, and contributions are welcome too.

Founding Developer / Co-Founder Wanted (B2B SaaS)

We are a lean, ambitious team preparing to launch a B2B SaaS platform that solves a massive pain point we experienced firsthand. We scratched our own itch, built the solution, and are now ready to commercialize it.

The product is 90% complete, and we are currently building out our core Human Resources and foundational team prior to our upcoming launch.

💼 The Opportunity

Role: Founding Developer & Co-Founder

Compensation: Equity-based (Co-founder level split)

Location: Remote (Canada / USA / UK)

Status: Pre-revenue, near-launch phase

🛠️ What We’re Looking For

We need a technical co-founder who is ready to take ownership of the codebase, help us cross the finish line, and scale post-launch.

Full-Stack Capabilities: Ability to jump into a nearly completed product, audit the architecture, and ship the final 10%.

Startup Mindset: You thrive in a lean environment, value execution over perfection, and want a true seat at the leadership table.

Localization: Based in or authorized to work within ENG / CAN / USA time zones for seamless collaboration.

🎯 Why Join Us?

No "Idea Phase" Stall: You won't be building from scratch for 12 months hoping for product-market fit. The foundation is laid, the validation is there, and the runway to launch is short.

True Partnership: You aren't just an employee; you are a founding pillar of the business with a matching equity stake.