LWC vs. Aura: What Architects Need to Know

Salesforce Architects who are considering a design shift from Aura to Lightning Web Components (LWC) might be wondering what kind of tradeoffs are involved and what impacts such a decision might have on their development teams. How long will it take developers who are familiar with Visualforce or Aura to learn LWC? Are there special tools or toolchain adjustments that come with adopting LWC? Is application performance significantly changed (or improved) by migrating to LWC? How can you decide which Aura applications should be targeted for refactoring or migrating to LWC? Is migration an all-or-nothing process?

If these questions sound familiar to you, read on. In this post, I cover how adopting LWC can make development simpler and increase business value, what will change for your development teams and toolchains, and how you can get started prioritizing your migration roadmap.

Why make the move?

Use of native browser APIs
Since Salesforce released the Lightning Experience in 2014, the web has evolved in amazing ways through investments in web standards. This evolution has been steered by several well-known organizations, including the World Wide Web Consortium (W3C) and the ECMA International Technical Committee 39 (TC39), both of which Salesforce is part. Salesforce has played a key role leading web standards conversations, especially for those standards that LWC uses, such as Web Components. As web standards evolve, browser vendors implement them in the form of native browser APIs. Salesforce regularly meets with major browser vendors to align priorities and directions.

While the Aura framework needed to implement a proprietary component model, proprietary language extensions, and proprietary modules, LWC uses web stack features implemented natively by browsers, which means that LWC apps are substantially more performant.

Support for modern JavaScript

JavaScript standards underwent significant changes in 2015 in the ECMAScript 6 version (also known as ES6 or ES2015). This included the introduction of amazing features such as modules, classes, promises, template literals, arrow functions, and much more. LWC supports all these features, plus more from later ES versions. JavaScript is not only the most important scripting language of the web, but it’s also widely used in other contexts, such as for server-side development with node.js. The use of common web standards in LWC makes it easier to find qualified developers who are already familiar with the technology and to ramp others up quickly thanks to loads of available documentation. If you want to know more about modern JavaScript, check out the Learn to Work with JavaScript Trailhead trail.

Time-to-value
One difference between LWC and standard Web Components is the amount of code that you have to write to create a component. To create a component with LWC, you just write a few lines of code, and then the LWC compiler will transform that code, adding the necessary boilerplate code so that those become, at the end, Web Components. This empowers your teams to be more productive, maximizing the time developers can spend on more critical application logic or UX considerations and minimizing time-to-value for the business. For more about Web Components standards and how LWC uses them, a good place to start is with two five-minute YouTube videos, Explaining the Shadow DOM and Custom Elements & HTML Templates.

Backward compatibility
Major modern browsers are usually up-to-date with the latest standards, but older browsers — some of which are supported by targets in which you can run Lightning Web Components — are often missing some modern features. Salesforces helps with this by enabing you to write your LWCs using the latest syntax and features, transpiling (transforming) the code to ES5, and adding the needed polyfills (emulation of missing features) when your code runs in an old browser. This means that you don’t have to worry about backward compatibility, and can deploy LWC-based apps to wider audiences with more predictable behavior across (supported) browsers.

Portability
Because LWC aligns with web standards and is open source (what we call LWC OSS), the components you create can easily work outside the platform. This means that you can write a component on the platform and reuse it somewhere else, for instance, in a non-Salesforce runtime. You have even more flexibility because can use base UI components and Salesforce Lightning Design System (SLDS) stylesheets outside of the platform, as they are also open source. Learn more about LWC OSS in the Build Apps with Lightning Web Components Open Source Trailhead trail.

Keys differences in Aura and LWC development

Let’s look at the key differences between Aura and LWC that Aura developers on your team must understand.

Developer tooling
You cannot edit or develop LWC components in the Developer Console. You’ll need to use another integrated development environment (IDE), and I recommend Visual Studio Code (VS Code). Why this particular IDE? Because Salesforce has released an extension pack that makes it easy to work with LWC (and not just LWC, but also Apex, Aura, and Visualforce, too). The extensions provide autocomplete and syntax highlighting capabilities, direct access to documentation and help, shortcuts for using the Salesforce CLI more easily, CSS validation, testing and debugging tools, and more. The extensions enable developers to write high-quality code much faster, to understand the execution flow of their code more easily and with more depth, and to simply ship better first drafts of code.

Because using an IDE means developers write their code locally, teams will need a way to deploy code to Salesforce environments. For that, I recommend using the Salesforce CLI. The Salesforce CLI works with any organization and has source tracking capabilities (ways to identify and compare what’s changed in an environment). It makes development teams, especially distributed teams, more productive.

This complete toolchain vastly increases developer productivity and code quality.

Note: The new developer tooling is something that I recommend all your Salesforce development teams use, even if they don’t work with LWC. All the benefits apply to Apex, Visualforce, and Aura development as well.

Standard syntax and files
The first time you take a look at the code of an LWC, it may seem quite different from an Aura component. In reality, it’s not that much different. One way to help developers with the transition is to have them bear in mind that LWC adheres to modern standards. In other words, conventions in Aura were specifics of the framework, whereas conventions in LWC are just standard HTML, CSS, or JavaScript. Whereas in Aura, you had a .cmp file, in LWC, you have a .html file. And whereas in Aura, you used custom Aura events, in LWC, you use standard DOM events.

From an architect’s point of view, a developer with some experience working in JavaScript and web development will add value to an LWC project faster. On the other hand, if a developer without that experience learns LWC, they will be learning modern JavaScript, and gaining new skills that are transferable to other JavaScript-based technology projects. Developing with standards also enables the use of popular testing libraries and standard debugging tooling, such as Chrome Developer tools. These tools not only enable you to mix-and-match the best toolchains for your projects, they also maximize opportunities for teams to work with tools they know and love.

Reorganization of responsibilities
With LWC, not all entities are defined in the same places they were with Aura. For instance, attributes are not defined in the markup anymore but in the JavaScript file (indeed, they are called fields or properties). Most importantly, they’re defined in the JavaScript class that extends LightningElement (which, in turn, extends HTMLElement). This is a meaningful change, as attributes represent the component state, and it makes sense for them to reside in the same place as the rest of the component logic. Markup expressions are moved to the JavaScript file in the form of getters, which makes testing easier.

The events dispatched by an LWC component do not have to be registered in the markup, unlike Aura components; events simply need to be fired in JavaScript. And event handlers are attached in the standard static or dynamic way. This makes LWC components much less verbose.

The metadata file becomes the one and only place that binds the component to the platform. Everything that’s platform-related — such as the experiences a component supports or the design attributes that are configurable in App Builder — are defined in that file. And, as a bonus, the metadata file now is more versatile, supporting more configuration options for LWC.

In summary, LWC component responsibilities are better distributed, and follow industry standards. LWC components are less verbose and more configurable. They’ll be easier to understand, test, and refactor in the long-term.

Performance improvements
On top of the general performance benefits you get from using modern web standards, component performance has also been improved with some key changes in LWC framework behavior.

The first such change involves property reactivity. In Aura, to trigger a component re-render, attributes need to be set explicitly using cmp.set(). In LWC, when you change a class property, the framework implicitly understands that a re-render is needed. The LWC approach improves the developer experience as it is more like JavaScript. Though the framework observes most property changes, there are two situations LWC doesn't observe by default for performance reasons: changes in array elements and changes in object properties. However, developers can explicitly declare that the framework should observe those changes by using the @track decorator.

The second important change is with the component lifecycle. Without going into too much detail, I’d summarize it like this: In Aura, most lifecycle events propagated from child to parent, and in LWC it’s the opposite. However, you and your team should take a look at the documentation to understand the whole component lifecycle paradigm. The LWC lifecycle adheres to the Custom Elements standard.

Lastly, Aura uses attributes to pass information down to a child component; in LWC, you use properties for this. However, to pass information from a child component to a parent, the story changes. In Aura, there are two methods to propagate information up: bidirectional data binding and events. In LWC, only events (the standard approach!) are supported. In other words, data binding in LWC unidirectional. This is one of the best improvements in the LWC framework. Information flow is much clearer and well-defined. In nontrivial (for example, enterprise) applications, the predictability of data flow significantly improves the developer (and architect) experience. It’s easier for teams to understand the behavior of an LWC-based component simply by how it’s written. This change is also a significant factor in LWC’s improved performance.

Lightning message service
In Aura, you use Application Events to communicate between components in different DOM hierarchies. The replacement in LWC is the Lightning message service. This service enables you to publish and subscribe to messages on a message channel. Lightning message service not only enables communication between LWCs in different DOM hierarchies, it also enables communication with Visualforce pages and Aura components.

Improved ways to work with Salesforce data

In Aura, Salesforce introduced Lightning Data Service, which lets you retrieve and modify Salesforce data and metadata easily from your components, with built-in optimizations (like caching and synchronization). In LWC, Lightning Data Service has also undergone dramatic evolution. The base Lightning Data Service engine has been refactored for maximum performance across the various ways developers can use it: base form components, wire adapters and functions, and Apex. Each Lightning Data Service invocation point is suitable for different use cases; therefore, an Aura developer should take some time to understand all the options for choosing the best pattern for Salesforce data consumption in LWC components.

By the way, the Lightning Data Service cache is shared among Aura and LWC components, which means all your components will synchronize if they use Lightning Data Service no matter which framework they use. Isn’t that great?

The built-in services of Lightning Data Service enable developers to access Salesforce data and metadata without having to go in-depth to understand the particular customizations of an organization or write Apex. This means development teams can save development time when working with unfamiliar organizations. Check out the Lightning Web Components and Salesforce Data Trailhead module to learn more.

Better unit testing with Jest
A common pain point in Aura development was the heavy lift for developers to find a solution for testing their components. In LWC, the testing experience is much more straightforward.

I recommend that you write automated unit tests for your components using Jest. Jest is a popular testing framework for which many JavaScript frameworks (for example, React and Vue) provide extensions. As you might expect, Salesforce provides one for LWC. The Jest extension (part of the VS Code extension pack) makes it simpler to unit test your LWC components, as it provides stubs for base components, a mocking feature for @wire, and more.

To migrate or not to migrate

Finally, there’s one remaining question I would like to help you answer: How do you decide whether Aura components should be migrated to LWC? First, it’s important to understand that you can combine Aura and LWC components within your organization and your apps. Here are some of the ways LWC and Aura are interoperable:

• Lightning Message Service can be used to communicate between Aura components and LWC. So, ideally, you could extend your existing Lightning pages in App Builder with LWC even if most of the components are written in Aura.
• Lightning Data Service shares its cache between Aura and LWC. This means components can synchronize data, regardless of which framework they’re written in.
• Aura components can include LWC. As a result, you can extend the functionality of an existing Aura component by writing the new bit of code in a child LWC component.
• JavaScript code can be easily shared between Aura components and LWC.

In most situations, you can extend and maintain your Aura applications by simply writing new functionality in LWC. For Aura-based apps that are working (and performing well) you can spare your team the work of undertaking a large migration effort for existing components.

In many ways, Aura technical debt is actually not such a heavy weight, as Aura can easily coexist with LWC and Salesforce provides many services to help.

However, there are certain situations in which you may want to prioritize migrating Aura components to LWC:

• When you have an Aura component (or application) that’s experiencing poor performance. The significant performance boosts with LWC might help users struggling with an app that feels unresponsive or slow in Aura.
• When you want to use platform features that only support LWC, such as custom property editors in Flow.

In my opinion, it’s a good idea to start building all new components in LWC now — if you are not doing so already — and plan an incremental approach to transition Aura components or apps that fall into one of the two categories above.

Summary

A transition from Aura to LWC can bring significant benefits in terms of performance, productivity, and portability. To maximize these benefits, however, the Aura developers on your team must learn the key concepts covered in this post as they make the move to LWC. I can tell you it won’t be that hard, as the two frameworks are not radically different. I’m also sure you’ll start enjoying the new coding features and that you will be much more productive soon. Keep in mind the scenarios in which it’s recommended to migrate existing Aura components or rather use the integration features that Salesforce provides to address any technical debt concerns you have in your system.

If you want a deeper look at these topics, set aside some time to watch this one-hour video in which I explain them in detail, showing side-by-side Aura and LWC code examples from a real application.

About the Author

Alba Rivas works as a Lead Developer Evangelist at Salesforce. She focuses on Lightning Web Components and Lightning adoption strategy. You can follow her on Twitter @AlbaSFDC.