Andrew: Hello. Welcome to the devtools.fm podcast. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my co-host Justin.
Open Source Beginnings [00:00:30]
Today, we're going to be talking to two people involved with storybook, a development tool that is radically changed the way components are developed. Would you guys like to introduce yourselves?
Dom: Yeah. Thanks Andrew. Hi, my name is Dominic. I'm a co-founder of chromatic, the company behind storybook and I work on storybook design.
Norbert: Hi. my name is Norberto de Langen. I live in the Netherlands and I am one of the maintainers of storybook.
Andrew: So where did both of you start your career? How did you end up working on an open-source project like this.
Dom: yeah, for me, I've started working on open-source a couple of years ago, maybe seven years ago starting with, meteor the first full stack JavaScript framework. It's still around, it's popularity is tapered off. But while there, we were thinking about hot module, reloading, optimistic UIs. The kind of stuff that you end up seeing in the ecosystem now, and then I moved on to Apollo graph QL, where we built the graph QL client libraries and was a part of launching that product.
And really what drove me to it is just the kind of freedom and chaos that is in open-source. And in that chaos it's this mineral rich Nebula of ideas that stars are born out of. Storybook is as one of those cool ideas, something that we love and blew our minds when we first landed on building components in isolation.
Norbert: Yeah. So for me it's been it's been about as long, I think maybe yeah, just about as long, I guess. I started thinking about open-source more and more ever since I started using it, started using NPM way back when, and I always had like this idea of I want to contribute, I want to contribute, but it's really hard to get into what exactly.
And like which project, like there was so many and so much was going on that it's hard to get into. So way I got into storybook was because I used it and it was building a little bit of an add on for it regarding testing. And I learned that storybook was unmaintained and I wanted to contribute. So one plus one to me equals two.
And so I just posted on GitHub like, "Hey, if you're looking for a new maintainer, I'm willing to do it." Really just hoping that other people would do that as well. It turns out that yeah, they were looking for a new maintainer and the next morning I was greeted by an email stating that I was the new administrator on storybooks organization.
So yeah, I just started. Trying to organize as many people as I could to get storybook going again. And I guess you have, the rest is history.
Justin: It's really funny how many open-source stories start that way. I was really interested in this project and they, it just was no longer maintained and needed someone to contribute. And now I'm like helping run the show. This is a very similar story for me is just like working on a thing for work and it was open-source and then the maintainers weren't responding and it's like, I really just wanted to get some changes.
I was like, just, just let me just please just give it to me. I'll take care of it.
Dom: Yeah, it's one of the tough parts too, right.
Andrew: I actually got a similar start of my first open-source project that I started help maintaining was jimp. And literally there was just an open call for people to maintain it. And I was like, I guess I can do it, but I did not know the amount of stress in like issues. It would, it would cause me.
Dom: Once you know how the sausage is made it's really tough to get into volunteering that time. And oftentimes, like for me, I came from just not knowing how the sausage is made and kind of jumping in to the deep end . But I could see why it's like tough for people to like, make that time in their lives. And especially when open-source can take over more and more of your free time and work time.
Andrew: Yeah, I've definitely been experiencing that. Now. I recently left Intuit and I now work at a startup and like the amount of energy I have after work to do open-source things is crazy different than when I was working at Intuit where I could say, "oh, Fridays, I'll just work on open-source."
And uh, none of that anymore.
Justin: Yeah.
Dom: We use some of your tools, Andrew, we use auto and we use react TypeScript doc gen. So, absolutely. Thank you. Big shout out to you.
Andrew: Yeah, that's definitely my biggest package. I go look at the downloads sometimes and I'm like, "oh my God."
Like, I literally I got the idea for that plugin out of a GitHub issue. And I was like, yeah, that sounds like it would work. And then eventually got integrated into storybook. Okay.
Yeah. When you guys mentioned a meteor, I always forget that you guys used to work on meteor. And then when you say that again, I get excited. It's like this weird, like tiny thread that connects me in a lot of developers. I know is that we all kind of started out as meteor was our first love in open-source front-end tooling.
Justin: Yeah.
Dom: And when you think about it, like a lot of the folks that used to work at meteor went on and did some cool stuff in the ecosystem. Storybook is one of them. So I think you met, you, might've met Tom. Michael came out of meteor. Even You from Vue came out of meteor. Apollo came out of meteor.
So some cool stuff in the JavaScript ecosystem.
Andrew: I didn't know that Vue, uh, that Evan You was from meteor also. That's crazy.
Dom: yeah, a long time ago. He was one of the first people I worked with
Justin: it was really ahead of its time. Like the things that it was really setting out, I felt like set the standard of what web tech would look like for the next several years. investing a little bit more personal time into learning elixir and Phoenix and playing around with LiveView and a bunch of WebSocket stuff.
And I always think back fondly to meteor and thinking about the uh, what was the data diffing protocol or the data payload pro protocol, like
Dom: DDP
Justin: or something that, that, yeah. Good times. So nostalgic
Andrew: Yeah, it's funny that those ideas are definitely coming back strongly right now with like blitz JS and Redwood JS full stack JavaScript out of the box is definitely something people are focusing on nowadays.
Dom: Yeah, it's one of those things, like at that time, it wasn't quite right because there was a bunch of like invention of new tools, like on every part of the stack. You had a view layer, you had a data layer, you had a backend which was like an abstraction on top of MongoDB or integration on top of MongoDB.
You had the isometric like stuff, which I'm not quite even sure what it means anymore. I've heard it so much. And even at like a package manager, right? All of that was bundled into one tool. And the challenge with being bundled in one tool and how new the ecosystem was, is like, there's still so much exploration that had yet to be done.
And as such, that exploration could only be done by like just people banging their heads against the wall. Like experimenting with routers, experimenting with view layers, experimenting with other parts and thereby innovating like way faster than one group of people can even possibly do.
Andrew: Yeah, I took him and totally forgot about that part. My first package I ever published was to atmosphere.
Justin: yeah, yeah,
Dom: Yeah. I designed that
Andrew: That's awesome.
Dom: and built that with the folks that work here, in fact, my co-founders!
Andrew: Oh, wow. Small world.
What is Storybook [00:07:36]
Justin: why don't we take a step back for a moment and talk a little bit more about storybook, especially for the people who might be tuning in who haven't used it, or aren't as familiar with it. Would one of you all like to describe storybook and sort of what the goal is with storybook?
Norbert: Yeah, sure. So storybook is a different tool to different people because it's pretty flexible. But in its core, it provides a workbench for working on components in complete isolation and the keyword for storybook, to me at least as a developer and engineer, is really isolation, and isolating one component from another.
We all know that writing components is good and writing isolated components. Like they should be self contained. We even write components sometimes with state and sometimes without state, like we try to even isolate that behavior out of an extract out of separate components. But a lot of developers, they don't really have a work bench for like how to actually engineer all of those components separately.
I see a lot of engineers just writing a page from top to bottom, top down. They start with the header, they create the logo and then the menu, and then, and they worked their way down and down and down and they created an entire page this way.
Storybook gives you in a way of breaking out of that. It gives you a way of going from bottom to the top. You start with your small components and you build up and at some point you're kind of done composing your components and you end up on the screen. That your product owner slash designer wanted you to create. You can't really do that in your entire app because you don't really have a place to do that.
Like you don't have a work bench. So once you have something like storybook, a work bench, you can create many more components in parallel. You can literally get more developers working on the same page. So that's one of the core concept of storybook in because you have this workbench you can catalog.
This is not a keyword for me for when I think about and talk about storybook, it creates a catalog of all of your components. One problem that I have faced all the time when I was consulting was all right. Can you please provide me with like, All of the possible states that this component can be in what are all of the variants that exist?
That way I know what I can create or what is missing because I just got a huge design document, but I don't know what exists to me. That is storybook. I can see one components and all of its possible variance. yeah, that also provide a place for if I need to create a new variant, I now know where to place it.
And to me that gives a lot of structure to my code and makes me write better components too. Because if I think about my components in isolation and how its API service should be and its interface should be then I start using it in the proper place. Whereas if you're writing a page top to bottom, It very often and it's feels very easy to do like, oh, I'll just pass along all of the data.
And you don't really think about what does this component need and how do, I create the proper composition?
Dom: and once you have your components and the edge cases mapped out as stories it doesn't take much squinting to see, "oh, these are your test cases for your test environment." Right. And so storybook also gives you the ability to do things like visual testing, AKA comparing screenshots to each other to find UI bugs, it does things like integrates with testing-library to help you, unit tests, those exact same components that you've already built.
And so on and so forth in the testing ecosystem. One thing that, that Norbert shined a light on me a couple of years ago was like, Hey, if you build stuff in storybook and this like component and story kind of model, you get a bunch of things for free. Things like testing, things like documentation, things like, accessibility, like heuristics, and then on top of that, all the add-ons that, folks are creating in the ecosystem. Integrations with Figma, integrations with Adobe XD, integrations with MSW, which is like a mock service worker library and so on and so forth. And so all of these things, like I've just come out of the box, if you write stories.
Story as a primitive [00:12:00]
Andrew: I like to call that like story as a primitive, once you have your story as a primitive, it unlocks all of those use cases. If you have your components, use-cases in that very defined structure. It's very easy to go. Well, that's a test case. That's a visual test case. That's a piece of documentation.
Dom: yeah the stories as a primitives, like, that's a cool thing because a couple of years ago, Michael Shilman and Tom Coleman and Norbert here, innovated on what stories are with, components story format, which is like this ES6, module based format that allows stories to be super portable.
So there's no like lock-in with storybook when you use it. You can use those stories with whatever other tool you end up using in your tech stack.
Norbert: That's not just like purely hypothetical, right? Because we actually see tools using components, story format. it's not just storybook that uses this other tools are using this as well.
Andrew: Yeah. Intuit built one. We have a test runner built on that format.
It's really cool to see you guys like shift storybooks API to that story as a primitive thing, because before with the stories of an ad, I, that was way different and so much more like overhead, like the new ES6 API is almost it's obvious once you did it, it's like, oh, like, oh, you can just export a function just like normal.
And now you have a component that you can use elsewhere.
Norbert: yeah, that kind of gives me a nice bridge because I think the next extension of component story format is args. You've probably already used it, Andrew Dom. I know you're familiar with it. I don't know about you, Justin.
It is short for arguments and you almost don't even, I need to write stories because for the most part, a story is a component combined with data.
And so what components story format allows you with args is you pretty much only really have to define your data. And then if you define your data this way, then storybook can also render a control for your data, which is amazing because not everyone is a developer and designers, particularly. And then I'm talking to you, Dom.
We both love it. You get to control your data right in storybook, and that allows you to experiment with it. And you can find those very, very weird edge cases like. You write stories to explore your edge cases, but there's always more edge cases. Like what happens if your button contains a really long text string or what happens if your list of items contains zero items?
These things you can now explore interactively in storybook as well. Something that we're really keen on exploring in the future is, well, what have you play around with those controls? And you can hit save, and it generates a new story for you.
Andrew: for our listeners who might not know what is a control and how is that expressed in storybook?
Dom: Yeah a control is a dynamically generated knob that allows you to adjust things. Data and state in your component, just by touching or like clicking on a UI. And that means you don't have to jump into the code to evaluate things like really long strings or different shapes of data.
I think the core thing for args is that if you take a step back and look at what a component is, right, a component is a function of props and state at the end of the day, AK data, and with our args now we have like a first-class concept in storybook that mirrors, what components actually under the hood. It's logic that takes data and state as arguments, and then outputs a rendered UI.
And when we can bring that to the users, whether they are developers, designers, product owners, inside of storybook, then that means, first of all, we don't know what, what comes out of that, but what is interesting that could come out of that is just more people getting involved in the UI.
More people getting involved in like understanding how a user interface ends up being rendered. And that can only yield, I think, good things. For me, if I'm using myself as an example, understanding how a component is made helps me design better.
Andrew: Yeah, I think that's one of the key strengths of storybooks is that it really brings developers and designers workflows together. And it makes a lot more collaboration happen. Where else has storybook, brought those two people together in a good way. Like I know docs is like a real cool win.
Norbert: A lot of people ask about this, can I use storybook as a documentation tool as well? Whereas as an engineer, for me, it is really about the work bench, but I also understand that if. Someone else is supplying components to me to use. I actually need to look up their documentation all the time.
Stories are documentation. but when you're really close to the same code base, then you look at stories in a different manner. When you're further away, like for example using a open-source component library, if they just directly expose all of their individual stories, it's not super useful.
What you're more interested in is an explanation of like, well, this is the core concept of the components, this is one variance, and you use it this in that situations. Here's another variance that you might want to use in such cases." this is a more of a documentation page, which is why storybook supports MDX.
And you can use your stories in your MDX files. In fact, you can even specify your stories in MDX itself. Storybook doesn't really mind if you referenced the stories or it can also extract the stories out of MDX directly. The idea is you have a single source of truth, which is your stories, and then you can either present them as isolated components, or you can compose them into a docs page.
Andrew: That was one of the huge selling points for storybook at Intuit was before the docs add on, we literally had a WordPress site that had embedded PNGs of like specs, not even like real components, just P and of the specs. And we had to update that also. But like that the add on docs really unified that experience.
And now we do have that single source of truth, where if you want to know what the design system supports you go to the storybook, you read the docs. And then we tried to, cater it to both designers and developers and build it to be a good tool for both of those targets.
Stories are Documentation [00:18:49]
Dom: When you think about it. Your components stories are the baseline documentation for UI and really what the docs, capabilities and storybook. They extend that further by being able to auto-generate things like props tables for a bunch of different frameworks, the ability to add pros and mark down and inject them alongside of your live components.
In addition to that, something that I saw from you, Andrew when you were working Intuit, you extended those patterns too, because you could build your own components that integrated into storybook docs, AK doc blocks, and that allowed you to get the flexibility of a more fully featured CMS, while also getting the automation of a tool that understands what your components are that understands how they work and their arguments and their data and the shape of their APIs and can automate a lot of the boring work of documentation.
One of the key things for docs , was that it's automatic. If you're like me and you you visit tools, docs, or like UIs docs and they're out of date, right? If one thing is out of date it, it starts eating away at you.
Like what else is out of date? Is a whole thing on a date? Like, does this tool even work? So we kind of removed that kind of anxiety, as like a design systems, maintainer or component library maintainer, or, or even like just a UI developer. We remove that anxiety of having to always keep these docs up to date because we just automatically do it for you.
Norbert: Something that a lot of people tell me is that maintaining story their storybook is a lot of work. I think it's a net gain, for most people, uh, I think everyone here agrees for sure. but some people don't and they think, keeping their storybook up today is a lot of work.
But honestly, I think a lot of those people are maybe still writing things top-down and then later writing storybooks, retroactive, actively. but if you think about it, like maintaining a site, like you said, with a lot of PNGs that's a lot of work, writing all of those unit tests with snapshots attached to them is a lot of work.
and I think storybook actually eliminates a lot of work and more work than, it takes. And to me, it doesn't really take more work to be writing stories. In fact, I find that a lot of work I could not do if it wasn't for storybook. And that's maybe a little bit weird, but if you think about what some components need in terms of data, it can be really hard to get that data from a real app.
An easy example would be a timeout, the component that shows, when something has timed out. Well, how would you reach that state in your real app? Like you gonna enable some sort of reverse proxy and get it to timeout. Like now you're waiting 60 seconds for your component, the render? To me personally, the thing I'm working on for chromatic right now, just to name an example, I need an account that is logged into both GitHub and GitLab and with our own username and password.
and it's really hard to get a user like that. So in storybook, I don't need to do that at all. All I have to do is provide the components with the right data, so much easier, so much less work. So I actually get that set up.
Dom: that's kind what we're seeing in the larger ecosystem. Storybook now has like however many, like tens of thousands of stars. What that is, is like a testament to like this, community of developers realizing that building stuff in isolation, building UIs specifically in isolation is the pattern to make UI development not suck. To actually make it a manageable, satisfying, good experience. Because in the past how would I have done what Norbert talking I was talking about, well, I'd have to like, get into my app, either provide a bunch of fixtures for that data, put it on a staging server, do a bunch of contortions in gymnastics to get my app into the right state and the right user and the right blah, that takes like a hell of a lot of spin-up work. Right. Like just to set it up, initially only to like work on one part of the UI, like really one, one component like that, like a dropdown menu.
And think about how many times you'd have to do that again. And again, for loading states for error states for, for any type of complexity. Just gets out of hand, like even marketing sites benefit from this because they also tend to have some very primitive data requirements.
The alternative isn't appealing and I think that's what our community members are realizing and why, storybook is becoming so popular. It's like the alternative sucks. So like, let's, do something, but that doesn't.
Justin: Yeah, it's pretty interesting. How storybooks as a tool promotes good development practices. So react and other frameworks have been pushing this notion of separating this idea of what a presentation of a particular aspect of UI should be versus like what the business logic of UI is in that state.
So often in my own experience that becomes like a forcing function, especially if you're doing storybook driven development where you're like building your components first and storybook. Oftentimes you're building the things that you need to power that piece of UI. And then you'll have a wrapping component or some context or some other integration that comes later to give it the sort of rich business logic.
So it is easy to get things in visual states because you're just driving the UI. I think the, the new format definitely helps, drive that forward even more. And the args thing sounds really interesting. I, especially as this, like, why are you are talking about that earlier I was thinking in my head is like, oh, this could give you the opportunity to do some like fuzzy UI testing, because oftentimes there are like weird visual states in which the component breaks.
It's like, oh yeah, this has really, really long text. But maybe if you just had a way to track. Like, oh yeah. We're just going to give this component, these different pieces of data. It's like easier to test. Yeah, pretty interesting.
Chromatic's Suite of Tools [00:24:58]
So speaking of testing, chromatic is a company that helps maintain a storybook. It is, really focused on this, notion of visual testing. so Dom, why don't you tell me a little bit about like, what was the inspiration for creating that and how's it going?
Dom: Chromatic is the company behind storybook. We maintain it, chromatic offers, cloud services alongside of storybook that do things like, publish version, access control, visual testing, UI review. And it's also a suite of other problems, that storybook users typically encounter, the heart of which is around like feedback and testing.
So talking about testing, visual testing is this idea. It's not new first of all, we didn't invent the idea of comparing screenshots to each other and at detecting changes. But what we figured was that like, Hey, in this new world, as we're moving towards components and component driven, development practices, component driven UIs, also seeing, the design tool and design industry moving towards component driven UIs as well.
They have components as a first class construct there. We realized that like, Hey, what you actually want to visual test is components in the past, you were visual testing pages, and what that meant was that was fine for like marketing sites. I was fine for like content sites, because you could take a snapshot of a page and compared it screen to screen.
but that doesn't really work in component driven UIs because, if you'd make a change to one component. So too will maybe like 50 pages change, maybe like a hundred pages change and, Uh, no. You're raising your hand.
Norbert: Yeah, I would argue that it doesn't actually work for marketing sites either because your content constantly changes. And so you're not visually regressing your components. You're constantly visually regressing your data which is by design changing and like you're approving a lot of things that it just creates a lot of noise.
Okay.
Dom: Yep. And so what visual testing at the component level does is it allows you to understand and pinpoint what has changed in the component hierarchy, and see how any changes in the component hierarchy can cascade, to other layers. When, for instance, like a button changes, like how does that effect a credit card for them?
How does that affect, a composite component? How does that affect, all the buttons on the site? So that's where this visual testing of components came from and why we were so excited to offer that to the world. The other stuff that chromatic does is, solves a challenge that I face all the time around this job that I have to do called UI review.
And that's the part after I implement the UI, so I can code my way out of box. I implement the UI, and I have to share it with other bunch of a bunch of other people. Right. you share it with your designer, you share it with the product owner, you share it with perhaps like your accessibility specialist and so on the list goes on.
Right? Everyone has an opinion about UI turns out, because it's so visual and so close to what the user ends up seeing. And when you share it with everyone, like in the past, how did you get feedback? Maybe your CEO, like Gabe sent you a slack message. Maybe your product owner added a JIRA ticket for you to do something. People sent you, emails, people sent, you GitHub messages. You're getting bombarded as a UI developer, from all different directions with like feedback and requests and not to mention like, sometimes some of these feed, this feedback isn't even on the version of the component that you actually care about.
Right. It's not like an old, old design, like final, final three, of your UI implementation. What chromatic also helps you do is it gives you a shared workspace for all of these people to come in and give you feedback on implementation that makes your job as a UI developer way easier because it, not only is all the implementation at one place, the actual things that people are talking about constantly stay up to date, because chromatic publishes your story booking in the cloud and keeps that up to date.
It's almost like a universal reference point for any new feature that you build or any new, piece of UI that you're proposing.
Andrew: That seems like another natural step and bringing those designer and developer workflows together. when you're working in like something like sketch or Figma, you can actually comment on specific parts of the UI. The fact that that comes to the actual code review process just makes the transition seamless.
Dom: exactly when you think about, the most popular design tools today and other handoff tools like Zeplin and abstract, like really what their value proposition, right? Like it's not painting pixels.
Painting pixels shared amongst all of them, really what they're talking about and what they're selling is the collaboration aspect and getting consensus on what is going to be built. And when you think about as a UI engineer, how do you do that? why don't we have these tools too, right.
Like how do we get consensus on the UI? That's going to get actually shipped. We're even closer to the end user than any, other, discipline, whether it's product owner, designer, or executive we're the closest people to the end user. But why don't we have this like suite of tools that help us like collaborate and help us like test and maintain our UIs?
That's what chromatic is trying to solve.
Justin: yeah, that's awesome. We had a conversation about this in our last episode where, this, this notion of bringing designers closer to developer tooling is a very powerful thing. Because the inverse thing where you bring in developers to design tools is great, but it's so far removed from the ultimate like process of shipping the thing
Dom: My colleague Hart, says all the time, software is never done. Right? there's always this process like ongoing iteration. And so it almost feels like a mistake to, to think about design developer, collaboration as like discrete pieces of like I design stuff in my design tool, and then I hand it off in my handoff tool and then I build it out in storybook.
Well, no, There's another like loop there's the rest of the loop to to kind of like, think about which is like, what happens after I implemented what happens after I ship it. And then what happens when someone else decides to come in and maintain this or change it or tweak it? so once the the design is being done, it's just the first part in like a never ending loop.
Norbert: we actually have a special word for software that is done. It is deprecated.
Justin: Nice.
Yeah. Into the lifecycle. There's an interesting business opportunity here to close that loop. It's like, okay, you've developed now something. Now we need to iterate on it. It's like, how do you get the things that's in storybook connected to the things that's in Figma to communicate.
This is differences. It's interesting.
Betting on Open Source [00:31:48]
I want to talk about one thing before we move on to the next question though, is just that there's been a lot of conversations about how hard it is to fund open-source. There's been a lot of companies who have struggled with this and I like to think of Mongo as an interesting story, where it's like, Hey, we're going to open-sources thing.
They're a little bit different because they're like this product that they're selling is their whole sort of open-source business, uh, with, you know, support tacked on top. But it's, it's challenging. So could you all talk a little bit briefly about like how this journey of creating a company that's really founded on open-source software that like adds on top of it?
Like, how has that been working out for you? W what is, what do you see is the sort of future of funding open-source?
Dom: Yeah, that's a tough question. because it seems like that question is being legislated on Twitter and like in get up discussions in private channels endlessly and there are a bunch of different ways. but none of them really stand out a winner. I can describe our way. And perhaps that shines a bit of light on how we're thinking about it.
Our business model is straightforward. It's we build an open-source project to scratch our own itch. We build commercial tools alongside of that open-source project that don't really belong in open-source. Cause they have like cloud components to them.
They have access control. We need to like keep track your accountant, secure your account. so we build those cloud tools. We sell those cloud tools and then we use that money to, build more stuff that scratches own itch and open-source land. And that life cycle just continues and continues.
And hopefully along the way, we make, UI development better for everyone. just by continuing that, that life cycle. but I don't quite know how all like every other company is, planning to do that. I think We're lucky because we have like the confidence of our customers and they pay us money to build stuff that gives them a bunch of value and they continue paying us money because they have that confidence in us and yeah, just, well, shout out to customers.
We really love you. And yeah, that helps us build more open-source stuff.
Norbert: I think storybooks, story is a little bit unique in the open-source world, considering chromatic or chroma. Doesn't actually own storybook at all. a story of pre exists, chroma bay quite a few years. Uh, so
Alright. A year.
so chroma doesn't own storybooks. Identity, it doesn't own, the repository. really is an open, open-source project where everyone is welcome and can contribute and voice their own opinions. we have a steering committee that does, have, more people than just of chroma employees. and we make sure that it stays that way. what we're trying to achieve is, a good open-source project that is welcoming.
And of course, Dom, me and Michael, for example, we contribute to the story, but could base a lot and we have our agenda, but we also welcome other people's agendas, in the story of the community and code base. A lot of the stuff that we do in storybook's code base, it doesn't really make. 100% business sense.
Like we have competing open-source tools that compete with chromatic. but it's yeah, like Dominic says, certain things don't really belong in the open-source because Like the things you mentioned, if you want to do and run everything on your own local machine. Yeah. You can run story shuts and you can create a image of every story.
We have tools, open-source tools that do just add for you.
Dom: we've even built some of those tools
Norbert: we have, yeah. Yes we have. And we maintain them, which is actually more work than just building them.
Dom: We see ourselves as a conduit for the good ideas and the rest of the community. And often those good ideas are something that we have never thought about and that in our role as conduits, that allows us to promote the best things forward.
that's what keeps the community so vibrant. And that's all we have, like, I think over 1300 contributors now, and continue growing
Andrew: I think that's one of the things that really make storybook stand out. I frequently say to many, many people that storybook is one of the most welcoming, open-source communities out there. Like literally. Really, I think I messaged Norbert like a few years ago and he's like, yeah, let's hop on a zoom. And I want to meet you and then I'll give you a public access.
It was like a completely different experience. And even that extends to pull requests. Like I've seen many a time, somebody puts up a pull request, they like stick around for it for maybe a week or two and then business needs or their job gets in the way. And they can't really take it over the finish line.
And then I'll see one of the core story book contributors actually pick it up, push a few commits to make it ready for merge. And then actually, which is super awesome to see.
Norbert: Yeah, I think it's totally understandable that people, contribute to an open-source project. But they can't be bothered because of time or interest to take it to the a hundred percent that is required of a large open-source project, like storybook, tries to be backwards compatible to a sane degree, and it must have a good read me to the same degree.
It must have a change log and a migration, log, et cetera, et cetera. There's a lot of epic ministrative work that goes into having a good and welcoming open-source repository. but not everyone can take it to that a hundred percent. And so I think it just makes sense for maintainers to like take those 99% PRS and take them to 100 and get a merge only makes sense to me, actually enjoyed that process a lot.
And I think it's very nice and people are super appreciative of you taking that 99 to a hundred.
Dom: there's another element here that speaks to the larger kind of maintenance effort of these open-source projects. And I've been able to see the inside of like three of them now, where. the actual work isn't the fun work is building stuff. Right? but that's like the tip of the iceberg it's that's small, like a little bit, well hill that you see from a distance like above the water.
But below that iceberg underneath the water is like the rest of like the maintenance work, release management, keeping things up to date. keeping things up to date with the rest of the ecosystem. Things like Webpack five, react 17, vue three, that have significant API changes that affect how people use storybook and use, that tool. That's where the work of maintainers comes in. it's the integration stuff that allow. our users to have the most seamless migration possible, no matter what tool they use. So if they decide to upgrade to vue two to V3, easy, if decide to change from vue three to react or svelte or angular, God forbid like, then that's easy to, we love angular.
We're going to support angular IV soon. In the next couple of months, but what I'm saying is we do this integration work. so you don't have to, so you can just use storybook builds components, have a great time, and you don't have to worry that, like, these things are gonna break or these things are gonna go out of date.
At least with storybook, you might have to do that with the rest of your app, but when you integrate, when you add story, but you can be sure that be out to date with the rest of the ecosystem.
Norbert: yeah, this also explains why you storybook must be such a welcoming space for new contributors and contributors in general, because we really need desperately need these people to contribute. I, I just don't understand angular or vue myself, but storybook still contains it and we still need to have everything work and be upgraded as Dom was saying.
And that takes a lot of mental capacity that I personally can't fit in my own head space. So that's, we, well, we need contributors for, to help us, understand these tools. Two three years ago. I didn't understand TypeScript at all. Now I'm a huge fan, but back then, I didn't, I think a, Testament to storybook community success has been our TypeScript migration that originated from us supporting angular.
Angular two was built using TypeScript and, storybook can react was nuts. but that, evolved over time and the angular developers that and maintain as a storybook, we mingled and now all of storybooks code base is TypeScript. And if it's up to me, then soon chromatics code base will also be.
Justin: Yeah, that's fun.
Managing the Community [00:40:42]
What other experiences have y'all had in scaling, contributions and managing large community? Cause like storybooks is such a big, expensive project and hits so many different technologies and as this, the case with most every open-source project, you're a relatively small team working and trying to scale this thing out.
so how do you do it? What's the experience? Like on the day-to-day what are the biggest challenges? Just curious about insights on that.
Dom: It's kind of like we're building the ship and also like sailing. So in some ways, like we are trying to keep it afloat by doing this like base layer of maintenance, while supporting more and more new tools, we can't do that without the rest of the community and, the rest of the folks like working together when you have larger, communities, all of those people need to talk to each other or need to of communicate.
We have amongst the main maintenance and, especially the core maintainers, The most context on all the different parts.
so rather than like trying to build every single different part, we try to connect people that have similar challenges to each other and enable them to build on top of storybook. What that says about the core maintainers is like, really what, what we're doing is like defining core API APIs, defining things like components, story format that other people can then build upon.
And in some ways like that built then building upon it is a fun work. They're doing dope stuff. And we get to watch it with like, you know, as like soccer dads on the side of the field saying " like, yeah, cool. Like you scored a goal. That's awesome!" What's it like for you Norbert?
Norbert: I remember in the beginning where I was reading every single issue that came in and PR but at some point that became impossible for me to to go through everything. I've definitely hit a period a year ago or so back where I just became a little bit too much. This is when I talked to Dom and Zol and Tom, like, "Hey, could I maybe migrate a little bit towards the chromatic side of things where things are just a little bit slower going, and we got longer term projects going on?"
And recently I've been kinda migrating back and getting back into the storybook side of things. That's kind of how it's been for me. I still have an open Calendly, uh, which is like someone else can schedule a zoom meeting with me which I posted freely. Anyway, can schedule a meeting with me to talk about storybook and if their main question is like, what can I do to help, or, Hey, could you help me understand this bit?
So I can contribute like, loved doing those meetings. Those are usually the highlight of my day. we have Michael, who is. Just amazing at managing the entire project. He responds to, I think pretty much every issue, every PR he does every release that we do of storybook.
Yeah, I would not want to be in his shoes. He's doing such an amazing job at managing storybook. He wants to have those shoes. and he fits them very real.
Dom: And then, yeah, we have a bunch of other team members doing in various facets of the team too. We have a on documentation and maintaining that. That's like a full-time job, which is like the surface area of storybooks API is like huge. And what it's capabilities are huge. And we're constantly adding new and more new features.
We have Varun on DX developer experience. He's like kind of articulating and helping people understand why storybook does the things that it does and how to use storybook to do things that things like testing things like component development, things like documentation and a bunch of other maintainers that kind of lift us up as well.
Yeah, those are to name a few. There are many, many others. I can't call them. I know them by name, but I'm like, we don't have enough time in this episode to really just go through it all.
Justin: Yeah. Yeah. Thanks for that perspective.
Gems from the Community [00:44:51]
So Dom, you had mentioned seeing some really cool things. What's your favorite thing that you've seen come out of the community?
Dom: There's a lot. Okay. So. Hey Norbert, you go first.
Norbert: I got a good example. So it's quite, it's not a new add on it. It has existed for quite a long time. But I think it's. A really great example of extending story beyond its original parameters which to me is the accessibility add on. I really, really liked the concept of it.
I want to take that out on so much further. In fact once I'm done with some of this chromatic work that I'm currently working on, I plan on taking a very careful look at that at all, and probably extract certain things that it does into the core itself. The core of storybook, like I think the main feature of this ad-on should be extracting data from the story, and then it really should be storybooks responsibility for showing this data.
I think the less work at, on creators need to do the better. So that means extending storybooks capabilities by quite a bit. Again and this also feeds back into chromatic. We actually plan on taking this extracted data and graphing it over time in chromatic as well, so that you can not just diff what the component looked like before and after, but also you can see, Hey, am I improving or decreasing my accessibility score over time?
Dom: A lot of the things that happen are in the add-on ecosystem. First thing off the top of my head is Yon a fellow maintainer just released a testing library integration that allows you to easily extract storybook stories and drop them directly into testing libraries.
You don't have to, it's just like ergonomically a super powerful tool. You write stories once you reuse them and tests, don't have to think about it.
" Varun is, has some really cool ad-ons that he's making things that are all around like CSS, debugging and CSS layout as a UI developer, that's kind of like all, all I do it is what it feels like.
I'm like, Hey, this does, uh, is that, does that like line up, right?" Or Is this the right one spacing? So he's building tools like that help you visualize alignment in storybook helps you measure the distances between like headings and titles distances between Dom elements.
Those are the two exciting ones that have come recently. And then there's just like an endless list of mocking out ons that like our new integrations with storybook. And then of course the design tool ad-ons which are constantly being innovated on. I think UX pen has a really cool one that we've seen recently that allows you to take stories that you've written in storybook and import them into your design tool so that you can just design with real life story data.
As a designer that's catnip for me because I don't have to maintain like a static component library and a storybook anymore, which storybook is source of truth. That's the code? I can use storybooks component library or store any UI inside of storybook in my design tool itself.
Yeah.
Andrew: Yeah. Closing that loop is like to me, the holy grail of front end UI development, getting it to where like designers, developers in their tools are both perfectly sinked. It's a very hard problem to accomplish. And there's like dozens and dozens of companies trying to.
Dom: yeah. Andrew, you took a stab at that too, right? You had a sketch add on, you had a couple of cool cool projects.
Andrew: my attempts got me to maybe 90, 95%, but you really want like that a hundred percent, especially at such a large company. So like we eventually moved away from sketch and our designer started using Figma. So what ended up happening is they maintain a Figma component library that is very robust.
And I don't think I could ever generate from code to make as robust as that. Maybe we can in the future, who knows. But that workflow worked pretty well for us.
Norbert: I think that too. Another cool thing that I've seen and actually used in the past was ink, which is like a react renderer for the CLI and I think ferrets who is my colleague at chroma. He decided not to use it, but he did actually decide to use storybook for the CLI that we use for chromatic.
So we actually have stories for what the CLI does and looks like for the chromatic CLI, when you run and upload your storybook to chromatic like that to me is also really cool. Yeah. Yeah. It's amazing. And like, actually we caught bugs in our CLI thanks to this, and we have visual regression on our CLI because of this.
I don't think many people can actually say that.
Justin: That's wild and I love it.
Dom: there's some really cool stuff going on in the ecosystem. As well, like inspirational stuff. That's not necessarily storybook, but what's built in storybook sawn made that a windows 95 UI component libraries. So you can like, do like build a windows 95 UI someone, I think into it.
Y'all made like a dev tools component library. So you can build things that look like Chrome dev tools, but in storybook or in a web interface there's some folks that are doing like 3d stuff. So integrating storybook with I think three JS is the 3d library. And so all of a sudden you have like textural mapping and reflections and three-dimensional space.
And when you like. When you think about it, like the whole isolated component development is perfect for three-dimensional stuff, because you want to be able to reproduce a UI state through data and props. Storybook is that tool that helps you like quickly get to, what does this look like on the Z axis when it's positioned like this?
And like the object is extruded, like bat
Andrew: Yeah. The concept of isolated component development and excited, it's exciting to see it like translate to all these different domains. Like I never knew about the terminal. That's crazy. Another use case we have it into it. A few of my coworkers made a storybook native experience a little bit better.
It'll render natively into like actual phones in your storybook. So you can develop your mobile components in just the same way as you do as your web components.
Dom: that's the exciting part of the web too. Like we get to innovate on the newest patterns and the newest, like dev like workflows. That's probably why you have this podcast dev tools.fm. Right? This is the, we get to see the future a little bit.
Justin: Yeah, for sure.
Tooltips [00:51:37]
Cool. Shall we go into our tool tips for the week?
Andrew: Yep.
Justin: you wanna kick us off?
Loopback [00:51:44]
Andrew: My first tool tip of the week is loop back. This really isn't a developer tool. What it allows you to do is to combine multiple sources of audio from different apps into one source and then use that as an input to another. So that may have sounded really confusing.
But so the example up here they have on their website is they take apple music and the microphone and create a new virtual device out of that. And what you can do at that virtual device is use it like in zoom. So if you wanted to have background music in your zoom call, for some reason, you could use this to do it.
And what I've used it for is there's this other app called krisp.ai, that removes background noise from audio. And I literally routed the audio from my editing tool into a virtual device, and then use that virtual device as input to crisp. And then I was able to actually run the background noise, removal on prerecorded audio, which helped with editing some of these episodes.
Justin: It's a super cool tool. I love their interface too. Very visual. Pretty awesome.
Andrew: Yeah, visual it hearkens back to Justin's love of visual programming tools. You get to connect things to other things. It's a fun little experience.
Justin: it's so true. Textual programming is very powerful very terse, but also not everything is really best displayed in text.
Stack Blitz Web Containers [00:53:06]
So on Twitter this week, I saw this really interesting blog post from stack blitz. So stack blitz is a service that gives you an online editor. So you can think of it, like GitHub code spaces or like code sandbox similar sort of thing.
They just released this feature called web containers, which actually will run your service in the browser. So it's like you have a no JS running a graph, you API, it will run it in the browser. This isn't necessarily. Totally unique. So code sandbox actually runs a lot of stuff in the browser I've contributed to that in the past.
And it's really interesting how they take their parents. It's a lot of just a lot of web workers and like loading things and woodworkers and trying to coordinate everything. But I think there's some really interesting things going on with these web containers. And I think there's some some very clever usage of what I expect to be webAssembly actually running these things more natively in the browser.
So really, really fascinating project. You can imagine being able to spin up, storybooks application directly in the browser. Everything running in the browser without having to like NPM install anything, or go through that process.
So really, really fascinating technology. We'll link the blog post where they intro it and in the show notes, but it's pretty cool.
Andrew: Cool to see all these tools trying to lower the barrier to entry to development. Uh, same goes back to repl.it, which we talked about last week. Very, very similar.
Mock Service Worker [00:54:41]
Dom: One of my tool tips is mock service worker provides API mocking that help you quickly and easily just mock data inside of components in UIs works with storybook as well as an add-on. There's some UIs that are intertwined with data, like inextricably intertwined with data, right?
Some something that calls out a third party, API AK like Stripe credit card farm. Right? It can be tough to build in isolation. But you want to build them in isolation because like you get all these other benefits of building an isolation. And what mock service worker does is that it spins up a service worker in your browser, intercepts requests, HTTP requests, and stubs in responses of your choosing.
It's pretty easy to do things like you stub in a response for whatever API that you need to mock.
Justin: I really love tools like this. I was actually going to share this one this week, myself. There's this interesting story around testing in particular, where it's like the layer that you test in matters a lot. And a lot of people over the years have expressed, oh, you should write your code in a way that like your individual functions can have dependency injection and like you're writing your code to be testable.
And as a result of that, often the code gets really hairy. It gets really hard to follow. It's not the easy path of like, oh, this function just does this one little simple thing. It's like, oh, well we're doing it. Dependency injection and this way, and it's got this interface, adapter that we use to like do this, blah, blah, blah, blah.
And then, and it becomes you write testable code that becomes very hard to reason about over time. And so tools like this mock service worker that kind of. Goes really, really, really low level and just says, okay, what are the exact parameters that you need to work with? Another tool in this vein is mock Fs, which is library on NPM.
Actually I put in a pull request to auto a while back to do this because mock Fs says, you're reading some files from the file system, the functions that you are using and like how you access them, you don't want to mock those out. Those are all implementation details, but you want to say the file system has these files.
I find that super, super low level of just like, I expect that this resource or this API, or this file exists with this content, and I want it to do this thing.
It can be so much more to your development environment, because it also means that you don't have to think about. Doing a ton of crazy dependency injection.
You could write your code the simple way and also test it in a non fragile way. And I think that's the holy grail for me.
Dom: yeah. In some ways like it w testing is moving towards like testing the horizontal layers of the stack, things like the UI and isolation of the data layer and isolation, the backend in isolation, microservices already. And like with docker containers and the backend engineers have already figured this out.
But now we're getting into this like front end and UI layer and tools like mock service worker, Mirage.JS. They help you like do the same thing engineers in other parts of the stack are doing except for our part of the stack, which is UI.
Bracket Pair Colorizer [00:57:48]
Norbert: So last week I was pairing with someone and they didn't have to say enabled, and I immediately realized how useful this is. So if you have a bunch of parens or objects nested in each other. By by default, all of the characters are white and it's sometimes really hard to match up, which one matches up to which one.
Now you can go click on it. And then VSCode will tell you where the other one was. But what if there was a way to just color code them differently based on which one matches so bracket, pair colorizer is that vs code plugin that does that. And like I said it can be very, very useful, particularly if you're writing your code in a really functional way.
There's lots of parens and lots of arrow functions, nested in other arrow functions that also have returning objects. Yeah, so really small, but very useful tool makes it much easier for me to read the code that I write.
Andrew: Yeah, I've used this one a lot. It really helps to be debugging. Like how I write my code after prettier is I'll write it as ugly as possible. And sometimes I'll miss like a paren and this is critical in helping me debug those situations.
Norbert: It's got 5 million downloads or something.
Andrew: Yeah, it's crazy.
macosicons.com [00:59:04]
My last dev tool tip this one is really not development related at all, but in the new release of MacOS Big Sur, they changed their icons from being just like icons and your doc kind of looking more like iOS icons and not every tool has transitioned to that paradigm yet. So this is a website where it's literally just icons built for Mac OS Big sir.
And you can make your doc look really pretty and have all the same shape of icon. It's not that hard to change the icon either. It might seem like a little bit of work, but it's not too much for example, Spotify is a great example of how not to do a big Sur icon. You don't just put your circle and the app square.
What I think you should do is make your logo become that square. And it looks a lot nicer to me.
Justin: Pretty cool.
Planet Scale [00:59:56]
Yeah I'll make this one, my last one for today. This is another big announcement that I think was this week. So this company called planet scale started the beta of their product. This is a really interesting service that gives you like a vercel development experience with databases.
So you can have a pull request that update to schema and get a sort of database instance for that pull request. And they handle the migration and everything for you. It's built on this technology called like Vitus or something. I don't know exactly what that's called.
This is huge. I'm really interested and excited to see where this technology goes, because this has been a tremendous gap in the ecosystem for a while. And there are a lot of interesting services that are popping up. Fanta DB has been like this, like server less a provider for a while, but in my opinion, their APIs is pretty complex and it's hard to get into that tool that planet scale is using it's essentially my SQL under the hood.
So if you've worked with databases, it should be very familiar for you. So anyway, probably one of the most exciting database companies that I've seen in awhile supabase is also really exciting, but this one for a very different reason,
Norbert: nice. Yeah, definitely experimented with Fonda before. And it was a pretty cool but the concept of automated migrations, sign me up.
Andrew: Yeah, it's not a problem you think you'll have when you start on your serverless journey, but databases are a huge problem. I manages a website called kickback.tv, which is basically just a fancy RSS reader for music videos and how I do it is by spinning up thousands of parallel serverless functions to scan blogs.
And my biggest problem has been connecting to a database and it's nice to see more solutions come out for that type of use case. Storybook Measer [01:01:52]
Dom: My second tool tip is a tool called measure that is currently being in prototype phase, but it should come out with a storybook 6.3. And what it does is It measures the distances margin, padding dimensions of of the box model, visualizes them in an, a canvas overlaid on top of the actual UI.
And what that helps you do is a check for spacing and check for the distances between elements really quickly inside of storybook. If you're a UI developer like me, you tend to do this all the time. And in fact, like I do this for most of my, most of the time, it's just oh, like this spacing doesn't look quite right.
This space doesn't look quite right. This gives you a cook at a click of a button, the ability to see what that spacing is.
Andrew: Yeah. I've seen this idea of evolve over the course of the years. I think the first time I saw it was with Adam argyles vis bug.
He's a developer on the web dev team at Google. And it's a lot like this. And I think recently another versatile engineer that works on the design systems front end had a blog post about this too.
So it's cool to
Dom: Yeah,
Andrew: throughout the ecosystem.
Dom: absolutely. And in fact, like I, I think inspect picks was that tool and then this bug definitely our inspirations as we build this out we're trying to get this to more people so that everyone can get the benefit of checking spacing.
DeepScan [01:03:22]
Norbert: So total that we've been using in storybook for awhile it's obviously eslint. I think everyone here is familiar with it. So I'm not surely recommending eslint because I think everyone is already using it. What I am recommending is checkout deep scan. Which is, I don't know how they do it, but they are immensely fast at detecting things that might be wrong with your with your code.
Things like you would have to configure eslint with all sorts of presets or plugins deep scan, just automatically checks for you and tells you like, "Hey, you're using a lead here, but you're actually not redefining it anywhere." Or "you are returning something here, but then you're not returning anything in the else clause in This function." A simple stuff that Islam can catch for you, but running eslint on your own machine can be quite a performance hog and running eslint over your entire code base can take awhile.
Deep scan is something you can run either as a GitHub action, or you can run it in vs. Code itself. And it is just ridiculously fast.
Andrew: This is definitely one I'm going to check out for our use cases that this one little example they show here where you make a render a function without actually returning your JSX. I do that all the time. It is so annoying doing that. Cause the error message it gives you doesn't really tell you that you just did that.
It just kind of confusing.
MHO [01:04:52]
Norbert: Um, but This one is a little bit out there. So this is actually one from the Ember community. I think this is one of the Amber core maintainers and it is a tool called mho which is the opposite of ohm which is probably a unit you might've heard of.
It is the electrical resistance. And apparently mho is the exact opposite of that. So it's Really allowing flow, which I think is really interesting. The tool was not ready for use, but it is an experiment of kind of a bundler that runs in your browser as well. So it's another one of those service workers tools.
And this time it is essentially doing a babel's work and webpack's work whilst you're requesting the files. And one thing that's been annoying me for a really long time is the whole pipeline of publishing packages. Doesn't actually make a lot of sense to me. For example, for storybook we are currently publishing common JS, and we're also publishing ESM and we're also publishing ESM, but without the regenerator runtime, Because some people will have more modern systems than others and you can't really poly feel regenerator runtime.
Once it's in, and it's just a syntax error, if you try. And if invoke it. And I really think like this entire problem of like getting code and running it it should be like near to consumer for yeah, like essentially Bibles work should be easily as possible. And this seems to me like a tool that could take us into depth direction.
So I'm personally really excited for it. I know it's not production ready. But yeah. Yeah. So something that really, really excites me service workers taking care of the transpilation of your packages and making sure they're like offline capable one of their core promises. Of Edward Faulkner, he stuck out, he mixed us and presented it at Ember CONF last year. He said you don't need to do any NPM install at All. You just spin up your app and it downloads it directly in the browser, which is I don't know about you, but I do spend a lot of time downloading packages from NPM, even if they're already in my yarn cache, but apparently it just takes a trillion times to get everything copied over.
And now my hard disk is full because it's got a billion versions of low lodash everywhere. We'd be nice to not have that anymore.
Andrew: We're definitely in a paradigm shift of this like CJs plus ESM to a big question, mark, because lots of experiments and new setups are definitely going around.
Norbert: Yeah, but like us, as I think everyone is aware at this point, like the JavaScript ecosystem is just a moving target, but ESM is the, maybe the final evolution of the module format we'll have in JavaScript. But it's definitely not the last iteration of JavaScript language. It is still evolving.
New features are being added every year which is a great thing. And so we'll never be really done with migrating to the next version of JavaScript. So a tool like this that takes it to the end consumer. Yeah. Again, excites me really a lot. I'm hoping that it will be a reality at some point
Conclusion [01:08:31]
Justin: Cool. Thanks for sharing this tool. So it was awesome. A great episode today. Thanks Tom. Thanks. Norbert is great. Having you on here. The storybooks is awesome. One of the best tools. So you're doing great work. Keep it up.
Thank you very much for inviting us.
Yeah, absolutely. and That's it for us today!
All right. Until next time I'll take it easy.
Norbert: Bye-bye.
Dom: y'all.