Brian: PodRocket is sponsored by LogRocket, a frontend monitoring and product analytics solution, which is to say it's not really sponsored by anyone. It's sponsored by us, LogRocket, and we're giving it away for free. The podcast is free. The product is not free. There's a free trial. We could split hairs about whether or not that's free to you, but anyway, that's it. There are no more ads. If you're interested and you want us to know that you came from the podcast, please go to logrocket.com/podrocket. If you don't care, logrocket.com works just fine. Thanks. Brian: Welcome to PodRocket, the LogRocket podcast. I'm Brian, director of content at LogRocket. And today, our co-founder, Ben Edelstein, interviews, Zoltan Olah, CEO and founder of Chromatic, which maintains Storybook. Ben and Zoltan discuss frontend testing, the philosophy of component-driven development, and obviously Storybook. I'm really excited about this episode, so let's jump right in. Ben Edelstein: So, now, I'm really excited to introduce Zoltan Olah. He's the CEO and co-founder of Chromatic. How are you today, Zoltan? Zoltan Olah: I'm great. How are you, Ben? Ben Edelstein: I'm doing pretty well. Really excited to have you here and be on episode two of our podcast, so thanks for bearing with us as we had our bit of technical difficulties before this. But I want to jump right in. And I think probably the project that most people know best of yours is the Storybook project, and so maybe you could give us a quick introduction. What is Storybook, and how does it help developers build better web applications? Zoltan Olah: Sure. Yeah, I'd love to. Storybook is a component explorer or an isolated component development environment, and it's an open-source project that teams install into their code base. And it reaches into the code base and pulls components out and puts them in an ID of sorts where developers can work on them in isolation. Storybook gets its name from the idea of stories, which are essentially test cases for components. They're pure JavaScript objects and they're data that feed into components, and it forms the basis for this idea of component-driven development and building components in isolation, outside of the main application that they're used in. And so, teams these days are building all sorts of things in Storybook, from design systems to component libraries and component packages, all the way to entire apps. Ben Edelstein: I'm curious, you mentioned that it's a development environment for components, so is it something that's only usable for pure components? Or can you have components that depend on outside data or have any kind of logic besides just display logic? Zoltan Olah: Yeah. It's best used for pure components, but there are ways that you can mock those external data sources that are a little bit more complicated. So, you can use it that way, as well, but primarily, people use it with pure components. And that aligns with the development process and philosophy that Storybook has been built around. Ben Edelstein: And how do you write these stories? You mentioned that they're objects, so tell me a bit more about if I have an existing set of components and I want to get started with Storybook, how do I encode the logic that displays the components within the development environment? Zoltan Olah: Yeah. So, Storybook has a little format, and basically, you just take a component, render a version of it with some data and pure JavaScript. So, it's essentially instantiating a version of your component with that pure data. Ben Edelstein: I see. So, basically, I'm writing, more or less, React JSX and instantiating the components in the same way I would use them within my application? Zoltan Olah: That's right. Ben Edelstein: But they're just displayed within the Storybook UI? Zoltan Olah: That's right. Ben Edelstein: I'm curious, you said something that I thought was interesting, you said the philosophy of component-driven development, and there was a blog post that I read by your co-founder Tom about this concept of component-driven development. So, could you explain this concept and explain what does it mean for teams looking to improve the collaboration between design engineering and product? Zoltan Olah: Yeah. So, UI development is special for a number of reasons, but from a technical perspective, the reason I'd say special is because it's really messy. You're dealing with output that's really difficult to validate without a human being looking at it, and you're also dealing with user input that can be unpredictable and messy. And so, that's where this distinction between pure components and impure components really helps. And with the philosophy of component-driven development, it is really built around the idea of isolating all of this messy UI-based stuff into the pure component layer. And then below that is really just plain, old software engineering. You're dealing with inputs, transforms, outputs that are easily mocked, easily tested. It's all pretty standard stuff. Zoltan Olah: So, then, when you focus into this world of pure components, and if you're able to separate out your UI concerns that way, then you start to be able to build components by themselves outside of any other harnesses outside of your main application. And then what that means is you can paralyze the entire UI development process and have different teams and different people responsible for building different parts of the UI, potentially at completely different times, and then piecing it all together at the end into full application pages or complex workflows. So, it's a process that takes the messy and entangled UI development workflow that used to exist with jQuery and rendering entire pages on the server and then connecting jQuery to it later, and it turns it into more of a process that's analogous to, say, the way that auto manufacturers build cars out of assemblies and sub-assemblies. And they're built in different countries, and then they all just plug together seamlessly. Ben Edelstein: And how does that fit into the workflow? I know a lot of teams, they do their prototyping in a tool like Sketch or Figma, and they build fairly robust prototypes of components before then having developers turn those into code, so does Storybook fit into that workflow? Or do you have any maybe future plans down the line to better integrate Storybook into that component building workflow? Zoltan Olah: Yeah. I mean, it really depends how teams do it. A popular way of doing prototyping is with a tool like InVision where you're essentially stitching together designs that are flat image files, and then you can get more and more sophisticated. And yes, you can prototype in Storybook. The great thing about doing it that way is you're able to use actual production components and pull them out of your real life application and build up prototypes that way. I'd say it can be a little bit more work doing it that way. There's two ends of a spectrum. Right? On the one end, you have essentially designers building prototypes out of images, and then on the other hand, you have full on software engineers building prototypes out of existing components. And then in the middle somewhere are these tools like Framer, they're starting to emerge, where it's kind of React code but not really production React code, but somewhere in-between. Ben Edelstein: Got it. And now, I want to talk about Chromatic. This is the company you founded, and you guys are the stewards of this Storybook project, but also building an additional set of tools for frontend developers. So, what are you working on now, and how does it relate to Storybook? And then I'll ask in a bit where things are going and what you're going to build in the future. But maybe, first, we could talk about Chromatic. Zoltan Olah: Yeah. So, Chromatic started initially out of our pain around UI testing, and I mentioned this earlier in our conversation, UI is traditionally difficult to test. The tools are brittle, they're hard to maintain. And so, we saw a real opportunity to plug Storybook into an automated cloud-based framework for taking screenshots and comparing them between changes, and being able to really zero in and make humans efficient at bringing what they do best when it comes to UI testing into the process and just minimizing the time that folks need to spend doing that. So, that's why we started Chromatic. That was the first version of it, and that was also the company that we built. And it's a cloud-based service, and funds from Chromatic feed directly into Storybook open-source development. Zoltan Olah: And just to quickly give you a little bit more history, as customers started signing up to Chromatic and we learned more and more about what folks do and their development workflows, we realized that there is also a UI review process that teams do. Our designers and product people come into the development process, usually later on in the process, and give their stamp of approval. And it's less about testing, it's less about identifying things that have broken and more about identifying things that aren't right, as per the spec or the design. And then, Chromatic also evolved into an hosting platform of sorts for Storybook and the components that are contained within it. Ben Edelstein: So, if I'm using Storybook and I've all ready... I have my component catalog in Storybook, I have stories written for my components, how do I get started with Chromatic and what will it do for me out of the box if I'm all ready a Storybook user? Zoltan Olah: Yeah. It's a really simple installation. It's one command that you include in CI or GitHub Action now that you run. That basically builds your Storybook, uploads it to a Chromatic platform, and kicks off any tests or UI review that you have configured. And it basically turns the single player experience of Storybook, running on your local machine into a collaborative multiplayer experience in the cloud where you can share links to folks who aren't even developers and get them into the process. Ben Edelstein: And if I'm understanding correctly, Chromatic helps with the testing of my components and helps with detecting unexpected regressions. Zoltan Olah: Yeah. Ben Edelstein: One question, you mentioned the word brittle before, and that's something that I always associate with functional testing, so I'm curious, how are you thinking about that problem of front-end tests historically being prone to breaking when they're not supposed to break? Zoltan Olah: The great thing about doing UI testing in Chromatic, well, firstly, the testing is really granular. Right? Because we have testing at the component level. We're able to isolate most of everything else and really just zero in on testing the component. And secondly, because the inputs to the component are really tightly controlled, they're very strongly mocked out, they're not changing, they're not random, but they're not changing very much. And so, that gives us an environment where we can really have a very strong reproducibility between test runs and we can eliminate a lot of that flakiness that comes from other forms of testing when you're testing the UI. Which there's a complicated stack running underneath the UI, there's the browser, there's the network layer, there are services that provide the application logic, and so we're able to eliminate most of the sources of flake and have tests that aren't very brittle. Ben Edelstein: In this space, LogRocket is based in Boston, and so we hear a lot about the work that the folks that mabl are doing. There's a few other companies I've seen in this space, like there's one called Testim, and so I'm curious if you're familiar with these products. How does the approach you guys are taking differ, compare and contrast, from some of those tools? Correct me if I'm wrong, but I think you guys are taking a bit more granular approach and working at the component level, versus building a generalized solution. So, what are the pros and cons of that approach? Zoltan Olah: Yeah, that's exactly right. The tools that you mentioned are primarily focused on end-to-end black box testing components and functional testing components. And those kinds of tests are valuable and important in the development process, but they're also the most expensive to maintain. They break often because someone changes the login flow for instance, and now all your tests break because the end-to-end tests can no longer log in properly. And that's just a very contrived example, but there's a lot of interconnectedness and moving parts. Zoltan Olah: And so, where we differ is going back to our previous conversation about brittleness is we zero in directly on the components, we eliminate most of the dependencies, and we're able to focus on that. And then, secondly, I'd say that our tests run really, really quickly. End-to-end tests are very slow. They simulate a user clicking around, whereas because we're testing at the component level, we're able to paralyze your entire test suite, essentially, and run it, usually, within less than a minute, no matter how big your code base is. Zoltan Olah: And then, finally, I'd say that we can also zero in on very specific changes very easily. So, your components are usually described by way of stories, which are these test cases that are very specific, and they'll say something like, "The user profile page with an avatar included and a missing first name," for instance, or whatever. That might be a test. And so, if something goes wrong, we can tell the developer, "Oh, something's gone wrong exactly in this spot." You don't have to dig through the end-to-end test run, watch videos of it, figure out exactly what led to the issue that you're finally being told about because, in Chromatic, you find out very, very quickly exactly what occurred. Ben Edelstein: So, going back for a moment to the idea of component-driven development, I've used Storybook quite a bit in the past and I am a big fan, and one of the sticking points that I've experienced on teams where we've used Storybook is that CSS is a leaky abstraction. And so, you have styling for individual components, but often, if you're not careful, a component and the way that it looks within a application is not a reflection of just the styling of that component. It's due to the cascading nature of CSS, it's being effected by the CSS or around it, so to speak. So, what do you see as the future of styling for components and component-driven development, and then maybe in a broader sense, what is the future of styling in front-end applications? Zoltan Olah: Yeah. I'd say developers have been moving away more and more from CSS because of that leaky obstruction problem, and moving towards more CSS-in-JS techniques. Where rather than providing global style sheet, styles are targeted directly at the component level, and also imported and use more like a software library might be, rather than this big global mess. And I'd say that's very much in line with the future of CSS in web components. CSS is part of the shadow DOM, so it's isolated in that sense, and so that's definitely the way that I think CSS is going. Ben Edelstein: Got it. And when you say shadow DOM, are you referring to the web components idea of shadow DOM and using that encapsulation? Zoltan Olah: That's right. Yeah. Ben Edelstein: Got it. And so, I'm not super familiar with where web components are today, so maybe could you give a bit of primer for folks like me who are not in the know there? Zoltan Olah: Yeah. There's some controversy developing around web components because they've been pushed for a little while as the next generation solution to UI, APIs in the browser. And folks are now starting to realize that those APIs are maybe a little bit less polished than ideal, a little bit clunkier than ideal, and so this idea of web components as the future keeps getting delayed more and more. It's almost like cold fusion, in some ways. But we hold that hope that this idea of having a more unified approach to building components is where we are going, and that's where web components hopes to end up. Because I think it's not great that we're all building components in Vue or Angular or React, or what have you, and we can't easily share those components. And that's somewhere, actually, where we'd like to make a strong impact at Chromatic because we really do want to open up that level of collaboration between all UI developers, no matter what their preference for component syntax is. Ben Edelstein: So, you've built a really great thriving open-source community around Storybook. And I know you previously worked at Meteor, which was another company that I think did open-source community really well, so maybe you could talk a bit about your approach to community building around open-source repos. Zoltan Olah: I've watched open-source develop over decades now, and it's really shifted, I would say, in terms of where it began. It was more small groups of really highly experienced engineers building software together, often foundational software, to whereas now it's gone... I would say it's gone mainstream. There are a lot of people participating in the open-source community, and a lot of them are fairly new developers. And open-sources become, essentially, the bedrock for building software on the internet. So, that's been an interesting evolution to watch. And I'd say one of the key takeaways for me from the Meteor days was having a much more hands-off approach to open-source as a company, Meteor was very much built in-house and then given to the world. Zoltan Olah: And then later on, before I joined, but certainly after I joined, we made a lot of effort to try and reverse that and make it more of a community-led effort. So, I'd say that's definitely something that I've learned and where we differ. If you look at the Storybook project, we're very hands-off and very light as Chromatic, even though we do find a lot of the development, but we try to make sure that the community guides the direction and feels like it's there, which it really is. Ben Edelstein: Sometimes I imagine the desires of the community might slightly diverge from your vision for... Maybe you have a five-year vision for Storybook, but community may just need certain things now. How do you balance when short-term community interests are not fully aligned with the long-term goals of you and the vision that your team has for the project? Zoltan Olah: I'd say Storybook is very much a foundational layer, and it has an add-on API, and we try to keep most of the work inside add-ons on that side of the API. So, it's actually not something that we've really come across very much so far. The great thing about source is folks come along and they scratch their own itch, and more often than not, that itch is a very strong product signal that like, "Hey, this is important. This is somewhere where you should be spending effort." And so, we use open-source, I'd say, in that way as well, as just let that guide our development and our roadmap. So, we don't have necessarily a five-year strong arm roadmap for Storybook, we let the community, in a big part, guide it, but then where bits of the project become opinionated, we try to make sure that that's inside add-ons. Ben Edelstein: So, you started this company, and Chrome was a commercial entity and you're the stewards of the Storybook project, but then there are thousands of people throughout the world who contribute and I assume are not affiliated with your company. So, how do you build trust within the community? There's been many examples in the past of Microsoft or other type companies that have become involved with open-source projects and the outcome has not been great for the community. So, I know there's sometimes distrust among open-source contributors when there's a commercial entity also involves that's funding part of the development. So, how do you think about building that trust and being transparent with the community members? Zoltan Olah: We've made a really big effort to make sure that Chromatic doesn't have an unfair advantage in terms of companies that are building on top of the platform, so that's something that we've done. And we've also tried very hard to make Chromatic a very separate entity. Right? So, Chromatic the company, Chromatic for commercial service, versus Storybook, the open-source project. Even the name is completely different. And that's something that we consider all the time when we're making product decisions or marketing decisions, is like keeping that separation really strong, because we do think, fundamentally, that it's important for Storybook to remain a community-led project and not to be strong armed by a corporate interest. Zoltan Olah: The fascinating thing about open-source is that people spend time and money scratching their own itch and building what they need, and then releasing it to everyone else. And in some ways, as a corporate steward of the project, we're really no different. We're just an entity that has a lot more hours to put into the project than anyone else. And so, that also guides the way that we see ourselves, rather than a contributor that maybe has 10 hours a week to spend on it, we might have 100, and so, naturally, our effort is going to be greater because we're spending more time on it. But other than that, we hope to create a completely level playing field. Ben Edelstein: And for Chromatics specifically, tell me a bit about your business model and you know, how your thinking around the continued growth of the company. Zoltan Olah: Yeah. So, we're first and foremost excited about component-driven development and components, and more broadly speaking, UI development. We see UI as being the shared language between customers, between companies or stakeholders. It's how everyone interacts with software now. And by shared language, I mean customers will say things like, "When I click my profile and I try and change this, it doesn't work." So, they use it to describe what they're doing in an application, and likewise, companies use UI to explain how to use their products. It's this shared language. And to us, that's tremendously exciting, and that's the space that we're very interested in shaping and innovating. Zoltan Olah: And so, to bring that back to our products, Chromatic is a cloud-based multiplayer environment for component development, and we believe components are fundamental to UI development. And so, we're looking at workflows that make component development better. Right? So, testing is a really important one that we've built so far, review I've talked about that, sharing and discovery of components is something that we're working on. There's all ready a little bit of that in the platform, but we really just started looking at it. And then, anything that makes shipping components more efficient is what we're working on in Chromatic Land. And in Storybook Land, it's mostly all about developing and building components. So, that's also the way we think about where to focus our efforts and where features will land. Ben Edelstein: And more broadly, what are you most excited about over the next few years in the world of front-end development? Zoltan Olah: I think I am really, really excited about, and we touched on this earlier, the idea of more unification between view layers. Right? And more sharing of components. I think reinventing the work in your own view layer, it doesn't make sense, and it goes completely against the idea of open-source, which is, "Hey, don't reinvent work, share instead." So, the thing I'm most excited about is being part of the movement that creates that unity and that layer of sharing on the UI level. And I'd say that frameworks like React and Vue have been the biggest step in the last few years, moving towards that idea of sharing more UI code. Ben Edelstein: And if you could wave a magic wand towards that problem of unifying the view layers or making components more shareable, would everyone in the world just settle on React and call it a day, or would web components help encapsulate components so that people could write in their view layer of choice and bring in components that are written within a web component in another view layer? What does that perfect world look like to you? Zoltan Olah: Yeah. It's definitely the latter, so where web components becomes more of a compile target of sorts for the view layer of your choice. So, we all have different preferences, we prefer different syntax and different philosophies, but ultimately, once we're done building our components according to those preferences, I really do believe that they should be compiled down to a very minimal set of primitives that are then shareable and plug and play no matter what people's preferences for building them are. Ben Edelstein: With that kind of encapsulation and, to some extent, duplication of things like styles or even view layer, JavaScript code, are there negative consequences for performance and bundle sizes and things like that, or is there a world in which we can have the best possible developer experience and also lightweight, fast JavaScript apps? Zoltan Olah: I think that there is, and that's the world that we're trying to build. If you were trying to do this today and share components between Angular or React, for instance, it is possible, it is technically possible to do that, but you're still going to have to load the Angular framework and the React framework and possibly quite a few other dependencies. And so, that's where we're at today, where that's an issue, but in the future with this compile target, web components model, we might be able to get away from that. I'm certainly hoping that we can. Ben Edelstein: As am I. And I'm curious to learn a bit about your background before you started Chroma and were involved with Storybook, I know you were an engineer for much of your career, and then most recently, you were at Meteor. Right? And I'm really curious, your title at Meteor was customer success, so I'm curious, what did that look like at Meteor? And how did your background as an engineer help you in the customer success side of the Meteor team? Zoltan Olah: So, throughout my career, I would say in the last decade, I began to drift towards business, customer focus, sales focus, product focus, away from engineering. And as part of that, my two current co-founders, Tom and Dominic, and I started a web development consultancy and agency called Percolate Studio. And still doing a lot of development back then, but I was also the client-facing person, and so I would try and bring in new business and get contracts signed and work with our clients that way. Meteor ended up acquiring our agency, which is how we joined them, and so the first role I landed at in Meteor was also a customer-facing role in terms of building out their support and customer success group. And so, that's why I was a Director of Customer Success there. That was based on that background. Ben Edelstein: And what were a couple of learnings you took from that role in Meteor that have been helpful as you've built Chromatic? Zoltan Olah: Yeah. I would say obsess over the customer. I heard a quote from Jeff Bezos recently, which is something along the lines of, "At Amazon, we're scared, not of our competitors, but of our customers." And that we've all heard about how Amazon is such a customer-obsessed company, and I really fully have adopted that mindset myself as well. And I'd say that running customer success at Meteor was also very pivotal in feeding into that mindset. I think if we all listened to our customers more, we just build better software. Ben Edelstein: Cool. Well, thanks so much for joining us, Zoltan. I really enjoyed the conversation. Zoltan Olah: Thanks for having me, Ben. And good luck with the podcast. Ben Edelstein: Thanks. Brian: Hey, it's Brian again. So, it turns out that running a podcast is maybe harder than we thought, and so I want to hear from you. I'm genuinely interested in your feedback. We have to think about new topics, new guests. We have to find them. And don't get me wrong, we can do it, but it's a lot easier if everyone else who's listening helps. So, if you'd like to suggest a topic or volunteer to be on PodRocket, we'd like to hear from you. Brian: So, you can do that by going to podrocket.logrocket.com/contact-us. The hyphen is next to the delete key, if you're curious. If all of that is too long, you can just email me directly brian@logrocket.com. That'd be great. Also, if you're feeling magnanimous, be sure to like and subscribe to PodRocket. Thank you.