HTML web components

@adactio I said this earlier this year, but feeling it moreso: I really feel like web components are (finally) starting to land in both our consciousness but also our fingertips (allowing us to actually use them day to day).

@keithjgrant @adactio the challenge is that front end apps will still need a meta framework for ssr.

Additionally web components dont offer a trivial state management solution.

Components have to be just templates & data loading will have to be done by something else.

@adactio I think you hit on something there at the end: “Web augmentations” also feels like a pretty catchy term.

@adactio good way to phrase things, I think. “Enhancement components”, maybe; some sort of name is a good idea. But the vibe of “wrap the proper markup in a component rather than making up your own markup” is one I hadn’t properly articulated inside my own head; good call!

@adactio

“Lots of people are still using it, but nobody can quite remember why.”

Ahh humanity.

Aa someone who only plays with the front end when there are no adults nearby to tell me not to, web,components have had the right “vibe”. But I’ve not had a reason to properly play with them and have people cry: ” oh dear god no! Why would you?”

@Meyerweb @adactio That term “Web augmentations” really resonates with me.

Wish we could extend built-in elements but alas.

We can wrap them at least!

@adactio in conversation, I’ve always just differentiated based on the specs. “Custom elements” versus Shadow DOM-enabled “web components”. Using a musical analogy, they’re both playing notes, but their composition generates different sounds, and that is okay.

@zachleat @davatron5000 the one thing that scares about web components is spending more time doing things that were easy in react. You get these posts from industry experts that tell you the BEST way to do something. I don’t doubt that, but sometimes dev time gets lost when we just focus on the most semantic and performant way to do everything.(1/2)

@chris_hayes @zachleat

There’s a learning curve for sure, but once you start getting into it you realize how much React separates you from good ways of doing things. It’s giving you an abstraction, but it’s no longer needed.

Lit is amazing coming from React. You don’t get to do hooks, some other WC frameworks have those. But honestly once you simplify everything like Lit, you just don’t need them. In fact, there is so much I just don’t need with Lit and WCs, and that’s what it’s really about.

@deadwisdom @zachleat I’m all for not having to deal with hooks 😁

@adactio@mastodon.social is there any way of using these without JavaScript? I was interested when I first heard about these but was immediately disappointed to discover that they’re not really just markup, they’re always dependent on programming as far as I can see

@jonoabroad @adactio like many others [citation needed] I’ve enjoyed not using frameworks and not having to update code to keep up to date. Web components keep it manageable. My language snobbery means I needs a Typescript build step but it’s my code and I can understand it.

@adactio Been waiting 11 years (https://news.ycombinator.com/item?id=4176236) so maybe another 10 years and like QR Codes they’ll hit the big time…

Web Components Github Org | Hacker News

@adactio (FWIW the best Web Components I’ve released have been ones to create a musical keyboard, and one to wrap forms that make them dynamic - neither of them UI components)

@u0421793 @adactio work in Declarative Shadow DOM and Declarative Custom Elements specs is underway. Those will let you define Web Components declaratively in HTML, making JavaScript optional only for when you actually need logic. Peruse conversations at https://github.com/WICG/webcomponents

GitHub - WICG/webcomponents: Web Components specifications

@trusktr@indieweb.social @adactio@mastodon.social the HTML Modules bit looks excellent – at the moment it’s impossible to build a website like I used to be able to teach people how to do in 1997, because we can’t put the navigation buttons inside a frame because we can’t have frames and we can’t import anything in htmlCurrently I’m trying to do exactly that in svg with foreign object to bring in xhtml bits of body copy, and have the navigation as another foreignObjectI like the way that in SVG I can avoid the need to know someone who knows how to write programs, by using eg for animation the SMIL words – they’re understandable

@u0421793 @adactio @trusktr I have similar feelings. I’ve always felt React was over-engineering when the native web is so powerful, but I’ve also always felt web components were *also* over-engineering, just less so.

Can anyone here explain to me why I would want to use a web component for any use case at all instead of just progressively enhancing some markup with CSS and JS the old-fashioned way? What is the benefit to destroying the CSS cascade and whatnot?

@adactio Great post. I prefer the term “custom HTML elements” because like you say it’s about introducing new primitives. Reusable “atoms” in the Atomic design parlance.

And components or partials would still exist, they wrap elements: both custom and built-in elements. They are the molecules and organisms in Atomic design.

@kethinov @u0421793

☝️Did you read @adactio’s article? You don’t have to destroy the CSS cascade or use Shadow DOM. Shadow DOM is optional. It depends what you’d like to do.

The following is progressive enhancement where the wrapper custom element adds additional features:

<super-slider> <label>…</label> <input … /></super-slider>

@kethinov @u0421793 @adactio

This is clean because now you can easily stamp the progressive enhancement where you need it, and the code is less book-keepy, instead it operates in the location where you place it, colocated with the HTML it operates on.

This is alternative to having the <input> inside ShadowDOM and mapping attributes to it, which gets complicated, and blocks outside CSS. So what you’re asking about is what that article covers.

https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the-light-dom/

https://aaadaaam.com/notes/step-into-the-light-dom/

Blinded By the Light DOM

@kethinov @u0421793 @adactio

You could do similar with jQuery for example, but then you have to manually keep track of when elements are added and removed from the DOM to apply logic to them. With Custom Elements, they instantiate and run at the location where they are without that book keeping.

And without Shadow DOM, you traditional CSS style at the document level works the same way.

@kethinov @u0421793 @adactio

Maybe jQuery does the book keeping, I don’t remember. But with vanilla JS you’d need MutationObserver to effectively re-create what we get for free with connectedCallback and other methods.

I think the word “component” in “web components” confused a lot of people — at least it did me.

“Web components” sounded like the web platform’s equivalent to “React components”. JSX had <MyComponent> and now the web had <my-component>.

But when you try building web components the same way you build React components, it’s easy to get frustrated and give up because web components don’t work like React components — I know I gave up a few times.

The grain of a React component is not the grain of a web component. Their design prioritize different functionality and forms of use. If you try to use one like the other, you’ll fight the direction of their natural grain.

Web components have their own grain and it favors enhancement over replacement. What do I mean by this?

A typical React component might look like this[1]:

<UserAvatar src="https://example.com/path/to/img.jpg" alt="..."
/>

You could write a web component this same way, e.g.

<user-avatar src="https://example.com/path/to/img.jpg" alt="..."
></user-avatar>

But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop.

This feature of web components encourages a design of composability. Rather than an empty “shell component” that takes data and (using JavaScript exclusively) renders the entirety of its contents, web components encourage an approach of composing core content with HTML and then wrapping it in a custom element that enhances its contents with additional functionality.

<user-avatar> <img src="https://example.com/path/to/img.jpg" alt="..." />
</user-avatar>

This specific flavor of componentization is what Jeremy calls “HTML web components”:

If your custom element is empty, it’s not an HTML web component. But if you’re using a custom element to extend existing markup, that’s an HTML web component.

React encouraged a mindset of replacement: “forgot what browsers can do; do everything in a React component instead, even if you’re reinventing the wheel.”

HTML web components encourage a mindset of augmentation instead.

I like that term “HTML web component”. It stands in contrast to a “JavaScript web components” which would be an empty element whose functionality and contents rely exclusively on JavaScript.

Per my earlier example, this would be a JavaScript web component:

<user-avatar src="https://example.com/path/to/img.jpg" alt="..."
></user-avatar>

It relies exclusively on the presence of JavaScript and is meaningless to the end user without it.

Whereas this would be an HTML web component:

<user-avatar> <img src="https://example.com/path/to/img.jpg" alt="..." />
</user-avatar>

It has meaning and content without JavaScript — then is enhanced by its presence.

This idea of augmentation/enhancement over replacement is intriguing.

On The Web, Augmentation Wins in the Long Run

Augmentative approaches work best on the web because 1) the web’s grain encourages enhancement to improve resilience, and 2) that’s really the best way to iteratively change something as big as the web.

Eventually all the best ideas of web-adjacent frameworks are subsumed into the platform to work in ways that augment the existing technology rather than replace it wholesale.

XHTML wanted to replace HTML4, but HTML5 wanted to augment it. HTML5 won.

Networking libraries wanted to replace XMLHttpRequest and their best ideas were eventually ported into the fetch standard — which exists in more places than just the browser these days!

The best ideas of Sass and jQuery were ported to the browser.

Typescript’s best ideas are going to the browser, but in a way that works to enhance not replace what exists.

With web components, you might even say React’s component model is being ported to the browser. But it’s being done in a way that works to enhance how the web already works, not replace it.

My takeaway is: if you’re looking for longevity, opt for a technical approach of augmentation and enhancement over replacement. The web’s grain is arranged in that direction.

1. I think React is trending towards becoming more like HTML over the years. Dan Abramov notes how component composition over prop drilling is a “top react skill to learn in 2023”. Even the react docs specifically call out the composability of HTML and how you might want to follow HTML’s example in your JSX. ↩

@zachleat @adactio.com @jimniels I went all in on the name for my post, while also throwing it some shade in the title (and literal ouroboros side-eye in the hero image). What am I going to do, argue with an entire week of tradition? 😅

@mia @adactio.com @jimniels I missed that your post went live! 🏆🏆

@adactio my contribution to the discourse: https://tess.oconnor.cx/2023/11/shadow-dom

Shadow DOM is for hiding your shame

@tosbourn “So long as it’s HTML first code, designed to work with standard web tech” — W3C pretty much the only resourced game in town without some agenda parallel to that

@tosbourn that’s a great @adactio piece

@mxbck “using custom elements to attach functionality to a specific kind of component.” The best part of this approach for me is the scoping of DOM references. Nice article, thanks for sharing! 🤗

@mxbck Care to elaborate? I’m curious how this approach is different from using querySelector and enhancing elements? If it’s reusability, I’m still on the fence.

Shadow DOM and the problem of encapsulation