KharkivJS: Flaws of the Web Components in 2019 and how to address them

Flaws of the Web Components in
2019 and how to address them
Vladlen Fedosov, Director of R&D @Namecheap, Inc
Hint: prepare your QR code scanners 😉

Vlad Fedosov
Director of R&D @Namecheap
TL;DR:
● 10 years in the industry
● Went path from Junior to Architect
● Use JS since Mootools era
● Amateur DevOps evangelist
● AWS ninja
● Believe in self-organized, cross-functional teams

“Opening the door for everyone to
a free and open Internet”

Our use case & concerns
● Browser support
● Frameworks compatibility
● SSR + SEO
● Styling
● Accessibility
● Versioning
● Delivery
● Solution of choice
● Integration path

Web Components
Quick refresh of the subject

Web Components – In the nutshell
Web components is a set of web platform APIs that allow you to create new
custom, reusable, encapsulated HTML tags to use in web pages and web apps.
Custom components and widgets build on the Web Component standards, will
work across modern browsers, and can be used with any JavaScript library or
framework that works with HTML.
Core speciﬁcations: Custom Elements, Shadow DOM
Important note: you may opt out Shadow DOM and stick to the
Custom Elements only.

Attention – WCs can be used in production
All major frameworks that exist nowadays fully support Web Components (only React has
are some issues with advanced integration).
Browser support:
● IE 10–11 and Edge (Chakra based) are out of the game as they do not support Shadow
DOM.
● All other browsers (Chrome, FF, Safari, iOS, Android, considering 2 latest versions) work
just ﬁne with all major techs we need.
Mobile: Ionic 4 heavily uses Web Components

But they’re still not perfect
Let’s go through the main issues you may face and ways to handle them

Growth problems – Young ecosystem
Web Components as a standard is under development during last several years.
And it was changed quite drastically in V1 (comparing to V0). Also the adoption
just recently grown to acceptable point. And so the tools are rapidly evolving and
changing. Let’s looks at the most relevant examples:
● Stencil – 1.0 version released few months ago, under active development,
documentation need to be improved, relatively low adoption
● LitElement – was started just ~1 year ago, under active development, just
recently published their roadmap.
● React support is far from being perfect

Growth problems – Browser support
Every major browser has open Web Components related issues nowadays. Some
of them major some of them don’t. But be ready to learn most of them at some
point.
The best browser to run them is Chrome, surprise, surprise 😅

Growth problems – Coming specs
As time comes HTML Imports spec was removed while Shadow DOM and Custom
Elements specs were evolved from V0 to V1. And I expect to see new
speciﬁcations being adopted as there are still gaps (which we’ll discuss later) in
the architecture. Let’s look at the examples I like:
● Declarative Shadow DOM
● CSS Modules V1
● Scoped Custom Element Registries
● CSS Shadow Parts

Shadow DOM - brief introduction

CSS inside Shadow DOM – How to load it?
CSS deﬁned inside shadow DOM is scoped to it. Style rules don't leak out and
page styles don't bleed in. But how should I load styles for my markup? Two
options here:
● Constructible Stylesheets (Chrome only, future spec)
● Loading via <link> or <style> tag (performance hit)

CSS inside Shadow DOM – Performance hit
Time, ms

CSS inside Shadow DOM – Performance hit
Devices count
Time, ms

CSS inside Shadow DOM – Way to load it now
● Include only CSS your component really need (extra CSS causes
performance issues)
● Keep WCs related CSS inside JS bundle to prevent FOUC
● How to inject CSS:
1. If available: Use Constructible Stylesheets, for Chrome users (~70% of desktop
users)
2. If Firefox: Use <link> with CSS Blob (Until Mozilla will ﬁx this issue)
3. Else: Use inline CSS via <style> tag (Webkit has optimization for this)

Server Side Rendering (SSR)
It’s theoretically possible to fully render WC at server side (and it even works for
simple ones), but...
There is no stable implementation yet, as well as way to represent Shadow DOM
in HTML 😟 But guys are actively working on a solution.
So what should we do then…? 🤯

Server Side Rendering (SSR) - YAGNI
YAGNI! Keep your content in Light DOM, put WC related code to client bundle and
communicate via DOM attributes/props/events. Treat your WCs as native HTML elements.
You can agree that you’re not rendering Shadow DOM for example for <input
type="text"> element. If components are well designed, crawlers do not need a ﬂattened
tree to get text contents. And use ARIA attributes to add semantic meaning to your custom
elements
<good-components>hello world</good-components>
// It’s shadow tree is using a slot to get text contents
<bad-components></bad-components>
// "hello world" is hard-coded in its shadow tree.

Server Side Rendering (SSR) - YAGNI
<x-tab-group aria-label="My test tabs">
<x-tab role="tab" slot="tab">Title for tab 1</x-tab>
<x-tab-panel role="tabpanel" slot="panel">Content 1</x-tab-panel>
</x-tab-group>

Server Side Rendering (SSR) - Experimental way
But if you really want somehow render your web components, try to experiment with
prerendering (medium complexity) or real server side rendering (hard complexity).
But keep in mind that serialization (including Shadow DOM) and hydration is up to you to
implement. Also server side Web API implementation needed for SSR.
Take a look at the Stencil and SkateJS implementation (scan QR codes).

Versioning – What’s wrong with it?
Currently (and it will likely remain) all WCs must be registered in global registry. So
you can’t have 2 versions of the same component on a single page. This follows
approach that Browser use for the DOM, you have single version of it at a time.
This may become an issue if you have multiple teams working on different apps at
the same website (microservices at frontend pattern).

Versioning – Options we have
Let’s look at the options we have here:
1. Never do breaking changes. This is the principle that Browsers use. And while it’s
possible to do it and it even may be the best option to start with, it’s obvious that it
contradicts to the principle “fail fast, fail safe” and doesn’t facilitate innovations.
2. Tag based versioning. So instead of having <x-button> you would have
<x-button-v1> to accommodate further major versions. So if Microservice 1 requires
button@1.1.5 and Microservice 2 requires button@1.2.1 – button@1.2.1 only will
be used. And if MS1 needs v1.1.5 and MS2 needs 2.0 – both components will be
registered.
3. Microservice based scoping. So instead of having <x-button>
you would have <x-button-mymicroservice>

Our use case & concerns
● Browser support 🙂 (good)
● Frameworks compatibility 😀 (very good)
● SSR + SEO 🧐 (non trivial, needs veriﬁcation)
● Styling 😅(good, but can be better)
● Accessibility 😀 (very good)
● Versioning 🙃 (tricky)
● Delivery 😎 (no major changes)
● Solution of choice 😜 (your choice, try LitElement ﬁrst)
● Integration path 😜 (your choice)

Bonus point
Don’t try to get rid of your favourite framework

Web Components vs Frameworks
To be short: they’re different. Don’t try to replace good old frameworks like Vue.js
or React with Web Components.
Use cases for Web Components:
● Design System / Pattern library implementation
○ Especially valuable if you have to deal with multiple frameworks or want it to be
used by your B2B clients.
● Use them internally to build next-gen framework 😅
○ Like Google did with AMP and Ionic made Stencil
● Bring our own use case 🙋‍♂

Thank you for coming,
you rock 🔥 🤘

Vlad Fedosov
Director of R&D
@Namecheap, Inc
vlad.fedosov@gmail.com
Slides:
Or just scan it: Related
article:
bit.ly/2lYh8eB
bit.ly/2mRZCJa

KharkivJS: Flaws of the Web Components in 2019 and how to address them

More Related Content

What's hot

Similar to KharkivJS: Flaws of the Web Components in 2019 and how to address them

Recently uploaded

KharkivJS: Flaws of the Web Components in 2019 and how to address them