Prerelease, Promise, and Pitfalls
Web Components Bona-Fides
- Web Components stan account since 2015
- Author of award-winning "Let's Build Web Components" series*
- Apollo Elements,
- Day job: Design Systems @ Red Hat
11ty at Work
Why we Like 11ty
- 📐 Standards-aligned
- Build and preserve team skills
- 🚚 Portable
- Any build environment, any web host
- 💄 Deploy previews
- Drastically better review workflow
- 👐 Low barrier to entry
- Design / developer collaboration
Why we Like Web Components
- 📐 Standards-aligned
- Build and preserve Platform skills
- 🚚 Portable
- Any framework, any backend
- 💄 Save-and-reload
- Drastically reduce tooling burden
- 🌴 Good-old HTML vibes
sudo dnf remove nodejs
- Initially drawn in by the “good-old html” vibes
~ Polymer 3, Bower => npm,
- msg shifted: emphasis on html => emphasis on framework interop
- Maybe that was a strategic mistake?
- Apollo Elements - built to show off the framework interop aspect.
- Chose GraphQL as a typically framework-centric space
- Maybe this was also a mistake?
- Anyways learned different frameworks from writing demos
- But that project gave me experience with implementing the same patterns in multiple frameworks
- So David East talk about njk shortcodes being the same as components. - resonated with my experience making apollo-elements.
When we first heard about WebC, it sounded like a slam-dunk.
- Component framework for 11ty
- Standards-aligned development
- A ✨ Zack Leatherman 💃 joint
So: What’s not to like?
So in this talk we’re going to present some of our impressions of working with WebC, from the perspective of design system and web components engineers with a strong standards-aligned development ethos.
- Low barrier to entry
- Instant familiarity with HTML / CSS experience
- Component mindframe ➡️ Quick iteration
- Brand-new WebC projects benefit from a low barrier to entry and immediate familiarity to anyone with some HTML and CSS experience.
- Internal experiment: evaluate migrating a CMS site to 11ty/WebC
- Designers and technical writers were able to quickly pick WebC up after a couple of short training sessions, and were quickly off and building.
- Taken an existing CMS site which had its own raw HTML layouts
- We identified repeating patterns, abstracted out webc layouts.
- But it’s not html: slots and templates.
WebC is Prerelease Software
- Changes are expected
- Those changes have been and might again be breaking before 1.0
∴ WebC's current state and APIs are like a taste of what's to come
Put critique in proper perspective
And to understand where critique is coming from - the desire to use this
- WebC ≠ Web Components
- WebC scoping ≠ Shadow DOM
- In some cases, data management is awkward
What is a Web Component?
- Custom Elements
- Progressive enhancement with
- Shadow DOM
- SSR with Declarative Shadow DOM
Client-side upgrade (aka "hydration") via libraries
Either or both, but not none
- Projects content into a shadow root
- Moves content from one place to another
When writing WebC framework slots, doing basic things like card - slots are like layout, transclusion layout targets. That was easy to use, and it lines up with user expectations, and is very similar to how real shadow dom slots work
Slots - Broken Platform Features
- Global CSS targeting content
Can lead to Unintended consequences
A Humble Suggestion: Disambiguation
<webc:slot></webc:slot> <webc-slot></webc-slot> <slot webc:transclude webc:nokeep></slot>
Why not an alternative, opt in syntax, which layers server-side features on top of HTML? The specific syntax is less important, although we tend to prefer colon, which is illegal in real HTML, and thus safe for framework use
WebC's style scoping, while fresh, doesn't take advantage of the platform's native scoping ability, Shadow DOM. Styles can collide.
$datavs global scope
- Ejecting to NJK or JS to assign names to data
In general, WebC's data binding is pleasant enough to work with. Sticking points:
Open Questions and Ideas
- DSD Hydration and bundling
- With Lit, etc. or without
- Enterprise scale translations
- in concert with CMSs?
Working with existing custom elements
- Codegen WebC from CEM
- Adopt 11ty?
- Adopt WebC?
- Don't use web components?
- Ready to employ workarounds?
- Looking to FAFO?
SFCs are nice. Fewer (but not none - b) helper functions (no need to context switch back up to 11y config)
Prototype design system elements or patterns in WebC, and the migration path to custom elements will be easier later on. Another case: wrapping existing custom elements in WebC components.
Templating features: custom elements with complex child elements (e.g. nav, tables, accordions) webc’s templating is really useful