Polymer’s Web Component Library LitElement and How it Compares to React
What React is to JavaScript user interface components, LitElement and lit-html are to web components. Well, in the sense that they’re both libraries that help developers build and deploy components for websites and web applications. But there are some key differences between the two sets of technologies; along with questions about interoperability.
LitElement and lit-html are part of the Polymer Project, an open source JavaScript library launched in 2015 by Google. The project’s aim is to make it easier to build web applications using Web Components. LitElement and lit-html are the two core technologies in Polymer, with the former a way to define web components and the latter an HTML templating library for JavaScript.
The next major release date for LitElement and lit-html is nearly upon us, so I reached out to Google’s Polymer team leader Justin Fagnani to find out more about how this might change web development — particularly in regards to building components. I began by asking how LitElement compares to React?
“Well, LitElement isn’t really like frameworks, in that LitElement doesn’t define the component model — the HTML spec does. LitElement helps you build a web component — Lit is just the insides — but the result is an [HTML] element. This is important for interop and decoupling, and LitElement is intended to be mixed-and-matched with other ways of building components — including frameworks.”
The React website claims that developers “are free to use React in your Web Components, or to use Web Components in React, or both.” But in reality there is little overlap between the two sets of technologies. As I noted in my column last week, GitHub (as one example) has chosen to use web components instead of relying on a frontend framework like React. Which seems to be a common pattern when adopting web components.
So why do the two technologies — React and web components — not mix more often?
“React’s difficulties with using web components stems from its attempt to hide the DOM from developers,” said Fagnani, “especially things like the difference between attributes, properties and events. Those are simply three separate things in the DOM, but in React developers don’t have the expressive power to use them directly.”
Framework Interop
Last week Fagnani did a webinar, hosted by the Java framework company Vaadin, on what to expect with LitElement and lit-html going forward. One of the most interesting points of discussion was what Fagnani called “framework interop.” You can probably guess which popular framework he picked out for special mention.
“The main benefit of web components,” Fagnani said, “is this idea that they work everywhere where HTML does. And so if you look on a website like Custom Elements Everywhere, you can see that most frameworks have very, very good interop ability with web components. The one that stands out as not having great interop is also used the most, and that is React. So we really want to, you know, have a lot of empathy for both the component authors and the potential component users.”
Component authors, he explained, want their components to be “usable in as many places as possible,” while users (meaning other developers) don’t want to “have to jump through hoops in order to use them.”
It turns out the Custom Elements Everywhere website, which gave React the lowest rating for support of Custom Elements (the cornerstone of Web Components, as I discussed in a previous column), is run by Google developer advocate Rob Dodson.
To give React some love here, at least one of the popular React-based frameworks — Next.js — has indicated it is open to using web components. Indeed, Next.js creator Guillermo Rauch told me that “Next.js was originally designed in such a way that web components could be incorporated.” However, there was a problem.
“The spec at the time paradoxically didn’t include a way of declaratively defining them in HTML in a way that was conducive to server rendering,” said Rauch, “[but] I’m still excited about the possibility of using them for certain scenarios.”
For his part, Fagnani said in the webinar that his team is “experimenting with a couple of things for framework interop,” including a method to “turn a web component into a React component.”
So there is a desire, on both sides, to add web components into the React environment.
Framework Lock-In
One common issue with adopting a new way of building components is that it might commit you to that approach going forward; at least if you want to minimize your workload. This might even be an issue when deciding on whether to use native browser APIs to create web components, or use a library like LitElement (an abstraction). Other WC libraries include Svelte, Stencil, FAST and the Salesforce solution Lightning Web Components (LWC, which I wrote about last week).
But wait, there’s more. There’s also a difference between LitElement and the library that preceded it, Polymer. Confusingly, LitElement is a part of the Polymer Project, but LitElement is quite different from Polymer the library. “LitElement is the Polymer Project’s current web components library,” is how Fagnani put it. In any case, the old Polymer library provides an example of what he called “too much coupling between components.”
“The two-way-data binding system is a contract between host and child component that other libraries didn’t implement,” he said. “So to migrate away from Polymer, you have to migrate from two-way-bindings or re-implement the protocol. In LitElement, we’ve eliminated all cross-component coupling like this, specifically to make it easier to interop with and migrate away from.”
“LitElement gives you three main things,” he explained further. “Reactive properties, a hookable update/render cycle that augments the custom element life cycle, and declarative templates.”
Other WC libraries have similar capabilities.
“Stencil, LWC, FAST, and many other helpers all provide this trifecta of reactive properties, additional life cycle, and templating,” said Fagnani, “[so] it would not be too difficult to port to one element-by-element while maintaining a working app.”
I had to bring up our old friend React again. I asked Fagnani whether LitElement (and web components in general) will be able to coax away the many thousands of React frontend developers out there, over time?
“Our goal isn’t to ‘beat’ frameworks,” he replied, “but solve real problems — especially around interoperability — and help make web development more robust and scalable.”
He pointed to some “big bets on web components” like Salesforce LWC “and other big projects we’ll hear more about soon.”
He envisions that web components will, in time, be commonly used in different frameworks.
“We’ve already seen frameworks evolve to interop better with web components,” he said, “and the more that different frameworks do well, like Vue and Svelte, the more of a need for interoperable web components there is.”
That word, interoperability, is key for both Web Components and the future of web applications in general. There was a time (the mid-to-late 1990s) when the main web browsers were incompatible with each other. Thankfully that’s in the past now and today the four main browser vendors (Google, Mozilla, Apple and Microsoft) all work closely with each other in defining web standards, as part of the WHATWG group.
That said, we still see interoperability problems between popular JavaScript libraries and web components — in large part because the latter is still relatively new. So it will be intriguing to watch how this dynamic in components architecture plays out over the next few years.