DEV Community

Lets Build Web Components! Part 8: Mythbusters Edition

Benny Powers 🇮🇱🇨🇦 on February 18, 2019

So far in this series, we've covered the underlying web components standards, the legacy-browser polyfills, and their implementation with vanilla j...

Read full post

Mihail Malo • Feb 18 '19

I understand why we can write web components. But why should we?
Are they currently faster?

Benny Powers 🇮🇱🇨🇦 • Feb 19 '19

You might have lots of motivations to use web APIs

Interoperability
Performance (both load and runtime)
Standardization
Vendor lock
You like the specific sugar offered by XYZ web components library or base class

Give this podcast a listen, they covered most of the major talking points.

pca.st/qY78

Comment marked as low quality/non-constructive by the community. View Code of Conduct

Wannes De Backer • Feb 28 '19 • Edited

None at all.

There is NO w3c spec, there is no stability. This article is bullshit.

Benny Powers 🇮🇱🇨🇦 • Feb 28 '19

I really don't appreciate your language and personal insults.

Wannes De Backer • Feb 28 '19

There, i fixed it (i shouldn't have attacked you in person but i'm still super-triggered by this article, obviously i don't know your skills and therefore i can't be sure).

But i really don't appreciate you ignoring the w3c, inspiring other to do the same and basically lying about some points. Also reading the comments here is really eyeopening how backwards the current state of the web is, with companies trying to impose standards, people ignoring w3c. I can't stress enough how wrong and even dangerous this is.

Westbrook Johnson • Feb 28 '19

github.com/w3c/webcomponents/

github.com/w3c/webcomponents/blob/...

😘

Wannes De Backer • Feb 28 '19

proposal...

Westbrook Johnson • Feb 28 '19

specs, for the baseline, requisite parts of deploying web components today, and Proposals, for a lot of great future possibilities that are important to discuss as a community right now so our voices can be heard in the process, it's kind of how the w3c does its thing... It's a pretty beautiful process, even if its speed can leave you wanting at times. 😉Have you taken part in it before?

Wannes De Backer • Feb 28 '19

That is my point, but there is a big difference between discuss possibilities in the community and just saying: It's ready, just use it. And claiming that it is stable when it is totally not.

Mihail Malo • Feb 28 '19

Companies are using it. That's what drives the browsers.
There are stats in the post.

Westbrook Johnson • Feb 28 '19

Other than the Template Instantiation proposal, which of the technologies above aren't in the specs folder of that repo? Beyond that (which is noted very clearly as a proposal) everything else is 100% ready, as outlined in the article. What's more, discussion of the Template Instantiation proposal, and the benefits that will bring are have in the context of a production ready libraries that do similar work and specifically one that builds on the capabilities of the spec in anticipation of its arrival due to strong support across browser vendors and the developer community.

Wannes De Backer • Feb 28 '19

That is never a reason, and browsers should implement what w3c envisions, not the other way around.

Westbrook Johnson • Feb 28 '19

Can you confirm for me what you think a proposal is?

It has been my understanding that the w3c doesn't make those internally, the community does. It just so happens in this case that some of the proposals came from the Chrome team at Google which had been spending a lot of time with devs and found some valuable additions to be made to the platform. In that case of Template Instantiation it comes predominately from Apple. In the case of HTML Modules, Microsoft.

Is the w3c not a consortium on many vested parties that together come up with the future of the web? You speak as the web we all work with is laid down as dogma from some shadow group.

Mihail Malo • Feb 28 '19

Are you seriously suggesting browsers shouldn't focus on implementing anything and everything that is being massively polyfilled in the wild?

Toni-Jan Keith Monserrat • Jun 28 '19

When you understand that the w3c's protocols on creating and establishing those standards would always start with a proposal that would need data (like how many like this implementation and how many people/devs/companies are implementing this proposed spec) to back up the claim that this spec is the way forward... then you'll understand that the web standard will always start at these proposals.

Besides, these proposals has phases.

"Browsers should implement what w3c envisions..." <- I think what w3c envisions always start in those proposals... and technically, they are already doing it.

Benny Powers 🇮🇱🇨🇦 • Oct 21 '19

I hate to reopen old wounds, but for the sake of those future readers who stumble upon this thread and think that there's still merit to Mr. De Backer's comments, I feel it's necessary to point out that all of the web components standards are in fact part of the W3C specification

Moreover, the W3C has in fact ceded control of the HTML and DOM specifications to the WHATWG, in effect retroactively ratifying the specs above mentioned.

All of the links in this comment are to w3.org

Now get out there and be awesome, everyone!

Wannes De Backer • Oct 22 '19

All unusable, will not work on Internet Explorer.

Benny Powers 🇮🇱🇨🇦 • Oct 22 '19

I'm responding here to spectators, because of course Mr. De Backer already knows that polyfills enable support down to IE11.

So, in fact you can write web components that work in ie11.

However, that doesn't mean that you should.

(((Benny Powers))) 🇮🇱🇨🇦

@powersbenny

ie11 support is NOT

🚫 "nice to have"
🚫 "a feature"
🚫 "A business requirement".

ie11 support is willful disregard of

🙋‍♀️ your users',
💰 your customers',
🔐 or your client's security

Stop supporting ie. 🙈🙉🙊

Let it die.

mashable.com/article/intern…

15:05 PM - 25 Sep 2019

18 36

Mihail Malo • Feb 28 '19 • Edited

Tag @bennypowers , you coward :D
Jk, but who cares about w3c? Implementation is all that matters.
Like, I wish tail call optimization was implemented, but it isn't?
So I'm obviously not going to use it?

Liron Goldenberg • Feb 28 '19

I wouldn’t respond t someone that being disrespectful... keep that in mind when responding

Mihail Malo • Feb 28 '19

Did you mean to respond to me or someone else?

Liron Goldenberg • Mar 2 '19

meant to replay Wannes De Backer :X
Sorry Mihail.

gugadev • Feb 18 '19 • Edited

Awesome and curated myth list, Benny! Currently, we are creating a design system in my company, but we are thinking in throw away using Web Components for a few but important reasons. Here are some of them.

1 - There is no way to access shadowed elements via CSS from outside (/deep/ and ::shadow selectors are deprecated and ::part is on draft yet). Yeah, this is a clear violation to the encapsulation principle, but, this is necessary in some cases. For example:

We have an <ck-icon> component. By default, it's color is dark gray (#333333). Theorically, this icon should inherit the color of the parent. Why? because, when it's inside an <ck-button> and the color is -for example- white, the icon should have the same color. Otherwise, the button will have a white color and the icon a gray one.

<!-- background: green; color: white -->
<ck-button kind="primary">
  <!-- color: gray; 😕 -->
  <ck-icon name="checkout"></ck-icon>
  <ck-text content="checkout"></ck-text>
</ck-button>

2 - ShaddyCSS has some important limitations. For example, when using lit-element and want to apply styles from properties (using interpolation) it didn't works.

<style>
:host {
  ${importedStyles.toString()}
  <!-- property inside style tag is not reevaluated by Shaddy
       so, we can't override default styles -->
  ${this.props.color ? html`color: ${this.props.color}` : null }
}
</style>

Note: this works fine on browsers with native support.

Benny Powers 🇮🇱🇨🇦 • Feb 18 '19 • Edited

Yes those are important considerations, and shadow parts will solve many of them. In the mean time, one approach would be to slot in elements you need to style from light DOM. Alternatively, expose lots of custom properties.

As for interpolated styles, CSS custom properties and the style attribute are the preferred route for now. I expect to see some nice patterns emerge as Constructable Style Sheets gain traction.

As mentioned, you could also take the approach of not using shadow DOM, but I think that would be a loss.

WRT color, inherited properties should pierce shadow boundaries, so this sounds like a bug. Repro?

Joseph Moore • Feb 18 '19

I've solved both of these problems using CSS Properties.

In their stylesheets, ck-icon and ck-text would both use a custom property:

  color: var(--ck-text-color, #333333);

Then, in ck-button (and any other element that manipulates the background color):

:host[kind=primary] {
  --ck-text-color: white;
}

We've solved your second problem by side-stepping it whenever we can - when we use attributes (like your 'kind'), we set styles based on the attribute values, often in the form of a bundle of CSS properties that get used elsewhere in the stylesheet.

For more dynamically-computed styles, though, you are kind of stuck. The Shady DOM polyfill stamps out its template and styles once for each element (I think this is done for reasons of performance). One thing we did was call back to the ShadyDOM polyfill with a different element name (my-element-{hash of state}) for each state we encountered (though you should be careful, as this can easily backfire). Or, you can, as Benny said, just set styles directly on the element. It's maybe not the prettiest solution, but it works!

Westbrook Johnson • Feb 18 '19

Joseph, my-element-{hash of state} is a really slick work around to the dynamic styling issue. The idea of "re-defining" your custom element on demand like that is actually pretty central to the way Skatejs approaches elements and their define package could be seen as a pretty fleshed out helper to intersect the two concepts.

Joseph Moore • Feb 18 '19

So, we don't actually redefine the entire element, we just define a new template for ShadyDOM to play with. The actual code is here. I wouldn't reuse it verbatim, as it makes some assumptions that are very specific to us (like that, 99% of the time, our theme elements don't change their template once they've been stamped out the first time, so we don't need to worry about advanced diffing and such). We're also using a slightly older version of the polyfill, so it's possible that ShadyDOM has some new features that would get rid of some of this code.

Westbrook Johnson • Feb 18 '19

I've gotten stung by your point about the icon colors inheriting before as well. If you use SVG based icons, maybe we've been running into it for the same reasons. When I've had the issue you outline it's been because I've forgotten to use currentColor in my SVG attributes. It's easy to get an SVG that looks great out of the box and push it directly into my project, but if the fill or stroke or color attributes have fixed colors in them they'll quickly clash with some insertion point in my project. If you were interested in sharing a little more details in regards to your ck-icon elements, I'm sure we would both have something to learn from each other!

Benny's point about making sure to use things like color: inherit;, etc. is also really important as between the use of these two techniques and possibly CSS Custom Properties if absolutely needed, you should be able to maintain full control over your icon delivery, regardless of the context.

Joseph Moore • Feb 18 '19

Thanks for debunking these myths! I'm definitely keeping this around for the next time I run into these (an almost weekly occurrence).

My organization has been an early adopter of Web Components - we've had them in production for three years, and they've formed the core of our (wildly successful) design framework for two years. We keep running into these myths about them, but it's really fun to tell people that, if they're using the official theme, they're already using them and they just didn't realize it.

I wrote up some stuff about what we've been doing here, for those that are interested in what kinds of problems we tackled and how we dealt with them.

Samwise Gamgee • Feb 18 '19

Can you provide an example of how you might pass complex data into a vanilla web-component via the HTML template?

I think the myth about web components not supporting complex data passing comes from folks having trouble doing React-style passing of props.

Benny Powers 🇮🇱🇨🇦 • Feb 18 '19 • Edited

import { html, render } from 'lit-html';

const hobbitTpl = ({name, ability}) => html`
  <dt>${name}</dt>
  <dd>${ability}</dd>`

customElements.define('muh-hobbits', class extends HTMLElement {
  set band(val) {
    this.__band = val;
    if (!Array.isArray(val)) return;
    // Would be a great place to use template Instantiation when it lands
    render(html`<dl>${val.map(hobbitTpl)}</dl>`, this.shadowRoot)
  }

  get band() { return this.__band; }

  constructor() {
    super();
    this.attachShadow({mode:"open"})
  }
});

const main = document.querySelector('main')
render(html`<muh-hobbits .band=${[
  {name: 'Frodo', ability: 'courage' },
  {name: 'Samwise', ability: 'loyalty'},
  {name: 'Pippin', ability: 'strength'}
]}></muh-hobbits>`, main)

But at this point you might as well extend from lit element. It's vanilla enough.

Samwise Gamgee • Feb 18 '19

That's sorta what I was trying to get at though. Lit is a light framework, but it would be nice to see an example of how one passes in rich data to a string literal web component template using nothing but the core spec. I think part of the reason this myth persists is because there's not a clear explanation about how to do it without resorting to tooling.

I have tried a bunch of different ways, but can't get past the fact that attributes have to be strings, and there aren't clearly explained ways to otherwise pass complex data into the component.

The closest I've gotten is to just use the slot system and require each page-level template to visibly nest component, so that arrays, as in your example, can be mapped in such a way that values land in their intended sub-component attributes as strings.

Benny Powers 🇮🇱🇨🇦 • Feb 18 '19

🤷‍♂️

Web component specs are not meant to solve every high-level concern for every use case. They're low-level primitives.

Libraries (in contradistinction to frameworks) like lit-html etc are there to build on the specs to provide high level uses.

Future primitives like Template Instantiation will let libraries like those be even smaller and more efficient.

Westbrook Johnson • Feb 18 '19

This is a great point Samwise, there is a lot of ambiguity around this. I'm gonna show you one way that you can address this, but I'd be very interested in knowing whether you have a non-web component example of how this might be possible. Knowing what the explicit goals you might have is half the battle when it comes to architecting a useful solution. What I share below will be useful for some requirement, but likely not all, in this area.

In so far as you want a library free (except the polyfills) approach to passing rich data into a web component, I offer the following:

There are certainly things that could be said against this approach. In particular, the idea that JSON.parse() prevents the maintenance of identity is a big one. In response to that, I'd question how someone would actually rely on the idea of setting data as attributes beyond the initial load of a page. In that case, setting an initial identity that then can be maintained inside of the application by passing properties (theoretically you'd be in/have access to the JS scope at that point, so it would look like otherElement.customProperty = y) would absolve that issue.

What other use cases for communicating rich data between web components have you run into? I look forward to hearing about it! I think this is a really interesting part of the web components conversation, and techniques established and discovered in this area will benefit well beyond simply trying to set rich data on an element.

Konstantin Rouda • Dec 30 '20

Nice write-up. I'd say that learning Web Components it's easier than learning any new Framework/Library.
I've even made a few myself.
Example: <switch-component></switch-component>

Avichay Eyal • Feb 21 '19

Well written. As a web-components evangelist I agree with everything you say.
I would mention Unit-Tests for web-components techniques.

You can read about my (working in production for several companies) tool here:
medium.com/.../easy-unit-tests-for...

Mihail Malo • Feb 18 '19

some of these examples illustrate approaches that use build-time transpilation to render your templates (svelte in particular). But you aren't limited to that

That's not a limit, that's a superpower.

rhymes • Mar 1 '19

tl;dr: Web components 💓love💓 frameworks.

Especially Angular and Vue I see. React seems to be going in another direction...

Benny Powers 🇮🇱🇨🇦 • Mar 1 '19

Alas... Unrequited love...

Benny Powers 🇮🇱🇨🇦 • Mar 2 '19

footnote, preact has a much friendlier custom-elements support story

Alexon da Silva Moreira • Mar 28 '19

Eu tinha tentando muito coisa, Vue, Angular, React, no primeiro momento parecia fantástico, mas quando você tentava utilizar puramente javascrip, tinha que me adaptar as regras de convenção destas ferramentas, quanto mais eu utilizavas estas ferramentas menos eu aprendia javascript, mas eu gostava da questão de componentização até conhecer web components e finamente chegar onde eu gosto, puro javascript eu crio as minhas regras o programador no controle novamente SHOW!!!! SHOW!!!! Muito Obrigado por este artigos, ainda ainda só estou dando uma passada , para estudar com calma cada linha!!!!!