LWC (the on-platform framework you write inside a Salesforce org) and LWC Open Source (the framework you can npm install and use anywhere) share the same component model and authoring experience — but they target very different runtimes.
The shared part
Both flavours use:
- The same component shape (
.html,.js, optional.css). - The same decorators:
@api,@track,@wire. - The same lifecycle hooks:
constructor,connectedCallback,renderedCallback,disconnectedCallback,errorCallback. - The same template directives:
lwc:if,for:each,iterator,lwc:ref, slots. - The same reactivity model.
A leaf-level UI component you write for LWC OSS often copies cleanly into a Salesforce org with only meta-XML added.
Where they diverge
| On-platform LWC | LWC OSS | |
|---|---|---|
| Where it runs | Inside Salesforce orgs | Anywhere — Node server, static hosting, CDN |
js-meta.xml config | Required | Not used |
Base components (lightning-*) | Hundreds of pre-built | None — bring your own |
Salesforce data modules (lightning/uiRecordApi, lightning/messageService, @salesforce/apex/*) | Available | Not available |
| Security model | Lightning Web Security (LWS) sandboxing | Standard browser sandbox |
| Build tooling | Provided by Salesforce CLI / Lightning Platform | lwc-services, Webpack, Rollup, or Vite |
| Deployment | sfdx project deploy start | Static hosting / Node / whatever |
| Routing | Page-level config via App Builder | Your choice (@lwce/router, hand-rolled) |
| State management | LDS + wires + LMS | Your choice (Redux, MobX, plain stores) |
| SSR | Limited (Lightning Web Runtime) | Yes, via @lwc/engine-server |
A minimal LWC OSS app
npx create-lwc-app my-app
cd my-app
npm install
npm run watchWhat you get: a project with package.json, a src/modules/ folder, a dev server, and one starter component. No org, no SFDX, no metadata API.
What you can do in OSS that you can’t on platform
- Use any npm package — no Locker/LWS restrictions, no platform allow-list.
- Run server-side rendering for SEO or first-paint performance.
- Embed in non-Salesforce sites — marketing pages, customer portals, internal tools.
- Customise the build — Tree-shaking, code splitting, dynamic imports, micro-frontend patterns.
What you can’t do in OSS
- Read Salesforce data directly. No
@wire(getRecord). To talk to Salesforce, hit the REST or GraphQL APIs yourself (with OAuth or Connected App auth). - Use base components.
<lightning-datatable>doesn’t ship with OSS. Either build your own, use a third-party library, or import from@salesforce-ux/design-system. - Tap LDS, LMS, Lightning Navigation, or Toasts. Anything under the
lightning/namespace lives only on the platform.
When to use each
On-platform LWC is the obvious choice when:
- You’re building inside the org — record pages, App Builder, Experience Cloud, Flow screens.
- You want LDS caching, base components, and zero auth setup.
- The audience is logged-in Salesforce users.
LWC OSS earns its keep when:
- You need a public-facing site or app that happens to share components with your in-org UI.
- You’re standardising the front-end stack across products that aren’t all on Salesforce.
- You’re building a design-system library you want consumable both inside and outside the platform.
- SSR or specialised bundling matters to you.
The “hybrid” pattern
A pattern worth mentioning in interviews: a shared component library of pure presentational components written once, consumed in both runtimes. Keep the components free of lightning/ imports and @salesforce/* imports — they’ll work in OSS as-is. Add .js-meta.xml and Salesforce-specific glue in the on-platform project.
Versioning gotcha
LWC OSS and on-platform LWC are not always on the same major version of the engine. OSS typically tracks newer engine features earlier; the platform ships them at the next Salesforce release. If you copy a component using a brand-new directive from OSS to platform, double-check the platform API version supports it.
What interviewers want to hear
That you understand same author-time framework, different runtime contracts. The bullet points worth nailing: LWC OSS has no js-meta.xml, no lightning/ modules, no LWS, and no base components. Everything else is the same.
Verified against: LWC Open Source, LWC Developer Guide — Get Started Outside Salesforce. Last reviewed 2026-05-17 for Spring ‘26 release.