Zoltan Olah: That's the beautiful thing about open source is everyone gets to scratch their own itch to build the thing that is important to them. And whether you have two hours every second night to work on it, or three people's worth of full-time effort, like it's still the same thing. Eric Anderson: This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Eric Anderson: We're excited to have Zoltan Olah joining the show today. He is one of the creators of Storybook or Storybook JS. Zoltan, thanks for coming on. Zoltan Olah: Yeah, thanks for having me. And just to correct you a little bit, I'm not one of the creators, but I'm deeply involved in the project these days, and I'm sure we'll get into that in the podcast. Eric Anderson: Perfect. To level set with the group here, what is Storybook? We'll start there and then we'll get into more detail on how it came to be. Zoltan Olah: Yes. Storybook is sort of the world's most popular isolated component development environment and what that means it's a class of software that was able to reach into the components in your code base. And it gives you an environment where you can develop those components independent of the application or the design system that they're built for. And that primarily means recording the states that those components convened in terms of their inputs, which is usually sort of plain old Java script. And then that gives you a sense of catalog or, documentation that helps you develop components that helps your team develop components in the future. And then it also leads into other additional bits of functionality on top, such as testing, such as review, integration with design tools and anything basically that helps developers in the component driven kind of development methodology. Eric Anderson: Got it. And maybe as points of clarification, so it's not a design tool, like I think of Figma or other things, but a compliment. Zoltan Olah: It's a compliment. Yeah, it's a tool that front end developers use and it sits side by side with their editor and Storybook is this hot module loading. It's refreshing components sort of next to their editor. And that's a better development workflow than sort of trying to do that inside an application itself where you may not have the data accessible that your component needs for whatever you're building. You might not be able to easily get to that state that you're working on inside the application. And then thirdly, you might have a hard time actually starting the application if you're a front end engineer. It might require all sorts of bits of the stack and databases and dependencies. And we've all seen that, [crosstalk 00:02:38] whatever NPM start and you just get a screen full of errors and you have to ask an engineer to help you out. Eric Anderson: Very good. So tell us the story on how we got to Storybook and along the way, you can tell your own story. Where did this begin at least for you, or where did the project began? Zoltan Olah: For sure. Yeah, it's quite a circuitous journey, actually. So my two co-founders and I, Tom and Dominic, we were running an agency. We're running a little studio and doing app development on behalf of clients. And we found that this component driven methodology sort of. No one was talking about it then. We're talking five years ago. Really helped us build apps faster. We're able to both reuse components between clients. So we'd build them once and then we could build them into every app that we worked on and we could really speed up our development process so folks could be working on building the design, developers could be developing the components even before design existed because they sort of knew what the data requirements would be. And so everything was really like able to be well paralyzed using this methodology. Zoltan Olah: And we've built tools internally at the studio to support that methodology. And so that's spiritually for us where Storybook was born and it's going to be different for different people. After that, our studio was actually acquired by [Meteor 00:03:59] . They're now Apollo. They're stewards of GraphQL. So our team joined Meteor and we brought this methodology along with us and we're building products inside Meteor. And then around about that time, another fellow in the Meteor community called [Erinodaa 00:04:16] decided to... I can't claim credit for showing him this methodology. I don't remember ever sort of talking about it, but it was I think, starting to gain steam in the development community. And he built an open source tool that was very similar to what we had internally ourselves, but solved a whole bunch of generalization problems that we didn't get around to solving which basically means as a developer with a project, like how do you integrate this tool into your interior development environment? Zoltan Olah: And that's actually a pretty hard problem when you think about all the different frameworks and webpack configurations and Babel, and the JavaScript tooling. So he went and started Storybook and solved a lot of those problems and started developing it out in the open and we got really interested in it and replaced our internal tooling with Storybook. And then he moved on from the project and started to work at Versal on net, which is another popular front end project and sort of put Storybook up for adoption to the community and said, "Hey, we're looking for maintainers. I'm looking for maintainers. I don't have time for this anymore." And that's when we got really heavily involved in it. And this was back in, I want to say 2017 ish. And that's also around the time that we left Meteor to start Chromatic to start our UI regression testing tool that we'd built on top of Storybook to leverage the work product that was being developed inside Storybook and to solve a long running pain point for front end engineers around UI testing. Eric Anderson: Very good. Zoltan Olah: So that's the first part of the journey for us. Eric Anderson: Yeah, no, I mean, it's exciting. You get to experience something, have a methodology and it gets you kind of inherited later on. Zoltan Olah: Yeah, it was sort of weird. And we're at a time in our career then where we were so focused on building the studio. And then later we were like running at a million miles an hour at Meteor, like working on open source there and on GraphQL. We just sort of didn't have time for it, for open sourcing our products and supporting them. Whereas now we do, and now we've built a company specifically for that purpose to be able to support the open source. So it's super exciting. Eric Anderson: And how wonderful for the community that Storybook wasn't abandoned or at least kind of left out to dry. You've got a whole passionate group picking it up. Zoltan Olah: Yeah, absolutely. Eric Anderson: In some ways these projects end up being closely tied to their creators. It's their vision or they have this following [inaudible 00:06:45]. What's it like to inherit a project and assume the reins? Zoltan Olah: Yeah, I mean, in our case it felt very natural because the vision was average and it was a shared vision that we have. So it wasn't alien to us in any way. We're excited about it because there was a lot of foundational work, a lot of the early heavy lifting that I talked about before around integration, that kind of thing was there. And we got to come in and continue the vision towards what we're building here. Eric Anderson: You mentioned at the beginning that this is all very tied to this idea of components. Maybe you can help us frame where we are in time. Were you at Meteor in kind of early [inaudible 00:07:24] Was that all reacts or was that web components? Zoltan Olah: Yeah. So, the early days of Meteor were actually programming in a technology called Blaze, which is Meteor's in house reactive componentized view layer. And we ended up kind of phasing Blaze out in favor of React. And so we're still heavily a React shop. Storybook now supports most of the view layers under the sun. We've architected in a way such that the tool can be plugged into them. But yeah, that's kind of the history. Eric Anderson: But the idea started but depends on a web component or component view of the world, which I guess is now standard. So maybe it's not novel anymore, but at the time it was new. Zoltan Olah: Yeah, definitely. But to us, it just made a whole bunch of sense. And I'm really happy to see that the underlying sort of concept and the architecture has spread across every sort of modern view layer. There is consensus around the fact that, hey, like really modular UI components with a well-defined API and a non leaky internal implementation is the right way to build things. Eric Anderson: Yeah. It's also interesting to hear about your path to the company. Take Tailwinds, for example. They built an awesome open source project that helps developers and they went the route of building components that you could buy. And you've gotten them out of this kind of UI testing framework, which I guess was kind of maybe what you wanted all along. It kind of fits your vision of making UI development more robust, but yeah. Tell us how you got there. Zoltan Olah: The testing is really just one part of it, but to us it was the lowest hanging fruit because it was such a painful part of the app development process really all along. So, CICD has become... like it's taken the best part of decades to get to where it is now, but it's basically an accepted methodology for building software. It's like, yeah, we want to ship fast. And in order to be able to ship fast, we need to have a pretty decent test coverage and a CI CD strategy to help protect us from the pitfalls of shipping fast. And it was always sort of weird to us that like UI was conveniently left out of that story. It's like, 'Yeah, we have CI CD." "Oh yeah, what's your UI test coverage." And we talked to a bunch of companies when starting Chromatic. Zoltan Olah: And when I asked that question, folks would kind of squirm uncomfortably in their seat. "Oh, well, we don't really have tests for the UI." It's like, "Well, how you doing CI CD? And it's more squirming. And then it's like, "Oh, we just kind of manually go in and make sure that everything's fine." And it's like, "Okay, well, that's not an automated testing strategy," but I get it. It's hard. Like when we have tools like selenium and there's brittle end to end tests like yeah, UI testing has always been hard. So that was the big sort of problem that we set out to solve with Chromatic and we just saw a lot of value in it. Eric Anderson: And then what's the relationship between Storybook and Chromatic? Do you kind of use Storybook as you're using chromatic? There's a dependency on one or the other? Zoltan Olah: Yeah, exactly. So when you're using Storybook and you're using it during development, you're also at the same time building an artifact. It's kind of a little bit meta, but Storybook is both a tool and it is both a build-out of fact. So when you build Storybook, you get a little single page app that contains all of your components and the navigator and the ad-ons and whatever that you've installed. And a lot of folks use that to document their design system and host it on Netlify. So Chromatic basically takes that artifact and then sort of adds a whole bunch of additional collaborative functionality on top of it, including UI testing. UI review is another piece of functionality that adds... It's also a CDN based hosting provider for Storybook, but the fundamental kind of thing driving all of this is the concept of a story, which is the data and the component that the data is for married together. And it's essentially a test case at the end of the day for a very specific state that a component can be in. Eric Anderson: Yeah. So you use this story to prototype and build. I mean, you need something to show that the component is working, so you're using it to develop. And then you're saying, once you're done, that becomes your kind of first test case, except for testing the component. And then you can add other iterations. Zoltan Olah: Exactly, your subsequent test cases as well. And so it serves double duty as a development aid, right? Because you don't need to run your local application. It's real fast to get to the area that you want to develop. It serves as documentation because once you've written these essentially to visual test cases than any other developer, including you, comes along in the future, can just cycle through these test cases when you're adding more functionality. And then finally the test cases serve as input into a visual regression testing tooling or UI review tooling. And you get all of that essentially for free. You don't have to do any additional work to maintain your test suite or your documentation. Everything's always up to date and it's sitting there as part of your CI CD pipeline as well, protecting you from shipping broken code to your customers. Eric Anderson: Yeah. This UI testing kind of whole is fascinating. You're right. So there's selenium. And maybe, I don't know if Cypress helps you here, but other frameworks. But most of the time I hear people relying on QA or just kind of manual probing of the [inaudible 00:12:35] or waiting for bugs to come in from users. We test APIs pretty thoroughly. Zoltan Olah: What we're saying is components are sort of like APIs at the visual level, and your application is essentially in our worldview, like if you think of the microservices architecture built around Rex, we have a similar view on UI and it's components of the Rex and the way they integrate together into an app or the micro services part. Eric Anderson: And Storybook captures all the states I would expect from my component. Got it. Zoltan Olah: Exactly. So Storybook is sort of like the Service Mesh in that like weird analogy, even though Service Mesh is kind of a confusing concept in and of itself. Eric Anderson: Yes. We had our listeners right up until, [crosstalk 00:13:21] so, and then help me understand who's using Storybook and designers, developers. I don't know if QA is still a persona we talk about anymore. We've kind of moved on I suppose, but certainly developers are using Storybook and designers as well, right? Zoltan Olah: Yeah, that's right. I mean these days the entire product team is using it and developers use it primarily and they're sort of building the work product in Storybook. They're building the stories and using it to build their components and then Storybook, the artifact becomes shared throughout the team. So designers look at it, product managers look at it. Any anyone else, a stakeholder in the development process ends up looking at the components in Storybook and then collaborating on them via UI review, for instance, or testing, or just literally just sharing a link around to a statically uploaded version of that story book. And it's a really fast way for everyone on the team to kind of be up to date on what's being developed. There's often a lag between engineering and design product, even marketing in terms of what's actually shipping and what's being worked on and this way everyone can get into the loop through Storybook, Eric Anderson: You mentioned they become documentation. You can publish this whole library of your components and in their various states and that's the documentation? Zoltan Olah: That's right. Yeah. But on top of that, Storybook has additional add on functionality that lets you build more documentation around the components. So the components and their states form the core parts of the documentation. And then we have things like controls add on that lets you kind of tweak the inputs yourself and that can form part of the documentation page. And then you can add additional custom documentation around your components and build a whole sort of site for your design system documentation, which is what a lot of teams are using Storybook for. Eric Anderson: Yeah. The advent of design systems, going back to an earlier discussion around people buying a component suite, most people are building custom components, I imagine for their applications rather than relying on an existing library. Is that fair? Zoltan Olah: Yeah. Most people, although that's not always the case. I mean we have component lab like material UI, which are really, really popular and they're almost sort of the bootstrap of the component driven sort of age. Which still a lot of developers very legitimately start their projects with. Eric Anderson: And as projects mature, you bring on designers- Zoltan Olah: Exactly. Eric Anderson: There's greater appetite to build custom component. Zoltan Olah: Exactly, exactly. And what we've noticed actually is that for larger companies, their brand is very deeply embedded inside their design system and their design system ends up being a source of pride that they maintain. They share. A lot of them are open source. You can throw a stone at a company here in the Valley and probably open source their design system and you can go and check it out. And I think a part of it is just pride and it helps with recruiting, but it's also a great way to spread the love in the world of components, so. Eric Anderson: I'm just thinking about how it changes the roles of designers and developers some. Designers used to design whole pages and now they're designing components and it's maybe a new thing or not. Zoltan Olah: Yeah. I think the design, I don't know the field of design... I can't find the word I'm looking for, has really embraced design systems as a way to design more like the way engineers build software because designs are repetitive. Right? So if you're in the old world where designers are building entire pages and shipping off the PSD to their developers, they're still using components even, and kind of design systems thinking, even if they're not really thinking about it that way, because they're trying to keep a consistent brand throughout every page that they design and the way they do that is by reusing elements on the page. And if they're using elements, then hey, we have an implicit design system. Even if we don't call it that. So the design systems movement is just a formalization of a paradigm that was already happening in design, but now we have a word for it and people evangelize it but it's a very natural way to design. Eric Anderson: And then developers who used to just receive PSDs and then build the spec, now maybe have more opportunity to express some ideas because they've got Storybook, right. They're creating them for them. Zoltan Olah: Totally, totally. And now that there is this shared language in the form of a design system and then a whole bunch of components that implement that design system, when developers get what is effectively at PSD, even in the world of today, which is a designed page, there's a link where now that page has the components that it uses very strongly spelled out, right? Like inside the Figma or whatever tool you're using. It's like, "Oh, is this component X." "X, this is the menu component." And so developers are just able to assemble pages from those components and designers are already thinking that way. So they're not going to throw a developer a curve ball where it's like, "Oh wait, what is this? This is kind of like that component, but it's a weird variant that like is only used on this one page. Like what's going on that?" Still happens, but it doesn't happen by accident. Zoltan Olah: It's very intentional because designers are like saving themselves time too by reusing components. Right. Whereas previously that kind of thing used to happen just sort of accidentally because there wasn't a design system. And so a designer might not have gone reaching for that component that they've used before. Eric Anderson: Now. Yeah. So there's two motions of a design now. They have this centralized design component effort. And then they have the applying those to a single case. And that latter part can be done in many times by developers. They can kind of get direction on a page and assemble given the standard components to a degree. Zoltan Olah: Exactly. Exactly. Eric Anderson: How long have you been maintaining Storybook and what were the kind of steps to bring that together? You kind of maintain the community, the code base. Any questions on licensing or governance? Zoltan Olah: Yeah, it's been very organic. So circa 2017 that's when we got really heavily involved in Storybook and Bay. We, I mostly mean my co-founders Tom and Dominick, I don't code much anymore. I am an engineer by trade, but these days I'm in product and CEO of Chromatic. Unfortunately I don't have anywhere near as much time as that. I'd love to have coding. So those guys got deeply involved in the project. And then there are a few other people that were very heavily involved in it as well who, in some cases like with Michael [Showman 00:19:53] we knew already and we were friends with. In other cases like Norbert Delaney, we kind of met through the Storybook project, but there ended up being kind of a core group of maintainers, including Tom and Dominic who were working on the project. Next to that, we were working on building the company and building out a UI testing tool kind of on top of it. Zoltan Olah: And we started to think about raising some venture to keep this thing going and Chromatic was already sort of starting to take off. We built an MVP, we had some customers and we started to realize that we had the opportunity to make a real impact on the world through front end engineering and by building just tooling around this burgeoning component based view layer infrastructure that was coming on. And then we also were deeply passionate about Storybook and about driving Storybook forward and working in open source. We've worked in open source for a big part of our career and so that's when we got this idea of like, you know what, maybe we'll raise some venture capital and we'll be able to pay a bunch of our friends that are also working in this project, being namely a sort of [Macklin Norbert 00:00:21:01]. Zoltan Olah: So it was this sort of jigsaw puzzle in a moment in time where it was like, "So would you guys quit your day jobs and work on Storybook full-time if we had the money to be able to make that happen because we'd love to do that." And they were like, "Yeah, yeah, that'd be really cool but also scary at the same time." And on the investor side, it was like, "Look, this is what we want to do. We want to support the open source project and we want to build a company on top of it. Like, what do you think?" And then manage to bring it all together, raise our seed round, get Norbert and Michael on board and that's essentially the sort of start of Chromatic supporting Storybook, the open source project. Zoltan Olah: And the way that we see it is really supporting environment via manpower. We're desperate to keep it a community, an authentic community driven effort. So we're very, very hands off with it. We're just showing up literally with developer hours and building what's dear to us. And that's the beautiful thing about open source is, everyone gets to scratch their own itch to build the thing that is important to them. And whether you have two hours every second night to work on it, or a weekend every month or three people's worth of full-time effort, it's still the same thing. It's just you have different amounts of time to spend on the project. And that's the way that we see ourselves being involved. Eric Anderson: Great. Just because we like talking about open source and you mentioned earlier that these design systems are increasingly kind of behaving like open source there's company open source and there're designs, what exactly does that mean? I've certainly seen the kind of visual descriptions of the design systems, but they're also publishing code. Zoltan Olah: That's right. Yeah. Eric Anderson: Yeah. Do you have the same kind of community development? I mean, I guess you wouldn't want to extend and change Airbnb's design system because that's theirs, but you could probably fork it or what's happening in the world of open source design systems? Zoltan Olah: That's a really good question and something that... I don't have a great feel for how many teams actually like [inaudible 00:23:12] say Airbnb, or, Workday's design system and then sort of build a tool on top of that. I don't really see that very much happening out in the open. I think the real power of it is basically with these companies where they have an API and they have components are built around that shape of data that their APIs already provide. Their components give sort of their integrators and folks developing on top of their platform, some UI as well to go along with their API. Then I have to build UI. So everything ends up being on brand. The experiences that they build around the product that these companies have ends up feeling like a natural extension of the product and that's just for certain companies that offer something like that. Zoltan Olah: Workday is an example that popped into my head. And then you have other companies, maybe Airbnb is an example of this where I think they're just excited to participate in the open source community because it lets them sort of hire better developers and developers have a natural inclination to want to build code in the open and to have other folks use their code and make it better that way, find bugs and extend it and one of the properties of the design system is that there's not a lot of proprietary sort of business secrets in a design system. So it's not like you're giving your competitors an edge. In fact if your competitors took your design system and [crosstalk 00:24:41] build their. Eric Anderson: [crosstalk 00:24:43] in it, they're like helping you, they're spreading your brand. Zoltan Olah: So I think design systems lend themselves to being open-sourced in this way, whether they're really used or not. It still makes a lot of sense for companies to do it. Eric Anderson: Yeah, no, certainly. I mean, I could just poke around through Airbnb site and I experience the whole system. So it makes sense that there's nothing [crosstalk 00:25:06] Totally. Yeah. Zoltan Olah: Yeah. Eric Anderson: Great. And where does Storybook go from here? Any thoughts on what '21 or even beyond? Are there big features or vision to watch out for? Zoltan Olah: Yeah, so we've always built and by we, I mean our little team Percolate Studio, Chromatic sort of. For the longest time we've built entire pages as components. So from the lower level sort of route sort of leaf node components that are pure components like menus and buttons and all the way up to the page level, we thought of everything as a component, right? And so everything has clean APIs. It's all well-defined and everything can be marked out along the way. And the companies that are like the furthest along in the component driven journey are also building this way. And the benefits are basically being able to decompose your app and share those states just the same way that you would in the design system, share those states with the rest of the team, document those states, to be able to jump straight in and start extending these sort of complex pages or sub pages that in and of itself contain a lot of very significant states that end up being kind of thrown away if you're developing the internet in an ad hoc way. Zoltan Olah: So our vision is to teach and to extend the tooling in order to make this way of development spread and to bring it to more people because it really helped us in building apps faster and building better apps and we want to do the same for the world. Eric Anderson: Fantastic. Anything you would tell our listeners, if folks have kind of peaked their interest and want to get involved, are there places to go or things to do? Zoltan Olah: Yeah. Storybook.js.org, learnStorybook.com. That's a resource that guides you through building an entire application on top of Storybook. They're the best places to get started. And yeah, there's no reason not to get started. You can install Storybook and it should integrate into your code base with one NPM command and then you're you're off and running. Eric Anderson: Classic. Zoltan, thanks for coming on the show today. Zoltan Olah: Yeah, absolutely. My pleasure. Eric Anderson: You can find today's show notes and past episodes at contributor.fyi. Until next time, I'm Eric Anderson and this has been Contributor.