Aura and LWC are both Salesforce UI frameworks, but they were built a decade apart and reflect very different eras of the web platform. Aura is the legacy framework; LWC is the modern one.
Side-by-side
| Aura | LWC | |
|---|---|---|
| Released | 2014 | 2019 |
| Foundation | Proprietary framework | Web Components standards (custom elements, Shadow DOM, ES modules) |
| Files per component | .cmp, .js, .css, .design, .svg, .auradoc, … | .html, .js, .js-meta.xml, optional .css |
| Markup | XML-like (<aura:component>, <aura:attribute>) | Standard HTML templates |
| Reactivity | Manual via aura:attribute + component.set() | Native — assign to a field, DOM re-renders |
| Two-way binding | Yes (v.value) | No — one-way down, events up |
| Performance | Heavier framework, virtual DOM diffing | Lighter, native DOM, faster initial render |
| Security model | Locker Service | Lightning Web Security (LWS) |
| Interoperability | Can embed LWC inside Aura | Cannot embed Aura inside LWC |
When you must still use Aura
The list shrinks every release, but as of Spring ‘26 a handful of features remain Aura-only:
- Some Experience Cloud Customer Service template overrides (the Build Your Own templates are LWC).
- Certain CRM Analytics dashboard customisations that depend on Aura events.
- Visualforce → Lightning bridges where you need
<lightning:container>-style hosting that LWC doesn’t expose.
Almost everything else — record pages, App Builder, Flow screens, quick actions, utility bars, Experience Cloud LWR templates — has full LWC support.
When LWC is the obvious choice
- New development. Period. The cost of writing Aura today is technical debt with no offsetting benefit.
- Anywhere performance matters — LWC ships less framework code and renders faster.
- Anywhere you want skills portability — an LWC developer can move to React, Stencil, or Lit with minimal retraining. An Aura developer learns a proprietary model that exists nowhere else.
The interop gotcha
You can drop an LWC inside an Aura component — Aura is the host, LWC is the child. But the reverse doesn’t work: you cannot put an Aura component inside an LWC. This is why migrations typically flow inside-out: convert leaf components to LWC first, then bubble the migration up the tree.
<!-- This works: LWC inside Aura -->
<aura:component>
<c:myLwcChild someProp="hello" oncustomevent="{!c.handleEvent}"/>
</aura:component>Events also bridge: LWC CustomEvent fires up into Aura handlers via the on<eventname> attribute syntax.
Migration playbook
- Inventory — list Aura components, group by leaf-vs-host.
- Convert leaves first — components with no children are simplest.
- Wrap the host temporarily — keep Aura as the shell while children migrate.
- Replace the shell last — once every child is LWC, the Aura host becomes redundant.
- Retire
aura:components from your codebase and update CI to forbid new ones.
What interviewers want to hear
The right answer is rarely “Aura is bad.” It’s: “For new work, LWC every time — better performance, standard skills, longer support runway. For legacy estates, we migrate progressively; some Aura is still load-bearing, but I treat it as debt to retire, not architecture to extend.”
Verified against: LWC Developer Guide — Migrate Aura Components, Trailhead module Migrate from Aura to Lightning Web Components. Last reviewed 2026-05-17 for Spring ‘26 release.