React on Salesforce Is Now Official.

For years, the Salesforce frontend story was simple and non-negotiable: you learn LWC, or you don't build on the platform. That's changed. Salesforce Multi-Framework, announced at TrailblazerDX 2026, is a framework-agnostic runtime on the Agentforce 360 Platform that lets you build native Salesforce apps in React, with Vue, Angular, and others coming. This is the most significant shift in Salesforce frontend development since LWC replaced Aura.

Why This Actually Matters

The LWC-or-nothing constraint wasn't just a technical limitation, it was a hiring and adoption barrier. React shops evaluating Salesforce had to either retrain their team or accept that platform UI work would live in a separate mental model. That friction was real, and it kept a lot of good frontend talent at arm's length from the platform.

Multi-Framework removes that wall. If your team already ships React, you now have a sanctioned, first-class path to build Salesforce-native UI without abandoning the ecosystem you've invested in. The npm registry, the component libraries, the testing patterns, the tooling muscle memory — it all transfers.

This matters beyond just React. The signal is that Salesforce is no longer trying to maintain its own parallel web stack in isolation. Pair Multi-Framework with Headless 360 and the Agentforce Experience Layer, both also announced at TDX 2026, and a clear direction emerges: the platform is opening up to where the web already is.

What's Actually in the Box

The starter template is where the story gets concrete. Generate a new ui-bundle with:

sf template generate ui-bundle

What you get is not a Salesforce-flavored approximation of a modern frontend setup. It's the real thing:

• Vite for bundling and dev server
• Vitest for testing
• Tailwind CSS for styling
• shadcn/ui for components
• @salesforce/sdk-data for platform data access

The bundle lives at force-app/main/default/uiBundles and runs locally at localhost:5173, exactly like any Vite app. No Salesforce-specific dev server, no proprietary preview layer you need to learn.

Data access is handled through createDataSDK(), which manages auth automatically. You write GraphQL queries for record CRUD, invoke Apex methods via SDK fetch(), and query user and context info through UI APIs. No manual token management. It's genuinely clean.

On the Tailwind point: we built LWC-Tailwind to bring Tailwind into LWC projects because the platform wasn't meeting developers there. Seeing it ship in the official starter template isn't just convenient, it's Salesforce explicitly acknowledging that developers shouldn't have to fight the platform to use the tools the web already converged on.

For AI-assisted scaffolding, Agentforce Vibes 2.0 generates React apps from natural-language prompts, producing React components, GraphQL queries, and metadata together. The Salesforce MCP server, Live Preview, and Einstein Trust Layer are all part of the tooling layer. And if you want to explore working examples, the multiframework-recipes repo has 20+ samples to pull from.

React vs. LWC: The Honest Comparison

React being supported doesn't mean LWC is the wrong choice. They have genuinely different strengths, and the right answer depends on what you're building.

LWC is still the right default for declarative components that live in Lightning pages, need App Builder support, or rely heavily on the base component library. It's been optimized for the platform for years and that shows.

React earns its place when you have existing component libraries you want to reuse, a React-native team that shouldn't have to context-switch, or UI that needs to run both inside and outside Salesforce. The cross-platform reuse argument is real, building components that work in your React app and your Salesforce org is now a legitimate architecture.

What To Do Right Now

Multi-Framework is in open beta for scratch orgs and sandboxes. It is not deployable to production orgs. Micro-frontend embedding of React into Lightning pages is in developer preview, with GA targeted for Spring 2027. Some platform APIs are not yet available in the beta runtime.

Given that: don't migrate anything. Don't rebuild a working LWC app in React because this exists. What you *should* do:

1. Spin up a scratch org and generate a ui-bundle

2. Clone the multiframework-recipes repo and run a few samples

3. Identify one new piece of work, a net-new internal tool or a greenfield integration, where you can evaluate the stack for real

4. Get your React developers into a scratch org before you make any architectural decisions

A Note for Norwegian Teams

There's a practical limitation worth flagging for teams in Norway: the beta currently has issues with non-English orgs. The recipes repo works around this by hardcoding "language": "en_US" in the scratch org definition. Norwegian-language orgs will hit problems during this beta phase.

This is a solvable limitation, and it's likely to be addressed before GA. But right now, if your org is configured for Norwegian, plan to test in an English-default scratch org. Don't find this out mid-demo.

Where This Is Going

Multi-Framework is real, but it's beta. The production path isn't there yet, App Builder integration is still coming, and Norwegian orgs need a workaround. Keep expectations calibrated.

What it represents, though, is a genuine strategic shift. Salesforce spent years building a walled web stack, LWC, Aura before it, proprietary tooling throughout. Multi-Framework, alongside Headless 360 and the Agentforce Experience Layer, signals that the platform is moving toward the web rather than away from it. For React developers who've avoided Salesforce, the platform just became worth a second look. For Salesforce teams, the talent pool just got significantly larger.