HTML Web Components is the wrong name

I’m psyched. My favorite way of building web components is starting to come into vogue and with all the recent discussion about this concept, I can’t help but toss my hat and thoughts into the ring.

I’m currently writing a much longer post about my time experimenting with, building, and using these components during the last year (plus I may or may not be soft-launching a tiny web framework that I may or may not have been working on for several months specifically focused on building this type of web component… who knows), but with things moving fast I wanted to at least chime in with my thoughts about the recently proposed and initially adopted name “HTML Web Components.”

This is an extremely new term to describe this concept –– about a week old as of writing these words. So while the dust hasn’t fully settled I want to add my two cents and implore those building and writing about this that we consider finding a different name.

My big issue can be boiled down to the idea that “web components” is an extremely overloaded term that I would argue has a principle definition that can roughly be described as “a set of evolving browser APIs that allow you to create custom HTML elements.” That is to say, “web components” are themselves literally HTML elements, so when I see the term “HTML Web Components” I can’t help but read it as “HTML HTML.”

For me, this name is confusing and does not do a good enough job of properly or intuitively distinguishing how this model is different from “regular” web components.

I should also acknowledge and clearly state my bias when thinking about this name. I’ve spent years teaching students and coworkers about various programming concepts (especially web components as of the last couple of years), so I often lean towards the perspective of a student or new learner.

In some ways, you might consider this post an argument in support of choosing a name that will help new learners ease into the world of web components –– which is already filled with so many potential potholes and points of confusion (no shade, but looking at you Shadow DOM).

I started a thread that already has some discussion on the topic with some very valid counterpoints raised, but I still think this name is worth reviewing. Below are a few of those counterpoints and my thoughts on them.

It would be great to re-use the “Web Component” branding

Reference

I actually agree and think this is one of the more compelling reasons to stick with “HTML Web Components!” Brand recognition is powerful and well worth considering.

With that said, “web components,” I’d argue, is one of the most fraught and convoluted web development brands and concepts of the last decade. I worry that explicitly rolling up to this branding will just add further confusion –– especially for those starting to learn about web components.

A different name that does not include the words “web component” could still very easily fall under the “web component” banner/branding, but it will not contribute to an overloaded phrase that already means a lot of different things to a lot of people.

In the best case, this is an opportunity to start fresh, so to speak. I could see an alternative name (if done well) pulling the interest/curiosity of those who have previously held strong negative opinions about “web components” by simply avoiding those words up front and center. Maybe?? 🤷🏻‍♂️

“HTML Web Components” focuses on the “HTML” part of web components

Reference

Jim Nielsen has written a few posts at this point where he differentiates between the two types of web components by calling them “HTML Web Components” and “JavaScript Web Components.” In his words:

I like the term “HTML web components” because it makes me think of the HTML-centered part of [the web component] “suite of technologies”

Like the branding counterpoint, I also really like this idea –– it makes a lot of sense to me to roughly categorize “web components” into an HTML-focused bucket and a JS-focused bucket.

With that said, what does “HTML-centered” mean? Especially for someone who might know less about web components? When you start getting into the weeds of web components you’ll find that “HTML Web Components” and “JavaScript Web Components” require almost nearly the same amount of JavaScript and HTML –– i.e. the Custom Elements API accounts for the vast majority of weight in a web component.

Of course, as one learns more they will eventually grasp the idea that this naming convention reflects/indicates a web component architecture versus a web component implementation strategy.

And I suppose there lies a key question that needs answering: Is it more desirable to have the name indicate an architectural differentiation or have the name better reflect a sort of blueprint of how this type of component is implemented?

*Editor’s note: As I’m doing a final pass I’m starting to wonder if this is a false dichotomy because an architecture can/does in some way indicate an implementation strategy…

Hopefully, the point I’m trying to make is coming across, but if not the core idea is that I worry people will not initially understand what “HTML” is supposed to mean in “HTML Web Component” and get wires crossed especially when considering that a non-zero group of people defines “web components” as a way of creating custom HTML elements.

Said a different way, what does an “HTML custom HTML element” or a “JavaScript custom HTML element” entail? I’d argue the naming does not make this clear and I really wish it did a better job of that.

This simply might not matter in the scheme of things

Reference

Chris Ferdinandi pointed out that this all might not matter in the big picture, noting that some of the alternative names that have been suggested might stray a bit too far into buzzwordy territory. I think he correctly points out that some of these names could “[turn] into a ‘yesteryear buzzword’ the way people sometimes treat progressive enhancement today.”

I’ve not named nearly enough things to have a strong opinion or experience on this one. I could see it going both ways, but I will admit that “HTML” and “Web Components” lean pretty heavily toward the “timeless” (versus “buzzwordy”) end of the scale. So barring an even better alternative name, this is likely a +1 towards “HTML Web Components.”

So.. what should we name this?

Personally, my favorite suggestion has been Ryan McNeely’s “enhanced components” or “progressive tags” but even those don’t feel quite right to me. To build on McNeely, I’d perhaps suggest “progressive web components” or even better “progressive custom elements.” They both indicate that progressive enhancement is a core principle of working with this model and the latter name makes clear this is a method of building interactive UI using only custom elements and nothing else from the “web component” bucket of APIs.

Zach Leatherman also (perhaps unintentionally) suggested “HTML Custom Elements”, which I like as well. It still kind of reads as “HTML HTML” to me, but at least it avoids using “web component.”

I’m not fully sold on any of these names to be clear. I think they do a better job of correctly conveying what we’re talking about, but I question if they are any more intuitive than “HTML Web Components” for someone who’s learning about web components for the first time.

The big call to action is one final round of name suggestions that keep in mind the historical baggage of the term “web components” and are considerate of the new learners that will enter the web component world in the years to come.

The train might have left the station already

Admittedly the train is already mostly out of the station with the fantastic posts I’ve linked to all using “HTML Web Components” front and center, but if there’s any willingness to reconsider I’d love to discuss and see if this naming can be a more accurate (and ideally intuitive) reflection of the concept.

With all that said, this is a strong opinion loosely held on my part, and without any great alternative name(s) I do think “HTML Web Components” checks enough boxes as is. So if the consensus and desire (from those who have already written about this and the wider community) are to move forward with “HTML Web Components” I will happily (for the most part) roll with it.

I at least wanted to convey these thoughts before it was too late. I invite you to add to the discussion in the form of response blog posts or adding to this thread.

As always, naming things is the hardest part of programming…