Web Components is an emerging web standard that allows developers to create reusable custom elements for their web pages and apps. Having only recently gained support in the leading browsers, the usage of web components isn’t as well documented as (for example) React components – which have received a lot of attention in recent years. For that reason, I decided to speak with a couple of companies that have implemented web components: GitHub and Salesforce.

Web Components vs. React

Advertisement

First, let’s address the elephant in the room: why use web components when you can use one of the popular frontend frameworks instead?

The community website WebComponents.org defines web components as “a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps.” One of its use cases is to create reusable UI elements; although many web developers currently use React (or a similar JavaScript library or framework) for that purpose. The key difference is that web components are portable, since they are based on HTML, whereas React components can only be used in a React environment.

It’s fair to say that not all developers see the value of web components. When Google Senior Staff Engineer Alex Russell (one of the founding developers of this technology) posted on Twitter that web components are now used by “12% of pages loaded in Chrome,” he got a range of positive and negative responses. This snippet from the discussion is illustrative of why frameworks adherents aren’t necessarily convinced yet about web components:

Clearly, frontend frameworks are all the rage currently. But that makes it even more interesting to explore why some companies have decided not to use them. GitHub is one of those companies.

GitHub and Web Components

GitHub now has about 50 web components, tweeted GitHub Senior Application Engineer Keith Cirkel. “Don’t see us slowing down either,” he added.

“GitHub has never used a framework like Angular, Backbone or React,” Cirkel told me when I reached out for more information. GitHub had been using the JavaScript library jQuery, he explained, but eventually they replaced it with “native web platform features – which includes web components.”

“Web components aren’t necessarily replacing jQuery for us though,” he continued, “they’re just a natural consequence of regular modernisations of the codebase. Web components bring to us the ‘component model’ which is a software paradigm that is maybe popularised the most from React.”

The ability to componentize software is a well accepted programming norm. But while JavaScript itself has a component model, the wider web platform (HTML, CSS and JavaScript) hasn’t traditionally had one. This was the motivation behind web components, created within Google and which continues to be worked on today by its Chrome development team.

I asked Cirkel for some examples of web components in action at GitHub. He highlighted three.

“Any UI with tabs uses Tab Container Element, dialog boxes use Details Dialog Element, anything displaying relative time uses one of the Time Elements – which are our oldest elements dating back to 2014 or so.”

Here’s the HTML code used for the tab component:

You can of course create a tabs component with React too, so developers have many choices as to how they do this. GitHub’s choice, though, was to rely on web standards – in order to avoid technical debt, speed up page load, and more.

A Note on Frameworks

Even though GitHub has opted to use web components rather than a frontend framework, it doesn’t entirely avoid the use of frameworks.

“GitHub still uses Ruby on Rails for the server side framework,” said Cirkel, “we just have no client side JS framework. We progressively enhance areas of the page with web components.”

Cirkel also noted that he isn’t against the use of frontend frameworks; he thinks they’re “useful for applications like SPAs which require complex UI.” But since GitHub isn’t an SPA (it has many web pages), he thinks web components are “totally capable of serving the same needs.”

Web components also scale well, Cirkel assured me.

“They provide good organisation, isolation, and encapsulation; which are all hallmarks of a technology that scales well.”

Salesforce’s Lightning Web Components

Another large scale internet company using web components is Salesforce. To find out more, I got in touch with Greg Whitworth, who leads the Lightning Web Components [LWC] team at Salesforce. Previously, Whitworth had worked on the Microsoft team that built its modern browser, Edge.

“LWC was designed around the idea of creating the thinnest abstraction layer on top of the Web Components APIs,” explained Whitworth. “This abstraction layer is highly opinionated to match with Salesforce platform restrictions and development philosophy. In the long run, the goal is to shrink LWC as much as possible to be able to rely more and more on the web platform native APIs.”

He noted that Salesforce actively participates in web standards groups, including for web components, “to ensure that the web platform moves in the direction that supports our customer’s use cases.”

LWC was used to build the so-called Lightning Experience version of the Salesforce CRM, an upgrade on the “Classic Salesforce” interface.

“Every base component [of the Lightning Experience] is built on top of LWC, said Whitworth, adding that “every single page in the Lightning Experience (not classic) has LWC.”

A big part of the appeal of web components to Salesforce is interoperability.

“Customers can build their own components or applications and deploy them to Salesforce,” said Whitworth, “and this is actually where the interoperability of web components shines and why we’re excited about the steps we’re taking to enable native web components within LWC on the Salesforce platform.”

As for the scalability of web components, Whitworth said they’ve “had very little issues with scaling them and using them across the various properties on Salesforce.com.” LWC itself is used by over 150,000 companies and had over 20 million LWC customer-deployed components by the end of last year. So there’s no doubt it’s working well at scale.

Conclusion

I’ve only touched the surface of web components in this post, but hopefully the case studies of GitHub and Salesforce will inspire many other companies to make the shift towards web components – which offer portability and interoperability advantages compared to frontend frameworks. They also scale well, too.

Lead image via Pixabay.

Please click here to read the original article as posted on The New Stack.

We source the web to bring you best Salesforce articles for our reader’s convenience. If you want to have this article removed, please follow guidelines at Digital Millennium Copyright Act (DMCA)..