DEV Community

Cover image for Lets Build Web Components! Part 8: Mythbusters Edition

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...
Collapse
 
qm3ster profile image
Mihail Malo

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

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

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

Collapse
 
wannesdebacker profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Wannes De Backer • Edited

None at all.

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

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

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

Thread Thread
 
wannesdebacker profile image
Wannes De Backer

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.

Thread Thread
 
westbrook profile image
Westbrook Johnson
Thread Thread
 
wannesdebacker profile image
Wannes De Backer

proposal...

Thread Thread
 
westbrook profile image
Westbrook Johnson

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?

Thread Thread
 
wannesdebacker profile image
Wannes De Backer

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.

Thread Thread
 
qm3ster profile image
Mihail Malo

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

Thread Thread
 
westbrook profile image
Westbrook Johnson

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.

 
wannesdebacker profile image
Wannes De Backer

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

Thread Thread
 
westbrook profile image
Westbrook Johnson

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.

Thread Thread
 
qm3ster profile image
Mihail Malo

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

Thread Thread
 
tjmonsi profile image
Toni-Jan Keith Monserrat

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.

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

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!

Thread Thread
 
wannesdebacker profile image
Wannes De Backer

All unusable, will not work on Internet Explorer.

Thread Thread
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

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.

Collapse
 
qm3ster profile image
Mihail Malo • 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?

Thread Thread
 
lirown profile image
Liron Goldenberg

I wouldnโ€™t respond t someone that being disrespectful... keep that in mind when responding

Thread Thread
 
qm3ster profile image
Mihail Malo

Did you mean to respond to me or someone else?

Thread Thread
 
lirown profile image
Liron Goldenberg

meant to replay Wannes De Backer :X
Sorry Mihail.

Collapse
 
gugadev profile image
gugadev • 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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

Note: this works fine on browsers with native support.

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ • 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?

Collapse
 
thatjoemoore profile image
Joseph Moore

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!

Thread Thread
 
westbrook profile image
Westbrook Johnson

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.

Thread Thread
 
thatjoemoore profile image
Joseph Moore

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.

Collapse
 
westbrook profile image
Westbrook Johnson

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.

Collapse
 
thatjoemoore profile image
Joseph Moore

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.

Collapse
 
dehuszar profile image
Samwise Gamgee

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.

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ • 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.

Collapse
 
dehuszar profile image
Samwise Gamgee

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.

Thread Thread
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

๐Ÿคทโ€โ™‚๏ธ

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.

Thread Thread
 
westbrook profile image
Westbrook Johnson

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.

Collapse
 
konrud profile image
Konstantin Rouda

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>

Collapse
 
eavichay profile image
Avichay Eyal

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...

Collapse
 
qm3ster profile image
Mihail Malo

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.

Collapse
 
rhymes profile image
rhymes

tl;dr: Web components ๐Ÿ’“love๐Ÿ’“ frameworks.

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

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

Alas... Unrequited love...

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

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

Collapse
 
allexon profile image
Alexon da Silva Moreira

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!!!!!

Collapse
 
grandemayta profile image
Gabriel Mayta

Long live to Web Components!

Collapse
 
directspeaker profile image
directspeaker

A great wonderful read. I must appreciate the way you have presented here for easy understanding.
Thanks