Are Web Components a thing?

Are Web Components a thing?

Talking to people that are not really into Web Components I found out that they feel like Web Components are not going anywhere. This probably because there was a huge hype around them since, let’s say, a year ago but not that much over the past months.

For those who paid attention, a really important news came out lately. First of all, Microsoft announced they started working on the implementation of Custom Elements and Shadow DOM. This is huge because, since a couple of weeks ago, there were no signs from the Edge Team.

The support in Firefox has finally landed in version 63 out today! From my point of view then, the future looks really bright.

Even though Web Components specification is being around for years now, it seems that a lot of developers weren't able to grasp the basics of this standard. There are a lot of misconceptions and myths around this spec. Let’s try to clarify some aspects.

You can’t pass objects as properties (true or false?)

I was puzzled after reading this tweet because I realized that even experience developers didn’t get how Custom Elements work. I’m not asserting they have to like them, but that you can’t pass an object as a property is a totally false statement.

So, how do I pass an object as a property then? Short answer: via properties ! :)

Take a look at the following image to get a better idea.

In the example above, we define a Custom Element containing a property called myObj. To pass an object to a property you first need to select your element

let el = document.querySelector('my-el')

and then assign a value, in this case a standard object, using the dot notation

el.myObj = {a: 'test'}

That’s it.

Why people are still confused about that?

The issue is that most developers talk about ‘ properties’ when they actually mean ‘ attributes’. The two can be related to each other, for example I can reflect properties to attributes but this isn’t needed all the time.

With attributes you can pass only strings or use them as a boolean value. In the latter case, an attribute returns true if it exists, false if not.

To be clear, in the following example att === true .

<my-component att="false"></my-component>

Is it misleading or not ergonomic? You can have your own opinion about that but this is how HTML always worked. From my point of view, this is consistent .

Is Custom Elements’ API bad?

Some people are complaining about the verbosity of the Custom Elements API and they think that is totally useless and bad designed.

The verbosity part here is true. Take the Codepen example and imagine you have ten properties instead of one. You’ll end up with ten getter and ten setter, in most cases they differ just for the name of the property but they do the same thing for each of them.

This is not convenient for sure, on the other hand, I don’t think this means the API is bad.

This is a low-level API and isn’t always handy to use it directly, but you can build on top of that. You don’t have to develop an entire framework or library, you can just write some abstractions. If you don't feel like to do your own abstraction, try hyperHTML-Element or lit-element they are great!

That said, if you are still comparing Web Components against React, Vue, Polymer, whatever-framework, you’re missing the point and, honestly, is not fair.

Web Components work everywhere

So, are Web Components a thing?

From my point of view yes, absolutely. Maybe they are not for you (yet), but this doesn’t mean they are bad or useless.

I think this is a good moment to start playing with Custom Elements and Shadow DOM. Getting to know Web Components in depth maybe will be useful to change your mind in case you are still skeptical about this standard.

If you are interested in this topic and you want to stay in touch, follow me on Twitter.