 Really excited to be here with you today really excited to talk about some of the new and amazing front-end work we're doing at phase two and Without further ado. I would like to get into decoupled design systems with web components My name is Jake. Jake's drawing. I have been in the Drupal community 15 or so years and Fun fact it's actually been about a decade since I've been to a Drupal con it's been that long since I have Been here been excited to talk about something hot and new so Glad to be here with you today Quick show of hands everybody in group. Who's a Drupal developer back-end developer? Front-end Drupal developer UX design Leadership Decision makers. All right. Thank you very much Nice balance So today today we're gonna talk about four main points we're gonna start with modern design systems and What that means from the design systems we were building about five years ago Next up we're gonna talk about web components the technology itself the stability of it and where we sit with it today you talk about elevating and Motivating your front-end teams to new heights and then finally We will talk about our newest open source product outline so first modern design systems and this quote really resonates with me and Kind of defines what the whole point of this presentation should be Design systems bring order and consistency to digital products. They help protect the brand Elevate the user experience and increase speed and efficiency of how we design and build products And that's something that we want. I think in every single Every single product site platform we build we should have that goal So diving into modern design systems a real design system provides brand recognition The digital source of truth Real design system will outlive your project framework and help accelerate implementation on the developer side So first into brand protection and one last quote here Our clients most important asset are their brands and a well implemented and designed Design system will help ensure that that brand is protected and adhered to for years to come So brand protection Not everybody's Google not everybody can change their logo weekly and still be known as Google We rely on brand recognition which builds brand trust and as we build design systems that are adopted in an organization it starts to influence more than just the project they were built for Five years ago ten years ago. We were building a system a component system But it was based just for that project. We were building it with and we would see very little if any reuse in the future so having having it as a As a resource for an entire organization helps put into code those guidelines That our clients paid a lot of money to get really great branding and outlaying t-shirts And if you simply want to keep your partner your client anything like that happy like that like them happy Protect the brand don't lose them the digital source of truth and Collaboration can't forget that part So what is the source of truth for a design system? And I think this has been one of those sticky definitions depends on who you ask if you ask a designer if you ask a developer Now we have the figma designs or figma design system And so design wants to you know take ownership of it being a design system We also have our design system code base That is actually what we take from figma and what we turn into Components that can be consumed by the application whatever that application may be So with that with that said there's continued to be a Problem where we still have to communicate back and forth So much with our design teams to keep these things in sync and make sure that changes in figma Relay their way all the way up to the code base Ready to be used one thing we're going to be We're working on implementing now We've started testing is a plug-in for figma called figma tokens and basically all of your all your design tokens your colors your typography Everything is exportable You put in everything in there, and then it just gives you some valid JSON That can be dumped out consumed by the design system consumed by any other platform so now we have a point where the two of these assets the figma designs and the actual code implementation of that design can be a combined source of truth and We do have a couple different topics on on design and how we're designing for Drupal So be sure to check those sessions out However, it's not just the designers in your organization that you need to make happy or need to work with in order to promote adoption make something like this a System that's adopted you need full buy-in Everybody in the company every department doing their part to promote support all the things Content strategy, I mean they're gonna want to be involved because we just want to get better Looking prototypes out of the air and our in our storybook instances and the components we build as we demo them Marketing and sales are always gonna be on your side because what what a design system provides has very clear has very clear of It solves many common challenges So it makes it really easy just to promote them they basically are selling themselves Qa Qa and uat we've definitely shifted the way we're able to test what we're doing now by Building a design system where the front end portion comes first building a component. We're iterating through it We're making it beautiful matches up with figma We're able to present that and let the client see that early and make a decision of a is it correct? Is it the way we wanted to go is this an AB test and we decided to throw it away? Long before we get to a back-end side and have to worry about actually implementing it in Drupal or another system And we've also had clients start to be more and more receptive to using the design system Where a lot of times in the past it would just be a throwaway asset. We might have looked at them for a while We recently had a client who the the VP stakeholder was taking our Storybook and all the components we were building back to her superiors like 20 stakeholders like a huge large group of stakeholders and Walking them through how these components worked and all this long before we showed it to them in Drupal So it was really exciting to see that start to play out not just in the way We use it in our own processes, but how our clients will start to use it in theirs You definitely have to have your back-end devs on your side because basically you're gonna Hold a rug out from under them and upset them a little bit because things are gonna change, but it's changed for the good It's easy everybody's on board and leadership finally enjoys when the efficiency and lower costs start to happen and with a homegrown design system There's going to be some time. There was a list of part article the design system efficiency curve And when you start off you take a dip as you start building all of those baseline components until you reach a point where Now everything's coming. Everything's coming faster You're reusing the accordion the button and you stop building these things over and over again Out living project frameworks why would a why would you need to shift framework and To make sure I'm defining a framework here ask Drupal and it's anything like Drupal So, I mean, you know Somebody calls you at 5 p.m. And you've broken copyright or some kind of law by using WordPress Who knows I'm making something up here, but For legal reasons you legitimately have to shift this next week High cost of some proprietary systems diverging requirements And even something abandoned by maintainers none of us have ever seen a Drupal theme or module that was you know abandoned So historically this type of Shift or this happening in an organization could have been very costly and You know been a full stop required everybody's attention With a decoupled design system This is where we sit now and Transitioning to a new framework should be invisible to the end user They should not even know it happened if you switched from WordPress to Jumla or Drupal It's just using the design systems following the same guidelines Nobody actually is caring about what's going on behind the scenes accelerating implementation front-end first standardized components and the tooling that we're now using allows our front-end team To coordinate with UX as soon as we get started And I have some other slides here in a bit to talk about kind of the timelines of when when the front-end teams have been involved in the past and where we're at now, but We Basically our front-end teams can take Outline take our tooling and start as soon as we have the first iteration in Sigma any color tokens We can start just plugging that in and putting a brand to what we know And that said we are able now to have our front-enders do a lot more up front and in the design system some of those architectural Concerns that you're still thinking about during planning and your back-end team is working on the front-end team doesn't really care about I don't really care where that image for the card comes from But I know I have an image a title a body and a call to action button. That's all it is every day every time So for the developer getting to use a system like this The first and foremost thing is standardization of cross projects. We're currently at 16 17 that have spun up on a new framework and Our developers now have the ability to just go drop into another project and see exactly the same code It's the same you can get help from other teams where before you might have seen, you know, just little diverging Techniques and all this stuff on every single project So that makes your developers more effective and efficient Time to delivery is going to come down simply because we've got reusable components. We're already ready to go We just need to paint them up make them match the brand and move on And as I mentioned, yeah easy to assist other teams with bugs and architectural decisions So we've got yeah, all these working on the same thing. Just reach out Every developer should know how to help you not just one or two. They're limited to your project team and For I mean the exciting part for me and for a lot of our front-end devs is the ability to Get to work in modern front-end technology I'm gonna say it. I'm I'm just gonna read it Front-end developers should not need to know PHP Flat out. I said it Let's talk And I know PHP but If you want the if you want the most talented front-end developers you could bring in you've got to let them focus on What is front-end because it is moving Faster than I can keep up all year to that and it has been for years and Bottom line ended the day what we put on the screen is HTML CSS and JavaScript. That's it. The rest of the stuff Doesn't matter. It does matter makes our lives easier does a lot of great things But it still just gives us that HTML at the end So how do we decouple our design system? We do that with web components So I'm gonna draw your attention to the black box first and This is for for the decision makers and in the room This is not something that's new and trendy a couple years ago like it was you know, maybe a little more sketchy to start using web components We still had a lot of IE 11 support made it hard. You're having to use poly fills that don't work the greatest But we've moved we've moved past that and a recent statistic in the Chrome feature usage Showed that January of 2020 There were four percent of websites showed using at least a web component on the page the function That is what would load it up and as of April of this year. It's up to 18% in just two years So for the decision makers that are trying to you know Understand why you want to bring this in the reusability of components again? You're not rebuilding an accordion You're not rebuilding a button you have all these things at your disposal ready to use ready to modify So that brings us to the extensibility of the components and if that accordion that we have it's great It's a normal accordion. It opens and does you know according to any things But on your next project you've got two new requirements for it We can now take an extend just through a class we can take an extend that component We can add new features to it and make one very specific in that specific use case that You know went a little above and beyond had a button with rainbows on it or something. I don't know developer productivity The standardization of all of the code base just keeps Developers looking at the same thing again You're not jumping into another project and trying to figure out years of technical debt. They all look the same and then repeatable testing and accessibility When we build these components when we build it into the system We were writing as many tests as we can both functional accessibility all this stuff and once it's there It's there and that same tests runs that same test will run in any system that you bring up And then again back to just a cool front-end tech if you're using a system like that You are going to attract developers that want to use those kind of town those kind of tools and platforms And it's gonna keep your developers happy if they're not writing your front-end developers happy if they're not writing PHP Okay for the developers Kind of rehashing the same thing here, but Exciting professional growth opportunities come when you get to focus back on the front-end the JavaScript all the good stuff Sawed after experience and skills bump up your resume get recruited by industry leaders And again, yeah focus on the front-end skills work with work with the the tools we know and love and Yeah able to make again the architectural decisions early on and this is where now Even if we come to a project and it is Drupal and we have a very you know a very set timeline You know, we've got a scope. We've got all the things We still now build our design systems in a way where we're thinking beyond just that Drupal site It's not just that there's going to be more So again web components are just HTML CSS and JavaScript in this example You know to pay much attention, but there's an outline widget that extends an outline element It includes some static CSS and if you actually copy this CSS, I found it on stack overflow. It recreates the blink and Then the simple bit here the actual meat is the render function the render method in there And in this case, it's just printing a hard-coded paragraph inside of a dip Now what a web component is going to look like when you're integrating it into your system? On these next couple slides. I want just focus on the bottom slide first kind of the vanilla HTML And this is one of our components outline link. You think well, what what kind of link component do not much really? Surprisingly a lot and this afternoon 2 p.m Be doing a demo of this particular component showing in depth a little more some of its flexibility but When we go to those architectural decisions about what we're trying to build We need a link to do more than just you know, take a URL take a text and a label Well, wait a minute Drupal has all these great things going on It knows how to build a link It knows how to throw a picture a responsive picture tag in the middle of that so in this scenario we're using slotted content and For web components basically just the cheese that's going inside of the of the tag itself. That's the It's the meat in the middle So in this is in this example We're gonna rely on the consumer application Drupal to give us the whole link the whole Link that they want to produce whatever field you put in So that's when you can look to the top example and twig and see more Drupal isms of pulling in the URL the target and dropping an image in there dropping an image just The way Drupal wants to do it Now this same component Can also be used now with an attribute for the href and if you pass that in The content that goes inside right now just text says phase 2 it could also be a picture tag It could also be all sorts of things whatever content you're trying to link sent from the consumer Or you can even go All the way to the other side and you can provide all of your Configurations for this particular component through attributes which turn into properties on the web component itself So this shows just one example of a component and how it had to think of Multiple scenarios in which it could be used So that it was flexible enough to just drop in So who trusts in web components All these guys and phase 2 and this is a slide where I was supposed to talk about that for 18% That's that one up anyway Yeah, you go to these websites now and yeah, we're we're at a huge number that are adopting them and Investing heavily. I mean a lot of these that you see up here have their own large design systems that they're promoting So are you ready for web components? For your front-end to be more productive For your front-enders to gain new talent and for your front-enders to be leaders in your organization Elevating front-end talked about design systems talked about web components We talked about the tools that we can use to get there. So now do we how do we elevate your front-end department? Let me back up for a second Let's talk about phase 2. We've been here 20 years as a Drupal shop a huge majority of our business is still Drupal and This shows how committed we are to Drupal and how we have been over the years modules Drupal sites Triple certified experts devs all over the place. We love Drupal But at the same time really do need an open relationship with Drupal and it's not me saying that as a developer That's what our clients are saying That's what they're coming in the door talking about they may still have a flagship Drupal site But they have other things they've heard about they have other things they want to use So how do we do both? These timelines are not approved by anyone. I completely made these up This is not part. Yeah, this is made up. However If we go back again to the really old days us triple-themers we had to wait until the back end finished all the markup all the views were done and Just go write some CSS and Maybe we'd get to go edit a view change something if the markup was really terrible But it was rushed it was at the end. It was a terrible experience of the client never getting to see like they're almost finished product product until the very end so they're sweating the developers are sweating It's just not a fun experience So then around 24 late 2014 early 2015 at phase 2 we went to the particle era Where we had twig based design systems And particle was the first version we open sourced we had some iterations internally before that that used to this same method and A twig based design system was great. We were building our components. We're showing them in pattern lab It was everybody was happy. It was beautiful And it allowed us to start working at the same time as the back end did it started some of these principles of front-end being able To get in earlier have a bigger voice on the project Let's talk about where we're at today What I'm gonna back up if you notice from this first slide in my imaginary timeline This took 10 sprints And then we moved down to about eight Yeah, don't hold me to that. I'm the developer So where we're at today We still have eight sprints. However If you look at where now the design system sits with web components And I pushed it a little further forward than I really really did but or needed to but this is where we're moving We are able to come in now again. Like I mentioned with UX and design we get in early We get early access to the designs to the creatives start making Collaboration and suggestions and improvements from both sides early on While sometimes our Drupal team is still sorting out the architecture. What API's are we gonna be calling? How many you know how many crazy back-end things need to get built in order to make this entire site happen? So this is where our traditional client is and then they've still got again. They're huge flagship Drupal site But we all know and love and built and maintain But then here's that here's that customer who's finally come in and asked for something else and They want a microsite that's react or Gatsby or any of the any of the great frameworks tools You've heard about over the past few years. Well, if you had a twig based system, you're out of luck You're just out of luck start over do it again However with web components, it's just JavaScript Just HTML and it's just CSS that you can pull right into your system right into this new react site Drop in the same header and footer that you have on the primary flagship site there you go and On this next one. I gave us I gave us a year, but we're gonna be at the point where we are having clients and customers come to us just for this portion of the work and We will be but we will be doing the planning the design and Large-scale design systems where we might not win that Drupal contract somebody else may have Have bit it but we will have built a design system and a documented design system that we can hand off to any team under any framework This is a hashtag. I really think everybody should use Let's throw on that out there All right, so let's talk about outline Outline is our latest in open source Component-based development and design systems. We've been really been working on outline now for a year It's been over a year I want to talk first about the core tech stack that we have we really went into web components So I won't do much on that portion TypeScript It took years, but again as we were able to focus on Modern front-end technologies. We were able to integrate TypeScript into every single bit of JavaScript we write now which which just Sorry back it up TypeScript is just going to give you the strong typing and the competence you need with IDE integration all this stuff. It helps you write better code without having to write as many tests I mean when your editor yells at you that you can't put a number there. It's not possible. It's supposed to be a string Times are good. It makes it really easy to debug as you're as you're typing out your code Lit 2 is one of the two major stencil being the other web component helper frameworks lit 2 is backed by Google and solves a lot of the Everyday I guess mundane bits of vanilla JavaScript you would have to write in order to build a component It's just laying on top of the web component standard giving us some shortcuts that make it Easier to implement and it is currently I mean by far and great leads The most supported of the systems We actually have a blog post where we went from lit one Then we switched to stencil and then we came back to lit 2 and it was a it was a journey for a lot of reasons but The backing of Google and their open-source community Now when this wasn't a PDF those slid in like a little bit later and I Want to talk about the outside pieces first here before we talk about CSS So we are using storybook in outline. It is far It's far better than pattern lab and it It allows it allows us to just have now an interface with these components that It's beautiful. It's easy to use. It's easy to go in configure a component for the various Things it can do switch a background change the text see what see what how you can use it and how you can possibly break it That's when it applies to like our QA people accessibility wise We're working with a command line tool with axe core That actually runs over every single storybook story we have so if we've created 200 stories It just goes through and checks for every single issue With the obvious exceptions being things like keyboard traps and stuff that you really take a lot of manual testing to get into And find some of those Okay for the CSS The biggest piece of note here is post CSS because that's what allows us to do really anything we want with our CSS The CSS variables tie in and we're starting to use it more and more To make sure that we're not having to do we're not having to extend a component to restyle it we can send in all the styles to the variables and Part of it scares me because it reminds me of like the days of using sass and having a variables file It was like 800 lines long and not knowing where to find things but We're learning how to how to organize those properly, but it still kind of is like that and you have that many options to Let a team quickly jump in and again You just got your new you you got your brand palette So you're ready to go just start changing a few of these things see what it looks like and then tailwind we actually we've used tailwind for like five years and There's a lot of things about it. We love We don't actually use the utility classes in our component markup We only use them as out-applies in the in a CSS file themselves So we choose to use them on our projects now and We also provide a method where the design system we bundle it up We put it in an npm package we send it out and we send it out with our tailwind config So our Drupal consumer when the Drupal team gets it They have all they have the design system and then they have all this extra stuff including the post CSS config So they can pull that in and now extend the same tailwind configuration And so now it's the Drupal developers putting you know a block template together Something just needs just needs a little bit of margin padding something like that around it It has all those utility a class classes available to Drupal and that's where we found At this point like the biggest benefit to be and why we stick with tailwind All right, what outline provides I'll kind of run through this. I've hit on most of these many times platform agnostic web components Reusable components across projects It's a fast and efficient starter kit and a baseline component library and the library is continuing to grow at all times Built-in accessibility of components. I won't claim they're a hundred percent accessible at the moment But again as we build it in and we fix a bug It's fixed once it's fixed forever and now it's accessible every time you use it You don't have to fight those same battles Rapid developer onboarding and these are legitimate numbers on the projects that we have With the same tool stack. I can get a new developer into an outline project and developing in five minutes That's all it takes and most four of that is waiting for node modules to finish. It's that A brand new outline project The way we set them up internally we bring them into our own CI process and all that 15 minutes brand new project We're ready to go and start being customized We do have developer production builds Experimental lazy loading of components a lot of people are working on this right now, and I don't know how far I'll personally make it on this piece but using intersection observer because web components are part of The standard HTML specs DOM spec you can you you can lazy load your web components the same way you can lazy load an image Again, what I was talking about with the CSS we have a decoupled CSS architecture so if you didn't want tailwinds hitting at the middle or You pulled in us wds components that are going to web components with their 3.0 Well, they're still using sass. Well, the fact that it was all just post CSS based All you need to do is get the right post CSS plug in turn it on you can use sass less whatever they're gonna Whatever they're gonna tell you to do One thing we've ran across now with a couple large large clients large projects as we do build these systems for more than one platform is that Well, we definitely don't want all the components. We built 250 components. That's actually way more than we ever built We built a hundred components But one project the flagship Drupal site only needs 80 of them the react spin-off site only needs about 10 So on and so forth. We're just using roll-up JS on the backside and We can just take pretty easily configure for each for each output need a specific Bundle that will be for that site Tons of configuration so much more Some of the things we're still working on. This is always a work in progress. It's open source The ability to pull in automatic updates our next one of our next big things is Getting everything into a mono repo pulling down specific packages So you know when you can update the button or when you don't want to update the button because there might be breaking changes So we'll have a versioned components and controllers The figma and figma tokens integration that I mentioned Really can't wait to see that in action and we're Continuing always expand the library put in more tests, you know get it as get it as stable as possible Make it as good as you can for each new project make it better every time And then with kind of announcing it here today. We're Hoping for more community involvement and we're always documenting. There's quite a bit of documentation out there at the moment When using outline is an easy choice I won't really go through this list here, but basically any HTML based system Can consume your web components? And I'll stop you there because that does not include React or native mobile apps because they don't they're not web And they are web components Again outline is open source. You can find it on github get hub phase two slash outline and It was not just One person that built outline. It was an entire team of contributors and this barely even scratches the surface of who all we have Internally working on myself Greg Oh for Dan Ian Josh Sarah Peter Biggie Ryan Chris Justin and some others not pictured Jonathan Michael Steven so many This is Honestly, this is our front-end department and now everybody's used it Everybody's up on the technology and everybody has contributed in one way or another through thought leadership through actual code implemented On a project or in the open source version of the product Next up as I kind of mentioned the you know the the full the full company adoption. Oh I'll do some shmoosing here It took you know my boss and his boss and everybody from marketing and of course our CEO among many others to be On board with this change internally how long it took us to get to a decent place and start to show start to show results Takes a village So are you our next client partner seeking an enterprise level design system for protecting or standardizing your brand? Are you an agency partner looking to adopt and contribute to a next-gen design system for your projects? Are you looking under that? Are you looking to expand your footprint beyond Drupal? Are you listening to what the clients are saying and what they want and will you be able to transition with that? Are you our next outline community contributor or even a passionate front-end developer? Looking to work with the latest technologies at phase 2 We do have a booth and we would love to talk to any of you and that's it questions I I can say that to date. We have only looked at it once. I think on one project. It's not something that we It's not something that's been a requirement. We've had to do but using the lit ecosystem I know for a fact they're they just put out like they have lit labs and it's like all you know And they just put out a version that's supposed to like enable SSR and just make it work like they've got some really great stuff in there that I think We kind of will just need to turn on give it a shot and work through a couple bugs. So I think it's very possible absolutely We Drupal react Gatsby The actual first First off we ate our own dog food. We did it first on our phase 2 website. We tried it out the first client project that we sold this to was multinational brand bringing 1719 different sites under one new brand and all the sites look terrible. They all look different So we built the massive system and these were all Drupal sites, so we were still in our wheelhouse It was going to be easy. We know how to we know how to get it into Drupal but one of the requirements they had was that oh Yeah, we have a payment portal for two of these sites It's written in dot-net and we have a third-party vendor who wants to use the header Wants to use the footer and just parts of the design system. It was a little nerve-wracking, but I told them I said yes, of course we can do that. I know it'll work and it wasn't until later in the project that they came in and Their development team asked for access gave them access to the github repository We set up a call for the next day to talk to this team walk them through some of the documentation They spent an hour looking at the code base and sent back an email and said we're all good We have everything we need They walked away and did the implementation We've done it ourselves in quite a few and seen success with others doing the same. That is a great question I I feel your pain and it's hard. It's Yeah, it does seem I think at time deprioritized, but it helps us Find issues earlier on. I mean one of the dot one of the designs I just did from a third-party company had massive grids of these cards Just with a title and you know a couple things on it Everyone had the exact same content in it. There wasn't one difference in the title links or anything So you look at it and you're just like you got to be kidding me The more that we can involve content to look at the content they already have Work with UX to know how you really want to put those figma designs together and all that If all that's in figma, there's no reason the front-end team can't just take and actually put in some decent Some decent things that in this case like catch bugs like oh when you do put in real data from Drupal All the blocks are different heights. So now we need extra code in order to make it look correct I mean, I yeah, there's a lot of benefits and it's It's a battle to it should continue The type script has made me a better JavaScript developer and I'm not very good Um Drawbacks like I don't know actually like it took us years to really fully Own it and just say that's the way it's gonna be and our Our developers picked it up. It's still is just drop is still just drop JavaScript You know a few bits added on and everything I think once you get in and you're understanding the extra pieces The extra layers layers you're adding for the typing and see the benefits of it. I think it just It makes it an obvious choice so to the To the source of truth like okay well to start with the if we're getting started early and Designs are still in rapid rapid change time Yes, there can be some going back and having to redo things But what you're actually redoing is very minimal because again with a component this accordion We already have a functional accordion Actually getting the styling in place and maybe the little extra JavaScript needed For this particular instance It's not that difficult that part is not that difficult once you have like the solid foundation of that component So, you know taking 20 minutes or whatever it takes to just go throw in the brand tokens Make it look like figment a day and it'll only take us five minutes tomorrow to update it if you make some minor tweaks to that one thing So I think it's it's doable. It's not It's not been something that we've lost a lot of time on Well, I will say one client, you know mid project decided to redesign everything like a complete A complete rebrand in the middle of the rebrand But the components were already there so all I mean all the team really had to do is just start, you know Repainting them I guess and then the figment side Yeah, this is yeah, I think a lot of times it was at some point thrown away abandoned not really Respected anymore and sometimes even on you know a third party that we might work with it's like yeah We hit a line and you know now we don't work with the the figment piece anymore But that's what we're trying to get away from with the figment tokens integration Jason data being passed back and forth because that can be in reverse too Like the design system could go ahead and change some stuff and then ship it back to figment with the tokens so We're hoping that in the near future. They are as I said like Shared sources of truth And that everybody's working together Right here in the middle naming things is hard Naming conventions Really kept it simple. I mean as as far as like Outline and our built-in components. It's an outline button. It's an outline thing And then for each client they kind of get their own specific You know folder where we're going to dump the custom stuff into and it would be client dash Like if they need to extend the button it'd be client dash button and then You know we keep it simple like I think with web components. You don't have to get too complex usually with Most of the things though we have seen some scenarios where we would have to put in a lot stricter conventions to that To date we have not seen a lot of issues like with caching and This is where like we've also tried our this experimental lazy loader We've been working on because as you get a hundred components or more. That's a pretty big javascript bundle But do you weigh off the Let's download 500k one time. It's done and that component javascript file everything there is cached in browser ready to go Or but if you turn to this other method and try to use lazy loading now On each page you're trying to pull 10 or 15 k and it's a different bundle every time so it's In my first tests of like actually doing that. I didn't see a huge gain compared to that just kind of cached once and Keep it in there No, not really at all because I think one like when the bundle comes it's already ready to Render that component on the page like it has all the data it needs And we have a set up in place for like the flash of unstyled custom elements Because if you dump stuff in it's in a light dom you can get that that quick flash while it loads, but I mean our first On to the Drupal side Yes, at the current point basically like our Drupal theme is going to take and include this outline.js that includes all 50 or 100 components and that's it. So that part all gets Just left over there and ready to use and Haven't seen many hits with that you first Yeah, go ahead. It's about communication between the teams I mean so and what you described is exactly what we want to do like i'm tired of building a button I am they am tired of building buttons like I want to build that cool Mapbox thing or whatever it might be. I want to spend my time there um Your teams have to communicate whether it's the developers or product managers that have are on multiple projects at the same time If you're if you're on the same set of tools they're like wait I know I saw this component or something very similar over here on the one we just wrapped up Can we reuse that and we have done that with A lot of our like a lot of our current components have come from a previous A previous implementation and we're kind of starting in a way now where we build our components That's the open source outline version and then create the client specific extension of that to give you know Start with our baseline that we're definitely going to reuse and then go ahead and add those couple extra features s and extend Just communication. Yeah, go ahead in front Mm-hmm very much so It's collaboration because in the design system I could choose to make that component as flexible as possible take a hundred properties and do all of those things But Drupal doesn't have to implement it that way And I was on a project where it was my Drupal project and we implemented this component that It had all 100 options and it was brilliant. However, it took a lot of knowledge of how to which Boxes to check and it was too much But so Drupal could take one really complicated web component and create 15 different Drupal blocks that Do the different variations if that's how the consumer wants to do it But at the same time we could also on the front end decide that Let's just go ahead and make these five separate things versus one that's extremely flexible and we're still learning that every day. That's There haven't been any problems. What are you talking about? You know it The tech is hard. It's a new tech. So if you've got If you've got a team of front-enders that have truly been doing Drupal twig theming for a long time It's an adjustment. It's an adjustment period and again, I I've been writing JavaScript for like 20 years and it wasn't until the past two years With type script and then web components that I think I finally got just a little bit like enough to say that I know some So I think that was the biggest the biggest hurdle is is the tech it's the tech we want to learn But that's everybody's excited to go learn it. So There's not as much of a struggle. I guess Yes, we're using the web components version of storybook I really liked storybook But at the same time storybook is kind of a complexity to itself because you're writing the whole story file It's a whole extra. It's a whole extra part of the development of how Yeah, how we're going to render this because storybook is just like Drupal storybook is another consumer really it's it's not We used to always hear like, oh, we're building our sites in pattern lab or something like that. No, we're not We're building components that are displayed in something and storybook being a consumer We're doing another consumer implementation in order to use it It's great. You know, our clients are using it our qa knows how to use it I don't think I haven't seen any features. I'm really aware of like we've tried to keep it Fairly slim on the features just because the more the more you start to add in like the more extras You know the more you're going to run into trouble um But we're also looking at alternatives like doxify and looking at how Some other design systems are just automatically generating, you know, great documentation Right out of the bat without additional code too someday maybe instead of What everybody wanted storybook It was just a hot it was the hot name at the time that was, you know Moving past pattern lab and like when we got a twig to go in like the twig plus storybook like the came, you know Everybody wanted to use it. It was the pretty tool at the time So we're definitely but you know, it's just one piece of the puzzle So it's one of those things that at any time we could decide to You know take a better alternative when it presented itself a lot of kicking and screaming Um It really did um, it took a long time because We're used to doing things a certain way. There's a pattern It it works for better or worse like we get to our deadlines. We get to our clients but how can we do it better and you know You see clients coming in with smaller budgets shorter timelines No, I forget the budgets but shorter timelines Like you didn't come when you had a year and a half for us to do this project You come three months before we got to go to launch That was I think that was the big win is If we get this system set up if we get all the components in place Now we can do those two or three month projects and get something out the door It's still just going to be a first release that we continue to iterate on But I think that was probably the probably the biggest thing of of knowing that at some point There will be that return on the efficiency curve Yes I Yeah, I mean, yeah, I think it is like every every component has to be a hundred percent accessible has to take everything into consideration And Got it Got it. No, not necessarily because still inside inside of that component Is a normal a tag or button tag at the end of the day like our button still is just a wrapper for Whatever other spec components we have And so it does inherit all that there are times when we build certain things that yes We do now have to like, you know, hand code some of this That is you know built into other things But not too much. I don't think we've I don't think we've seen a lot of that until we get into really advanced components that You know you get you get down to the brass tacks of trying to make keyboard navigation possible across a map or something like that That's when you'd see a lot of custom stuff Anyone else Thank you. Yes Three front-end devs to build out design system for a web project Sure. Okay. Uh, yeah Three devs eight weeks, I mean I think we see like We have a lot to go well beyond that but If you already have, you know design and stuff ready to go It's pretty quick to start implementing those components and and that's why we're moving it up in the in the in the chain a little earlier because We have to have half the components ready like we've got some of them already now out of the box and As soon as we turn on that consumer as we soon as we turn on Drupal, they're ready to go Like they can start pulling in pieces and implementing them Yeah, I Two months three months lake is any reasonable timeline. I think we see a lot Go ahead That's a must-have like it that's that's the whole point of the single source of truth That's and I'll admit some clients will be a little Sticky on what they want to you know, keep in their tool chain that might conflict with something Um in your case now like two separate design systems Um, yeah, I would fight every way I could against that and not recommend it Thank you all very much for coming. Appreciate it