This content originally appeared on Hidde's blog and was authored by Hidde de Vries
I wrote a post about Web Components about two years ago, wondering what kind we would need, if any. More companies have recently started adopting web components. I’m starting to get more excited about them, and think they can be very helpful to encapsulate compositions of elements.
Please note: this isn’t a recommendation for ‘switching to Web Components’, at the time of writing browser support is weak and the ‘components without libraries’ is not reality yet. I’m only exploring the theoretical argument.
We have all the elements we need…
At university, I learned something about Conway’s Game of Life: it can do super complex things with only four simple rules. It has been used to implement things as spectacular as Boolean logic, a clock and a Turing Machine. Similarly, I have always thought the small set of existing HTML tags is enough to build interfaces suitable for anything. From your local grocer to rocket science (for most websites, with some exceptions). We have all the elements we need.
Glider Gun in Game of Life (source)
To have the capability of creating one’s own elements seemed like fun to me, but unnecessarily complicated. At first sight, it seemed puzzling to me: how many companies are there with the resources to implement Web Components and implement them well (fast, usable and accessible)? Two problems still stand out to me: the need for polyfilling and the fact that going custom means having to provide custom usability and accessibility.
Web Components require polyfilling
To get Web Components working in most browsers, we need to use some sort of polyfill or framework. This puts our problems on users. Maybe they don’t have a fantastic connection or a brand new device. To put it bluntly, they might now experience issues they would not have had to experience if it weren’t for our custom element usage.
Custom makes usability and accessibility harder
Custom elements are custom, so browsers and device don’t ‘know’ what they are for. This means:
- they can’t provide a perfect UI that seamlessly matches the platform (as they do for native elements like
select), which could result in reduced usability - they can’t give assistive technology information about semantics, which could result in reduced accessibility
When the (Shadow) elements inside a web component are native elements, part of this problem goes away, as for those native elements, browsers would likely have perfect UIs and good exposure to assistive technologies.
…but we don’t have all the compositions of elements
Maybe providing new “primitive” HTML elements isn’t the point of Web Components. Although the basic building blocks are there, we often combine basic elements. We combine them to create our own things, our own components, patterns, modules or widgets. We may have all the required elements, we don’t have all the required compositions of elements.
Components are often that: compositions of existing elements, complemented with JavaScript and CSS to make a New Thing. The question is: do we want to encapsulate our New Things, so that they are actual, separate things?
We do this without Web Components, too. In front-end pattern libraries, each pattern often has its own folder, its own CSS file and its own scripts. In React or Vue, developers often blend markup, style and behaviour together in one piece of JavaScript.
A web standards way to compositions of elements
In recent years, the web standard gods have worked on lots of new stuff that allow developers to have more access to and influence on the web platform. And more control. Numerous new APIs have been released to give developers access to stuff that only the OS could access, like location and Bluetooth, and to stuff that only browsers could access, like stylesheets and the network. Getting access to the set of elements that exist, and being able to extend that, makes sense in that bigger picture.
Web Components provide a component model to web standards, so that we can stop using complex tools. Yup, less or no external tooling is part of the argument for web components.
With components that are part of web standards, we need less reliance on frameworks, says Alex Russell in his post Bedrock:
We observed that most of what the current libraries and frameworks are doing is just trying to create their own “widgets” and that most of these new UI controls had a semantic they’d like to describe in a pretty high-level way, an implementation for drawing the current state, and the need to parent other widgets or live in a hierarchy of widgets.
In that 2012 (!) article, he observes that creating widgets becomes the core of what modern web development looks like:
Let that picture sink in: at 180KB of JS on average, script isn’t some helper that gives meaning to pages in the breech, it is the meaning of the page. Dress it up all you like, but that’s where this is going.
So, creation of components, widgets, modules, reusable patterns for user interfaces on the web is commonplace — most web teams do it in some way or another. Frameworks provide ways to do this, but Web Components provide a standardised way to do this. See also: Web Components, the long way.
The bright side
I think the decision to go all Web Components shouldn’t be taken lightly, as many organisations may not have the problems they solve, but there are definitely upsides to them. The future for web components is looking quite bright.
Accessibility
Native elements do a great job at having accessibility built in, i.e. if you use a select you can be quite sure most of your users will be able to select stuff with them, even if they use assistive technologies to access your site, even if they have colour blindness. At the point of usage, you don’t need to worry (much) about how accessible it will be.
If you build your own component now, you will likely use some JavaScript to make accessibility provisions. There’s some risk they get lost when being copy/pasted. With Web Components, those provisions are not in the markup, they are an integral part of the component. They will be there every time you use the component’s terse syntax.
Even better, if the Accessibility Object Model becomes a thing in browsers and Web Components are better implemented, we can set accessibility properties and states directly in JavaScript.
Real encapsulation
With custom elements, you can have scope in HTML and CSS, not just in JavaScript.
IMHO, this is a solution for a problem that is not a problem, but I realise people disagree about this. The advantage of this solution is that you never need to worry about where you use a component, as it will have exactly the styles you’ve applied to it. Personally, I will probably still take advantage of CSS’s cascade.
Conclusion
And that’s what I’d like to end this with: the pre web component web is not going to go anywhere. If your website is not extremely complicated, it still makes lots of sense to just write HTML, CSS and JavaScript, keep things simple and stay away from custom elements and Shadow DOM. Peruse that cascade, do some simple DOM scripting, leverage all that built-in usability and accessibility, and be done with it.
If you have quite a complex codebase that is componentised through a framework like React, it would make sense to look at Web Components, the web standards way to build encapsulated components. In the future, when they are supported across the board. That isn’t the case at this time, so for now, they are still just theoretical awesomeness.
Update 24 October: removed parts that suggested I was recommending Web Component usage today; added a note at the top to clarify.
This content originally appeared on Hidde's blog and was authored by Hidde de Vries
Hidde de Vries | Sciencx (2017-10-19T00:00:00+00:00) Web Components as compositions of native elements. Retrieved from https://www.scien.cx/2017/10/19/web-components-as-compositions-of-native-elements/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.