It’s almost that time of the year again - the Spring ‘19 release is upon us!
There’s loads of goodies coming our way, but one of the most exciting for developers is the release of Lightning Web Components. It’s a new programming model for Lightning component development, built on top of cutting-edge web technologies - and we think it’s going to bring a wealth of benefits to Salesforce developers.
What’s a web component?
To explain what Lightning Web Components are all about, it’s useful to take a look at the tech they’re built on top of, and how it came about.
The concept of “components” on the web has existed for a long time. The general idea is to split your UI component into modularized chunks, each of which is self-contained and re-usable. There are many benefits to this approach, not least of which are the reduction of duplication in your logic and UI, and the maintenance advantages of building your application out of small, easy to understand pieces of functionality.
Modern web frameworks such as React, Angular and Vue all put some concept of a “component” front and center as core primitives, with great results. However, even as this approach has become more and more common, the frameworks themselves have remained fragmented in their implementations - you can’t (easily) drop an Angular component into a React project or vice-versa, and once you’ve learned how to create components in Vue you might have to re-learn a lot of concepts before you can be productive in one of the other frameworks.
Web components are an attempt to address this fragmentation, and create a set of standards for how components can be natively supported by all browsers. By standardizing the underlying technology, we can both pave the way for interoperability between different frameworks, and reduce the friction for web developers and teams who want to migrate between different frameworks.
...OK, but what’s a web component?
Web components are a set of standards. There are several different specifications that make up what people refer to as “web components”:
- Custom elements - These allow you to define a custom HTML tag that can be used inside your existing markup. Instead of an endlessly nested set of
<div>tags, you can create your own
<myapp-navbar>element which has its own encapsulated UI and behaviour.
- HTML templates - HTML templates allow you define a chunk of HTML markup which is not rendered until you need to insert it. They can contain
<slot>elements which allow you to dynamically inject content into certain parts of the markup. You can think of this as a standardized version of Handlebars.js (or your HTML templating library of choice).
- Shadow DOM - Much less ominous than it sounds, the shadow DOM (Document Object Model) is a way of “componentizing” the DOM . The DOM is a representation of all of the elements in your web page - but accessing the DOM is usually done in a global manner by querying the entire document for nodes matching certain properties, which causes issues when you’re trying to encapsulate components and stop them treading on each others’ toes. The shadow DOM gives you a way of creating a “shadow tree” which only contains the elements in your component. This allows you to hide elements inside the tree from elements outside it, and vice-versa, creating the encapsulation that components are all about.
What does any of this have to do with my Lightning components?
This standardization push opens the door for a new breed of web frameworks, which are more focused on providing specialized functionality on top of the platform, rather than plugging gaps in the platform itself. We’ve touched on the benefits already, but they include the prospect of:
- Interoperable components between frameworks, making it easier to migrate between frameworks and re-use functionality that other developers have built using other frameworks
- More transferable skills for developers: developers will be able to get up and running across different technology stacks with less ramp-up
What about my existing Lightning components?
With the addition of Lightning Web Components, the existing development model for Lightning components is being renamed back to the Aura programming model. Aura Components and Lightning Web Components can coexist and interoperate, and they share the same high level services for accessing Salesforce data and metadata, as well as the same base Lightning components (which were already implemented as Lightning Web Components!) You can put both types of component on the same page, and Aura components can include Lightning Web Components.
The upshot of this is that you can manage your migration to the new programming model however you like - you can continue to build Aura Components, or you can start to slowly transition your new components over to Lightning Web Components, without worrying about interoperability.
If you’re starting a new project then we’d recommend jumping straight in with Lightning Web Components. It’s built on modern web standards, it’s here to stay, and most importantly it delivers a whole host of benefits that you can start to realize straight away.
An exciting step forwards
Lightning Web Components represent an exciting step-change in frontend development for Salesforce. It’s a technology stack built from the ground up on cutting edge web standards, but it’s available to you right now - and better still, it integrates with your current codebase so that you can handle the migration seamlessly.
If you want to read more, there’s some great blog posts on the Salesforce developer blog introducing the new components and going into a bit more detail about developer tooling. There’s also a Trailhead module if you want to try out making your first Lightning Web Component. If you want to know more about the web components standards themselves, I’d recommend the MDN documentation as a good starting point.
Lightning Web Components is getting local development support
While developing with Lightning Web Components is already a good experience, there’s always room for improvement. One of the main limitations at the moment is that you can’t run your components locally. When you want to run your code, you have to push it into Salesforce. Although scratch orgs and many parts of the DX tooling make this easy to do, it still lengthens the feedback loop and slows down development.
The good news is that, with the announcement of Local Development for Lightning Web Components, the lack of local build support won’t be an issue anymore. You’ll be able to run your components locally as well as connect them to a live org to test with real data. In other words, you can iterate rapidly without losing the benefits of building and testing in an environment close to production.
Local Development for Lightning Web Components isn’t available yet, but there’s an upcoming webinar to preview the new tool, which should enter Open Beta in the summer.
The Lightning Web Components framework is now open source
At the end of May, Salesforce announced that it will open source the LWC framework. We think this is a great move, for several reasons:
- Developers get greater visibility and input into the roadmap and the development process.
- Trust and transparency help engage the community and result in a greater likelihood that the right features get built and prioritized effectively.
- Developers can gain a deeper understanding of the framework by reading the source code, contributing to the documentation where it’s lacking, and getting insight into the development process.
- The open sourcing of LWC should give developers the confidence to use LWC for projects outside of the Salesforce platform, especially once a community develops around this modern framework.
Lightning Web Components is getting easier to use outside of Salesforce
Speaking of using Lightning Web Components outside of Salesforce, that’s getting easier too! The LWC framework has no dependencies on the Salesforce platform - it’s based directly on modern web standards. All of the integration with the Salesforce platform builds on top of the framework, which means you can use the framework independently of the platform.
If you want, you can build a complete web app that’s unrelated to Salesforce using Lightning Web Components. There are a host of benefits to this, including for Salesforce developers:
- It allows you to carry over all your frontend development skills from Salesforce to other web development roles. So you can learn one set of skills - essentially modern frontend development practices - and use those skills whatever project you’re working on.
- You can use a single framework everywhere and share code in apps that have some aspects in Salesforce with other aspects that are not. For example, if your application has a Salesforce interface and a web interface hosted on Heroku (or anywhere else), you can use Lightning Web Components throughout.
The lwc-create-app tool and other useful LWC resources
It’s got much easier to get started on building a standalone web app with Lightning Web Components thanks to a new tool called
lwc-create-app. If you’re familiar with
create-react-app, you’ll notice the similarities. After installing
lwc-create-app, you only have to run a couple of CLI commands to generate a fully working template for a web app based on the LWC framework, including a build process, a local development server and a test framework.
There’s a new developer site for the LWC framework, where you can find more information about building apps and components of your own, along with information on how to use the
lwc-create-app tool. As usual, the Salesforce developer documentation is a great resource, too.
We’re always keen to talk Salesforce developer tooling, so if you’ve got any thoughts you’d like to share don’t hesitate to get in touch via the live chat!
You can deploy Salesforce changes, including LWCs, faster and more reliably with Gearset. If you haven’t already, start your free 30-day trial today.