Web Components Bona-Fides

• Web Components stan account since 2015
• Author of award-winning "Let's Build Web Components" series^*
• Apollo Elements, <stripe-elements>, etc.
• Day job: Design Systems @ Red Hat

11ty Bona-Fides

• This website is made with 11ty
• Use and Advocate for 11ty at work
• Contributed to Rocket pre-release
• eleventy-plugin-slide-decks
• webc.nvim

11ty at Work

• ux.redhat.com
• patternflyelements.org
• Our design system docs sites, including:
  • Custom Element API docs
  • Live Code Playgrounds
  • Component Demo Pages

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, .html to .js
  • 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.

1. Component framework for 11ty
2. Standards-aligned development
3. 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.

🥦 Freshness

• 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.
• This was particularly good for layout components like card grid. We think that 11ty could have done this great with dsd / standard custom elements, even without clientside javascript to register the tag names
• Most of our interactive bits or javascript parts were about reflecting attributes for css selectors, etc

🥦 Freshness

• 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

🧀 Less-than-Fresh

Put critique in proper perspective

And to understand where critique is coming from - the desire to use this

🧀 Less-than-Fresh

• WebC ≠ Web Components
• WebC <slot> ≠ <slot> in HTML
• WebC scoping ≠ Shadow DOM
• In some cases, data management is awkward

What is a Web Component?

Make-your-own HTML

Custom Elements

• (Currently) requires JavaScript
• Progressive enhancement with :defined

Shadow DOM

• Does not require JavaScript
• SSR with Declarative Shadow DOM

Client-side upgrade (aka "hydration") via libraries

Either or both, but not none

Slots

HTML <slot> element

Projects content into a shadow root

WebC <slot> component

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

• ::slotted
• slot="named-slot"
• 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

Scoping

WebC's style scoping, while fresh, doesn't take advantage of the platform's native scoping ability, Shadow DOM. Styles can collide.

Data scoping

• $data vs global scope
• _components vs _includes
• Ejecting to NJK or JS to assign names to data
• 11ty:type=js semantics

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

Takeaways

Adopt 11ty?

👍

Adopt WebC?

🤔

Don't use web components?

👍

Ready to employ workarounds?

👍

Looking to FAFO?

👍

Thank You!