Vojtech Miksu from Uber
Chris Strahl:
Hi, and welcome to the Design Systems Podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design, code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at knapsack.cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think, go ahead and tweet us at the DS pod, we'd love to hear from you.
Chris Strahl:
Hey everybody. This is Chris with the Design Systems Podcast. Today, we're going to do something a little bit different. We have a lot of these conversations that tend to be about how we implement design systems or stories about the design side or stories about collaboration. We wanted to do an episode that was focused on tooling, and we ran across this really interesting article about Ladle, which is this open source project that is very similar to Storybook in how it visualizes components. And it really got us thinking about one particular phrase in it. What is the next gen tooling for front end? And so we looked up Vojtech who happens to work at Uber, and we have him here today on the podcast to talk with Evan Lovely, the chief architect at Knapsack. So, Vojtech, welcome. Really glad you're here. Thanks so much for joining us.
Vojtech Miksu:
Yeah, thanks for inviting me.
Chris Strahl:
And hey, Evan. Glad to see you too.
Evan Lovely:
It's great to be on. Thanks for having us.
Chris Strahl:
Awesome. So we wanted to jump off the conversation today at sort of a question. When we think about what the tooling is right now, like that state of tooling, that understanding of the meaning of that tooling, and you guys said something sort of before the show that I thought was really interesting as an important aspect of modern tooling or next gen tooling, and that is this idea of a focus on realtime feedback for developers. So maybe take me through what you mean by the current state of the tooling and why that realtime feedback really matters.
Vojtech Miksu:
Yeah. So there's been always a big gap between your code base and what you actually ship into the browser. And this just creates this longer loop and that kind of disconnects you from the experience of developing and debugging. So if you can remove like some of the stuff that happens between your code base and the browser, we can make this loop much faster and that's just better experience because anytime you make a change, you don't have to really wait for the tools to pick it up.
Evan Lovely:
Yeah, it's interesting. Because I think that's also what design systems are about is making it so the feedback cycle is quicker because when you make a component, you'd also traditionally have to implement it in the application before you could actually see it on a website somewhere, which is where somebody would be actually experiencing it.
Chris Strahl:
So is this related to not having to think about like running through a build process? Is this about that time gap between like I wrote this line of code and I can see what this line of code produces visually, where's that real disconnect from real time to async that you guys are talking about?
Vojtech Miksu:
Applications are getting more complex and just bigger. And usually as they go bigger, they just go slower. Right? So sometimes to spin them up, it just can take minutes. And then to make even incremental changes can take 10 or 20 seconds and it just gets worse. As the application gets bigger and bigger, it usually gets slower. So we need like some different tooling that's able to solve this issue so the development cycle doesn't get slower with the application. It should not matter how big is your application, you should always get similar experience. So I think that's the biggest difference between the older tooling and the new generation tooling.
Chris Strahl:
Gotcha. So in the old model, as the application code base gets bigger and bigger and bigger, the ability to make change to that application slows down. And moreover there's all this tooling that is around that application, like testing comes to mind or any sort of feedback tooling that also summarily has that same sort of slow down effect. And it overall has this big effect on the speed and agility of development.
Vojtech Miksu:
Yeah. If you want to be a specific, the biggest or the most expensive part is bundling. So it's kind of the process of picking up all your files or your modules and just creating something digestible for the browser. And that just takes more and more time as the code base grows because you need to now look through all these modules and combine them together into these bundles. And that just makes all the tooling slower, including the application and the testing. And there's now a shift to start using tools that don't do this part. They just completely skip the bundling and they just let browser to do what browsers are really good at. And that's just requesting modules and being able to catch them and just speed things up.
Evan Lovely:
And it's kind of really like the browsers have finally gotten good enough and, more specifically, they've got an update cycle that happens automatically. With internet Explorer 11 finally, finally going away all those years ago we ended up with browsers that will self update every six weeks or so. And so, we can feel confident that our users have got a more modern browser, which can handle what the tools used to have to do.
Chris Strahl:
So this is a lot of shifts from tooling that was before you got to the browser, the tooling actually happens in the browser. And so when we think about what a next gen web tool is, you're trying to take advantage of a lot of the capabilities that a web browser offers you that before you had to stuff into the tool. And that overall helps with the bundling you guys talked about and generally makes the application more performant now in a way that isn't as intimately tied to the size of the app.
Vojtech Miksu:
Yeah, correct. Historically we didn't have a good way how to encapsulate code in JavaScript for browsers and how to load the code into browsers. And then the Node.js came and they had to solve this with CommonJS, which didn't work in browsers. So we still didn't have a good way for browsers how to load JavaScript, so we built all this tooling that's able to take the CommonJS code from Node.js and turn it into something digestible for browsers. But then recently we got ES modules which try to solve this issue and they just offer this mechanism for both browser and node to load and execute code, and we don't need this tooling anymore that does all the bundling and compilation.
Chris Strahl:
So these modern pieces really are about performance. Are they about feedback? What is it that is the core of the value beyond just the speed?
Vojtech Miksu:
Performance is a big part. But I think it's also just kind of removing some of the obscurity. Because when you take your code base and just turned into one giant file, it's much harder to reason about it. Right? It's like something that you didn't create. It's something that the tool created. If you let browser to download your modules one by one, you can just go to your network tab and you can directly browse all these modules you wrote, you can search through them and it's much easier to understand what's happening in your application. So it's both performance, but also it's, I would say it's easier to debug it. And sure we have tools like source maps, but they are not always great. Sometimes they break, they definitely slow down builds. It's kind of like a workaround for the issue we had with bundling, but now we need to do less and less transformations. So that just improves debugging part of the developer experience.
Chris Strahl:
When you think about that, it lends me to this idea of when I'm making a change and I want to understand how that alters production, it seems like you have a much clearer traceability to that. Right? So I know that I'm making this change over here. I have this idea that there is a scope for that change that is within that particular module or within that particular part of the application I'm working on that no longer affects like this broader system. Is that also correct? And when you think about how I observe real time change and what I'm working on.
Vojtech Miksu:
Yeah, that's correct. We still do some bundling even with this new generation of tools, especially for production, but in the future we might be able just to skip the bundling, even for production applications. Technologies like HTTP/2 and HTTP/3, it's not as expensive to fire up a lot of HTTP requests so we can get much simpler applications even in the production mode. And that's definitely going to help to debug problems in production as well. Like today, if your production is broken, good luck with debugging, you just get this giant file full of one character variables like heavily optimized and you have no idea what's going inside. Right?
Evan Lovely:
Yeah. I think that it's, what you get is you are a lot closer to what is experienced by the end user, and it's about removing layers of abstraction. You said something about, hey, this is the code that I wrote, and then being able to take a look in the browser and seeing your code being ran. When you're looking at bundled code, it doesn't feel like it's your code. And so being able to be one step closer to what users are actually experiencing in the medium it's destined for in a browser helps a lot.
Chris Strahl:
Yeah. And this is where it kind of starts to relate back to design systems, right. Because if I'm looking at that card or that button or that hero, whatever component is that I'm looking at, and I'm looking at that in a system that is attempting to look as much like my production environment as possible to the point that it is literally the thing that I'm testing or working with should be the exact same thing that is in my production environment. It's tools like this that help us bridge that gap.
Vojtech Miksu:
Yeah, for sure. And if you think about this, this is how the JavaScript also started, right? You were just able to open an HTML file and type some JavaScript into it and run it and you could see it in the browser. You didn't need any tooling to modify your JavaScript code. You didn't need any bundling. It was very simple and nice for it, and it was very inviting for newcomers to use, but over time it just started developing these very interactive and giant applications and we needed to invent all this tooling to make it work. But now we are kind of going back to the roots and we are just able to let browsers do a lot of this work and to make it work even for these more complicated applications. So we can, again, just start modifying files and see them in the browser without all the obfuscation and bundling and all that stuff.
Evan Lovely:
And having things like that can really help newcomers quite a bit. Many developers have learned by looking at the source code of a site. And I think that can really also help out designers or anybody who wants to kind of dip their toe into things because usually you start out coding by editing somebody else's code as opposed to writing your own from the ground up.
Vojtech Miksu:
Yeah, for sure. Something special about web, right, and how open it is, I can just go to any website and kind of copy, paste and steal their code and just run it for myself, modify it, play with it. That's not possible with iOS or Android native development where it's much harder. And I remember it was pretty controversial back like 10 years ago when you start using all this bundling and minification, and some people very kind of upset about this, like we are losing this part of the web and it's so open that anyone can just open the source tab and just change things and see how it works. We kind of lost that in the process, but maybe now we can just reclaim part of it back.
Chris Strahl:
That is really interesting because when I was doing more engineering and more web development, I always thought about, I want to be able to understand the impact that the code I'm writing is making on the thing I'm building. And there was a really clear straight line to that. I mean the last time I wrote code professionally, it's like 2011 at this point or something ridiculous. And so when I think about that and that sort of straight line impact of being able to observe that thing, I do think about when I look at modern web applications and the very arcane nature of the code that I look at now.
Chris Strahl:
And so what I think that you guys are alluding to is a future state where maybe that first reality is present again, because all that reason for doing the bundling, the obfuscation, the minification of the stuff that we're putting in our applications, the reasoning for that goes away. And I kind of want to understand a little bit more about that, right? Like what exactly is a browser doing differently now that allows us to not care about those things anymore?
Evan Lovely:
Well, before, a JavaScript file had to be all in one file. I think the first JavaScript tools just took several JavaScript files and then stuck them together one on top of the other to load. And so when you're all kind of in one file you have what's referred to as global scope. And so if you say variable name time, nothing else can use that same variable name. And once you start using libraries, it gets almost impossible to not step on each other's toes.
Vojtech Miksu:
Yeah, exactly. And now we finally have ES manuals, which solve this issue, and we have much better way how to load code, how to make sure the code is encapsulated, it's in modules, it doesn't conflict with the global scope, just all the good stuff that other languages always had. We finally also have it in the browser. So that's kind of like the new change, the new shift that's happening right now.
Chris Strahl:
So shifting it over to tools and thinking about Ladle and thinking about these ES modules, webpack alternatives type script, et cetera. When we think about this modern tool set, if we're no longer trying to do this bundling, we're no longer trying to put everything in the same space, what are these tools solving that's different than the tools that came before? What makes them really next generation?
Vojtech Miksu:
Yeah. So for example, with webpack, when you start webpack and try to run your application, it needs to do all this work, it needs to go through every single file in your code base and create this bundle, and then it starts the server and serves you this bundle. And this can take a long time. It depends how big your application is. Vite is like very different. Vite just starts the dev server immediately. It serves you the index HTML page and then it uses browser to download these ES modules on demand as it goes. Right? So now the browser is pretty much discovering your code base and loads only what's needed. And Vite does some compilation, like for example, you need to get to remove type script types or JSX from React. Vite doesn't do any bundling or very little bundling, and it just gives you the webpage, the web application immediately and lets the browser resolve all these imports.
Chris Strahl:
Gotcha. So this is enabling you to be, I guess, a little bit more dynamic about how you think about how the code is enabled or used inside of an application. And that's ultimately what leads to better performance or is it something even more than that?
Vojtech Miksu:
So the performance is the biggest difference, right? When I just hit my command to start developing, I can see the browser opening the application immediately. With webpack I sometimes have to wait like a minutes before the browser spins up and I can start working. The performance is definitely the central part, but then also in the browser you're not getting any bundles, the browser downloads each module individually. So you can just open your request and you can see how your application looks like. You can see the files you had in your code base. You can see them in the browser. There's no bundling in between.
Evan Lovely:
And also caching is a lot better as well, because let's say there is hundred modules and somebody opens the page and loads them. Then later you ship an update that changes two of those modules with the old build tools, you would have to redownload all 100. And with the new tools, they can cache the other 98 and only download the two that have changed.
Vojtech Miksu:
Yeah, exactly. And in past we had some very complicated ways on how to split one big bundle into couple small bundles, just trying to decide what should be cached for longer time versus for shorter time. And that's kind of bad. If every application ships its own React and it's inside of this giant bundle, that means you are keep downloading React every single time. There are some proposals to maybe build some global cache inside of browsers for popular libraries, which actually kind of seems as a bad approach as well because it introduces all the problems. But the approach with ES modules is just like, caching is way more granular so you are just caching each individual module instead of trying to create these bundles. So for sure caching is much easier and more efficient this way.
Chris Strahl:
Interesting. So help me understand how this relates to the work that we do in Design Systems, in particular the coding work here. When I think about an engineer working on components or working on assembling an experience based on those components, what does this change about my workflow?
Vojtech Miksu:
Yeah. So again, it makes it much faster. If you're building a component library, you probably use to do like a storybook. As your library gets bigger and bigger, you just need to keep adding more and more stories. And again, that means more and more work that a tool like webpack has to do before it can spin up, it needs to do more work before it can send you an incremental change. So it just makes your whole developer cycle slower. With Vite or Ladle, this kind of goes away because it doesn't matter how many more components you are adding, it always kind of guarantees the startup time is instant and it only downloads and shows you the component you are currently working with. It doesn't have to really go through the whole code base before it does the thing. It definitely also scales much better.
Chris Strahl:
Specific to your problem at Uber. One of the things that was hard about the system that you had is you guys do a whole bunch of stuff that is external after that component gets built, that is associated with testing, that is associated with all of these other aspects of the engineering cycle that ultimately would require you to rebuild your application over and over and over again. And so that performance hit was multiplied over many different tools. Is that right?
Vojtech Miksu:
Yeah. Correct. Hundreds of projects. Because the build part is just the first step, right? Once you build your component library or your Ladle instance, only after that, you can run all these tests. So you always wait for the build to finish first. So that just kind of slows down everything down the pipe.
Evan Lovely:
So talk to me about some of the testing that you run.
Vojtech Miksu:
Yeah. So we run multiple types of testing. One of them is visual snapshot testing. So what we do, we take your Storybook, or now Ladle, and just visit every single page and take a screenshot. And we do this without you, as a developer, you don't need to do anything, we just do it automatically on our servers. So as long as you are developing your components inside of a Storybook or Ladle, you just get this coverage. So that's one important part of our tooling. We also do accessibility testing. We run a X to just check for accessibility issues. And we have additional tooling for interaction testing so you can just write these short snippets for selected stories and you can run tests like click on this button and assert that some value changed to something else. So we try to build additional tooling around Ladle or Storybook, but a lot of it is just automated. So you, as a developer, you don't need to do anything and your components are already covered by visual snapshot testing, which is really nice.
Evan Lovely:
Interesting. So one of the promises of Design Systems is that it represents what users will actually experience. And so that's over in production and another web app, and there's more build tools there. So how do you make sure that when you build out your design system using some tools and then later there is the web application or website that takes those same components and then uses some different build tools that the results are the same and we know what our users are experiencing and testing?
Vojtech Miksu:
Yeah. So we don't take visual snapshots only for these stories. We also take them for production applications, but that's much harder because, first of all, it can't be automated, because we can't just kind of find every page and every state of your application and take a screenshot. It's something you have to tell us. And also these applications are way more complicated. They do a lot of network requests. They are very flaky. They can just break in so many ways if you try to run them in your CI. So we have these tests as well, but there are always just very few of them and we can automate it as well.
Vojtech Miksu:
But when it comes to testing, I think visual testing is really the most important one when it comes to the user experience. We had these all other types of tests, like we did just snapshots, which tries to compare the HTML output, the HTML dam, but that doesn't really tell you like if the component looks okay and if it breaks, when it breaks, you don't even know like, is this serious or not. People just always glance over it and they don't even know what's happening. So I think using visual snapshots is really good way how to test your components.
Evan Lovely:
Yeah. That's a lot of what we have experienced as well is that it is a lot easier to test in a design system than it is in a production application. You're able to see a page with just a button on it and can make sure that works as opposed to trying to go and take a picture of your homepage and make sure that not a single pixel has changed because those tests always produce false negative. There's always going to be a pixel off on a homepage. So you learn to not trust them.
Vojtech Miksu:
Yeah. Also would be, so you say you have like a button and it's easy to test it. We see our developers sometimes create these stories that are essentially full pages. So they're trying to recreate like bigger parts of the app inside of stories because they'll have all this automation and tooling around it. Maybe some developers spend even more time developing in inside of Storybook and Ladle than compared to the production application because they just get all this testing for free. So that's also something that might change. We might have these just two equally important development environments, one that's your application and then another one that's using this concept of stories to split your application into small parts. It's easier to test and automate.
Chris Strahl:
That's been an interesting thing. That's been a really important part of Knapsack that we were thinking of early on is the ability to take a bunch of components and sort of assemble it into a full experience because nobody in user land use a component in isolation, people are always viewing sets of components that ultimately represent an assembled experience. Thinking about that through the lens of testing is an interesting idea where if you had a bunch of sample pages that were created with the design system, you'd be able to test those full experiences instead of just those individual patterns in isolation.
Vojtech Miksu:
Yeah. And that's what we saw too. People trying to create these bigger parts of application inside of stories instead of just using stories for very atomic pieces of the UI.
Evan Lovely:
So the thing I'm curious about is should Design Systems ship build tools? Because the problem I see is that in a design system, we are building our components and then doing a lot of testing there, which is supposed to give us faith that it's going to be fine in the end. But then in production for the web app, we build things again, which has a possibility of being a little different, especially if those build tools are very different. And so design systems are supposed to be collections of reusable solutions. And I view those not just as like reusable buttons and cards, but also things that help solve problems, like build tools. I'd like to hear some of your thoughts on that.
Vojtech Miksu:
Yeah. I agree. When I started at Uber, I was working a hundred percent of the component library and design system. And after some time you realize like that's not enough, you also need to provide some tooling and we need to make it easier to use all these components in your application. Over time you actually transition into this role to also build supportive tooling, like Ladle, the tooling for testing, for visual snapshot testing. So we were also just interested to see how developers are using our components. When you take screenshots, you can just kind of directly index all these use cases and see what they do. We also build this tooling that analyzes code base, and we were just searching for a code snippets, how people are using our components, what properties are they customizing. So we were always very interested into like how our components are being used. So I think it's not just enough to create a component library and hope for the best, you also need to closely follow what developers do with your components.
Chris Strahl:
When you were talking about all of the automation that comes along with your design system as well, I was framing in my mind like that's actually a part of the design system that's on top of the components, that's on top of all this other stuff. Right? There's an infrastructure piece to this that ships along with the design system that provides a lot of that powerful automation and a lot of value to your engineering team. I think that's a really cool way of thinking about it is like, it's more than just the component library.
Vojtech Miksu:
Yeah. And a lot of this tooling we built first for our component library, like visual snapshot testing, we've been using that since the beginning. And then we saw the value of it and we also wanted to bring it to developers so they can use it in their applications, in their stories. So yeah, all of the tooling was built for the component library, but then we also made it more robust so it can be used across all the applications.
Chris Strahl:
If there's an engineer that's listening to this that thinks about like, hey, you're living in that next generation, you're living in that promise land, what do you see as the transition that most people have to go through to get to where you guys are at? When it comes to you all and your modern stack and doing something like building Ladle, where does that transition really happen? Where does that start and what does that feel like?
Vojtech Miksu:
Yeah. So first of all, we are not there yet. Not even close. We are also in this transition and it's going to be a long transition. I think with ES modules, it's almost like Python 2 versus Python 3 migration. It might never be really fully done. And we talk about a lot of benefits here, but there are also a lot of painful points with ES modules. And I think it's going to take years to actually fully adapt them in the ecosystem. So, that transition needs definitely a lot of changes in terms of tooling. And it's not just bundler, even the tools for testing, they don't always work with ES modules correctly. So you need to kind of change all the tooling. You need to change all the libraries. Everything that's on npm needs to at some point embrace ES modules. So there are a lot of changes we have to make as an ecosystem. And that's going to take a long time.
Chris Strahl:
And when you think about the scope of those changes, we've talked a lot about like the JavaScript side of it. Is there other pieces of this, too, that also represent that next gen tooling?
Vojtech Miksu:
It's not only about ES modules and the tools that skip bundling. There's also this like a new shift in the way how this tooling is built. People realized JavaScript is not always the fastest language. They start to utilizing languages like Rust or Go. So you have this generation of tools like esbuild or Speedy Web Compiler that can just make your application way faster, even in today's paradigm. So you can still keep using webpack and bundling, but if you can make this underlying compilation like 10 times or a 100 times faster, it can also give you a great performance boost. So I think there are like two different directions and they are complimentary and they're both difficult in different ways, but I think in that future, we might be this ideal promised land when we use ES modules and or outdoing is written in Rust and it's extremely fast. So that might be the future in like five years.
Chris Strahl:
When I think about the vision and I think about you sitting down to construct Ladle, I mean, obviously there was more than just you involved in that conversation, that decision, what was the original thought about why you built that?
Vojtech Miksu:
Yeah, so it kind of started as a prototype. We saw some of our story books at Uber got really big. Some teams, they just created hundreds of stories and it got very slow. They start complaining like, hey, when I try to start this up it just takes minutes, when I make a change it takes like 50 seconds. Like, can we do something about it? And we kind of start digging into it, like, why is this so slow and like, what's the slowest part of it? And that's when we started looking into different build tools like Vite, and we just saw a big opportunity how to improve this. And we just decided, hey, let's just try these new bundlers and start to prototyping a new solution. So I actually tried a couple different tools, like [inaudible 00:28:58] 2, Snowpack, and then finally we landed on Vite, but it was just kind of a discovery phase, trying to use all these different tools and see like, what are the benefits? What are the drawbacks? Is it something we could use?
Evan Lovely:
Once you settled on the build tool that you wanted kind of at the core of your Storybook replacement, how hard was the lift to be able to implement the pieces of it that you wanted?
Vojtech Miksu:
I would say it was surprisingly easy because the tool itself, the webpack or Vite, actually does all the hard part, all the heavy lifting. Right? So you don't need to build that much around it because the essential parts that need to be done, like serve your application, go for your code base, all that good stuff, that's already being implemented by Vite or webpacks. So you don't need that much to build around these tools.
Evan Lovely:
That's awesome. I think that it's pretty easy to look at all of the tools out there and think that they are so hard to replace or so perfectly done when really, basically with this big open source world, we just are continuously standing on each other's shoulders and pushing each other to be a little bit better. It's great to be able to not get comfortable with everything being already done.
Vojtech Miksu:
Yeah. And we are always in the cycle when you create a tool, it gets adoption, people start asking for more features. So the tools grows over time and then it gets bigger and slower and it's much harder to steer it or change it in a bigger way. So somebody else comes and creates another tool that's much smaller, it doesn't have all these features, but it can be much faster. And then again, it grows over the time and kind of like a never ending cycle of open source and the libraries spheres.
Chris Strahl:
Yeah. Yeah. Cue the Lion King music and the circle of life and everything like that.
Vojtech Miksu:
Yeah. And we can also just help each other to improve. It's much easier just to create a new tool when you try to prototype with ES modules and Vite than trying to change existing tool that's being used already by thousands of developers. It doesn't mean it needs to be a fierce competition. It's more like, hey, this is a prototype of something new, and maybe there are some lessons you could take from this. And you can even see there is now a Vite builder for Storybook. So this might also just kind of help to prove that Vite is something that's viable for Storybook as a concept, and it can bring you all this performance. Maybe you should try it too.
Evan Lovely:
If you could wave a magic wand and add any feature to Ladle, what would you add that would help out your teams?
Vojtech Miksu:
Specifically for my teams, we are pretty much feature complete in terms of what we wanted to build. One of the things is like interaction testing, make it easier to run tests and see the feedback inside of your browser instead of run it in your terminal and see the output there, because these tests run in browser on real components and they do actions like clicking and typing. So it'd be kind of cool to see it real time and just getting all this feedback in your browser. And maybe even developing these tests in the browser. We used to have these ways with Selenium when you could click around, you could record it, you could replay it. And the premise was like, hey, this is something even like product managers could use to write tests. It never really happened, and it's always up to developers to write these tests. So it's always something I'm thinking about like, is this possible, like, could we do this in the future? So that might be one big thing I would like to see.
Chris Strahl:
Yeah. I definitely see that as an important future. The idea that you can democratize some of that work, right? That idea of like, what does interaction testing look like? Or what is it that I want to see, or my intent in an app.
Vojtech Miksu:
Yeah. And we also had these natural languages to write these tests. So you could just write like English sentences and it would run these tests based on them, but I've never seen it working. It always came back to developers and writing some JavaScript. Hopefully in the future, it's going to get easier.
Evan Lovely:
Yeah. Bringing in more members of the team. Right? It takes a village to be able to build all these things. And especially in the realm of testing, if the people who were asking for these components to get built, the designers and the product managers, if they could basically say, I want a button that when I click the dropdown menu, I can see menu items below it, then that's going to help the engineer build to that spec. And then also it's going to make sure that it ends up doing what it's supposed to do. And then also, as time marches on and the code continues to change, that the component continues to still function that way. It's the great thing about tests.
Vojtech Miksu:
Yeah, for sure. And yeah, just in general, always trying to close this gap between product owners, designers and developers is really important.
Chris Strahl:
So what struck me by a part of your story was thinking about some of the parallels of when Evan and I were thinking about Knapsack in the early days. When we were an agency and we were building design systems for large enterprises, fully custom, one of the tools that we reached for pretty frequently was Pattern Lab, which is fairly similar to Storybook in its implementation. And ultimately this sort of same thing played out where we found that Pattern Lab for a variety of reasons wasn't really meeting our needs. And so we looked at different tooling. I think there's an interesting sort of analogous story here.
Evan Lovely:
Yeah. Pattern Lab served purpose for us very well for a long time, but we ended up starting to hit some of the walls. And one reason why we were using Pattern Lab is because we would be building for languages that need to be rendered server-side, and Pattern Lab works well with that. It wasn't about React, basically. And some of our clients needed to be able to have server-side rendered components, but then also React and view. So we ended up having these needs of something has to be able to be rendered server-side, but also they had a couple different template languages and wanted to demonstrate their design system with that all under one roof. And then the other final missing piece, of course, was adding documentation. The only way to really add documentation in Pattern Lab and older versions of Storybook was to just write out the HTML in some component that showed that. And that was really unapproachable by some of the other non-technical contributors.
Chris Strahl:
I love the parallels here between kind of thinking about what old tech or legacy tech looks like relative to modern tools, relative to next gen tools. Vojtech, I just want to say, I really appreciate you telling your story. This has been awesome. Do you have any final thoughts you'd like to leave us with?
Vojtech Miksu:
Yeah, thanks for bringing me here. Final thoughts. You should look into these new tools like Vite. Read through documentation. They have really good description of how it works, what's changing. Give them a try. If you see your applications are not performing well, maybe this is something you could use. And it's kind of like a paradigm shift, but it's very interesting and I'm just encouraging everyone to read through it.
Chris Strahl:
We'll make sure we link that along with a few of the other projects we talked about in the show notes. But again, just wanted to say thank you. Also, Evan, thanks for co-hosting with me on this one, definitely helped me get a little outside of my own technical depth. I really appreciate y'all.
Evan Lovely:
Thanks so much for your time, Vojtech. It's great being on the show, Chris.
Chris Strahl:
That's all for today. This has been another episode of the Design Systems podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter @TheDSPod, we'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.
