BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Web Components at Scale at Salesforce: Challenges Encountered, Lessons Learnt

Web Components at Scale at Salesforce: Challenges Encountered, Lessons Learnt

This item in japanese

Bookmarks

Diego Ferreiro Val, principal architect at Salesforce and co-creator of Lightning Web Components (LWC), talked at WebComponentsSF about the challenges and lessons learnt in building a platform leveraging Web Components at enterprise scale. Albeit with missing pieces, the Web Components standard was instrumental to achieve Salesforce’s interoperability, and backward and forward compatibility objectives at scale.

Ferreiro started by presenting the specific constraints of Salesforce. Among other services, Salesforce sells a platform for customers to implement their own enterprise application, and as such must be completely customizable. Customers may thus create their own components, objects, and user interfaces. Ferreiro quoted the following business requirements for the platform:

  • multi-author
  • multi-version
  • backward compatibility indefinitely
  • accessible
  • personalizable
  • localizable
  • secure
  • performant (including old browsers)

The third requirement is particularly meaningful in Salesforce’s context. Ferreiro emphasized:

If our customers write a component today, it has to be working in the next ten years.

Salesforce had the opportunity three years ago to start from scratch and looked around for available options to achieve their objectives while satisfying their constraints. Developers wanted away from proprietary technology, favored a common component model that allowed them to use Salesforce or Adobe indifferently, acquire transferable skills, and not being locked into a given technology, all the while leveraging standard tooling.

After months of research and discussion with existing front-end frameworks, Salesforce observed that the web platform has managed to evolve without breaking former content. Salesforce thus concluded that the best way to be future proof is to align with standards as much as possible, and the best option was to rely on Web Components. Ferreiro commented:

It took us a while to arrive at this conclusion but that is kind of at the core of what we are building.

Ferreiro observed that however, the web component standard was providing an API that was too low-level to be directly exposed to Saleforce customers, and thus decided to add their own syntactic sugar on top of it. The result of that work, the Lightning Web Components framework (LWC) added better ergonomics, filled the gaps in accessibility, in performance, and browser compatibility. An example of code is as follows:

<template>
  <p>Counter: {count}</p>
  <button onclick={increaseCounter}>Add</button>
</template>
import { LightningElement, track }  from "lwc";

export default class MyCounter extends LightningElement {
  @track count = 0;

  increaseCounter() {
    this.count += 1;
  }
}

Adopting Web Components proved to be challenging, with two themes taking a particular importance: IE11 support and Shadow DOM encapsulation. IE11 support was and remains very important, as IE11 amounted to 43% of the traffic as of September 2019.

Supporting Web Components in old browsers is thus a requirement for enterprise software. This means bringing ES5 to ES7 by means of polyfills and Babel plugins. Ferreiro emphasized that the team spent months implementing IE11 support, corrected a number of bugs in existing polyfills, resorted to ad-hoc Babel plugins for performance reasons, and were the first to implement proxy support for IE11.

Emulating Shadow DOM and CSS variables in IE11 in a way that is performant was another set of challenges. So were event retargeting, focus and tabs. Not less importantly, the team had to fix Selenium and became the maintainers of the IE11 Selenium driver. The team also added web component support to JSDOM and fixed several other issues that occurred in other browsers like Safari and Chrome.

Shadow DOM encapsulation meant changing the way testing and styling was done. Traversing the shadow root to access the encapsulated DOM meant rewriting thousands of tests. While Ferreiro described the effort as painful, he also mentioned that as a result, components and tests became more reliable, resilient, and scalable. As positive news, some testing frameworks implement some form of shadow selector abstraction, and the Selenium WebDriver is soon to have a shadow piercing primitive.

Shadow DOM styling customization remains still an issue in progress, even as it improved style encapsulation. Ferreiro believes that specifications in-progress like custom properties, ::part and :state() will solve 90% of the style customization use cases. While the CSS Shadow parts specification is still at the working draft stage, it is already implemented in both Chrome and Firefox. Constructible Stylesheets may also help to gain additional control over component blueprints in a controlled way.

Ferreiro concluded that although the path to production was hard, Web Components are helping Salesforce scale. Pages of the Salesforce CRM application typically feature over 8,000 components. Salesforce counts 5M developers, and 1M created components. 73% of Salesforce developers use LWC, and 95% of Salesforce developers feel that Web Components are the right direction. While the web component standard is not finished, Ferreiro believes that the future is bright and signaled that Salesforce will keep pushing the web platform forward and representing the enterprise use cases in the W3C and TC39 committees.

Salesforce.com, Inc. is a cloud-based software company providing customer relationship management services and selling a complementary suite of enterprise applications focused on customer service, marketing automation, analytics, and application development.

Lightning Web Components are available under the MIT open source license. LWC’s RFCs can be accessed on a dedicated website. Contributions and feedback are welcome and may be provided via the GitHub project.

Rate this Article

Adoption
Style

BT