Salesforce: LWC vs Aura components

Introduction

Recently I've been working on a salesforce project. This project kicked off as a PoC done by a third party company and it was developed using Aura components (also known as lightning components). In previous projects I've worked with multiple frontend frameworks, such as React, Angular or Vue, and all of them are similar in many points, apart of the concrete features/syntax of each framework.

However, the first time I saw Aura components it was a little concerning, since it is not a framework based on standards. It is a highly customised framework. This has two direct consequences:
  • You will have a hard learning curve to learn a custom framework
  • You will be completely restricted by the framework rules and you won't be able to use advanced and modern JavaScript features.
Fortunately, Salesforce team was aware of the disadvantages of using Aura components and they have been working on a new framework over the last year. This new framework is Lightning Web Components (LWC), and it is the solution to most of the problems that Aura framework presented. 

LWC vs Aura components

Once I learnt both frameworks, Aura and LWC, I started to migrate my project to LWC due to all the benefits of LWC over Aura. As a result, I would like to analyse there the advantages and to help you to understand why you should consider using LWC. 

LWC is based on standards

The slogan for LWC is "more standards, less frameworks". In this point, Salesforce team has done an excellent work leaving custom solutions and sticking to industry standards. In LWC we can see the adoption of standards in multiple points: 

LWC is faster

In LWC most of the code is recognized by the native web browser engine and web stack. As a result, the performance has been improved significantly. In this article, we can see an example of a real application, where the performance has been improved up to 60% by using LWC: https://developer.salesforce.com/blogs/2019/06/case-study-dreamhouse-gains-speed-by-switching-to-lwc.html.


LWC enforces good practices

LWC is designed to enforce good practices. Some of them are: 
  • Code reutilization: in Aura we could have one controller and one helper per component, but we couldn't reuse that code for multiple components. In contrast, LWC allow us to build components without view and use the code we place there as ECMAScript modules. This feature allow us to build Service Components, where we can place our application logic and reuse it for multiple Web Components. This helps us to design following Single Responsibility Principle. 
  • Small web components: the most concerning part of the legacy application done with Aura component was the fact that the entire application was only one huge component. As a  consequence, the code base was extremely difficult to read and maintain. However, by design LWC will force you to build smaller components if you have a data model where you have to build smaller UI components and access to their properties.
  • View is html and it contains no logic: one of the biggest problems of Aura components is the fact that .cmp files are a mix of custom code, html and logic. However, LWC is very strict about this point, and you can only place html in your template file. If you want to add logic, you have to use getters and place the logic out of your view file. Of course, custom code such as variables are not allowed in the view. This point is extremely useful for teams where html design is done by UX team and logic by developers, in the same way Angular does.

Easy unit testing with Jest

For Aura components, salesforce provides a custom way to write tests installing the Lightning Testing Service and using the $T Utility Object (https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/lightning_testing_install.htm), which is not a really standard or straight forward way to configure and write tests. 

However, in LWC you can use jest by installing the package sfdx-lwc-jest as a npm package in a similar way to react, angular, etc. You can also use mocking or async wait in a really convenient way: https://developer.salesforce.com/docs/component-library/documentation/lwc/testing

Learning curve and agile development

Since LWC is based on standards, if you are used to working with other frontend frameworks, working with LWC will be really straightforward. As a proof of that, I just had to learn the LWC syntax for data binding and conditionality and I could rewrite the whole project in LWC in a few days, whereas the original Aura project took several months. In addition, adding new functionality to Aura project was a nightmare and our LWC project is now really well structured in smaller components and services, which makes easier to extend and maintain.

Documentation

In spite of the fact that LWC is a short life framework, the documentation is better and it is easier to find information if you have a problem. Actually, the official documentation is great: https://developer.salesforce.com/docs/component-library/documentation/lwc. 

I would also recommend to have a look at this LWC recipes repository to learn LWC and good practices: https://github.com/trailheadapps/lwc-recipes

Open Source

LWC has also an open source version https://lwc.dev/ (known as LWC OSS). This framework includes cool features that are included in other modern frameworks, such as: 
  • Hot reloading 
  • Integration with npm packages
  • Component bundles
  • In future, it might support other advanced features like typescript support.
If you are working with Salesforce Platform, you won't be able to use this open source framework. If you are not working with Salesforce Platform, I personally prefer a different framework, such as React, Angular or Vue, since they are more advanced frameworks and the community is bigger. However, I think it is nice to have that open source framework available, so the community can contribute to improve it, as happened for the most popular frameworks.

LWC is compatible with Aura components

If you already have an application developed with Aura components, you can schedule a progressive migration or developing your new components with LWC instead of Aura. If you are planning to migrate from Aura to LWC, I would recommend to have a look at this document: https://developer.salesforce.com/docs/component-library/documentation/lwc/migrate_introduction 

Conclusions

In this article we have seen multiple reasons why LWC might be a better candidate for your Salesforce projects. I think it is great to see how a company can evolve and use the lessons learned to build a good framework, based on standards and good practices. As a result, the community has embrace LWC and I wouldn't be surprised if Aura components are deprecated shortly.

May the salesforce be with you. 


Comments

Post a Comment

Popular posts from this blog

Building Micro-Frontends with Single-Spa

Image
Introduction Micro-services architecture is becoming trendy since it is a suitable option many projects, specially those that are complex and we want to be able spilt our business logic into different services that can be built and deliver independently. In spite of the fact that micro-services architectures are more complex, they increase the resilience of your system and increase the time-to-market delivery, which can be crucial for many companies. But it is not all about services and backend. With the introduction of single page applications (SPAs), we can build fully-functional user interfaces that can work independently in the browser. And here we should ask ourselves the same questions as for backend applications: Is my SPA becoming a huge monolith? Would I like to deliver functional modules independently? If you using micro-services, is there a relation between my services and your UI? Do we want to have functional teams that can deliver new features (frontend+backend) independe
Read more

Why you should migrate your old csproj to SDK format

Image
Introduction  With the introduction of Visual Studio 2017, the format used for csproj was updated including several advantages. This new format will be used when you create a new .Net Core project or .Net Standard library. In spite of the fact that VS2017 continues supporting old csproj format, you can migrate your old projects to SDK format. As a result, you will have the following benefits: Cleaner csproj files. With new format, a lot of things can be omitted, so your csproj files will be cleaner. Files are included using a wildcard , instead of including every single file.  Solution project references are simplier . NuGet reference packages as PackageReferences , so you won't need packages.config and you will be able to use wildcard in your references (for example, 1.0.*). NuGet package definition as a part of the project file. You won't need more nuspec files. Definition of AssemblyInfo attributes in csproj , you won't need more AssemblyInfo.cs files. In ad
Read more

AWS assuming role + MFA with pulumi (and other applications)

Image
Introduction In AWS, managing your IAM in a centralized account is a good practice, so then you can assume a role to access to other accounts without need of duplicating users. You can find more info about this approach in this article . In addition, for security reasons, it is highly recommended to enable MFA (Multi-factor Authentication), so you need a device to generate a temporary code to get access. In the image below it is showed how assume role with MFA works, but you also have an article about MFA in this link . This approach is really useful and most of the configuration can be automated with pulumi (or other providers like terraform or CloudFormation). And once it is configured, you can switch your role and get access to other accounts with a few clicks.  However, when it comes to external software such us pulumi, getting access assuming a role and using MFA might not be too straightforward. In this article we will see how this can be configured and how we can easily refresh
Read more