Bit with Debbie O'Brien
Debbie O'Brien discusses her journey from Vue/Nuxt advocacy to working at Bit.dev, exploring meta frameworks, component sharing, and remote work culture.
Episode Description
Debbie O'Brien discusses her journey from Vue/Nuxt advocacy to working at Bit.dev, exploring meta frameworks, component sharing, and remote work culture.
Episode Summary
In this episode of FSJam, Debbie O'Brien shares her path from discovering Vue and Nuxt while solving server-side rendering problems at a previous company to becoming a prominent advocate in the Vue ecosystem, and then making the leap to Bit.dev where she's learning React and TypeScript from scratch. The conversation explores what meta frameworks like Nuxt and Next.js offer over their base libraries, with Debbie and co-host Christopher Burns comparing the ecosystems and how plugins and modules extend functionality. A significant portion of the discussion centers on Bit.dev's approach to component sharing, examining how it differs from monorepos, Storybook, and private package registries by enabling collaboration, versioning, and visibility across teams and projects without precompiling components. The hosts press Debbie on the complexities of CSS handling in component libraries, leading to a nuanced exchange about dependency management and design system flexibility. The episode also touches on Bit.dev's Discord-based remote work culture, which Debbie defends as a tool for better collaboration rather than surveillance, and closes with her excitement about upcoming features and her Twitch streams where she learns React in public.
Chapters
00:00:00 - Introductions and Debbie's Career Transition
The episode opens with Anthony Campolo welcoming Debbie O'Brien, an experienced developer advocate who has worked with both open source projects and product companies. Debbie introduces herself as Irish but living in Spain, and explains that she recently transitioned from Nuxt to Bit.dev roughly six weeks prior to recording.
Debbie candidly describes the challenge of going from being at the top of her game in the Vue world to feeling like a junior developer again while learning React and TypeScript simultaneously. Despite the steep learning curve of a new language, framework, product, and team all at once, she frames the experience as both humbling and genuinely enjoyable, setting the tone for her honest and enthusiastic communication style throughout the episode.
00:03:04 - Discovering Vue and Falling in Love with Nuxt
Debbie recounts how she first encountered Vue while evaluating modern frameworks at a company, then hit a wall with server-side rendering. Eduardo from Vue Router suggested she try Nuxt, but her initial reaction was frustration with the "magic" it performed behind the scenes, from auto-generating router files to handling Webpack configuration automatically.
Over time, she came to appreciate that Nuxt's conventions and automation were genuine developer experience improvements rather than restrictions. She loved it so much that she began advocating for it in her free time, eventually making it a requirement at her next job. Teaching Nuxt to her teams reinforced her conviction, as even a non-developer colleague on her team could understand the project structure, confirming that the framework's conventions were intuitive beyond just her own perspective.
00:07:19 - Comparing Vue, Nuxt, and the React Ecosystem
Christopher Burns, coming from a React background, asks what Vue is without Nuxt. Debbie draws a direct parallel to React without Next.js or Gatsby, explaining that Vue alone is a single-page application framework while Nuxt adds server-side rendering, automatic code splitting, file-based routing, auto-imports, and a rich module ecosystem of around 150 plugins.
The conversation naturally moves into the concept of meta frameworks, which Debbie notes is the term Google Chrome's team uses for tools like Nuxt and Next.js. Chris probes how far Nuxt goes out of the box versus what developers still need to add, and Debbie clarifies that things like authentication and CMS integration come through modules and third-party services like Auth0 and Storyblok rather than being built into Nuxt itself. The discussion of NPM packages and the Nuxt plugin system provides a natural bridge into talking about component sharing challenges.
00:13:36 - Introducing Bit.dev and Component-Driven Development
Debbie explains how Bit.dev solves the problem of sharing, discovering, and collaborating on components across teams and projects. She describes the platform's ability to display component compositions, dependency graphs, live test results, and code, giving teams visibility into what exists and how components relate to each other.
A key differentiator she highlights is the collaborative workflow: a teammate can import a component, fix a bug, export a new version, and make it available to everyone without needing access to the original repository. Chris connects this to his own experience of finding 80 inconsistent buttons across a project and suggests Bit is less a Storybook replacement and more a solution to the painful monorepo component library problem. Debbie agrees, emphasizing that Bit supports flexible working arrangements whether teams prefer monorepos or distributed repositories, and that it handles more than just UI components, including hooks, Node modules, and serverless functions.
00:20:03 - The Complexity of CSS in Component Libraries
The conversation takes a deep technical turn as Chris and Debbie discuss how Bit handles styling dependencies. Debbie clarifies that Bit does not precompile components; instead, it ships them with their source styling, meaning consumers must have the appropriate loaders or compilers in their own projects to handle Sass, PostCSS, or other tools.
Chris raises the thorny problem of CSS-in-JS compilation across component boundaries, and Debbie argues that not compiling is actually a feature because it preserves the ability to apply theme providers and customize components at the consumer level. The exchange highlights a fundamental tension in the JavaScript ecosystem between convenience and flexibility, with both acknowledging that CSS dependency management in component libraries remains one of the harder unsolved problems in frontend development.
00:27:20 - Bit vs. the Competition and Building with Your Own Product
Anthony asks if there is anything truly comparable to Bit on the market. Debbie says she has never found an equivalent tool despite years of trying to solve the same problems manually at various companies, noting that the Bit team has been working on the product for seven years. Chris suggests that combining Verdaccio, a private NPM registry, with Chromatic might approximate some of Bit's functionality, but Debbie pushes back on the collaboration gap.
Debbie shares how Bit is built with Bit itself, which creates a valuable dogfooding loop where the team discovers missing features firsthand. She gives the example of needing Markdown support inside React components and the team simply building a Markdown aspect on the spot. This practice of using their own product drives rapid iteration and ensures the tool genuinely serves developer needs rather than theoretical use cases.
00:36:02 - Remote Work Culture and Discord-Based Collaboration
Anthony brings up Debbie's article about her company's Discord-based remote work setup, comparing it to a Panopticon where everything is visible. Debbie pushes back on this characterization, explaining that the system is about signaling availability and enabling spontaneous collaboration rather than surveillance. Being in a "recording studio" room simply tells colleagues she is unavailable.
She contrasts this with her previous remote experience at Nuxt, where the company was still figuring out distributed work processes. At Bit.dev, she can see who is available, jump into quick screen-sharing sessions to solve problems in minutes, and maintain the casual social interactions that make remote work feel less isolating. Rather than requiring scheduled meetings for every question, the system lets people work faster and more naturally while still respecting boundaries.
00:40:41 - What's Next for Bit and Closing Thoughts
Debbie shares her excitement about Bit's upcoming features and its approach to continuous shipping, where a new version goes out every day during the public beta. She describes tools she has personally built, including generators for React hooks and components that scaffold all necessary files, and a demo project system that avoids the friction of git cloning.
The episode wraps with lighthearted banter about Irish and Scottish heritage, EU freedom of movement, and the joys of living in Spain. Debbie encourages listeners to find her on Twitter, LinkedIn, or her website, and specifically invites people to join her Twitch streams where she openly builds React applications as a learner, embracing mistakes in public. Anthony and Chris thank her for being a great sport through their challenging questions, and the conversation ends on a warm, fun note.
Transcript
00:00:00 - Debbie O'Brien
Chris agrees.
00:00:12 - Anthony Campolo
Debbie O'Brien, welcome to FSJam.
00:00:15 - Debbie O'Brien
Thank you. Hey.
00:00:16 - Anthony Campolo
Super excited to have you. You are someone who does very similar work, I think, to what I do, so we're going to have fun getting into that. You're an advocate. You've been an advocate for both open source projects as well as companies with products, and we're going to get into a little bit of everything that you do here.
So why don't we just start off by telling the listeners who you are and what you do?
00:00:38 - Debbie O'Brien
Cool. So yeah, my name is Debbie O'Brien. You should all know me by now. No. I'm Irish, but I live in Spain because, you know, the sky is bluer here. I used to work at Nuxt as a dev advocate, and now I'm working at Bit.dev.
Basically, I just have fun sharing cool things with the world. I think that's what our job is about now in dev advocacy. It's like, do cool things and show people cool new toys that they can play with and learn from.
00:01:02 - Anthony Campolo
You had just transitioned to this job recently, right? How long have you been working for Bit?
00:01:07 - Debbie O'Brien
I don't even know what date it is today, but yeah, is it like six weeks? Is it even like... It's a month and a half, I think, more or less.
00:01:14 - Anthony Campolo
Awesome. Yeah. How's it been going so far?
00:01:15 - Debbie O'Brien
It's been amazing, but it's also been a massive change for me because I went from being, and this is not putting myself up there, but I went from being almost at the top of my game in the whole Vue world and knowing what I was doing and being able to build fast and live stream and do stuff, to going into a world where I'm building in React and I'm like a junior developer who doesn't even know how to build a component, making very basic mistakes and trying to figure things out.
We're in TypeScript as well, so now TypeScript is thrown on top of me, plus a new product, plus a new team. It's a lot to take in. It's a lot to do. It's been fun. It's been a challenge, but it's been great fun.
00:01:50 - Anthony Campolo
I'd love to get into this whole arc you've gone through, and we can start in the Nuxt world, because this is, I think, where a lot of people would have first gotten to know you. This is something that I had been aware of for a while, just looking at the front-end landscape and the different things that were around. But I also listened to a lot of podcasts, so I kept hearing you come up on many of them.
And it was great because when you listen to these podcasts, you hear so many people come on who do so many different things. There are people who find something they love, and they go out and talk about it and do it so much they eventually get involved in the project. And there are people who come onto a project to go out and talk about it. It doesn't necessarily mean that the people who are brought on to go out and talk about a thing aren't genuine or passionate about it, but you can kind of feel the difference.
[00:02:40] I think you hear this when you listen to people talk about these things. And so hearing you talk about Nuxt, it just reminded me so much of my own journey with Redwood and how it was a tool that I genuinely used and loved and wanted to learn more about and wanted to get involved in and wanted to meet the people who were doing it.
So I would really love to hear how you very first came in contact with Nuxt. What was the very first way you even heard about it, found out about it, or used it at all?
00:03:04 - Debbie O'Brien
We were trying to solve a problem in a company where we were moving toward using a modern framework, because we weren't. So we were testing out every framework and kind of seeing what would work best. And Vue was very young at the time, so we started testing out Vue. There was a meetup at the end of the conference which demoed Vue, so I got to kind of really see Vue. So I was like, great.
Then we started trying to build a demo or a proof of concept for the company, but we were having problems with server-side rendering and we couldn't get it to work, and we tried and it wasn't working, and it was a nightmare. So I reached out to the guy who did the meetup, Eduardo from Vue Router, and I kind of said to him, like, hey, look, I love Vue. This is an incredible framework, but I'm having problems with server-side rendering, you know, and what do I do?
[00:03:48] And he's like, Debbie, just use Nuxt. I was like, okay. And that's kind of how I then started using Nuxt and getting involved in Nuxt. And as soon as I saw how... Well, to be honest, I'm going to be very honest here, I actually didn't really like Nuxt when I first started using it because Nuxt was doing all this magic for me, and I didn't understand what it was doing, and I couldn't figure out why things were happening.
And I was like, I don't like this because, you know, where is my router file? Why is all this happening? I can't control anything. They're doing all this and I want control, right? Where's my Webpack config? I want to play with my Webpack config. When you start to learn Nuxt and you really understand what it's doing, you kind of go, actually, I don't want to play with Webpack config. I don't want to build a router file. Let Nuxt do that for me.
[00:04:31] This is actually cool. This is improving my developer experience. Pretty much from that moment, I just started to fall in love with Nuxt more and we started to use it.
I changed companies at the time, and one of the things I said in the job interview was like, I want to use Nuxt, I want to use Vue. And they were like, well, you're going to lead the team so you can use whatever you want. It's like, great. And when you start teaching Nuxt to people and teaching how easy it is, I just found we could get work done very quickly. Therefore, the more I worked with Nuxt, the more I loved it, and therefore the more I just wanted to share that knowledge and contribute to it and speak at conferences and do things.
And yeah, I was working at an agency at the time, and I was basically advocating for Nuxt in my free time because I just loved it so much.
00:05:13 - Anthony Campolo
That's cool how you say you were teaching it, because to me, that's also a good litmus test. You can learn a tool and find that it fits your mental style really well, but you still can't really know if that's just because it happens to fit your brain really well or if it is actually a simple, nice abstraction for everyone.
And so once you go out and start teaching it to other people and find that it gels with other people's brain styles as well, it's kind of like this confirmation of, okay, I'm not crazy. There are other people who this also makes sense to.
So I'd be curious, what was the context in which you were teaching people Nuxt?
00:05:45 - Debbie O'Brien
So again, I was leading teams, I was leading developers, and I was working on different teams, and I needed to get them to build the products. Because I'm alone, I can't build everything, so I need everyone else to be able to do what I do. And we're going to work with Nuxt, and we were shipping Nuxt for different clients, so I needed everyone to be onboarded to Nuxt, to know it as well as I did, and to be able to just, you know, ship and deliver.
And one of the interesting things was that we had someone on our team who was half on my team and half on the marketing team. She wasn't a developer, but she was on my team for kind of half of the time. And I wanted her in all those meetings, and she was even able to say, like, yeah, no, that's where your pages go. That's where your components go. That's where this goes. And she was almost able to teach Nuxt, right, without developing.
[00:06:32] She knew how Nuxt works, which means any designer or non-front-end person can come into that application and easily know where code lives and easily be able to understand it, or, if they needed to contribute to it, if it was a back-end developer, for example. And I think that was the thing that was like, you know, everyone just gets it. Everyone just understands Nuxt.
And I've done a lot of calls with clients when I worked at Nuxt where I interviewed them. They're going to have it on the website hopefully soon, showcases. And I interviewed clients and they all kind of said, like, we just love how easy it is for non-developers to be able to contribute to the project, to be able to go in and you just understand where everything is and you can see it, and the layout structure, the project structure, you know, where you have the components folder, the pages folder, the layouts folder. It just makes sense to people.
[00:07:17] Right. And you want things to make sense, right?
00:07:19 - Anthony Campolo
Thank you for humoring me with those answers. I know you've told these stories a million times on other podcasts, but we have just a few listeners here who probably don't really know you as well. So Chris here is not a Nuxt or Vue developer, but I know that he's used other similar frameworks, so I'm sure he has thoughts.
00:07:38 - Christopher Burns
Back in the day, I started with PHP, and then I found my way to JavaScript. I first went React Native and then followed that to React. My first real big question: I have friends that play around with Vue and other languages. I treat them as outsiders, personally, having never been enlightened by the React spotlight. I'm just joking. But what would you say Vue is without Nuxt? Because every time I hear about Vue, everybody always says just bundle it with Nuxt. But what is Vue without Nuxt?
00:08:11 - Debbie O'Brien
What is React without Gatsby?
00:08:14 - Christopher Burns
And Next, the standard framework?
00:08:16 - Debbie O'Brien
Just a standard framework. Yeah, it's just a single-page application that gets the job done. It's the code. It's the mother. It's the base of everything, right? If you take Vue away from Nuxt, there is no Nuxt. Nuxt needs Vue, just like Gatsby needs React.
00:08:28 - Anthony Campolo
You don't have pages and you don't have a router. That would be what I would say. You don't have pages or a router or anything involved with a server. That's what you lose.
00:08:37 - Debbie O'Brien
I think it's easier in the sense that things are done for you to make the developer experience better so that you can develop faster. And the same with Next, right? Next is a fantastic framework. If you're a React developer and you want to just have server-side rendering or static pages and not have to worry about making your router and doing code splitting and stuff because Next is going to do it all for you, Nuxt does it all for you if you're in Vue. And yeah, it's making life easier, I think.
00:09:03 - Christopher Burns
Yeah. So in essence, obviously a lot of our viewers are very React-centric. So what Nuxt is, is the wrapper around Vue to obviously provide things like an API-level authentication and all these other more complex things, or not necessarily more complex things. It's just more in the middle, where it's just like Gatsby, you.
00:09:24 - Debbie O'Brien
No, like authentication, no. I mean, Nuxt, again, Nuxt is very similar to Next. So if you're a React developer and you know about Next, and I'm sure you do, and Nuxt is inspired by Next, right, the two projects have been kind of like going side by side and they're very, very similar. If you were to do a course on Nuxt and you're working in Next, you're going to go, oh yeah, I get this. Just the syntax is a little bit different. One or two things are different, but it's very, very similar concepts and it's just about getting things done quicker and not having to deal with certain things such as...
Nuxt will give you auto-import of components, so you don't have to write import component from component and write that in, right? It's going to be auto-imported for you once you're using it, and then it's tree-shaken. So if you're not using it, you're not getting that bundle. You get automatic code splitting. It does all that stuff for you for performance benefits, so that you don't have to. Like a PWA, you can just install a module, you get a PWA, right? Search engine optimization, you can add all the head kind of stuff. You get a lot of stuff out of the box.
So it means you can just get started very quickly and develop very quickly, which is what people want, right? They just want to get the job done.
00:10:32 - Christopher Burns
I totally get that. It's kind of like my litmus test to see where it sits on the framework scale. We have frameworks, and now we have a new stage of frameworks that are like meta frameworks.
00:10:42 - Debbie O'Brien
They're called meta frameworks.
00:10:44 - Christopher Burns
Yes. Meta frameworks. I was going to use the word meta frameworks.
00:10:48 - Debbie O'Brien
It's what Chrome uses to describe them. And Chrome works very heavily with the Nuxt team and with the Next team to ensure that these meta frameworks are performant and that people are using them the right way, and they're being built the right way.
00:10:59 - Anthony Campolo
To make sure that they're AMP-ready.
00:11:01 - Debbie O'Brien
Yeah, for example.
00:11:03 - Christopher Burns
So, for example, we see things like Blitz that is built on top of Next that obviously then adds all the authentication, API-level things, all the functionality to just take that application a step further.
So the reason I asked was to see how far it does go by default, because that's a really good question, as in, as you said.
00:11:26 - Debbie O'Brien
You use modules.
00:11:28 - Christopher Burns
Yeah. All the things that you do and how it's meant to speed you up, that's great. But how much stuff do I still have to do on top? Do I still have to define all my user authentication?
00:11:38 - Debbie O'Brien
For sure. I mean, Auth0 is the best, right? In authentication, you want to use that. You're not going to use Nuxt to build a custom... That would make sense, right? If you're going to use a CMS that has the UI and stuff, then you want to use something like Storyblok or Prismic. And, you know, what we do is give you a module so that you can easily integrate it, so then you can easily use it. You want to use Storybook to, you know, compose your components, et cetera, then you can use that.
So I think Nuxt has about 150 modules. And you can just use these to improve your developer experience, right?
00:12:10 - Christopher Burns
And that brings me on to the next question. And someone who's not a Vue-er, as you may say, more like the React-er in this audience, do you still install random packages off NPM that are oriented to Vue? That's a really good question that I don't know the answer for because I've never used Vue and I've only used React, where you go, I need a tooltip, React tooltip. Ah, there we go. That suits the job.
00:12:37 - Debbie O'Brien
I would answer in a way of saying yes, we do. And what we do is you would take that and create a plugin, and then you're using that tooltip. So you're installing it as a node module, and then you're using it as a plugin in Nuxt. Because you can't use a Vue NPM package, right? You've got to use it through a plugin. And then you use that plugin and then you've got that Vue tooltip or whatever it is that you want, or the calendar or the date picker or those components you never, ever want to create yourself.
00:13:04 - Christopher Burns
So you say that the plugins and components are more tightly coupled in Vue than necessarily in React. As in React, you just install them randomly off NPM, but in Vue you have to take a few extra steps to be...
00:13:18 - Debbie O'Brien
No, not in Vue. In Nuxt.
00:13:20 - Christopher Burns
Nuxt. Sorry.
00:13:21 - Debbie O'Brien
Yeah, yeah, yeah. Because I don't know how it works in Next, right? So I'm not familiar if they have a plugin system or not. But this is how it works in Nuxt. But of course, right now what I'm working on is a solution to that problem in itself, in a way.
00:13:36 - Christopher Burns
Yeah. That's where my questions were leading. As in, I've looked at Bit before and I know one of the main things it does is, you know, you've got 20,000 components across your 20,000 projects. Put your button on Bit and you can just share it between every project. That's the whole premise of it, to what I understand.
00:14:00 - Debbie O'Brien
Yeah, pretty much. I mean, it's about sharing your code, but sharing your code in a way that not only can be used on any repo, any codebase in your organization if you keep it private, or across the world if you make it public, right?
But it's also a way for you to see a collection of your components. Have you ever worked in a company where you're creating components and you get to a stage where you actually don't know what the teams have created, what you have, how to find out, like who's created this before? Where is it? Being able to see everything, search for it, find it easily, see it, see the different compositions of how it looks depending on if it's primary or secondary buttons, for example. Seeing that the tests are passing live in the cloud or in your local dev server, and seeing the code as well. Because you can also see the code, see what dependencies there are, and see the component dependency graph of what components depend on that component.
[00:14:53] Right? So your card component is made up of the button component plus the title component and the description component, and maybe the stars component and maybe the price component, right? And you can see how it's all made up.
One of the great things that it does is it's not just about you sharing those components, but about you working with the components in a better way. For example, imagine me and you are working together, right, and working in React because that's what we're doing. So we built this React component. We built this card component, and I've put it up in the cloud. And then, I don't know, you found a mistake in my work because I'm not a very good React developer. So I make mistakes and you see it and you go, no, I'm going to fix that. Well, you can just import it. Obviously, we have user permissions because we're working on the same team. So you're going to import my component and you're going to fix that component.
[00:15:37] This is in your workspace, right? So you don't have to go to my repo. You don't have to go into the repo. You're importing it into your workspace where you're working. You make that change and then you export it and you create version two or whatever version. And then basically, when I come in the next day to work, I've got this new version that you've made better, and this one is going to be used in, you know, all the applications. And then you can just eject that out of your workspace because you don't want it to live there, right? You just eject it out and it's gone and it's not in your way anymore.
And that's cool, right? That's something like what we used to do in the past when we copied and pasted and modified, only we kept that copy-pasted, modified version there for life, right?
00:16:13 - Christopher Burns
I think the easiest thing that I've done in the past month that very much shows me why things like Bit and more Storybook-driven development can be important is when you decide and you notice that there are loads of buttons in the application and they're not all the same, and you go, I think I'm just going to make one PR that fixes every button into the same structure.
You start going through it and you're like, the PR turns out that you've changed 80 buttons through the application. And it's just like, how? How are these not all the same? It's like because you never defined a default component in the first place, and then you had different use cases in different areas, you know? So that means different props, different colors, different blah, blah, blah. You know, it just gets so easy to get lost sometimes.
Something that always, always sticks with me: you get it working and then you refactor. And a lot of people, and this is not even a bad thing, get it working and never refactor. So they get it working. They put a button in there because it doesn't need to be the official component.
00:17:24 - Debbie O'Brien
Or it suits their need at that moment. They think of one thing.
00:17:28 - Christopher Burns
Exactly, and then it's never refactored into the standard way. And look, when I said there's 60 buttons in the application, 80% of the application was written by me, so you know I'm my own devil here, devil's advocate. So it totally makes sense.
And I think what really interests me about Bit and that whole strategy is it almost seems like a replacement for something like Storybook, but actually it's not a replacement for Storybook. It's a replacement for a god-awful monorepo situation where you have a component library and that is really bad. I've tried it multiple times and cried my way out of it and gave up multiple times.
So the point is, well, I've had the same button in two different projects just because I didn't want to deal with a monorepo because they made me cry.
00:18:21 - Debbie O'Brien
Yeah, and it's funny because it allows you to work in a monorepo if you want, right? You can have all your code there. But the great thing about it is you can do what you want. You can work how you want to work. Like you could literally put all your components in one repo. You could have them in 20 repos and then just export them all to the one kind of cloud and stuff. You have to work how best fits your needs as a team, and if that means all working on one monorepo, perfect. If that means separating out so that, you know, Chris works in one, I work in another, you work in another, Anthony. We all work on different repos, but we all export it to one organization. Whatever works, it doesn't really matter because you can choose what works for you.
But at the end of the day, we can all use those components. We can all see those components. We can all use them. We can version them. If you break it and I still don't want to, I don't like your version because it's just crazy, and I still want to use my version one, I can still just remain on version one for the rest of my life. That stays there, and version two can be for everyone else. But if you want to just update it and use it across the projects, everyone updates to version two and happy days.
00:19:17 - Christopher Burns
My next big question for something obviously like that is that, as you said, it's not just having the component. You allow the component to be installed through Yarn or NPM. You obviously provide the install command to make it easy, and then you obviously import it if you're talking about React.
And I think what's really cool about that is, as you said about different versions, so say you have one project in Next and a different project in Redwood, but they both need the same button. And I assume, and this is where my golden goose question is, that all your styles and things like logic that you choose to bundle are already precompiled, so it doesn't matter what they were made with, if that makes sense.
00:20:03 - Debbie O'Brien
Yeah, but it's not how you're thinking of things at all. So if you're going to build a component with Sass, you're not getting a rendered component with the Sass converted to CSS and ready to use. That's not what's happening. You're getting that component that's going to depend on Sass. And if you're going to use it in your application, then you're going to have to add to your application a Webpack Sass loader to be able to use that component.
So we don't think about...
00:20:28 - Christopher Burns
You don't compile the components.
00:20:30 - Debbie O'Brien
No. We leave that to you guys to figure out where you want to use it and how you want to use it.
00:20:36 - Anthony Campolo
Chris doesn't like hearing that something's left to him. That's not good.
00:20:39 - Christopher Burns
No, no, no. I'm going to bring up the perfect example why it's a good thing and a bad thing. It's a good thing because, as you said, you leave it up to you to do whatever you want. But it's a bad thing if you use two projects, one using PostCSS 7 and one using PostCSS 8, where they're breaking and they complain at you all day. Anthony's laughing.
00:21:05 - Debbie O'Brien
No, and that's why you should document your component and you should make sure that, you know, like this is a component that uses what it uses, right? You can see what's dependent on it. You can see the dependencies, so you know in your project what versions it depends on, for example Tailwind.
Right. Maybe you have a component that uses Tailwind, a component that uses Sass, one that uses PostCSS. Are you really going to mix all those into your application and use three different CSS frameworks or whatever, right? You have to decide if you're going to use that, and does that make sense in your application? Because if it does, then go ahead and do that. And then, you know, that's going to be compiled on your end and it's going to be slower because you've got to compile source and everything. Maybe that works for you because maybe that makes sense, but that's up to the person who's building that application, because we're thinking about components and we're thinking that component is built this way to be used this way.
[00:21:56] And yeah, we don't want to put Webpack in there and start doing build times, start doing all that kind of stuff. Do you know what I mean?
00:22:02 - Christopher Burns
Yeah. No, it's super interesting because it then backs up the question. That's a really hard one in JS and CSS. You maybe never touched it, or maybe have.
00:22:13 - Debbie O'Brien
Played around a little.
00:22:14 - Christopher Burns
Is the whole thing of, so say you're doing a component, I mean, you just use CSS-in-JS. You can run across the problem where your component gets piped to your application, but the styles are not even being compiled because the JS and CSS doesn't compile in the component library, it compiles in your local repository, but your local repository doesn't know to compile your component library.
So what you end up having to do is run a preprocessor like Rollup to compile the JS into CSS in your component library before it gets piped to your application. This is why these kind of things get really complex, because they need very specific tooling that is still really hard to come across. For example, some people do it to Windi Macro. They have a repository where they explain, like, here's your subcomponents that use macro that's based upon styled components.
So you've got exactly the same problems in styled components or Emotion. But it's this whole thing of like, okay, when you say you just want a component library where you can share two things between each other, it gets really complex really fast because of CSS.
[00:23:33] It's one of these really hard things that I think we're still yet to fully solve, making everything not interdependent. But as you were saying, you just import the one thing in the tree of dependencies hidden with things like component libraries.
00:23:50 - Debbie O'Brien
That's a lot to go back over, right?
00:23:52 - Christopher Burns
That's me rambling about all my problems with component libraries.
00:23:56 - Debbie O'Brien
Let me see. And again, I haven't worked enough in the React ecosystem to play around with so many different styling ways of doing things, right? The way I can answer this right now, to the knowledge I have, and if I do it wrong, you'll be giving out to me, right?
00:24:12 - Anthony Campolo
Just keep in mind they're all equally obnoxious.
00:24:15 - Debbie O'Brien
No, you have a lot of choices, right? That's for sure. Styled components, Sass, CSS-in-JS, et cetera, right?
But let's take Sass as an example or Tailwind as an example, right? Both of those as an example. What you need to have in the actual component itself, because that component needs to work in isolation, right? That component is going to work with Sass. If it's a Sass-built component, you're going to be able to see it because it's using Sass and the compiler is set up to have Sass, to have Babel, to have React, to have whatever, right? But it's a dependency that doesn't get shipped with that component. But that component will expect it.
When you go to consume that component, you now have to install that dependency into your application or wherever you're going to use this component. That's basically a good point because you can see what's being used. So testing library, right? If we're going to go into testing, imagine we would like to ship that component with all those dependencies.
[00:25:11] Every single component would just be like a massive balloon.
00:25:15 - Christopher Burns
It's a balloon tree. It's a really hard problem. It's like, okay, we choose to compile it down to the CSS, so no matter what compilers you need on CSS, it's all done. But then it's kind of like, but that's a super hard problem sometimes, even with, you know, CSS, Sass. I've not used Sass for some time, but it's always stuck with me. The nesting was the reason to use it for me.
00:25:39 - Debbie O'Brien
But what about design systems and things like you want to be able to make that component be able to be consumed inside and have a theme provider that allows it to be modified. And if it's already in a dist folder and it's completely compiled, right, you have no... That's it. That button is green for the rest of your life in a story, whereas if it's not compiled, you can then put it somewhere, put a theme provider on top of it, and decide that that button is going to be blue because your theme consists of that or whatever, right?
00:26:07 - Christopher Burns
I totally get it. And it's, you know, it's that thing of, okay, if you had a project that didn't have CSS, but your component library now requires PostCSS and you go install PostCSS into that client, it totally makes sense in the grand scale of things. To keep things simple, it's just a tiny thing that I wish could be solved, but it would probably get solved and I'd go, that's not what I meant. So back to the old way.
00:26:32 - Debbie O'Brien
Yeah, exactly, exactly. Remember, when you're building your components, you always have to think about the fact that this component is going to be used in an endless and infinite way that you want it to be used in, right? Obviously, you're building that component as an API. You're deciding that you're going to be able to change the background color, the main color, you're going to be able to add an icon in there. Perhaps it's a button, right? You're going to be able to do this to it. And that's as far as it goes, right? So you control that.
But you also think about the possibility of where that button is going to be used, who's going to be using it, and you build it for a bigger audience, like you said earlier, right? You build that for you just for right now, not thinking about the future of that component. And this kind of way of building is making you think about who is going to consume it and what they're going to be able to do with your button and how they're going to be able to...
[00:27:20] I'm using a button example, and in my company they hate me using a button example. Like, it's not just always about a button, right?
00:27:26 - Anthony Campolo
Well, we're building buttons, so.
00:27:27 - Debbie O'Brien
Let's.
00:27:29 - Christopher Burns
Go with my second favorite, a toggle, a drop-down, or an avatar.
00:27:34 - Debbie O'Brien
Lovely, lovely. Well, you know, and this is another thing: remember that you're not just sharing UI components, right? You're also sharing hooks, right? So you can share a React hook. You can share node modules. You can share anything, right? So you can share a serverless function and reuse that across your applications. And that's where it's powerful.
So, and this is where people say sometimes Bit and they think Storybook because they're seeing UI. But we built Bit with Bit, and there are aspects, hooks, all sorts. So it's not just UI.
00:28:09 - Anthony Campolo
Yeah. I wanted to get into this actually. This is a really good segue because Chris brought up Storybook. I brought up Storybook when we were talking a little bit before the show.
00:28:17 - Debbie O'Brien
And Storybook is great, right? You can use Storybook with Bit, right? So don't get me wrong, I'm not saying we're taking... Storybook is great if you want to keep using it. We integrate very easily with Storybook and you can keep using it. It's great, but...
00:28:30 - Anthony Campolo
I think it's so funny, like going back to all the parallels I see between what you do, what I do, our backgrounds. It's the same thing. It'd be like people would constantly ask, like, what is Redwood like, this? And there would be a this, and it would never be the thing that was actually most similar to Redwood. To me, the thing that's most similar to Redwood is Amplify AppSync. And I've never, ever been asked a question about that from anyone in a Redwood talk. And I find that so strange. Everyone will ask about Next and Blitz and all these other things.
So I'm curious, and I know some people don't really like talking about competitors, so I hope I'm not putting you too much on the spot. But do you think there is something similar to Bit out there that you would want to compare to it, that you do actually think, if you wanted someone to get a mental model to understand it, you could point to something else? Or is there nothing else?
00:29:11 - Debbie O'Brien
You know, I can't believe that we're in the year we're in and that there is not a tool like Bit, because I've had the problem and tried to solve the problem in many companies. I've created a Bit mini version, right? I've created that component library where we're sharing it, but I couldn't figure out how to import one component. We ended up having to NPM package everything.
And, you know, NPM package is different to what Bit has built, right? Because it's just completely different. So the whole way of being able to see the components, the dependency graph, the tests, all these features are something I wasn't able to build, right?
And this company had been working for seven years on building this. And the first version has been out for many years. The new version is in public beta and obviously it's much more improved because they've even learned from the first product that they built that this doesn't work exactly how they want it to work. So they end up having to build on top of that.
[00:30:02] And they built Bit with Bit, right, which is crazy. And I'm doing the same right now at work. And it's like, it's actually really hard to build with your own product. And like, we are the ones that use our own product. So if it doesn't work for us...
Like I was building the other day where we put in, there's no tests, right? You have no tests. So instead of having an empty card that kind of says you have no tests, yay, we put something really cool in there that says, to create tests, all you need to do is this. And here's how to do it. And then you've got a test, right? Because then you just copy that code, even copy the code snippet, put it in a test folder, you've got a test up and running. Then you'd be more inclined to write a test, right? Rather than say, here's a link to the documentation, but you're never going to read because you don't read because you're a developer.
[00:30:42] So, like, you know, we're building that. And like, I couldn't get my head around it. I was like, I need Markdown. This should be Markdown. I should be able to just put Markdown in here into this React component. Why can I not do this? And then they just went and built a Markdown aspect, so we can now use Markdown inside the React component. And now it all just works exactly how I want it to.
So we build the features as we're building Bit, and that makes it easier for us to make sure it's built how developers want it to be built, because it's built how we want it to be built as well, and how we're using it. And then as more people use it, we learn from other developers and what features are missing to improve it on.
But back to your question, if you find something like it, let me know because I have never, in all the years I've been working in front end and I've suffered quite a lot in many companies, ever seen something like it.
[00:31:28] And, like, I can just tell you the things that are coming out in Bit. It's like it's going to blow your mind. Like, seriously, it's insane.
00:31:36 - Anthony Campolo
That's cool. Yeah, it's a bit of a catch-22 to be in because you are going to have a hard time explaining it to people. But if it is a truly unique thing, like, that's a real value prop, you know, that means you can actually say, I can offer you something that no one else can.
00:31:52 - Debbie O'Brien
It's a solution to your problem. That's basically what we're offering, a solution to all your problems, to help you work in a better way. You choose the framework you want to work in. React, work in React. You want to work in Vue, work in Vue. But you're able to collaborate and work better.
00:32:04 - Christopher Burns
I really could.
00:32:07 - Debbie O'Brien
Say it. Come on, Chris.
00:32:10 - Christopher Burns
Two products that are like Bit when put together.
00:32:14 - Debbie O'Brien
Okay.
00:32:15 - Christopher Burns
Verdaccio and Chromatic. Obviously there's a lot of manual gluing to do there. Chromatic is that... Have you never...
00:32:24 - Anthony Campolo
I've heard of Chromatic because it's connected to Storybook, but I haven't heard of the first one you mentioned.
00:32:28 - Christopher Burns
So Chromatic is like we host your Storybook on the internet.
00:32:34 - Debbie O'Brien
Is that what you think it is? Is that as far as you got?
00:32:38 - Christopher Burns
Wait, wait, wait, wait.
00:32:39 - Anthony Campolo
You said it was part of it. He said it was.
00:32:41 - Christopher Burns
Part of it. I only said it was part of it.
00:32:43 - Debbie O'Brien
Right.
00:32:44 - Christopher Burns
We host your Storybook on the internet, and Verdaccio is a really cool product that not many people know about. It's not really a product. It's more of a project. Redwood does use it.
00:32:56 - Anthony Campolo
It's an NPM proxy registry. I don't even know what that means. I mean, I can kind of assume what that means, but that's interesting.
00:33:03 - Christopher Burns
So say you want to host some NPM packages, but you do not want them to be on the World Wide Web, such as NPM. So you host them in your own NPM repository that you can then import into your NPM projects. If you put those two things together, it kinda is a little...
But there's a big thing here that, don't worry, don't worry, it requires a lot of probably manual time, yanking things around and installing a lot of duct tape. What you're saying is you've got the golden path to me.
00:33:39 - Debbie O'Brien
Well, I'm just saying, I'm sure these products are great, and I just opened it there and I'm like, yeah, a private package manager. Is that the solution to your problem? As a package manager, you're going to have to import that package, right? Now you want to change that version. Like I told you earlier, we're going to collaborate together. Where's the collaboration in here? Can we collaborate together using Verdaccio? Are you going to import that and make that change and export a version?
00:34:03 - Christopher Burns
You're selling me a business proposition. I just sold you a developer proposition. And those two things are very different.
00:34:10 - Debbie O'Brien
No, I see as a developer, if we're going to work together, you're going to help me and you're going to fix my problems when I have problems. And I would hope that you would do that because we are a team and I want to work as a team as a developer. That's just me. I like teamwork.
00:34:22 - Christopher Burns
No, no, no.
00:34:22 - Debbie O'Brien
You work on your own. You build your 25 buttons.
00:34:25 - short split/interjection
[unclear]
00:34:26 - Anthony Campolo
Zero-sum or not is what we're getting at.
00:34:27 - short split/interjection
Yeah.
00:34:28 - Christopher Burns
No, don't worry. I'm not saying it is bad because I've looked at it a few times. I've just never integrated it myself. I'm not saying Verdaccio isn't the solution to these things, because obviously then you've got to also host it on Docker and manage a server by yourself. And if that goes down, your whole team will kill you and there'll be downtime when you could just point a finger at a different company to fix your problems.
00:34:53 - Debbie O'Brien
Yeah, well, you could host it on your own as well if you want. If you're a developer that likes, you know, doing all that kind of stuff, you can host it yourself.
00:35:00 - Christopher Burns
Yeah. I like to point my finger at other people when things go down.
00:35:05 - short split/interjection
Chris loves stuff.
00:35:06 - Anthony Campolo
On PM2, right?
00:35:08 - short split/interjection
Yeah.
00:35:09 - Christopher Burns
Well, you say that, Anthony. The other day I woke up one morning, my whole server was deleted off PM2. All gone. I'm like, what? Why? Dunno. Couldn't ever get to the bottom of it. Just had to reinstall PM2 and it started working again. But then things happen.
00:35:27 - Debbie O'Brien
And one thing I want to say as well is remember, like, it is open source, right? All those components that are created that are not enterprise are open source. So, you know, you can choose to use it and you can choose not to, and you can leverage other people's amazing work, which is great because I love stealing people's work because I'm so bad at building stuff. So I like designing. So sometimes, you know, someone's going to build a really cool component and save me a lot of work. I'm quite happy to use their code.
And I think that's one of the things I like about it the most. Being open source to me is really, really important, and being able to give back to the community.
00:36:02 - Anthony Campolo
It's definitely a big thing with us, so you hit the right note with that one. It sounds like it's a really interesting product, a really interesting company. I'll definitely want to check it out. There's a couple more things I want to get into with the time we had left.
You wrote a really cool article about the online working culture of what it is like, and I'm gonna be honest, I read it and it made me think of the Panopticon. I don't know if you're familiar with the term Panopticon. So a Panopticon is a fancy term for an environment where everyone sees everything. It's like a big donut, and everyone lives on the outside looking in so everyone can see everything at all times.
And so your article is about how you're always going to be in a different room in Discord. No matter what kind of work you're doing, you'll be in this room. Even if you're on break time, you'll be in a different room. I appreciate what it was going for, but it seemed like something that I personally would not be very much into.
[00:36:55] But I'd be curious to get your take on it and kind of why you actually enjoy it, because you genuinely sound like you do enjoy this kind of setup that your company has, and I believe that. So I'd like to hear you explain why you think this is cool and why it's not this weird Panopticon kind of thing.
00:37:12 - Debbie O'Brien
Okay, so I came from working in companies very much in office, kind of, you know, meeting rooms are here. You see what's going on. When you're working with a lot of teams, it's very easy. You can hear what's going on. You can jump into a call, into a session, into whatever, pair programming. Everything was very easy.
I only ever did remote work from Nuxt. That was the first company that was remote for me. And it was very different because, you know, Nuxt were learning as well and they had just started as a company, so they were kind of figuring things out. We went through so many platforms and it took them a while as well to get to where they are, because they were the company before who had to test things out and become remote because of the situation.
So it's not like what you're thinking in the fact that, like, if I go to the toilet, I've got to put in and go to a different room because I'm going to the break room to go to the toilet. Like, it's not like that at all.
[00:37:59] Right? But like right now I have Discord open. I am in the recording studio, right? What does that mean? It means if anyone wants me right now, they're not going to get me because I'm recording. And recording means Debbie's attention on you is zero. She's got Slack notifications turned off. She's not going to get on WhatsApp. You don't call her because you're just not going to get her. But if there's something very urgent, she will finish that recording and maybe read that Slack message and maybe answer whatever it is. If it's an urgent thing right now, I might just switch off and go to bed. You know, that's my choice, right?
But I can also see who's in the office. So I can see right now which people are in which room. So if I finish this call and I kind of went, you know, that Christopher one, he asked me a really interesting question on CSS-in-JS and I'd love to know an answer. Well, I know who's available to actually ask them and get that information, because I know who's working and I know who's not. So maybe if I see, oh, no one's in the office right now that I could talk to about that specific topic, well, I'll Slack them or I'll wait till tomorrow because I'm going to forget tomorrow, right?
So it's more about being able to collaborate with teams better as opposed to being watched or whatever like that.
00:39:03 - Anthony Campolo
Yeah, I think that was great. Yeah. Because that, for you, the way you're describing it, it's giving you control over how people perceive what you're doing and when you're available, what you're actually doing with your work hours, versus like just kind of responding to messages whenever, you know. So it's kind of structuring it more.
00:39:22 - Debbie O'Brien
So it's about being able to collaborate better and know when you can jump on a call with someone or not. And not even jump on a call. Sometimes I'll jump in a room and say, this isn't working, I've got this problem. And they're like, oh, share your screen, bang, and in five minutes it's fixed and you're like, great. And you can carry on with your day. And that's what it's about.
It's not stopping people and having to organize a meeting just so you can get something done. It's about working quicker and having team collaboration, being able to get help when you want to ask a question when you want to. And it's really fun and engaging because you hear voices all day. You have people to talk to. And sometimes I might jump in and go, hey, how was your weekend? And you have that kind of fun thing that is missing from the life that we live in these days, right? You want to be able to just talk to people sometimes, and yeah, it works great for us.
[00:40:08] It really does.
00:40:09 - Anthony Campolo
Yeah. No. It's cool. I thought that was a very good defense of the work.
00:40:14 - Debbie O'Brien
I've been defending this whole podcast. I didn't know I was coming on The Defenders podcast.
00:40:19 - Anthony Campolo
We're very critical here, so.
00:40:22 - Christopher Burns
But it's only to pull out the best questions. And that's not a bad thing. If you don't sometimes ask critical questions, you don't find the hardest answers.
00:40:31 - Debbie O'Brien
Well, that's very true.
00:40:32 - short split/interjection
And we know you can take it. We know you can take it, Debbie.
00:40:36 - Debbie O'Brien
I'm so glad you didn't send the questions beforehand.
00:40:41 - Anthony Campolo
Yeah. Is there anything else that you'd like to talk about before we kind of close out here? Anything you're excited about that you want to put out into the world?
00:40:48 - Debbie O'Brien
Obviously, like, I'm going to say I'm excited about it, and that's what I'm here for. But no, seriously, I'm excited that when it comes out of beta, we're going to be doing a lot more kind of like YouTube videos and getting it out there because it's still not finished, right? So that's why we've held back on a lot of the video content and stuff.
It's still, it's not... When you say beta, people say, oh, will I use it, will I not use it because it's in beta? But in developer's life, beta is like, yeah, go for it. But it's not finished and it's just going to get better. I think it should be called better than beta instead of beta, right?
So we're continuously shipping new features. Like this week we shipped, which I built actually, the generator for, like, you know, generating React hooks. You get all the files you need to be able to build that. Generate a React component, you get all the files you need with a dummy test and everything. So literally you can just modify and you can build quicker. And all these tools.
Another one I'm creating is a Bit new demo, and you get a whole demo project, right, instead of having to git clone, because I hate going git clone and clone something. I just want it in my codebase, and then when I don't want it, I just want to remove it because I don't want to use that component because that was a terrible component that we created, right? But I want to use the hooks one or the counter hook or whatever.
It's really cool to be able to work in a company where I get to actually build developer experience tools and listen to developers and what they want. We have a Slack channel. We're very active in that channel. Any message gets answered by us. We look through it, people suggest things and we basically say, oh, that's a great idea, let's implement this. Let's, you know, put it on our list at least of features to implement.
[00:42:14] We have a team that works very, very fast, which is incredible because when you're in Bit, you're able to just ship. We build and ship every day. Every day there's a new version, right?
So if you're working with Bit, seriously, upgrade every day because you're going to get the cool things, and that's much better than waiting for the project to be finished and then saying, okay, here's our lovely, cool tool and it's all finished and you can all use it now. I much prefer this kind of like, here's this cool tool. We're in beta and it's just going to get better and better and better, but have fun and tell us if something breaks and we'll fix it. Or tell us if something is missing and we'll add it.
And that's a really cool place to be in. I think you'll understand that, Anthony, more than maybe Christopher. But, you know, that's a cool place to be in as a developer advocate. You can actually be part of the journey of the growth of the product and help drive it forward into the direction that you think it should go based on what developers want.
[00:43:02] Chris agrees.
00:43:04 - short split/interjection
No, I'm not. I'm not gonna say. No, no, don't worry.
00:43:07 - Christopher Burns
Don't worry. My last question, and I love shouting out the... My guess is that your nationality is Irish and you live in Spain due to the EU freedom of movement.
00:43:20 - Debbie O'Brien
Well, I live here because the sun shines.
00:43:22 - Christopher Burns
Yeah, I love Spain.
00:43:23 - Debbie O'Brien
Yeah, and the beer is cheap.
00:43:26 - short split/interjection
I'm afraid we lost our rights.
00:43:29 - Debbie O'Brien
Yeah. You're not allowed here anymore.
00:43:31 - short split/interjection
No, we're not allowed.
00:43:33 - Christopher Burns
We just assume that everyone will talk English around us in Spain.
00:43:36 - Debbie O'Brien
You could probably get an Irish passport and be Irish.
00:43:38 - short split/interjection
Yeah.
00:43:39 - Christopher Burns
Yeah, maybe.
00:43:41 - Debbie O'Brien
There's ways around everything.
00:43:42 - short split/interjection
What?
00:43:43 - Christopher Burns
What is it? Is it...
00:43:44 - short split/interjection
Us.
00:43:45 - Christopher Burns
Again? Goodness. There we go.
00:43:47 - Debbie O'Brien
I'm sure you have Irish family somewhere down the line.
00:43:49 - Christopher Burns
Probably.
00:43:50 - Anthony Campolo
I actually do. Irish, actually.
00:43:53 - Christopher Burns
So my partner is Irish.
00:43:57 - Debbie O'Brien
There you go.
00:43:58 - Christopher Burns
What's really funny is my partner is of Irish descent, and I'm of Scottish descent.
00:44:03 - Debbie O'Brien
Oh, well then you're a perfect match.
00:44:04 - Christopher Burns
Our names match. I have the Scottish word for the name, and she has the Irish word for the name. So we have almost identical surnames. It's crazy.
00:44:15 - Debbie O'Brien
Brilliant.
00:44:16 - Christopher Burns
I know. That's it for me. Thank you for coming on this podcast.
00:44:19 - Debbie O'Brien
It was... I have to say, it was more fun than I imagined, more challenging than I imagined. But it was...
00:44:27 - Anthony Campolo
You were a really great sport. We appreciate you answering all our questions. We try to go deep on this podcast. We think that that's where the listeners really get a lot of value, and you have a lot to say about what you're working on. So we're happy to get the opportunity to hear how you think about these things. And you're an advocate, so it's good to give you the chance to really advocate for what you're doing.
And then why don't you also let our listeners know how they can get in contact with you, like what your socials are.
00:44:52 - Debbie O'Brien
Yes, I live on Twitter, like practically. So Twitter is the best and it's at underscore O'Brien. And I would say just reach out on Twitter for anything. My DMs are always open, so just ask a question.
I'm also on LinkedIn as well, Debbie O'Brien, and my website is Debbie Codes. So if you go to that, in the footer you're going to find the links to my YouTube channel, to my Twitch channel. YouTube does have a lot of Nuxt stuff, so if you want to learn Nuxt, that's the place to go. And Twitch, I'm doing a lot of React stuff on Twitch because Twitch is great for just going on and making mistakes and trying to figure things out, and, you know, having everyone see that you actually have no idea what you're doing, and you can get away with that on Twitch. And I really love that.
So that's where I'm hanging out these days as well. So if you don't remember that, Debbie Codes, you'll find everything there.
[00:45:39] But yeah, do come and hang out and follow me and help me build React applications because I need a lot of help building React components, et cetera. I'm learning hooks right now.
00:45:51 - Anthony Campolo
I'll definitely hop in. Just fair warning, though: if I do, the first thing I'm going to say is you should just install Redwood and start using that as well.
00:45:58 - Debbie O'Brien
Actually, the other day I was on Twitch live streaming how I was building in the core of Bit and how I was trying to do my task and I couldn't figure it out. And I'm in the core of it. I'm like, I'm going to break it right now because I'm doing this and it's really fun. I think a lot of people don't share their internals enough, and I'm like, just share what you're doing and let people watch it. If they don't want to watch it, they don't have to. It's Twitch, right? So just, you know, but yeah, come and watch me have fun.
00:46:22 - Anthony Campolo
Awesome. Well, thanks so much. Have a good one.
00:46:24 - Debbie O'Brien
Thank you very much. Bye.
00:46:56 - Anthony Campolo
Cool, cool. Thank you so much.
00:46:57 - short split/interjection
You're cool.