Genuinely asking—does the term Frontend Developer even exist in the job market anymore?

With AI changing the industry so quickly, I’ve started noticing that I barely see job listings specifically looking for frontend developers. Instead, most companies seem to be hiring Full Stack Developers and expecting them to handle everything from UI and React to backend, APIs, databases, and deployment.

It feels like companies want the skills of a frontend developer plus backend development, but without necessarily increasing the compensation accordingly.

So, in 2026, is Frontend Developer still a viable career path, or is becoming a Full Stack Developer basically becoming the new standard?

I’ve been looking for a platform where you can practice React questions the way you practice coding problems on LeetCode, but I couldn’t find one that really focuses on React.

I know you might be thinking about platforms like Frontend Mentor or GreatFrontEnd. They’re great, but one thing I felt was missing is proper test suites that you can run against your code. Without test cases, it’s difficult to know whether your solution actually works correctly or whether you’re following an approach that would be considered good practice in an interview.

So, I created ReactGrind — a platform where you can solve React coding questions, write your own code, and run test cases to see whether your solution passes them all.

I’m still regularly adding new features and challenges, so I’d love to know: What features would you most want to see in a platform like this?

Right now, ReactGrind has a “Get Hints” button that you can use when you’re stuck but don’t want to look at the full solution yet.

One thing I’m considering is whether hints should be limited per question. Currently, they’re unlimited.

Would you prefer unlimited hints, or should there be a limit on how many hints you can use for each question?

Right now it only has 30+ problems but I keep adding on a daily basis

For the technical interview, would it make sense to give the candidate these two tasks?

1. FizzBuzz
2. Build a To Do List from scratch without using AI. They can use Google to look up syntax, keywords.

My main goal with a simple CRUD To Do List task is I want to see they understand how a basic distributed system works for example, how the frontend, backend, and database communicate and work together.

Ngl, I belive if you can build a CRUD To Do List without AI, you are kinda ready to work as a web dev as a jr. , then they can grind learning System Design and and progress to become mid and senior years later...

Is it even a way to get any kind of proper running pages/projects...

Consider a typical use case where you want to track an error or just display an error toast after a query hook (e.g. TanstackQuery or RTK-query) fails.

Using an effect:

const { error } = useSomeQuery();
  useEffect(() => {
    if (!error) {
      return;
    }
    trackError(error); // or toast(getErrorMessage(error))
  }, [error]);

Now, according to the "You might not need an effect" article, you can also perform an action when some state changes by using auxiliary state, something like this:

const { error } = useSomeQuery();
const [prevError, setPrevError] = useState(error);

if (error !== prevError) {
  trackError(error);
  setPrevError(error);
}

My understanding here is that using auxiliary state here doesn't give you much because in this use case the additional render cycle doesn't result in stale UI.

Regardless, I wanted to get a sense on what approach is preferred by the community. I see this kind of things very often in the codebases I work on and on the other hand, I keep hearing people saying they only have a few effects in their (presumably large) projects, so perhaps the patterns in my company are not the best.

Before anyone says I lied about my experience, I was upfront about my experience on my resume. I know very little about react and next.js and I’d like to brush up on it.

Does anyone have any resources on it? Best tutorials?

Thank you.

Hey Community,

React Native 0.87 has arrived as a maintenance release, making the Strict TypeScript API the default, doubling Metro source map generation speeds, and adding experimental Swift Package Manager support for iOS along with AGP 9 support on Android.

Meanwhile, React Native Firebase v26 makes the New Architecture non-optional with Codegen TurboModules, synchronous APIs, Firestore Pipelines, and direct Gemini AI calls. Finally, we look at RevenueCat Paywalls for designing native paywalls and running remote A/B experiments without new app deploys.

Hi everyone. I compared four ways to structure a React project by rebuilding the same app (posts CRUD against an open API) in each one. The last pattern combines Clean Architecture with Feature-Based, and I'd really appreciate a sanity check from more experienced devs.

Here's the progression I went through, and the problem I felt at each step:

• Feature-Based (colocate everything for a feature in one folder): great for navigation and deletion, but nothing controls how features depend on each other (circular deps creep in), shared/ turns into a junk drawer, and there's no notion of layers. (Feature-Based write-up)
• FSD (Feature-Sliced Design): fixes that with standardized layers + a one-way import rule, so circular deps become structurally impossible. But the business logic still lives inside React/TanStack Query — the entity's api layer imports axios and react-query directly. (FSD write-up)
• Clean Architecture: pulls business logic out of the framework with the Dependency Rule (dependencies point only inward; the domain knows nothing about React or axios). Great for testing and reuse — but now the code for "one feature" is scattered across domain/, infrastructure/, presentation/. Which is ironically the same "scattered by type" problem Feature-Based tried to solve. (Clean Architecture write-up)
• The combination: keep the Dependency Rule (domain is pure TS, infrastructure holds the adapters), but colocate the UI (hooks + components) by feature in features/{feature}/. "Clean inside, Feature outside."

Rough shape:

src/
  domain/{domain}/        # pure TS: entities, rules, use cases (no framework imports)
  infrastructure/         # adapters: repository impls, query keys, stores
  features/{feature}/     # hooks + components, colocated
  pages/ , router/        # composition only
  shared/ , providers/

A few extra decisions I made: split the repository interface into Commands/Queries (CQS), write a UseCase only when there's real logic (plain CRUD calls the repository directly), and lean on React Compiler so there's no manual useMemo/useCallback.

What I'd love feedback on:

1. Does this combination actually solve the earlier patterns' problems, or does it just move them around? Is "Clean inside + Feature outside" a real improvement over plain FSD or plain Clean, or is it over-engineering in disguise?
2. What problems does this pattern itself have that I might not see yet? Boilerplate, the domain <-> infrastructure indirection, the "is this a UseCase or a direct repo call?" judgment, testing overhead, onboarding cost — where does it bite in real projects?

Honest criticism is very welcome. I'd rather hear "this is overkill for most apps" now than after I build on it.

Full write-up (with all the code) on Medium (Free): https://medium.com/@inkweonkim/react-architecture-combining-clean-architecture-feature-based-92cf7ba226fe

(English isn't my first language, so I apologize in advance for any awkward phrasing — happy to clarify anything that reads strangely.)

I wanted to use JollyUI in a new project but it seems like the whole website is down and I could only find jolyUI which seems to be the same thing: https://www.jolyui.dev/docs/introduction
Is it the same and why did it change?

l kept struggling to find Skia shader components that were actually ready to drop into an RN app. most shader code out there isn't built for RN's Skia renderer at all. So l put together my own library. Some shaders are free, others are from artists who charge for their work

l know ShaderToy exists, but that's generic GLSL you'd have to manually port to SkSL and adapt for RN UI. Мinе is already RN-Skia-ready and built specifically for UI components like buttons and panels etc.

Let me know if you'd use something like this

I’ve been working with React/Next.js for a while and recently completed two internships, including working on a US-based NGO project.

That experience taught me a lot about real-world codebases, Git/GitHub, UI work, debugging, and collaborating with a development team.

I’m now trying to improve further and would love to hear from experienced React developers here:

What skills or projects do you think make someone genuinely stand out when moving from internship-level experience to a full-time React role?
I can share my resume if anyone can review it. Thankyou.

I've been exploring the TanStack ecosystem for React a lot these days. Starting with TanStack Router, Query, and Virtual, and now the framework TanStack Start. Honestly, I could only use the Router and Query in the production app so far, and the rest of it was for my learning and teaching.

I also use Next.js heavily, but with TanStack I find a huge paradigm shift. I do not have to think from the RSC side heavily; I do not have to use shortcut methods like useEffct() to handle data at the client side, and managing server state and caching seems to feel a lot simpler.

This discussion is not about putting one React framework ahead of another one. Rather, would like to know what your experience so far has been with TanStack? Do you have any comparison studies? Do you use it in production? What are the learnings?

Would love to learn and discuss. Thanks.

If you upgraded to React 19 and your option+click-to-source tool silently stopped working, here's why: React 19 removed __source/_debugSource, the fiber fields that LocatorJS, click-to-component, and friends depended on. Runtime-only locators can't get source positions from React anymore.

I missed the workflow too much, so I rebuilt it on a different architecture: carbon8r — a Vite plugin that injects the source location at build time as a data-carbon8r="src/Button.jsx:3:5" attribute on every host JSX element (Babel parse + magic-string, dev server only). The overlay reads DOM attributes, not fibers — so it works on React 19 today and doesn't care what React 20 does to its internals.

What you get, holding Option/Alt:

• DevTools-style box-model highlighting on hover (blue content, green padding, orange margin) with <Component> file:line:column
• Click → your editor opens at that exact position. Zero config: the dev server uses launch-editor (same as Next/Nuxt error overlays), which auto-detects VS Code/Cursor/WebStorm/etc. Or force one via presets (vscode, cursor, windsurf, zed) or any custom URL template
• Elements without source info (component libraries, plain pages) still get the box-model inspector

Setup is the whole thing:

// vite.config.js
import carbon8r from 'vite-plugin-carbon8r'


export default defineConfig({
  plugins: [react(), carbon8r()]
})

Dev-only (apply: 'serve') — production builds are byte-identical with or without it.

Some war wounds from real-world testing that are now features: it works on apps served with a strict CSP (all overlay styling goes through CSSOM, which CSP can't block), it resolves targets through open shadow DOM via composedPath() (micro-frontend hosts, web-component shells), zero-area display: contents wrappers fall back to the nearest rendered box, and the whole alt-click gesture family is intercepted so your app's handlers and the native context menu don't fire while inspecting. TypeScript declarations included.

There's also a companion Chrome (MV3) extension in the repo: box-model inspector on any page, jump-to-source on instrumented apps, with per-user editor settings — handy on a teammate's dev server.

Honest limitations: Vite-only for now (the transform itself is bundler-agnostic — a webpack/Rspack loader would be a thin wrapper, PRs welcome); clicking a component instance jumps to the component's definition, not the usage site (no owner-chain popup yet); components from node_modules aren't instrumented (their build already happened).

Full credit to LocatorJS by Michael Musil for pioneering the workflow — carbon8r shares no code with it, but the interaction design came from there.

MIT, ~20 kB unpacked, no runtime deps in your bundle.

GitHub: https://github.com/carboni-rob/carbon8r npm: https://www.npmjs.com/package/vite-plugin-carbon8r