The rule today is simple: All new custom development must be LWC. For declarative (no-code) development, use Lightning App Builder to assemble pages, and Dynamic Forms to put fields conditionally on a page without writing code.
The Verdict: Keep the Visualforce page (it's still the best engine for rendering PDFs). Leave the working Aura components alone, but freeze them (no new features). Build the new business requirement entirely in LWC. UI migration is a roadmap, not a reckless rewrite.
๐ฌ Real-Life Example: The Rebuild That Should Have Been a Wrapper
A development team inherits a 2018 Aura component that handles Quote Approvals. The business asks for a new feature. Eager to modernize, the team plans a full rewrite in LWC.
The Old/Bad Way: They budget six weeks to rebuild the entire application from scratch—including the parts that still worked perfectly in Aura.
Why this is bad: Rewriting perfectly functional code delivers zero new business value and introduces massive regression risk. Meanwhile, the stakeholders wait six weeks for a simple feature update.
The New/Good Way: Build only the new piece as an LWC, and nest it directly inside the existing Aura component. Aura can hold LWC; LWC cannot hold Aura. This one-way interoperability rule sets your migration strategy: new work is always LWC, and Aura shrinks from the inside out over time.
The Payoff: The new feature ships in a week. The legacy Aura component becomes a phased migration list rather than a massive roadblock, and old code is only replaced when someone actively needs to touch it.
๐️ The Three UI Generations Explained
To architect Salesforce correctly, you must understand the history and current purpose of its three distinct UI frameworks:
- Visualforce: The legacy generation. It consists of an HTML-like page tightly coupled with an Apex controller, rendered entirely on the Salesforce server. Today, it survives only in niche use cases—primarily generating PDFs (
renderAs='pdf') or maintaining very old legacy sites. - Aura: The transitional generation. It was Salesforce's first attempt at a modern, component-based Lightning framework. It is heavy, relies heavily on proprietary syntax, and is noticeably slower at runtime. Aura is essentially in maintenance mode.
- Lightning Web Components (LWC): The current standard. Built natively on modern web standards (HTML, standard JavaScript, CSS), LWC is lightweight, lightning-fast, and the default choice for all new programmatic UI work.
๐ Framework Comparison Matrix
| Feature | Visualforce | Aura | LWC |
|---|---|---|---|
| Era | Legacy | Transitional | Current Standard |
| Rendering | Server-side | Client-side (Heavy) | Client-side (Web Standards) |
| Performance | Full Page Reloads | Slower Runtime | Lightning Fast |
| Use for New Build? | Rarely (Only for PDFs) | No | Yes (Always Default) |
| Component Nesting | N/A | Can host LWC | Cannot host Aura |
๐งญ 360 Card — UI Layer Strategy
Rule: Use LWC for anything new. Use Aura only to host legacy components. Use Visualforce strictly for PDFs and legacy maintenance.
Gain: By defaulting to LWC, you gain true web standards, vastly improved real-world performance, and alignment with Salesforce's future product roadmap.
Price: Migration is not free. Rewriting perfectly working Aura code into LWC costs time and buys no immediate business value.
Limits: Aura can hold an LWC, but an LWC cannot hold an Aura component. This strict one-way rule dictates your incremental migration path.
Mirror (The Big Rewrite): Choosing to rewrite everything in LWC all at once sounds like a great way to get a clean codebase, but you absorb massive regression risk while delivering zero new features to your users.
At Volume: Aura is incredibly heavy at runtime. A page loaded with legacy Aura components will be sluggish before your custom logic even begins to execute.
๐ Key Points
- LWC is the undeniable standard. Unless you have a hyper-specific blocker, all custom UI development should be in LWC.
- Lightning Message Service (LMS) is the modern way to bridge communication across the DOM between LWC, Aura, and Visualforce components living on the same page.
- Dynamic Forms allows you to conditionally render fields and sections directly in the App Builder, eliminating the need to create endless Page Layouts and Record Types just to hide or show a few fields.
❓ Core Q&A (Scenario-Based)
Q: A stakeholder asks whether a new complex UI screen should be built in Visualforce, Aura, or LWC. How do you advise?
A: Default entirely to LWC. It is highly performant and easily testable. You only ever pivot to Visualforce if the exact requirement is a generated PDF document or an older Visualforce-based email template. You only pivot to Aura if you must interact with an obscure, older API that hasn't been bridged to LWC yet (a list that shrinks every release).
Q: You have a massive, existing Aura component and want to build a new feature. Can Aura and LWC interoperate?
A: Yes, but with a strict directional constraint. An LWC can be nested inside an Aura component, but not vice-versa. Therefore, you build the new feature as an LWC, and drop it into the Aura wrapper. If the components need to talk to each other across the page, use Lightning Message Service (LMS) to bridge the communication seamlessly.
Q: When should an admin use Dynamic Forms instead of creating more Record Types and Page Layouts?
A: Use Dynamic Forms when the only difference between user experiences is which fields are visible. For example, if you just want to "Show field X when Stage = Closed Won", use Dynamic Forms. It adapts one single Lightning page dynamically.
You should only create a new Record Type if there is a fundamental difference in the underlying business process—such as needing entirely different picklist values, distinct sales paths, or branching backend automation.
Q: What is the biggest "smell" of poor UI architecture in a declarative setup?
A: An explosion of Record Types whose only real difference is field visibility. This creates a maintenance nightmare for admins. Modernize by collapsing those layouts into a single Lightning Page powered by Dynamic Forms visibility rules.