Recently, Salesforce has announced new multi-framework support for its platform as part of the Headless 360 strategy. It’s generally available as part of the Summer’26 release.
It unlocks new opportunities to accelerate project delivery and reduce operational costs, all while minimizing technical debt and business risks.
It means that we are finally getting support for open-source libraries. Initially, they have React as an example.
Since I’ve been building React and Angular apps for the Salesforce platform since 2016, I’d like to share some of my thoughts on how these changes can drive faster, safer, and more cost-effective project outcomes.
I already have some old posts about building Angular apps with Visualforce, architecting self-service portals outside Salesforce, and a podcast episode related to this topic.
Why third-party frameworks?
First, I’d like to start with the reasons why we used React back in the day when there was no seamless support on the platform yet.
Back in 2016, we didn’t have LWC and only had Visualforce at our disposal. Everyone who worked with it knows the developer experience was far from ideal.
On the other hand, modern JS frameworks such as React and Angular offer an incredible developer experience and allow teams to bootstrap single-page web applications in no time.
Time-to-market was the major factor back then. I joined the company that needed to develop an OEM package for the Salesforce platform to transform the licensing industry. We had the first client, an enterprise company in the entertainment space.
Choosing Angular allowed me to deliver the fully working POC in a matter of days.
Additionally, modern frameworks enabled us to drastically improve the user experience and develop highly interactive web applications that would’ve been difficult to build in native Visualforce.
Of course, in simple implementations it might be overkill, but it was incredible in the context of product and AppExchange development.
As a recap, there were the following benefits:
- Faster time-to-market
- Bypassing the SFDC platform’s limits
- Best performance and user experience
- Wider talent pool and community support
Introduction of Lightning Web Components
A few years later, we got Aura components, Salesforce’s attempt to develop its own UI framework.
The developer experience was still bad, and the capabilities were worse than those of the other frameworks.
Fortunately, we didn’t have to wait long before web components technology was introduced, and Salesforce developed the Lightning Web Component framework on its foundation.
LWC has been a game-changer for UI development for Salesforce. Finally, we got the modern technology to work with.
The best part was that it’s native technology and doesn’t require any workarounds. On the other hand, it’s web components with limited functionality.
Around the same time, we got DX, which improved deployments and added a bunch of out-of-the-box features.
However, we still had no local server, which meant we were missing the live component preview and state management. Also, it was difficult to extend and use third-party frameworks in the LWC context, so it wasn't worth it.
For example, I’ve recently worked on another AppExchange product in the travel industry, a large application with highly complex states and transactions.
At some point, you hit the wall with LWC, which eventually slows down development and negatively affects application performance.
Third-party frameworks in modern Salesforce
That said, in some circumstances, it still makes sense to use third-party frameworks to develop solutions off-platform and integrate them with Salesforce.
The most common use cases are AppExchange, where many companies delegate UI heavy lifting to Angular/React/Vue, and self-service portals, where organizations want to leverage existing resources, ensure the same look and feel, improve UX, and overcome limitations.
Companies were already using the SFDC platform as headless and developed solutions across multiple clouds, so it makes total sense to move to Headless 360.
The main concern for custom development has always been platform support, which made it a suboptimal choice in certain scenarios.
For example, if an external portal is developed, integration, authorization, and sharing logic must be built and maintained independently, which is a major risk in regulated industries where long-term support, compliance, and platform security far outweigh any initial implementation savings.
Now that Salesforce has introduced multi-framework support, it perfectly aligns with the strategy.
We can develop modern web applications and still rely on seamless integration.
How does it work
Currently, Salesforce supports only React as a framework.
I tried to look into other frameworks because it’s possible to have an empty app template and, technically, create whatever application you want. However, the problem lies with the build, as the application must be configured to be compatible with Salesforce tooling.
Overall, the UI bundle, as Salesforce calls it, is a JavaScript web application that communicates with the platform via the REST API.
Back in the day, we had to use Remote Actions and the API directly to make callouts and invoke Apex methods.
The multi-framework introduced a Data SDK library with native support, making data communication straightforward and requiring no extra setup.
It automatically handles OAuth flows, access tokens, refresh tokens, and session states.
Therefore, all permissions and sharing are handled automatically, which is especially relevant for customer and partner portals.
The SDK supports GraphQL, simplifying data retrieval and mutations. Also, if you need to invoke Apex methods (RestResource and InvocableMethod) directly, you can do that with the SDK’s fetch method.
You can read more about the Data SDK here.
More features
Finally, the ui-bundles offer the proper live preview in the local environment.
It uses the currently authorized user in SFDX to make API calls to the connected org.
It significantly improves the developer experience and speeds up the process, so there is no longer the need to deploy and validate changes in the live org environment.
Best of all, as a native technology, multi-framework support lets us embed other Salesforce platform features, such as Agentforce, directly in modern apps, enabling new use cases and efficiencies without compromising system integrity.
Conclusion
I’ve been waiting for native third-party framework support for many years and am looking forward to getting my hands on it in the next implementations.
Overall, it’s great! It offers seamless integration and aligns with the current state of enterprise app development.
I’m sure a lot of people talked about the benefits already, but here are some just as a recap:
- It increases the development pace, leading to faster time-to-market
- Community support is much larger for frameworks like React, so it’s easier and faster to resolve issues.
- React offers incredible capabilities out of the box, such as client-side routing for developing fully fledged single-page applications, as well as a ton of open-source libraries to cover needs we lack in LWCs, e.g., state management, forms, etc.
- The talent pool is much larger, and more developers are willing to work with React rather than LWC. Plus, many organizations can leverage the tech talent they already have.
- Companies can use existing design systems with no extra effort.
- It improves the user experience, leading to better customer satisfaction.
I’ve already mentioned that the biggest concern has been native support, and in some cases the benefits still outweigh that. I personally delivered at least 5 projects with Angular and React for Salesforce that I can remember.
Now, when Salesforce has solved that challenge for us, it becomes much easier to choose React for the next managed package, internal SF app, or Experience Cloud implementation.
I wouldn’t say it's a no-brainer, because everything has to be analyzed for each specific use case, but it’s always great to have such a powerful tool at our disposal.
If you have already developed new UI Bundles for Salesforce or are looking into it to improve delivery speed, eliminate tech debt, and cust costs, I want to hear your thoughts! Please connect with me on LinkedIn or reach out via email!
Nikita Verkhoshintcev
Senior Salesforce Technical Architect & Developer
I'm a senior Salesforce technical architect and developer, specializing in Experience Cloud, managed packages, and custom implementations with AWS and Heroku. I have extensive front-end engineering experience and have worked as an independent contractor since 2016. My goal is to build highly interactive, efficient, and reliable systems within the Salesforce platform. Typically, companies contact me when a complex implementation is required. I'm always open to collaboration, so please don't hesitate to reach out!
