all right morning
everybody uh I want to kick off just by
saying that building uh front ends with
consistency and and code reuse and
maintainability in big companies is
freaking hard uh I've been building
front ends for over a decade for
everyone from large Enterprises and
startups and and massive government
departments um and we always end up
chasing the same things so today over
the next 60 minutes or so I'll share
with you how I'm working using uh design
tokens and reusable web components to
solve our problems of having you know
consistent uis that we can build quickly
and change quickly uh I'm uh idev I work
for an Aussie company called zware and
we're currently working with the
Australian government building their
next generation of Design Systems uh and
it's a very fun topic so why web
components why why did we go down this
path well for us we want to be able to
achieve this we want to write one
component we want to make a button my
dash button here and we want to use it
in three different places we want to use
it in react we want to use it in angular
we also have to use it a CMS system
which is always that odd ball that you
get on the end that makes helps pivot
you to this decision using web
components because web components are a
standard I think before the talk we had
about you know 20% of the room put their
hand up and said they're using web
components which is you know always a
growing number every time I ask that
question um so it allows us to achieve
this ability of having one component we
WR InStyle in one spot and using
different Frameworks and platforms
across larger companies and for us in
particular I said we've got this concept
of our CMS system and we're trying to do
a micro frontend strategy so our shell
of our CMS system might use this blue
button in the top main menu and then we
might have you know one micr front end
for an angular uh feature one using that
same blue button and then also with
react having on the same
page and we also using design tokens a
lot so imagine this idea that your
business all of a sudden says we want to
change color we want a new primary color
we want to go from a blue to a green and
this is where like say imagine this
second button here on the angular micr
front end is helping us so I'm not going
to be talking Lots about micr frontends
but this idea that you have this need to
be able to have consistency in your UI
across lots of teams and then be able to
have components that can run in
different platforms because as you get
bigger in these companies you tend to
not have the luxury of a single
framework so these design tokens are
pretty simple um and they're really just
key value pairs who's using just another
survey of the audience who's using
design tokens at
work okay maybe a smaller number here
maybe like 10% okay so a pretty new
thing they're very simple we're going to
talk a bunch about them um if you
haven't used them before uh they're best
basically a key value pair so on the
left you got some name on the right you
got some value here so this is color-
primary that's set to a blue color and
you put a version on it and that's one
of the most important things that you
get out of this benefit is you're
codifying these designed decisions you
want to change it it's just like normal
code you bump the version you change the
color and now you've got that green
color all the teams can decide when they
want to pull that package just like
normal things so this kind of process of
having things codified makes a huge
difference for us so we're going to be
talking a bunch about design tokens but
these design tokens and components one
thing we've found is you know that's
only probably 2third of what you really
need to bang out really consistent uis
really quickly for us there's also a
whole bunch of CSS like shared CSS stuff
and also your documentation that you're
going to need to really nail to be able
to have someone just very quickly build
out a UI in a consistent way in a new
project so this stories today I guess
they War becoming War Stories we've been
at this over a year now um and we have
many Design Systems many many teams many
projects many repositories and when you
have that scale and that mess to afford
having a platform team then a lot of
what I'm talking about today is on that
level so if you are a frontend Dev but
you're not necessarily dealing on a
platform team hopefully there's a bunch
of takeaways from today in the eyes of
like well what would it be like if if we
were to actually stand up a team to do
this and centralize all our components
what are the challenges around it but
also maybe some tips and tricks for you
that you can take back to how you're
building on a smaller level sharing
components within an app or within a
couple of apps or something like that
but it really is more of a story around
a bigger scale of like you know you've
got lots of teams and departments and
you've got some budget to solve this
it's not our first rodeo this is
actually our third design system so when
we started it that scared the hell out
of me because I'm like how many years do
we have before we're one of these other
Design Systems or sets of components
that's died but we've we've been very
successful doing we've got a lot of
value out of it we had one in react one
in angular last one's about 5 years old
and eventually it's become too Limited
in being its scope and it's its audience
being just in angular where we
are so about a year ago we set off on a
journey we got budget we got about five
people and we took off to build our next
generation of of components really
naively which is always great at the
start of a project we're full of
enthusiasm I'm a bit more jaded now but
it's still been a lot of fun over the
process so today we're going to we're
going to talk about the team that you
need to pull this off because that's a
big part of it um and then we'll talk
about y web components for us and then
we'll talk about design tokens and how
they're represented in code and then
we'll talk about some of the tooling and
packaging that we've used um in our
setups to be able to achieve
this so what's the team that you need to
pull this off it's worth talking about
this if you get to the scale where
you're actually going to try and
influence a team that you don't work
with it becomes a really big part of it
and I got a quote here about Design
Systems you know being something about
digital experiences and cross functional
teams and a shared language um that
eventually ends up being a language that
you use across devs and designers and
for us that's been a really big part of
trying to get buy and intraction is
unifying these devs and designers and
coming up with a shared way of being
able to describe all the different parts
I'm sure a lot of developers in the room
have experienced frustration getting
handovers from a designer and it looks
great but there's just no detail there
to be able to implement it so being able
to get a really rich experience on that
Handover and work with the designers a
lot has been really important for us and
you often see people ban to this around
saying the best team you need you want
to stand up like a small team with a
designer a developer and like a cross
designer developer kind of lead person
in my role that's what I do I'm kind of
the glue person not much of a designer
much more a developer very much Hands-On
in the team as well shipping code as
well as kind of doing a lot of the
advocacy for our product um but this is
not really enough in my mind I kind of
think it's great it's true but what
we've experienced over time is that you
also need an accessibility expert like
if you're going to go build a whole
bunch of components for your team it's
quite difficult to get right down into
that nitty-gritty of accessibility so
even though everyone on my team now has
done it for a year and we talk about it
every day we had to meet with our
accessibility Team every week for a year
to get to that point that we really have
at grock so it's really good to have and
someone who's just lives and breathes
accessibility to be able to access and
of course bigger companies there's
always politics and minutia you really
do want to try and find some Champion
for your product to get out there and
drive at a higher level someone who sits
in meetings all day long with business
deciding where money is going and
getting that force in place so this is
what we kind of had and took off with
and it was working quite well for us we
kind of hit some Road bumps in the way
that we'd taken off with our team and
really that's because we had this maybe
not 10x team but we had a great team
like totally not a problem with our
skills to be able to get the job done um
but it was it's kind of worthless if all
of a sudden you're not the source of
Truth you really need that buying from
all the company and all the other
departments to use what you've created
and that was a real challenge for us
especially around design what we
realized that we designed all of these
components we had this great setup and
then we're like uh this other team in
the six months that we've been going now
who already do all the designs and speak
with everyone else actually there's two
departments we found there was a whole
another department doing their own
designs in another space um we had to
stop and actually get everyone to come
back together so what we actually ended
up was just sticking with traditional
silos so we kicked the designer off our
team um because we're like we love
having you here but as while you're one
of us building stuff with us devs it's
not going to work because this other
team is off doing their own thing and
they really are the source of Truth so
we ended up going back to more of a
siloed model like this and just spending
our time trying to collaborate with the
design team which worked out much much
better because all of a sudden they came
on board to say say we're going to take
all of our marker all of our design
tools we use XD we'll version it and
every 2 weeks we'll release our designs
with a change log in a version Oh my God
it was amazing um and that really
changed things for us and really started
bringing this together and on the flip
side of that what happened in these
teams is that each of these silos has a
business champion and when we actually
released we actually released as three
different teams presenting the one
product and everyone was actually like
rather than going oh yeah I'm not sure
what they're doing everyone from all
angles was saying if you've got a
problem or you're doing a new page you
should use the design system and our
components so we ended up kind of
pivoting back to this sort of model and
it was really good to actually do that
and just invest in the relationships
across these different
silos one thing I really wish we'd done
earlier to kind of poke holes in all
this stuff and I guess it's like a
normal principle of design or
development and we spoke about this a
lot at the start is I really wish it
built for purpose I really wish we said
okay what's the next web page or
whatever it is coming off the factory
floor and let's just take one component
and build for that and let's challenge
ourselves to get that into production in
the first month so rather than rewriting
and getting everyone in this idea that
it'll be 6 to 12 months and then it'll
be a big bang rewrite and we'll rewrite
everything just say look we're just
going to take the next web page coming
off we're going to write a button and
that button then needs to be versioned
documented and agreed and signed off and
tested and all of these things that you
would have flushed out in that process I
really wish we' done that we didn't we
spent 6 to 12 months we did a big bang
release and it's been good but it would
have been much better if we'd done it
this way because it would have poked out
all of those politics and made everybody
come out earlier and realize especially
all the business people who just assumed
we just spin up this component Dev team
and they'll solve
everything so that's enough of the
politics I think it's worth talking
about you can hear in my voice that
there's a bunch of challenges around
trying to get that off the ground even
if you're a small company there's people
who have already invested in their
components and their way of doing things
and for them to change can be sometimes
tricky
but let's talk about the fun stuff let's
talk about some web components for a
second and move into talking about that
so why web components for us well I
already showed you this
slide and if you look closely at this
we've got this my button we actually
wrap our web components um for react and
angular uh it comes out of the box we
use a tool called stencil I'll show it
in a second um so if you look at the
second line here with with the react one
it's actually like a react looking
component it's in um title case and
it'll work just like a react component
for the reactives same with the angular
one and they can use angular binding and
angular form controls and then we have a
vanilla JavaScript one at the bottom
that the content management system use
so all the debugging all the developer
experience at that level is just what
they're used to and it just kind of
works for the framework that they have
takes us a couple of weeks at the moment
for someone to get up to speed to
contribute to our team so we do inner
Source we're not open source and if a
Dev comes and wants to help us and have
permission because they want to solve a
problem probably takes them about 2
weeks to understand what's happening in
our component kit to actually contribute
and build something but because there's
so much in there now it's not too hard
they can copy and paste and go through a
merge request and they get it in so
we've had several kind of inner Source
merge requests come in from other teams
which is great and the other thing that
we found with these web components is
because they kind of come down to one
file that someone uses a lot of our devs
can just open them up in the dev tools
and they debug them because it's just
JavaScript and the front end Dev know it
and they're like oh I found this issue
and this happens and that happens and
they can put in a pool request or at
least contact us and say here's a code
snippet I think it's this thing that's
going wrong because they're not that
complicated under the hood there's just
one piece for a button or a form field
and it's JavaScript really and you can
just open in the dev tools and inspect
it yes there's a bunch of web component
standards that most front-end developers
haven't been exposed to yet but they can
just go ahead and do
that but let me be clear I I think you
got to be pragmatic it would just be
heaps easier if you just used react to
do this or insert whatever framework you
want in particular react because it's
got this massive ecosystem um and I'm
not a react Fanboy or an angular Fanboy
I luckily get to play with all of them
which is fun um but it would be easier
you could just go get a headless UI
Library there's one called headless UI
there one called radex and you could set
up design tokens and just use react and
that would just be much easier because
you don't have to reinvent the wheel but
when you have that that desire or a risk
to run in other places than react then
you don't necessarily have that luxury
and we didn't have that luxury um we
have a mix of react and angular but we
also have other things so it it would be
hips easier it is an investment to use
web components but it is the main driver
for us to get into this place so it' be
easy to argue that web components you
know some people might think that
they're still a toy or they're not quite
ready for production but YouTube uses
them I'll roll through a few here you
know you can go look at uh Adobe who
have released their beta version of
their web product pretty complicated
uses web components just the other week
uh Google who are a big proponent of web
components um said if you want to use
one of our map widgets here's a web
component there's not a react version or
an angular version this just here's your
web
component and then if you're using Bing
and then new AI stuff that's all written
with web components as well this is from
the fast UI team at Microsoft um and
they use web components as well so
uh lots of people using it lot of these
big players it's hard to argue that you
won't get to the Finish Line with web
components you don't have to read this
code it's not the point it's just to
show you that I've got a file with some
JavaScript written in it that's not
compiled or anything it's just
JavaScript you can write to write a
basic web component it's a web standard
and you can take this simple file no
compiling no typescript in it and then
you can just write a script tag in the
browser and you can just say well here's
my custom element Define which is
supported in all the abren
browsers give your name to your custom
element Hollow dworld past your
JavaScript your Hollow world and then
you can just plop it on the page and it
will run and that's really the vision
and the dream of doing this is that it's
kind of runs anywhere it's it's kind of
interoperate with all the other
Frameworks ironically we don't do that
we all use some library on top of it
most people do so we use stencil it's
one of the main two there's another one
called lit which is from Google and this
one these it's really a two horse race
between these two different people
you're going to end up having to do your
due diligence if you go down this web
component path I'm not going to get into
a big discussion about one or the other
super satisfied with stencil it's
amazing you're totally going to get to
the finish
line and really they're the only ones
this is the npm downloads for the two
libraries um and I really see two things
on here not one is better than the other
or something like that more just the
fact that there's this going up since
the beginning of kind of 2021 is as as
this became a browser standard and you
could start using web components without
polyils and all of that stuff that both
of them are trending up still small in
the perspective like this is what one
and a half million downloads between the
two top libraries every month and then
if you look at react it's like 10 or 20
million but it's still it's significant
and it's growing this trend and you can
see I think it's hard to ignore here
lit's definitely more popular and if we
were to start
again would I use one or the other I'm
not sure pretty happy with stencil um
but probably yeah I'll do the due
diligence and put them head-to-head and
see which one you want to
choose this is also really interesting
shows that same correlation here with
web components so this is looking at
Chrome statistics of page loads who call
that custom elements. Define so you can
start to see this trend here of it going
up still not massive but we're like at
15% moving towards 20% of every web page
that loads with chrome has a web
component on it or calls that method so
it's it's definitely a growing spot but
still a niche but I'm surprised I've got
a room of people who want to talk about
this Niche it's good to
see so I think the reason why we're all
so excited about it is because it's web
standards there's three web standards
there's custom elements to make a
component you got HTML templates you get
your kind of Syntax for binding and all
that sort of stuff and looping and or
what have you and then you got Shadow
Dom and I'll probably spend a bit of
time talking about Shadow Dom today cuz
a bit of a pain in the ass it's a really
nice encapsulation
um but it's got some challenges at the
moment and that's probably where our war
stories are around um and but it's also
one of the great points of web
components but it's definitely it's
soaked up a lot of time on our team to
get up to become an expert in it um but
as a web standard it's worth investing
in that I
think as I mentioned if you go to the
can I use website this is what we're a
few years in on this it's Evergreen
Evergreen browsers you're all fine like
you're going to be able to use most of
the main things that you want to be able
to do without any polyfills or such and
I is dead as of about a certain time
last year and most of us don't have to
consider it and that was kind of also
another big pivot point that I think you
start to see in these charts of people
becoming you know more comfortable to
use these browser
standards so I'm not going to go into a
huge like Story how do you use a web
component how do you start writing one
and all that sort of stuff I I think it
they really do do what they say on the
tin you know I think you know if you're
choosing to go down the web component
path that you're going to be able to use
them and you're going to be successful
um and that really what it says on the
tin is these are you know a w3c standard
to be able to use just vanilla HTML CSS
and JavaScript to write your own
reusable custom elements and the
dream if you're you know riding down the
beach on a unicorn you know into the
sunset is that you've got this
interoperable set of tools with any
JavaScript framework and you know you'll
have simpler code and faster and more
readable and all those sorts of things
and I I think it is true I think you
know if once you've got your head around
them and them being a standard you know
and you can move them between these
different places you will be able to
move faster especially if you're in a
transition period from one framework to
another all of a sudden you get this
massive return in investment because you
can just move or you can experiment you
know there's lots of benefits there and
for us mostly about getting the design
consistent so Shadow Dom's pretty simple
got this idea of a document object model
a Dom tree full of nodes divs spans
buttons whatever and then you've got
this custom element in pink here that
has its own separated you know Dom tree
and we call that the shadow Dom the
Green Space would call the light Dom and
a lot of conversation back and forth
about where you are about all sorts of
things and a lot of it comes down to a
couple of different pain points but if
you run this component in the browser
and you open the dev tools and you
inspect it you'll see you know Shadow
root sitting there and it's the HTML
there's this Shadow Dom tree there that
you see inside of it it's a stuffy right
there that's encapsulated and separate
from what's outside of you on this
Shadow host which at this point is your
Hollow dash world component or
element there's a couple of reasons why
Shadow da makes things a fair bit harder
um it's a nice encapsulation and it's
only going to get easier to work with
but yeah we've definitely dropped a lot
of time trying to get used to it so one
of those reasons is theming and it would
be really interesting because there's so
many people here today actually using
web components to speak with um
afterwards see how they're solving this
problem of theming because you
inevitably going to end up with a bag of
components and you want to style them
but you don't necess you know you want
other people to be able to potentially
override those Styles and there's a
balance between that
point luckily we have CSS variables now
in the browser and good thing about CSS
variables you know this dh- color-
primary here this prefix with the dash
dash you know Works in any of the
browsers like SAS variables would but
you know these are kind of taking over
now being a web standard these can cross
that shadow Dom boundary and the CSS can
come in because really the CSS between
you know your Shadow Dom and the light
Dom really can't influence each other
the way you would like to just normally
with global CSS which is a good and bad
thing so if you imagine this is kind of
PSE sudish code imagine the green my
button here is your Shadow host your
boundary that's your web component and
then the stuff inside your button here
um that button is just a native button
so if you've never seen a web component
or thought about this idea here you
don't actually take a native button from
the browser and then extend its ability
that's not going to come to this there's
already been a lot of discussion around
that you're going to put these things
inside but now all of a sudden you have
to somehow do what You' normally do to
the button but you've got this layer
outside of it so we're just talking
about the styling side of it here but
you could also think about the props
that you need to drill in like a button
has a lot of HTML things on it that you
might need to expose outside as well and
then you got a prop drill down to it but
really what I want to talk about here is
the styling so I've got a class on this
button but it's inside the Shadow do
class equals BTN terrible name but it's
in the shadow Dom so I really can't
affect the Styles in a global space and
there's a few ways to work around it
I'll show you where we've kind of ended
up now in the next 5 10 minutes so if I
wanted to globally style this imagine
this is kind of pseudo code I just put
it on a page and then I made a style tag
underneath this won't work for me I
can't just go select dot button select
it with CSS because it's inside that
shadow Dom even though I'm kind of
trying to choose the background color of
that button and apply a CSS variable
that I said works it won't work because
it can't cross the shadow Dom to get in
there until you actually register it
inside the shadow Dom um so for us we
kind of took off in this way first we
said okay we've got all these components
here a drop down here's a button here's
some um a card and so forth and then we
actually inline all the CSS and that's
brilliant because then you got this tiny
little bundle that someone can just
install they don't care about the whole
thing but then theming becomes difficult
because you've now got this black box
and they can't just easily reach in
you've got to set some strategy up to
reach in and there's a couple of
different approaches that you can take
but for us we we didn't really have a
very deterministic start to our journey
we had one main depart depart that was
funding us and they had a big enough
problem that that was fine if we never
went past that but we knew very quickly
that we're going to probably become more
whole of government especially in an
umbrella set of departments that we had
and they were going to come to us with a
bunch of unicorn designs that were very
bespoke and just be too difficult for us
to describe in properties for what they
could
configure so if you took this button
component again with this button class
inside the shadow Dom what I can do
inside the CSS for this web component I
can set up like a public API I can say I
want to have a colon host and then I'm
going to say this D- background- color
is my public API for my component we're
going to say upfront what are the things
people can style inside of the Shadow
Dom here for this component and this
works well when we started doing this
but what we found really quickly is that
it just became really difficult to know
upfront what our consumers were going to
want to style so even though this works
and it's one of the primary methods for
doing it and if you have quite a simple
component with only a few things that
you want people to configure this
approach works well but for us we really
didn't have much idea so it just started
growing and then you want to change the
background color then you want to change
the color and then you very quickly end
up in this place where you've got to
document all of these things up front
that you might want to change on a
component and that gets really difficult
for us and we had just we didn't really
know what people were going to want and
we knew that we're probably going to
need to style a lot from it from outside
of the
component so for us we invested quite
heavily in in a web component strategy
uh tooling with the part attribute now
this is something you probably haven't
seen if you're doing one of the
Frameworks is it's only what You' do
with Shadow Dom and what it what this
allows you to do it's a web standard it
works in all the browsers is you say I
want to say this part and I'll declare
it up front inside my shadow Dom is now
exposed outside of that shadow Dom so I
can then go and do something with this
weird syntax of button you know colon
colon part and then pass in that name of
button and then that person can do
anything they want with that button not
just what we've said they can do with it
they can't do anything with the children
just the button so it's still
restrictive but it works quite well for
us we probably
put five to 10 parts on one of our
components and we document it the
tooling just autog generates it for us
um and that's been enough for us to
style everything from the outside and
when we want to do more parts we just
add more parts to this thing so here
imagine I used another component and I
started composing components and
components it's still got this my- icon
component still has its own internal
Shadow Dom that we want to get to I can
expose that as another part and then
down here at the bottom I can just do
the same strategy icon colon colon part
icon so a lot of people are like ah
parts are good but that's kind of
cumbersome yeah still a bit annoying
it's solving the problem quite well for
us we're able to dog food uh our
strategy now is having a global theme
for different kind of Brands and Design
Systems and we end up with a fair bit of
stuff in a global space where we've kind
of styled it all out there to prove to
ourselves that when the next design
system comes on we can do that for them
this kind of sucks though because now
we've got Global CSS and we have to pay
a cost for downloading that in the
browser so that's about 10 kilobytes for
us gzipped when we go speak with all the
teams they're like actually ours is a
mess right now that's better than what
we're doing so we can live with that um
but 10 kilobytes it's not too bad but it
would be much nicer if I just wanted to
use the button and I only get like half
a kilobyte of CSS just for the button um
but for us it's a compromise that's been
okay and in the future it's very easy we
could pivot to say to people look you
might have to do one extra step to
inline the CSS just for the button but
you can have the component and the CSS
and be a smaller package but most of our
consumers are like we're building this
big web app we don't mind that 10
kilobyte
hit other second thing that's pretty
tricky with Shadow Dom is accessibility
um in terms of the fact that
accessibility is harder because you
can't ID reference across that shadow do
either so this is definitely something
that just adds another level of learning
curve especially as we talk with the
accessibility experts not they've not
only got to try and help us but they
also got to try and change their me
mental model and come on the Journey of
using web
components and that's because these ID
references don't cross that shadow
boundary into the shadow Dom so this
works I got an input and a label just
native HTML elements I've got a four
attribute on the label and an ID and
they're pointing at each other so an
assisted screen reader will just work
yeah that's fine both in the shadow Dom
also fine they can point to each other
so if I put those same combination
inside of it and this is what we do a
lot we just try and solve all the
problems for the devs by even
accessibility but inevitably you want to
customize this accessibility stuff from
the outside so when someone wants to do
something like this you can't you can't
just go make a label element outside of
the Shadow Dom and then have it Point
into the inner Shadow Dom and that kind
of sucks this is a real kind of eh don't
like that um but you got to live with it
and for us most of what we've found is
most of the time all of the
accessibility is usually dealt with
inside the shadow Dom and when it's not
we will prop drill down a property on
the outside on the shadow host to say
input area label or input area
description or input R message error
message you know these options that
we'll pass in and have a convention for
that and then we actually just pass it
down onto the inside thing and it works
it's working for us but it would be nice
if we didn't have to do that and someone
didn't have to learn that idea and they
could just point
across so here's the grass greener I
feel like I've been winging for 20
minutes about Shadow Dom um I I do think
it is I'm really bullish on web
components if you have this problem
running across different platforms or
different Frameworks
um and and these things are always
changing you know even in the time that
I've been kind of we've been on this
journey and one of the the great parts
of it is you spend most of your time
reading these two documents you're not
going to be in the angular docs the ACT
docs The View docs you'll be on these
two sites looking at web standards to
figure out how to do stuff which is
great and that's great because these
things move like a glacia they just
don't move very quick even though
they're moving at the moment but you can
stop and invest in them and take your
products and your teams and your careers
along with
them they are changing really quickly in
a way I say they're moving slowly but
they do change um service side rendering
is an example right now service side
rendering isn't out of the box there's a
library from stencil there's a library
from lit there's a library from Fast UI
and there's an emerging standard called
declarative Shadow Dom and a lot of this
a lot of Google's one of the big pushers
for a lot of this innovation in this
space and this will solve this problem
of being out of render you know your web
component on the server and then just
pass it down like we do in a lot of our
modern meta Frameworks but it's not
quite here yet I think Firefox is the
lagging browser in this
position but the points that I'm trying
to make is things are coming through and
these are web standards and it's getting
better just over the time that we've
been using element internals is now in
Safari that was the lagging browser
because you in the shadow Dom and you
want to talk to a form field and there's
ways around it but it wasn't like a b in
thing and now there's element internals
that solves that problem theming is
coming soon which will probably mean
that we need to use less parts and we
might be able to do some different
strategies cross root Ras in the you
know in the pipeline but these things
aren't here yet you have if you're in
the trenches like us you have to solve
them now um but there's things coming on
web standards that are going to improve
all of these
things this actually stole from robt
Eisenberg who's been blogging quite a
bit from the fast UI team at Microsoft
he's really worth checking out if you
going to dive into web components he's
got a like a few recent blog posts
talking about lots of things again
you're not meant to read this slide this
is just to show you colored dots green
dots are the things that are here now
all the other colored dots on the
periphery are things that are coming and
being discussed they either in the
browser but not every browser or they're
on their way to being approved or
they're still early days so I think this
is really exciting because I'm like wow
we're in production right now using web
components and having a good time but
there's all this stuff coming to make it
even better and a little bit less janky
so my point here about Shadow Dom is
that it is awesome but it's got some
things that you're going to have to work
around at the moment and that's stuff's
not technically hard it's just
cumbersome for everyone to learn and
everyone be up to speed and figure out
how to work with it as a Dev that just
picks up your stuff it's not to too bad
but as the people building it there's a
fair bit of you know knowledge to pick
it
up so that's kind of Y web components
for us but let's move on to talk about
uh design tokens because that's been
another big part of our journey uh is
trying to get all of our design
decisions into code and have this
relationship with the designers like and
you can even hear in my voice they are a
different team they're another Silo for
us um we work with them every day uh but
we really kind of collaboration between
those two sides is a big part of the
deal so design tokens are a single
source of Truth blah blah blah to name
and store design decisions um but I
think the key things here series across
tools and coding languages so you don't
make them in CSS you make them most
people use Json and then you compile
them down to what you want them in uh
and we'll talk more about that in a
second this is an example of one this is
from the Spectrum Library Spectrum
Global color static blue 600 pointing to
this blue color and the first time you
see these you're like what a terrible
name like especially as a
developer uh is long cumbersome names
but you really don't have much to play
with you've kind of got a key value pair
here it's not a complex object on the
right that you're pointing to and it's
just a string and when you've got a
couple of thousand of them knowing what
to do with them on your second day in
the job or if you're just rushing
through someone as a designer or a
developer is really hard and they'll get
misused so you really need to have great
names because you haven't got a
hierarchy of this name is in a folder so
then I'm inheriting the parent name
you've got to describe everything in
this
string and it has to make sense to a
designer and a developer not not just
one side of the fence so they're a real
rabbit hole um it's amazing I think I
copied and pasted someone on the first
day and they did US fine and then we've
been nine months discussing trying to
get our version one out the door so it
there there I'll tell you why it's a
rabbit hole we'll kind of go into it so
it's emerging at the moment a lot of
bigger companies will be talking about
it there's quite a lot on youtubeers as
You' expect in this sort of space
talking about these things and most
people break them down into three sort
of levels I've got my Global design
tokens which would be things like a
color scale color blue 100 to 900
spacing token from 1 to 10 font size 1
to 10 and they're really simple um and
easy tokens and quite reliable they
don't change much they're just scales
but then you need to compose them and
give them meaning so then you would have
shared tokens or semantic tokens and
there's lots of names for these
different levels but most people tend to
kind of group them in these three so a
shared token would be let's say I chose
a blue 500 as my primary color from my
Global token but then I'm going to
actually give it an alias name of
primary color pointing to that blue
color and then I have a shared token
that is my primary color token but then
I have a component that wants a
background color it might make a button
background color pointing to the shared
token which is my primary token color
that points to my base token so you can
see how the naming becomes really
important hopefully I've I've a few of
you in the room right now going what did
he just say like tokens and colors and
Global and semantic and all that things
the and I think that's a really
important thing to stop and think about
these tokens you just don't have you've
got such a constraint to keep them
simple because everyone needs to
understand them in like less than five
minutes so designers developers everyone
on the team is going to be using them
and if they're any more complicated than
what I've just said that probably a few
of you glazed over not because it's
complicated just because I was saying
lots of words then that's about as much
room as you have for complexity because
you just can't make them very complex
because everyone's got to understand
them really quickly
and it really becomes like a balance
between precision versus coverage so
Precision would be that example of like
a button on a dark background and I'm
talking about the state on Hover so
you'd have a token for the primary color
of a button on a dark background when
you're hovering lots of precision and
then you can change and toggle that and
theme sites between dark and light and
different brands so if you got lots of
precision in your tokens we found that
really brittle but if you're really
mature you probably reach that point but
we're not so mature what we went for is
more of a coverage approach so we've got
lots of Bas level tokens describing
these scales so most of the CSS you
write on the page comes you grab one of
these tokens it's a space five it's a
primary color uh it's not necessarily a
component level token and that's been
really good for us because we're
starting from a crap point where we've
just got CSS everywhere um and having
tokens and their versioned and their
standard language has been really good
so we've not been very precise we're not
is themable with our with ours but we've
got a lot of benefit in having a real
Foundation across everyone starting to
share their
language so naming is hard with these so
here this button. primary. color on the
left is pretty easy yeah it's button
primary
color and then on the right it's
pointing and that would be a component
level level three and on the right
you're talking about a second level a
primary color a shared a shared token
but you can't see that from here until I
describe it and if it's your first day
on the job you're like I don't get any
of that from reading this so they start
to get more of a Bose so first thing
you'll do is well which brand or design
system is this pointing to well I'll put
my at the front I'll prefix it with my
DOT button and then you're like well
what level are they on I'll do my do
component on the left because it's the
component level and on the right I'll do
my. ref I've copied this from Material
design system which is quite a popular
one from Google and they use the word
ref versus shared but they still use
three levels like most of
us and then it's a bit clearer and then
you go well I want to use this really
Precision component now I want it to be
on a dark theme so you do my. component.
button. primary. color.on dark points
the my. ref. color. primary. on dark and
it's getting kind of wild and then
you're like you want the hover and then
it's getting even more wild again and
you can see how this can get out of CW
but I would much prefer to have this
once I've spent five minutes with
someone describing this to me because
now I've got this verbose token at the
bottom that I can't get confused because
we constantly when the components change
someone has to find and replace and fix
them and we always catching all these
spots where someone's put like a primary
button token on some other thing or
something else because they're not an
expert in this stuff so you really
constrained at not being able to make it
complicated so these long names even
though they're complicated they kind of
stop a bit of that this is the material
design component Fab button for their
second variant label text font
description all
right there is a w3c community group
that's doing a great effort to describe
this you can't go there and copy and
paste and you're finished and it's it's
all perfect it's like a discussion group
these are emerging things but it's a
great place to start to start to get an
idea how you should do your
tokens they really are the glue between
the two teams this problem of being able
to hand off a design spec from the
designers and the developer can pick it
up and understand what the other person
was thinking is really difficult where
we are we would get we use XD um which
is a pretty arcane tool who uses XD
here I think we with the last oh there's
a couple of hands okay um probably
everyone's using figma or something like
that um but it it wouldn't change really
much the Handover what we need to do is
we need to say we want this language to
to infer this thing that ends up needing
to be en code and design tokens have
really helped with
that we needed the designers to use
those tokens in XD or when you were
going to fail the last project had made
a whole set of tokens uh the last design
system and components and we couldn't
actually inherit them because they were
just made by the devs and they never
left the stone walls of the devs repo
and the designers didn't use it in any
of their markup so it was instantly
unusable for us so we didn't want to
make the same mistake so we started the
project and then we went to the designer
and said hey can you sprinkle your magic
on this we want you to get to the point
where you name these the way that you
want we'll help package inversion them
but we want you to own it so that it
ends up in the the design files and a
lot of devs didn't like that because the
names the designers make are not as like
we have quite analytical hardcore people
that think of things as a box and a box
and a box and a box and they're not
they're like you know more not I won't
dig myself a further hole than that but
so but it was so everyone was like you
can't like I the person from the
previous system's like you can't let the
designers do it they just can't do it
they're not as good as me I'm the
developer I'm going to nail it I'm like
no but if we don't we'll fail they have
to do it for us um and that's just
dragged out in this really long process
but it's brought both the teams together
and they just they did such a better job
than us even though I don't like some of
the names um it's yeah we had to kind of
go down that path so we use a tool
called style
dictionary everything lives in Jason
which is another a bit of a area for the
for the designers to be able to
contribute to this but basically we have
spreadsheets and they go we want to
change this to this or we want a new
suite of some named passive variants or
something like that and we'll go in and
document all of that in the Json forom
and publish the package and uh we put
that into an internal mpm repository so
for the web teams we we take this Json
and we pump it out for CSS and SAS so
we're we're not like going to pick a
battle here some of the teams like SAS
some like post
CSS some just want straight CSS and all
the different Dev teams can then pull
all those design
tokens not our components just our
design tokens livein this package and
some shared CSS we went and spoke with
the mobile team because we can also have
this opportunity to compile the same
tokens to Swift and Android and flutter
and so forth they were like eh we live
in this other Silo we don't talk to you
yet but that's all right I think in the
future as we get more mature they might
come back yeah but they have a great
life they just get to go Rogue they came
up with a whole Dark theme and nobody
knew about it and they went to
production it was awesome um and and of
course the business people love it
because they see all these downloads on
the iOS platform and they're like yes so
they're doing well so we take all these
components and we document them in story
book so when you do that compilation
step you can write some transformation
we transform a bit of syntax to use a
plugin from storybook and we can have
all of the design tokens represented in
storybook it's not too hard it's a
couple of hundred lines of JavaScript I
think um we'll probably end up writing
our own little widgets to show these but
at the moment we just do it in story
book so if we update the code we release
a new version people want to see what
that is it instantly updates trying to
find 2,000 tokens and manually keep your
documentation up to date will be
pretty error
prone
so who uses towi
really only a couple who's heard of twin
CSS before okay everybody who hates twin
CSS oh not too many people yeah it's
kind of kind of polar people love it and
hate it I'm a huge fan of twin CSS I
wouldn't use it at work I'll tell you
why in a sec but I like in my other
projects or in other spaces I really
love towi it's awesome you can move
really quickly you can go buy their
Tailwind kit I'm a huge Tailwind fan um
and and they have things like this you
just get a code snippet and you cut and
paste the code for this into your
project and then you've got this really
nice UI you move really quickly and you
don't need a CSS file because you just
put all your CSS in line on the HTML I'm
not showing this to say I hate I'm just
told you I love tow wind you can move so
fast doing this but this is not a design
system and this is not good in 50
different repositories at your
workplace for what we're trying to solve
where we've got the budget to have
consistency because you don't need to
read this you can see here all of the
kind of orangey stuff is the CSS
attributes so on the third line I read
it out of class equals block text- small
font D medium leading D6 text gr 900
totally fine for a midlevel to Advanced
front-end developer to be doing this
move really quickly get it done but the
problem with this is you have to be
quite Advanced or you have to be quite
good at this and there's so much
decision making here and you're going to
not move too quickly whereas it's not
that hard to have a set of custom
components that could be react for us
it's web components where you just go
well my- input my- input my- button in a
form component and here's all my
properties that are predefined and
documented you don't need to be a front
end expert you could be a full stack Dev
even a backend developer and probably go
I did a bit of htl in the past I could
bash this out so this sort of is our
whole Holy Grail or our direction that
we're heading and helps us design all of
our components to say you shouldn't need
to be a CSS expert you shouldn't even be
thinking about too much JavaScript yes
you've got a huge amount of JavaScript
to write to actually communicate with
the backend and manage state in your
application and process a form and all
that stuff but if you just need some
markup it should be like this shouldn't
be like
that if if you've got the time to invest
in
it so tokens and components are great
but they're not all you need you need a
few more things to be able to close this
Loop of being able to smash a bunch of
components onto the page like I just
showed you and be able to have just
simple bunch of components but this is
just the form what about the rest of the
page um and I said that we've got this
shared CSS you know what what is there
that you can't get out of a component a
design token that you're going to need
to be consistent and move quickly so one
of those things for us is probably three
main things that we've actually taken
out of our component kit and we put into
our a separate package that is nothing
nothing to do with our team that it's a
department team that's just CSS like our
tokens um and that's layouts and grids
because you can just use grid and flex
box they're fantastic but again you have
to know grid quite well it can get quite
messy and complicated and there's still
just lots of design decisions that you
have to make and mark up the page to be
able to get a header stuck to the top a
sticky footer that is fluid across the
whole page you'll see that nav bars on
the left and then you got this
constrained stuff in the middle and you
got this gap between these two sections
and then that's got padding and then
you've got another list of grids there
so we just have components for all this
all this gets wrapped up in a fluid kind
of component um for doing a layout
component and you jam in there your
Navar then You' have another layout
component which is your midsection
that's constrained and then you'd drop
in a card component and then you would
do some stuff in your card component and
then you'd have another subheading card
component and then you'd have a tile
list component most of it's just really
kind of declarative component markup on
the page it's like a couple hundred
lines to build this whole page versus
like thousands of lines if you're
talking about doing everything kind of
exposed all in the one spot like we saw
in the Tailwind example so we just
copied um Brad Frost we we copied lots
of stuff from Brad Frost he's really
worth checking out he exposes most of
his secret Source in how to do layouts
and grids and we just kind of modified
it for us and it worked quite well cuz
at this Point layouts and grids whatever
you do is a convention someone's going
to have to learn in your team you're not
going to be able to come up with
something better or perfect so we just
kind of copied what they did and went
down that road and it's been quite good
for us it's taken months to come back to
the designers and say to them we want to
do this can you come with us on the
journey can you go rename all this stuff
and poke holes in what we've missed in
describing this stuff um but now we're
there it's quite good other thing we
really found that was quite tricky was
text um and fonts and font size and font
spacing because you'd go into the design
tool Handover process and they' just
handwritten every single like piece for
describing say a header like this it's
this line height this font weight font
size and it was just handwritten into
the XD file and the mistakes were
everywhere and the difference between
all the headings and all the places was
everywhere and they didn't really you
know it's hard to get great tooling I
think figma does a much better job but
for us in code as well it was really
eror prone because you just ended up
with people who are like I don't know
what that is all I know is it's these
five variables on a desktop and these
other five things on a mobile so we
wrote a bunch of mixins with with post
CSS and SAS depends on what you want we
just package it up and give it to people
and we call them text presets again we
copied it from Brad Frost so you would
say this would be for example we have a
scale of text presets 1 to 10 it's the
text preset one you go into the design
tool and you see the heading there on
the page and it's a text Pres set one
and the dev goes Ah that's cool I just
apply my mix in my text to preset one
done we all use the same language and it
all goes across everywhere so this is a
newer thing for us we've got it running
in production it's working um took a lot
of time to talk about it's getting a bit
too unicorny for our current stuff but
it's working quite well and people are
really enjoying the process of not
having to kind of hand kind of configure
all this
stuff the last thing we put in this
shared base was media queries and again
this is tricky because you can't put
them in design tokens because media
queries don't run in the same way like a
CSS variable would so we needed to use
mixins again um so we exposed a set of
mixins for you know small and below and
small and above and again that's a
terrible convention to try and make no
one's going to be right on the
convention and naming that you come up
with you know you can look at bootstrap
you can look at whatever um but we went
down we we chose the ones that we wanted
we went through the process with the
design teams and everybody and and and
came to a subset and we shipped them all
people learn the convention and it
works so I'm going to move on to the
last Point here so that kind of design
tokens and codifying all these design
decisions have been a huge part of
getting our components to work um on the
first day we kind of had it all finished
then it's taken us like six to nine
months of discussions back and forth to
get everyone to kind of really come on
the journey so tools and
packaging what did we use to get this
done
um we kind of tried to keep it as simple
as possible but it's a bit different
than your normal setup for building a
web app um we use story book for pretty
much everything that we do it really is
kind of the king of the castle at the
moment there's not too much competition
for this um and a bunch of you have
probably already used story book we
don't have a web server you can't just
say I'm going to build a new component
it's going to be a password input field
and that component oh I'll spin up my
web server and look at it and debug it
we don't have that there is no web
server we only have storybook so if you
want to actually play build a component
for our team everything's done in story
book you write mpm start story book
spins up and there's a list of
components in story book and you choose
it and you go to the file and you make a
story because that's how story book
works you probably a lot of you have
already using it you probably wouldn't
use this if you're just banging out a
web app I've seen a bunch of our teams
also try and like they're just building
a web page and they want to use
storybook to describe their web page
um yeah I guess I I might um but on a
design system level or if you're
building shared components then it's
awesome worth the overhead so it looks
like this you got a list of Stories on
the left you choose a story and then you
can you know configure your story to
have a button that's you know
preconfigured to be in a certain State
you can also get lots of plugins again
we use the token plugin um and that's
been pretty good for us but there's lots
of other plugins for accessibility and
all sorts of stuff works all the
different Frameworks react angular and
so forth and web
components you're going to also probably
end up with a bunch of packages you're
going to end up with packages for your
icons eventually and your components and
then your design tokens and then your
shared CSS and then maybe you've got you
know like us we have this primary
sponsor they want their own named
packages for their brand um so we packag
that and we've used a lot of NX where we
are cuz we're a you know a big react and
angular shop but we just you know NX is
a mono for building a monor repo to have
all of those shared packages for us we
just didn't want that overhead and it
was seemed too early and brittle to be
able to do it with web components so we
went with npm workspaces Yan was kind of
dead and was reborn over the process but
npm workspaces worked brilliant for us
because they're just so simple for
simple packages that aren't sharing much
between them um and then we distribute
all of those packages from the one
repository out to our package manager
and
Nexus so npm works has been great for us
but when you give up on NX NX does a lot
of code gen for you so it'll pump you
can kind of configure it to pump out
some starter stuff so we used a little
Library called plop and plop just is an
ability to say I'm going to mark up some
handlebar markup and a bit of JavaScript
to say someone can go into the terminal
and say npm generate and then it prompts
them it says do you want to make a
component do you want to make a whole
package like custom things to generate
for your team so we used plop for that
and that was really good we've got like
five or six commands but it's what we do
all day and it's been really
useful I won't hark on too much about
SAS and post CSS we went down the road
of using post CSS internally for all of
the design stuff and all of the theming
we're doing mostly because our team does
a lot of platform work and we're very
web standards and focused on that and
post CSS very much is tracking down that
web standard sort of path whereas SAS is
just like we just solve the problem in
an awesome way um so even though we have
SAS mixins for a lot of things we
actually went down the road using post
CSS for all of our stuff and honestly
right for me depending on the team and
the framework I was using even if I
wasn't doing web components on a
platform team I probably wouldn't use
SAS again as much as I love it I'd
probably just reach for post CSS it's
been a really great
experience so
takeaways would I use web components
again well absolutely I think you've
heard me be pretty bullish I would I
would use web components especially if
you're building across multiple
Frameworks I would absolutely use web
components again would I build my
startup in web components nah n stay
away just get it done um but saying that
I had to build a um a date picker for
something that was written in um react
and we were like oh we want to move
quickly and we might not stay with the
react we might be hipsters and go use
Quick um so we used a a web component to
do the date picker someone had the most
of it already on some weird part of
GitHub I took it down and just changed
it to be kind of more hardcoded to what
we want and then we made a web component
for it and we can take it to whatever
framework we might move to in this
certain project so I might use it in
places outside of big teams and platform
work um but if you're moving quickly and
you don't know where you're heading just
yet then you're probably better off just
using the framework but nothing stopping
you from going all in with web
components they're
amazing would I use design tokens again
oh that's a trickier question
um only if I have a design system if I
didn't have a design system I wouldn't
use them and and this is just Duncan ISM
and being opinionated I'm totally wrong
probably in saying this um but I
think the the overhead of getting
everyone to understand how they work and
and what they do you really need to have
the problem to solve that you have
enough teams for that and time to kind
of bake it in because it's so early in
the journey if I was just doing a web
app got a customer on a contractor you
know there's five of us working on it
for six months I would probably just
have a set of CSS variables to name my
common things my primary my tertiary
like what we classically have done a lot
with SAS variables I'll just stick it in
a file and I'd probably do that maybe
version it and stick it in a package if
you've got multiple repositories um
because design tokens are a pretty big
step I think to take to have another
tool to package those design tokens and
a language and all that sort of stuff
but if you're at that point then they're
pretty
good last thing I'll say I always say at
every project I wish we' gotten into
production quicker I'd really challenge
you not to rewrite your design system
like we've done I would say just grab
the next web page coming off grab the
first component that you can do and
force the department and everyone to
come out of the woodwork and agree that
you're going to be allowed to do
it so in some we had to look at the team
you need to pull this off we had to look
at why web components are all awesome
design tokens a code um and we looked at
a bunch of tools and packaging we used I
know it's quite a bespoke little area
this um but just want to say thanks for
letting me share my story um I know that
we have a party this evening here
tonight it's a very geeky topic and I
know there's a bunch of people in here
doing a similar thing which is cool so
come grab me for a coffee or a beverage
um I'd love to hear what you're building
so thanks for letting me share my story