Back to Podcast List

8. Bolt Design System and Front-End Architects

Episode 8 - March 05, 2020

In this episode Chris talks with Salem about:

  • What a front-end architect is
  • Breakdown of web components, what they are and who uses them
  • What tools they're using at Pega systems and how their team works
  • And much more

Download episode transcript.

Guest

Salem Ghoweri

Lead Front-End Architect for PegaSystem's Bold Design System

Salem is the lead front-end architect for the digital team at Pegasystems and the creator of the open source Bolt Design System. He’s also worked on frontend architectural projects for Wayfair, Akamai, Panera, and Lysol, and is a core maintainer of the popular prototyping tool, Pattern Lab.

Show Notes

Check out Bolt Design System here: https://boltdesignsystem.com/

Episode Transcript

Chris Strahl:
Today on the Design Systems Podcast, we're talking with Salem Ghoweri. He's the lead front-end architect for the Bolt Design System. That is a design system built by Pega systems, the organization he works for. Hey Salem, welcome to the podcast.

Salem Ghoweri:
Hey Chris, thanks for having me.

Chris Strahl:
First of all, before we get started, talk to me a little bit about what a front-end architect is. So this is something that I'm a little bit familiar with but not all our listeners might be. So describe to me exactly what you do.

Salem Ghoweri:
Well, honestly some days I don't know what I do myself. So front-end architects are a relatively new role in the broader front-end part of the web industry. Front-end architects are basically internally focused developers that help other developers, help designers, content authors solve problems. So if you think of a normal front-end developer as someone who gets their hands dirty writing CSS, HTML and JavaScript, et cetera, for the actual say website or product, that's exactly what I do. But rather than working directly on a website or a product, I'm actually internally focused at Pega, helping my team come up with the code base architecture for our design system, Bolt, working on the build tools. It could be working on DevOps and continuous integration and continuous releases. It really has a lot of different aspects to it, but really comes down to I help other developers write awesome code.

Chris Strahl:
Yeah, that's really interesting. When I was at An Event Apart earlier this month, well I guess last month, one of the big jokes was two front-end developers walk into a bar and they have nothing to talk about. The idea being that there's now this sort of segmentation inside of front-end development where there's the back-end of the front-end and then the front-end of the front-end and these traditional differences in roles are starting to actually be present inside of the realm of front-end development. So you do both the front-end of the front-end and a lot of the back-end of the front-end to help enable other people to write better code. If I could put it in any more of a confusing way.

Salem Ghoweri:
Wherever the need is, wherever there's a problem, I got to roll up my sleeves and help the team figure it out and really ship the thing.

Chris Strahl:
So tell me a little bit about how you address the problem space that you run into in the Bolt Design System. We're talking today a lot about maintenance and fragmentation around design systems. What is it that you do that really drives at that problem?

Salem Ghoweri:
Well, I think you actually nailed the problem right on the head, Chris. Fragmentation and maintainability are really the two greatest concerns that I have every day, top of mind. Design systems are this game changing, tectonic shift for how we build and maintain these elegant systems that have consistency and uniformity. However, as I've found hands on, the maintainability story of having a design system, I think is, frankly one of the hardest things about having a design system. You can build it and people might use it, but if you don't have a way, if you don't have a strategy of keeping the whole system together, making sure that things don't start to get pulled apart from the seams. You have a mess on your hands, you don't have a system that you can actually sustain for the long term.

Chris Strahl:
So is that what you mean by fragmentation that coming apart of the seams? Describe to me a little bit with maybe some examples, of what fragmentation actually means.

Salem Ghoweri:
So I know there's some systems out there that have a relatively light touch as far as code and deliverables that the design system consumers are using. So I think Primer CSS, so GitHub's sort of first generation of their design system, I think is a prime example. No pun intended. So Primer actually shipped with just plain CSS like utility classes, here use this class for the button and then your button looks how a button is supposed to look. Nothing too crazy.

Chris Strahl:
Stuff that you cut and paste.

Salem Ghoweri:
Right. You're manually cutting and pasting or copying and pasting snippets of code from maybe the documentation side and that's how you consume the design systems source of truth. The problem really starts to become apparent when that system needs to continue to evolve and change and grow with the organization and with the team.

So copying and pasting, c-button, nothing too crazy until you need to change your button. Maybe you realize that, Oh maybe the original strategy we went with isn't scaling. Maybe we need to actually rename our classes. Maybe we need more flexibility based on feedback that our end users or our end consumers are requesting. Well, what do you do? Sure you want to change your class names. But if that's the very thin thread that's holding your systems consistency together, change your class name all the places that are currently using that CSS class, those all break.

Chris Strahl:
Yeah I mean it's even hard to even know where all those places are.

Salem Ghoweri:
You don't, that's the incredibly difficult part of sort of that old school, class name based way of having consistency in a design system.

So what's a better way then? If you can't tie together the thread, this thing out in my documentation equals this other thing inside of a digital product via class name, what are better ways that you can have a stronger tether?

Salem Ghoweri:
Well, in the front-end industry you'll hear a lot of folks talking quite a lot about React, Vue.js, maybe even Angular as these frameworks that will solve a lot of their problems. And they really do solve a lot of problems. They have a huge following and-

Chris Strahl:
Yeah, I've heard of React.

Salem Ghoweri:
Yeah. I think a number of people have heard about React and maybe in a different organization with a different set of consumers, React would be a prime candidate to actually ship the design system through React components. However, the team that I'm on, the folks that actually consume the components and layout and patterns that we're producing, they're not React developers. They're actually back-end developers, PHP developers, Drupal developers as one set of consumer. But we also have actual content authors, folks that are in the CMS creating landing pages, rolling up their sleeves and doing the front line of work. And they're not React developers either. That's essentially the problem that we ran into was React would be great if everyone knew JavaScript, our team isn't made up of JS engineers. What's the next best thing? And that's I think really where Web Components come into play as far as what gets me up in the morning, what I'm really passionate about.

Chris Strahl:
So it's interesting, right? Because I've heard the flame wars of the internet talking about Web Components and how useful they are and is this just React with extra steps? How cool the name Shadow DOM is relative to all the other stuff that we've come up with in JavaScript framework land help me settle this. Why do you feel that Web Components are really valuable to your organization? Beyond helping build that bridge among content authors and PHP developers? What is it that really draws you to them? Why do they excite you?

Salem Ghoweri:
I think it's actually really important to take a quick step back and sort of define what the heck is a Web Component since we hear about components every day. It's nothing new really. I think at a high level, Web Components are a set of browser specifications that Chrome, Safari, Firefox, all the big browser vendors have agreed on as a way to build reusable consistent components natively. Custom elements, custom HTML tags you have select or video as built in components that the browser ships with. It's no different than bolt-button or bolt-blockquote. Custom elements really are just an HTML tag that captures a lot of the behavior for your component.

Chris Strahl:
And that's really important, that native support, because having the fact that the people actually create the browsers are bought in to Web Components means that there's an advantage there over say a framework that exists outside of a browser.

Salem Ghoweri:
I think one of the big misunderstandings is Web Components have actually... At least they're getting the ball rolling for introducing support and actually shipping it in browsers. This thing has been going on for I think almost seven, seven plus years now. They're nothing new, but yeah, you're totally right. It's a way for browser vendors to let developers like myself create native components for the browser, that package up that component functionality and behavior in a way that's actually maintainable. It's packaging for components that the browser natively supports.

Chris Strahl:
So if you're talking to somebody that is a Web Component skeptic and is just saying, why aren't you just using React for this sort of thing? What's your answer to that question?

Salem Ghoweri:
Oh, that's the thing that really... I think I find that really interesting because we are using React kind of sort of. We're actually using Preact for a handful of our components. For anyone who's never heard of Preact it's basically a super lightweight version of React. It's much tinier, maybe 10 kilobytes or something crazy. From the outside though, you could pretty much drop in any React component that would work normally elsewhere and Preact has full API support. Want a React component? You can totally use it.

Chris Strahl:
So in that case Web Components for you guys are working both with your design system, which is predominantly built using PHP and also with Preact. So you get kind of a double dip here?

Salem Ghoweri:
More like a triple dip. So that's actually one of the great things about using Web Components as our sort of packaging and distribution strategy with the Bolt Design System. So we use Preact for a handful of our components. I think video, our icon component, those all use Preact. We also use element, which some of the really smart developers at Google have been working on for a couple of years now. It uses something called a template literals, sort of these back ticks where you really can just write pretty much any HTML within those back ticks. But you can also do dollar sign, curly brackets and use JavaScript variables, have functions, et cetera.

Salem Ghoweri:
It feels a lot like JSX in the React world. So a lot of our newest components are actually built using LitElement and LitHTML, both of which Google's created, then that's one of the things I actually loved so much about this approach. We can actually use whatever framework or whatever library we find solves the right problems for us internally and from an end user, from an end consumer, they don't even know what's powering that component. All they see is the carousel or the type ahead component. It's an internal implementation detail, what framework or what library powers that component from the outside as long as the API doesn't change, a component is a component.

Chris Strahl:
I can imagine that has a whole lot of benefits when you apply to cross digital products because it's very rare for an organization to be completely standardized on one technology. There's a lot of lofty goals out there about, Hey, we're going to be all React or Hey, we're going to be all Vue or something like that. So if you have to support multiple different languages and multiple different frameworks and libraries, this seems like a great sort of glue that ties it all together.

Salem Ghoweri:
I think glue is actually a fantastic way to describe this overall strategy that we've been running with for a few different years now actually. Different teams have different legacy code bases. Libraries come and go and really for us, we know we're a small team. We don't always have the luxury of writing every single component from scratch. There's not enough of us, not enough time. So having the flexibility to go to npm and find the best library, the best dropdown, the best carousel library, that's really powerful as a tool for us. It's a lot of flexibility. We need to ship something, great. We can use a React component if it makes sense, if it solves the right problems for us. We can use a LitHTML component. Heck you can even use Vue.js Or Angular actually in Web Components as well.

Salem Ghoweri:
In fact, there is a great site. Custom elements everywhere that shows all these different frameworks and libraries that fully support Web Components. All the big ones Vue, Angular, Svelte, Preact, they all have like 100%, 10 out of 10, full support for Web Components. It's actually React, the not Preact version of it, that is still a little bit behind. Honestly even the React support is pretty darn good. There's folks like the Ionic team-

Chris Strahl:
Mm-hmm (affirmative).

Salem Ghoweri:
...they have Ionic framework which previously was Angular and then more recently they made the full switch to Web Components. They actually provide all of their components, button, list, card, et cetera as pure vanilla Web Components for cross framework compatibility in addition to providing a wrapper. So if you're using React, you can just pull in the button and you don't even know or really even care that it's actually powered by a Web Component. It really just works.

Chris Strahl:
And that gets kind of to this idea of, like you were saying, that the underlying API can't really change so there's an importance to this theme of maintainability and fragmentation where that data contract or that API contract that you've created between whatever your consuming product is and the underlying web component, that has to be something that's really solid and so is that a lot of the focus that you take inside of the organization? Is trying to make sure that's a really well established thing. How is it that you go about making sure that all this underlying stuff stays consistent?

Salem Ghoweri: That's really the hardest part about what I do. The Bolt Design System's about three years old now, we started of with one of our enterprise sites being our only consumer. Then we had two, now we have closer to I think six, maybe seven with a few more in the pipeline. You need a way to actually allow developers to choose which pieces they use, while still having some path forward to maintain that consistency, that predictability so that people actually feel comfortable relying on the design system.

Chris Strahl:
This is what Brad gets to in a lot of his talks about design systems scaling. What's your target for use of your design system, right? Do you want 80% of your digital product powered by it? 100% is really unlikely-

Salem Ghoweri:
Right.

Chris Strahl:
... You should probably at least go for 50%, what do you guys typically target with something like that?

Salem Ghoweri:
I try to really shoot for 80% as far as components go. A design system really is more than just components. It's design tokens. Those could be just sort of written out guidelines but it in practice, again with the whole consistency and maintainability aspect, you can't enforce just having some hex values on a website somewhere that you expect someone to copy and paste. It doesn't really work that way. So even our design tokens, we have SaaS functions, SaaS mixins that really just point to that source of truth. So rather than copying a hex value, you might say, bolt color Indigo and then... Or Indigo dark, Indigo light, whatever the Indigo hex value ends up being, you'll always use that always up to date, source of truth.

So components are sort of in the middle of deliverables. Design tokens are at one end, and then you really have low level tools for solving all those edge cases. Things like utility classes. Let's just say you need to add a little bit of white space or a little bit of margin bottom to a card or something. You could hard-code that, but then you're spacing scale on your whole site's going to start getting out of whack. Or you could reach for a utility class that packages up all of those design tokens, all of those spacing values and puts it in the form of a drop in CSS class.

Chris Strahl:
Right. So space small is something that you could attach to the bottom of a card and that would bump you 12 pixels or something like that.

Salem Ghoweri:
Yeah, exactly. And then if you have space small is 12 pixels space extra small might be six pixels or space medium might be 24 pixels. Components, designed tokens, utility classes and then tooling. It's actually something that I haven't heard a lot of folks in the design systems community talking a lot about, but our team isn't primarily comprised of front-end developers. It's more full stack or more back-end developers. Components, all this front-end code, it gets complicated very quickly so-

Chris Strahl:
Great and I can imagine that scaling to even a handful of digital products, with a small team, I mean you said you were like four or five people.

Salem Ghoweri:
Yeah.

Chris Strahl:
How do you use these tools to sort of have augment your impact? How is this a force multiplier for you?

Salem Ghoweri:
It's funny, our team, the design system team hasn't really changed in size, but the rest of the team has ballooned in size as more and more web properties are spun up. I think for us it comes down to really thinking through your encapsulation and your packaging strategy right out of the gate.

Chris Strahl:
As always, this podcast is brought to you by Basalt. A full service digital agency. Basalt is committed to building a better web and specializes in creating design systems. Learn more at basalt.io.

Salem Ghoweri:
You brought up Brad Frost earlier-

Chris Strahl:
He's a frequent mention on this podcast.

Salem Ghoweri:
... Brad and I work with... We've worked together actually for a few years now on Pattern Lab, one of the things that I do on the side. Pattern Lab for anyone who doesn't know is basically an open-source prototyping workshop tool for front-end devs, designers-

Chris Strahl:
And much of boltdesignsystem.com is actually looking at Pattern Lab. Right?

Salem Ghoweri:
It kind of gets blurry being a maintainer of Pattern lab where the Bolt Design System needs have helped inform what we end up shipping in Pattern Lab and Pattern Lab capabilities ended up sort of pivoting Bolt to make sure that we could take full advantage of these tools. Back to Brad Frost though, he actually mentions this thing in a number of his talks called the Holy grail of components or the Holy grail of templating, which really is this magical place where you have one single source of truth template and the front-end developers with their prototypes they're referencing and using that single template, the back-end developers, the rest of the folks on your team consuming the design system. They're also using that exact same template.

They're not actually copying over that code. They're literally pointing to the button, a twig template or the card twig template, which is the same code that's being maintained and shipped out of the design system. This holy grail of templating, this has been something that we've been fully running with for about three years now and that's been one of the core ways we've been able to keep the whole system together, keep at least a certain degree of uniformity and consistency because most of our components, almost all of them have back-end friendly twig templates. That packages up the API, you can pass in your couple of different props to them, point to button, button.twig, text is hello world, size is small and then you get a small button that says hello world.

Salem Ghoweri:
Nothing too crazy. That helps with a lot of the problems that back-end developers are trying to solve for. However, what else is out there? So even with a CMS you might actually have one of landing pages that the back-end developers can't create a nice pretty admin interface for-

Chris Strahl:
A point in time event. Hey, I'm having a conference or a meetup or something like that, right?

Salem Ghoweri:
There's a surprisingly large number of those. We need to solve this problem and the safety of having a CMS doesn't quite get you all the way there. And then there's things like personalization too where you might dynamically inject components onto a page based on your demographics or your industry. How do you solve for those? I'm partially being affectatious, but really that's something that we have to solve for. If you have your button component and the twig template that normally would get safely used just doesn't cut it, how do you get a button out in the wild that you can at least to some degree maintain and support?

Chris Strahl:
Right. And know that it's honestly got that safety of your brand, right? One of the big reasons why you look at design systems as this critical thing is people see the safety in that enforced consistency. And so if you're going outside of the design system, how do you make sure that when you do go outside, you actually have that similar sense of safety around.

Salem Ghoweri:
You have guardrails really that, you're out in the wild area but you still have a way to sort of keep certain things in sync and up to date with the rest of the system. And that's really where our Web Component strategy comes into play. Most of our twig templates that we have, are actually shipping the Web Component custom element markup right inside of that twig template. So when you call, the button.twig component, you're actually getting the button Web Component on the inside and you might not even realize it. The beauty of this is you get the benefits of server-side rendered, really performant progressively enhanced templates, that as soon as it hits the browser and the JavaScript runs becomes fully client side rendered. If you're doing more dynamic, more rich interactive storytelling, that client side rendering is almost a must have nowadays. Shipping twig templates that are Web Component powered means the templates that the back-end uses are kept in sync and up to date, but the Web Component internals, that's the glue that keeps the not easily solved component problems in sync with the rest of the system.

Chris Strahl:
So I mean is that looking at kind of a new way of thinking about progressive web apps?

Salem Ghoweri:
Honestly I think it is. We talked about before, Web Components can be powered by Vue, Angular, Preact, et cetera. The custom element markup really is just the packaging. Whatever's powering it on the inside doesn't really matter. You just write the right HTML tag that you want and you can animate stuff on the page, you can do anything and everything you can do with a modern rich web application. It's really just a tiny implementation detail.

Chris Strahl:
Thinking about that from the tooling perspective that provides a lot of power to a broad array of audiences. Right? So you're basically saying, Hey, no matter what, I build this experience in, the experience being a component or whatever, I have a set of tooling that is there to support me and create this nice, like you said, set of guardrails and this glue that still tethers me to the centralized design system.

Salem Ghoweri:
Right.

Chris Strahl:
And so that provides a great ability to scale because now it's less about individual technology choices and individual ways of thinking about implementation details and a lot more about, Hey, let's use what we have and then where that stops being useful, we can use whatever we want.

Salem Ghoweri:
Right. It's about solving really the problem and everything else sort of comes after that.

Chris Strahl:
Yeah. That's incredible. So those technology tools, that has to be paired with some sort of human process around this. Right? We just spent the better part of 20 minutes talking about what this is. How do you go about communicating that to your stakeholders? What human things do you guys do as a design systems team to let people even know that this kind of capability exists. How do you get it out there? How do you get people using it? How do you get people to adopt this sort of stuff?

Salem Ghoweri:
One thing we learned the hard way early on was, the design system that we have can only really be as large as what we can support ourselves. So, if we build a ton of components that are maybe half documented or don't really have the API fully fleshed out that comes back to bite you really quickly. Where do I find the documentation on the button? What can I pass in? What are the constraints? What are the guardrails that are put into those components? I think one part of the human side of tackling this thorny problem is understanding who are the end users here. We're not just talking about front-end developers, which we use the design system too, to solve our own problems. But most of our users are other technical from a back-end point of view or content authors. So can you avoid jargon with your different parameters that you could pass along? Can you keep things short, concise, memorable? Can you really give people confidence that your documentation is always up to date and actually still relevant?

Chris Strahl:
Right because I mean, what's worse than no documentation, is wrong documentation.

Salem Ghoweri:
Yeah.

Chris Strahl:
Well, and then I also think one of the things I did want to mention that I think is really incredible specifically about Bolt is, I mean you guys built out boltdesignsystem.com which is something that is maintained entirely independently from Pega. And I think that the ability to kind of just like.... None of that exists behind a login, right? Any single person listening to this podcast can go to that URL right now and see what you work on every single day. And I think that's an incredible tool to sort of break down those barriers between teams that exist in a lot of organizations, right? When you have a hard enough time just finding what system to log into or what confluence page to go to. Yeah, I think that's really remarkable.

Salem Ghoweri:
Those barriers to getting that nugget of information you're looking for, that adds up. It's friction. The Bolt Design System's entirely open-source. We've been open-source since day one and we were really powering our public facing for the most part and few internally facing enterprise sites for Pega that's separate from the product. The product actually has their own system that has their own set of different problems and different focuses. That's really what's allowed us to keep the doors wide open. Let anyone chip in to help out a little bit, see how our components work. Especially for something like Web Components, the more resources, the more examples people can check out. It really helps the entire community, I think.

Chris Strahl:
So you have these systems that are utilizing design systems in kind of interesting and unique ways to build more modern progressive applications, to support a wide variety of technology needs across a broad swath of users. What are the big wins that you have personally seen inside of Pega that have really led you guys to continue to invest in this approach? I mean this is no small undertaking. What makes this super valuable and why do you guys keep doing it?

Salem Ghoweri:
That was one of the big reasons why I came on board. We weren't always doing things this way. We were doing things every website its own special snowflake. We're all solving completely never before seen problems. Oh this site has a navigation and has a footer and has calls to action. We did things that way for a while and it didn't scale. There wasn't consistency. Every web property required its own separate dedicated team and that gets expensive. It's expensive from a team point of view. It's expensive from a time point of view and having to solve the same problem over and over. I think it was maybe about two years ago now that the first really huge win, we really started seeing the payoff of having a design system come into play and that was when we had the second website, community.pega.com actually launch using Bolt and we didn't have to write literally a single line of code in order to support that brand new site's build out.

Chris Strahl:
That's remarkable.

Salem Ghoweri:
It's almost unheard of that we had enough building blocks enough the pieces in there that totally different use case, totally different audience can solve a lot of the same problems and not require new deliverables from the design system.

Chris Strahl:
Yeah, I mean in contrast pre Bolt, what you would have thought about for that is a whole separate set of designs, a whole separate set of development, a whole maybe even separate development team that would literally be building those exact same things that you'd already built for pega.com for community.pega.com.

Salem Ghoweri:
Right. Not only would it be reinventing the wheel over and over again, but once the site goes live, it's going to sit on the shelf and it's going to just slowly decay over time. In a previous life when I worked on the agency side of things, I saw that time and time again, Lysol, Akamai, Panera, you know these sites where these huge development pushes, you get the thing live and then pretty much it just slowly rots away.

Chris Strahl:
I've always thought organizations, very large organizations invest a tremendous amount of money and time into building these big digital properties, right? These big digital products and they're almost radioactive, right? They slowly decay over time into something that is less than what it launched with. And so I think that that's, that's actually a benefit we don't nearly talk enough about in the design systems community, is how you fight back against that radioactivity of your individual digital products. And I think that this is a really interesting thing about using a system like Bolt, is that you get this constant state of refresh and renewal that just comes along with the continued development of this sort of centralized system for all these experiences. I mean, have you noticed that? Have you guys experienced that inside of Pega?

Salem Ghoweri:
I mean, being able to roll out whole sites that from day one are up to date with the latest and greatest stuff. It kind of gives you butterflies. For the most part, if you're using the design system, you'll stay up to date. But we still let developers ultimately have the final say of when they're upgrading. It's not like the latest version is shoved down someone's throat. They're still opting in stuff to run npm update. So whenever the timing makes sense, they can pull on the latest and greatest and their Web Components, their twig templates, those will be upgraded to the latest version with very little headache. They still hold the keys. They still have that control. But that's been one of the huge reasons why we were able to see websites evolve over a few years without a lot of work required downstream to actually see those changes through.

Chris Strahl:
Got you. So basically the difference for an upgrade is instead of having to think about let me re-engineer my site and make a major upgrade that only exists for this property. It's all of this other work has existed outside of my individual site. And now I can take advantage of that by basically saying, okay, my baseline package for the design system has a new version. I can upgrade that and take advantage of all those changes that have existed kind of in this ecosystem.

Salem Ghoweri:
Right. And the sort of sandbox that the component or the component updates are crafted in, they're tested very heavily, they're documented, they're demoed, all that stuff that happens in a bubble. Once everything's ready to go, we publish to npm and then downstream they just npm update that package. And as long as the API doesn't change, which we're on the hook for, knock on wood, it just works.

Chris Strahl:
So it sounds like this is actually really core and fundamental to the way you guys think about building digital products now.

Salem Ghoweri:
Everything. Every single thing that we're shipping, design tokens, documentation, automated testing coverage, releases. Really this idea of the systems thinking mindset affects practically every decision that we make. Because frankly we're too small of a team to just do things the hard manual way. We need to let the robots do a lot of the hard work for us.

Chris Strahl:
So what do you do with all your extra time?

Salem Ghoweri:
Worry about major version bumps.

Chris Strahl:
But in all seriousness though, have you found that it's let you explore different avenues of design or development that you wouldn't have necessarily been able to take on in the prior cycles where you were just so focused on building these individual properties?

Salem Ghoweri:
Oh absolutely. The things that you would never have enough time to do in a million years. Things like documentation, testing coverage, accessibility, performance, those things used to be a pipe dream. And now that all the core problems are solved and really are built on, with every subsequent release we're able to really focus on the other problems, the other hard problems that we would never have been able to get to otherwise. Animations are another great example. They're hard to do, but when you spend the time and you nail it, it's totally worth the payoff.

Chris Strahl:
So Bolt is obviously an awesome example of this in practice. Are there other favorites that you have that you can point people to that kind of show them the power of this approach?

Salem Ghoweri:
The Duet Design System, I think it's D-U-E-T-D-S.com. There are one of our huge role models. They're really new too. We predate them by a year or two. Beautifully designed, its all web component powered. I know, I think the Clarity Design System from VMware, I know they've been shifting to Web Components. I know Red Hat, good buddies at Red Hat, you know their design system's also powered by Web Components. I know Salesforce, our largest competitor, they recently made the announcement that lightning Web Components would basically be the new platform for all Salesforce applications. It's really comforting to see that the rest of the industry is embracing and taking full advantage of the power behind Web Components. Really to solve their everyday needs, their maintainability problems. It's nice to see that we're in good company in the enterprise world of things.

Chris Strahl:
Well, hey Salem, thanks so much for taking the time to be on today. I love the work you guys are doing. It's awesome to be working with you and keep working with you on Bolt. And I can't wait to see where this leads.

Salem Ghoweri:
Been one hell of a journey, but couldn't imagine doing anything else. Thanks for having me, Chris.

Chris Strahl:
That's all for today. We'd love to hear from you with questions, ideas for new episodes, beer recommendations or comments. You can find us on Twitter, @TheDSPod. Cheers. And thanks for listening to the Design Systems Podcasts.