On April 14th 2026, Salesforce published the starter template for its new Multi-Framework SDK . It imports Vite, Vitest, Tailwind, and a component set called shadcn/ui — and notably, it does not import the Lightning Design System. The SDK is named @salesforce/sdk-data, the framework it ships with is React 19, and the launch post calls React a first-class citizen of the platform. None of the front-end vocabulary Salesforce spent fifteen years building is in that starter.
I recently wrote about Headless 360 — the rebrand Salesforce announced at TDX in March, the first one in twenty-five years that doesn't extend the moat — arguing that the move asks customers to do less inside Salesforce, not more, by making every capability accessible directly as APIs, MCP servers, and CLI commands. The Multi-Framework SDK, opened to public beta soon after, is the other half of the same shape: if Headless 360 opened the data exit, the Multi-Framework SDK opens the UI entry, and the two moves shipped closely enough together that they read as a single announcement told in two pieces.
Here is what was actually announced. @salesforce/sdk-data is in open beta — scratch orgs and sandboxes only, English orgs only, no production support yet. React 19 is the supported framework today, with Angular and Vue on the roadmap. A single function, createDataSDK(), auto-wires authentication, GraphQL queries against the platform's UI API, and direct invocation of Apex methods, with field-level security, CRUD, and sharing rules enforced exactly as they are inside an LWC component. Apps deploy through the same sf project deploy start command Salesforce developers already use, the runtime sits on the Agentforce 360 Platform alongside LWC, and LWC itself is staying — multi-framework is additive, not a replacement. ABSYZ has the most concrete walkthrough of what the developer experience actually looks like.
As with anything Salesforce related, limits matter. There is no Lightning App Builder integration yet, which means a multi-framework app cannot be embedded inside a Salesforce-shaped page — apps launch from the App Launcher and live there. There is no support for Lightning Base Components, the eighty-plus component library most production teams rely on, which is why the starter ships with shadcn/ui in their place. The bundler is Vite, the test runner is Vitest, and none of the toolchain comes from inside the Salesforce-shaped ecosystem. It is fair to read the whole thing as a continuation of Lightning Web Runtime and LWC Open Source, both of which Salesforce has been talking about since 2023, and the genuinely new piece is the auto-wired createDataSDK() bundle, which removes the bridge-building friction that made every prior open-source LWC project awkward. The friction that protected the moat is the friction Salesforce just removed.
The previous seven rebrands all attached a new noun to the seat. Cloud, Social, Mobile, Customer 360, Einstein, Agentforce — each one made the Salesforce-shaped surface bigger and the seat licence more expensive to substitute. Headless 360 and the Multi-Framework SDK do the opposite, in two directions: data leaves the platform through APIs and MCP servers without a browser involved, while UI arrives on the platform through frameworks and component libraries Salesforce did not author. The Lightning Design System and the LWC component model were the moat artifacts that kept customers on Salesforce-shaped tooling even when the underlying value was, as Satya Nadella put it, CRUD with business logic stapled on top, and shipping a starter that uses neither is Salesforce conceding, in code, that those artifacts are no longer the point. That is not a concession a vendor makes from strength.
The other consequence, less remarked on but at least as interesting, is who can now build on Salesforce. For fifteen years the platform has had its own developer profession — a track defined by Apex, LWC, the design system, and a certification ladder wrapped around a vocabulary that exists nowhere else in the industry — and the Multi-Framework SDK collapses that wall in one step: a React developer who has never seen a Salesforce org can install @salesforce/sdk-data, run the starter, and ship something that talks to a real Salesforce backend with sharing rules enforced. The talent pool for the platform is no longer the people who picked Salesforce as a career; it is, in principle, everyone who already picked React, which is a much larger pool that does not exist on Salesforce's payroll, in Salesforce's training material, or inside Salesforce's partner network.
There is a quieter version of the same argument running underneath, and it is the one I think actually drove the framework choice. The frontier coding models — Claude, Codex, the rest — are exceptional at writing React and noticeably worse at writing LWC, for the obvious reason that the training corpus for React is the open web and the training corpus for LWC is documentation behind a Salesforce login. Shipping a React-first SDK is therefore shipping the framework the agents already know how to write, and a customer who lets an agent generate a multi-framework app gets a usable result on the first try in a way the LWC equivalent has never reliably produced. The alignment with where code generation is going is not stated in the announcement and does not need to be: the same agent layer Headless 360 invites in to read and write Salesforce data is the agent layer best at writing the front ends that sit on top of it. The two halves of the rebrand point at the same model of how software gets built next.
I have built on LWC since it shipped, written components against the design system, and integrated the parts of the platform the marketing material insisted would not need integrating. Some of that work was a real ergonomic gift — the auth model, the data layer, the trust footprint — and some of it was a tax paid in component primitives and styling vocabularies that existed nowhere else in the industry. The React-on-Salesforce experience createDataSDK() enables is the most pleasant front end for the platform I have ever seen — and the first one where the artifacts that kept it sticky have been quietly taken off the bill.
The signals worth watching from here are specific. Whether and when the SDK exits open beta into general availability is the first one. App Builder support is the second, and the more interesting — once a multi-framework app can embed inside a Salesforce-shaped page, "additive to LWC" stops being the framing and "default for new builds" becomes plausible. The arrival of Lightning Base Components on top of the new runtime, or the open-sourcing of the design system to make shadcn-equivalent ports possible, would be a third — closing the component gap the starter currently has to route around. Angular and Vue support is the fourth. The largest signal, and the one Salesforce cannot decide unilaterally, is whether the wider front-end community actually shows up: the runtime and the SDK are now in place, but whether developers who have never worked on Salesforce-shaped problems decide that this is the platform they want to build on is the question the announcement does not answer, and cannot.
The Headless 360 post closed by saying that for the first time in twenty-five years, the answer to what replaces the seat-based Salesforce is being written by people who do not work there. The Multi-Framework SDK is Salesforce explicitly building the tools for those people — the platform is no longer fighting the unbundling, it is shipping the SDK that accelerates it, and asking, politely, to be the substrate underneath. Whether that is strategic surrender or strategic re-platforming is the same question the previous post raised, sharpened now by what Salesforce shipped after it; the answer remains genuinely uncertain, but the direction the platform is being pulled in does not.
No comments yet