You really don’t need jQuery any more …and that’s thanks to jQuery.
A step-by-step guide to wrapping up a self-contained bit of functionality (a camera, in this case) into a web component.
Mind you, it would be nice if there were some thought given to fallbacks, like say:
<simple-camera> <input type="file" accept="image/*"> </simple-camera>
I strongly recommend that you read Going Offline by Jeremy Keith. Before his book, I found the concept of service workers quite daunting and convinced myself that it’s one of those things that I’ll have to set aside a big chunk of time to learn. I got through Jeremy’s book in a few hours and felt confident and inspired. This is because he’s very good at explaining concepts in a friendly, concise manner.
The beauty of this approach is that the site doesn’t ever appear broken and the user won’t even be aware that they are getting the ‘default’ experience. With progressive enhancement, every user has their own experience of the site, rather than an experience that the designers and developers demand of them.
A case study in applying progressive enhancement to all aspects of a site.
A good explanation of web components, complete with some code examples.
Web Components are not a single technology. Instead, they are series of browser standards defined by the W3C allowing developers to build components in a way the browser can natively understand. These standards include:
- HTML Templates and Slots – Reusable HTML markup with entry points for user-specific markup
- Shadow DOM – DOM encapsulation for markup and styles
- Custom Elements – Defining named custom HTML elements with specific behaviour
Andy Bell is documenting is journey of getting to grips with web components. I think it’s so valuable to share like this as you’re learning, instead of waiting until you’ve learned it all—the fresh perspective is so useful!
I’m on Team Dave.
Three technologies that Ada is excited about:
In which Brian takes a long winding route through an explanation of why the
is attribute for custom elements is dead before he demonstrates the correct way to use web components:
<!-- instead of writing this --> <input type="radio" is="x-radio"> <!-- you write this --> <x-radio> <input type="radio"> </x-radio>
Sadly, none of the showcase examples I’ve seen for web components do this.
I think this is the best delivery of this talk I’ve ever given. It was something about being in that wonderful venue.
I got quite worked up around the the 32 minute mark.
The latest edition of Heydon’s Inclusive Components is absolutely fantastic! The pattern itself—toggling sections of content—is quite straightforward, but then there’s a masterclass in how to create a web component that still allows the content to be accessible in older browsers. The key, as ever, is progressive enhancement:
Whether implemented through web components or not, progressive enhancement not only ensures the interface is well-structured and robust. As we’ve seen here, it can also simplify the editorial process. This makes developing the application and its content more inclusive.
At the 14 minute mark I had to deal with an obstreperous member of the audience. He wasn’t heckling exactly …he just had a very bad experience with web components, and I think my talk was triggering for him.
One of the things we’d hoped to enable via Web Components was a return to ctrl-r web development. At some level of complexity and scale we all need tools to help cope with code size, application structure, and more. But the tender, loving maintainance of babel and webpack and NPM configurations that represents a huge part of “front end development” today seems…punitive. None of this should be necessary when developing one (or a few) components and composing things shouldn’t be this hard. The sophistication of the tools needs to get back to being proportional with the complexity of the problem at hand.
I completely agree with Alex here. But that’s also why I was surprised and disheartened when I linked to Monica’s excellent introduction to web components that a package manager seemed to be a minimum requirement.
Monica explains how Shadow DOM could be the perfect answer for scoping CSS:
Although, in a way, Shadow DOM is also another flavour of CSS-in-JS:
Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
A really great introduction to web components by Monica. But I couldn’t help but be disheartened by this:
Web components tend to have dependencies on other web components, so you need a package manager to herd all them cats.
For me, this kind of interdependence lessens the standalone nature of web components—it just doesn’t feel quite so encapsulated to me. I know that this can be solved with build tools, but now you’ve got two problems (and one more dependency).
Really, really smart thinking from Paul here, musing on the power relationship between the creators of custom elements and the users of custom elements.
This is nice example of a web component that degrades gracefully—if custom elements aren’t supported, you still get the markdown content, just not converted to HTML.
<ah-markdown> ## Render some markdown! </ah-markdown>
I spoke my brains in this podcast episode, all about web components, progressive enhancement and backwards compatibility.