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
Richard MacManus
Richard is senior editor at The New Stack and writes a weekly column about web and application development trends. Previously he founded ReadWriteWeb in 2003 and built it into one of the world’s most influential technology news and analysis sites.
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:
👁 Image
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:
<tab-container>
<div role="tablist">
<button type="button" role="tab" aria-selected="true">Tab one</button>
<button type="button" role="tab" tabindex="-1">Tab two</button>
<button type="button" role="tab" tabindex="-1">Tab three</button>
</div>
<div role="tabpanel">
Panel 1
</div>
<div role="tabpanel" hidden>
Panel 2
</div>
<div role="tabpanel" hidden>
Panel 3
</div>
</tab-container>
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.
