My comment to yesterdays Dev.to post: Web components failed. We can fix them became a full post:
Web Components Never Failed
Web Component history
The Web Component story didn't start with today's Custom Elements.
Almost 28 years ago, in 1998, Microsoft proposed HTML Components (HTC):
https://www.w3.org/TR/NOTE-HTMLComponents
Mozilla took its own stab at componentizing the Web with XBL, first developed for Mozilla and later proposed as a specification:
https://www-archive.mozilla.org/projects/xbl/
Different technologies, different APIs — but the same underlying desire:
Make pieces of the Web reusable, encapsulated, and programmable.
Browser vendors were already building Web Components
Browser vendors have been using Web Component machinery for many moons longer than we mortal developers have had today's standardized Web Components APIs.
To Us, Modern Web Components became broadly available roughly around:
Chrome 2016 · Safari 2017 · Firefox 2018 · Edge 2020
But browsers themselves have always had another problem to solve.
The WHATWG specifies what an HTML element should do.
Browser vendors still have to decide how to build it.
Take a complex native element such as:
<input> <textarea> <video> From the developer's perspective, that's one element.
Underneath, there may be an entire internal UI: buttons, sliders, labels, tracks, controls and state.
That should sound familiar.
It is the same shadowDOM architecture us mortal developers use!
<video> with sahdowDOM in Chromium
<video> with shadowDOM in Firefox
With the appropriate DevTools settings, browsers can expose these internal trees for inspection.
They're not your DOM to manipulate.
They're implementation details.
And that's precisely the point.
Web Components did NOT fail
So saying:
"Web Components failed."
has always sounded a little strange to me.
We interact with componentized browser UI every single day.
The browser platform itself demonstrates why encapsulated components are useful.
The question isn't whether components work.
The interesting question is:
Why don't we build more of our own software that way?
Mortal developers and Web Components
I think part of the problem is that we keep thinking in Apps.
Frameworks encourage that.
They scaffold applications.
They give us routing, state management, rendering systems, build pipelines, dependency graphs and application architecture.
And that's perfectly fine when you're building an application.
But:
Frameworks scaffold Apps.
Components are components.
A component doesn't necessarily need to know anything about your application.
A <date-picker> doesn't care whether the surrounding application uses React, Vue, PHP, Django or plain HTML.
A <relative-time> shouldn't need to know either.
Neither should:
<playing-card rank="Queen" suit="Hearts"></playing-card> <mark-down src="playing-card.md"></mark-down> They should just work.
We're still building like it's 1899
There's another problem.
Many developers learned one particular way of building software and then taught those patterns — directly or indirectly — to AI.
So AI happily reproduces them.
Ask AI to build something and you'll often get an entire application architecture when what you actually needed was:
<something-useful> The tool isn't necessarily wrong.
We're asking it to build the wrong thing.
That's a mindset change.
Change your perspective from:
Everything is an App
to:
Apps with frameworks. Components with Web Components.
There are Henry Fords out there already working differently.
And I suspect some of them aren't shouting about it.
Why would they?
Once you've trained your tools — and your AI — to produce small, independent components instead of miniature applications, it can become a competitive advantage.
"I can do Web Components better!"
In 2022 there were already around 60 approaches listed in:
I-can-do-Web-Components-better
Sixty!
And here's where I think we repeatedly take the wrong turn.
You discover Web Components.
You develop a few helper functions.
Then:
Oh, it needs this feature...
Then another feature.
And another.
Soon you've created conventions.
Then abstractions.
Then dependencies.
Then documentation.
Congratulations.
You're building a framework.
Instead, write the abstractions you need for your components.
They don't have to become somebody else's architecture.
What about Lit?
Yes, I consider Lit a framework.
It provides its own abstractions for rendering, reactivity and component state.
That's useful if that's how you want to work.
But it's not the only way to build Web Components.
You don't have to write HTML template blobs.
The DOM already has an API.
document.createElement("button") isn't primitive.
It's powerful.
You have the entire browser platform underneath you.
Use it.
Write a one line helper function
const createElement = (tag,props={}) => Object.assign(document.createElement(tag),props); And you are really using the platform!
Developing Web Components
Develop Web Components like you use .reduce():
No developer ever told you that you must use it exactly like they do.
That's the freedom Web Components give us.
There doesn't have to be one architecture.
There doesn't have to be one framework.
There doesn't have to be one correct abstraction.
Build the component.
Give it a useful API.
Let the browser do the rest.
Every <input>, <video> and <textarea> you use is a reminder that complex functionality can live behind a simple element.
So:
Web Components never failed.
Maybe we just haven't learned how to use them yet.
