Ep. #59, The Component Marketplace with Alexander Karan of ClimateClever

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line I've got Alexander Karan. Hey, how are you?

Alexander Karan: I'm good, thank you. How are you?

Brian: I'm doing well myself. I'm curious, why are you here? What brings you to JAMstack radio?

Alexander: I'm here to talk about Bit, which has revolutionized the way we develop the front-end at ClimateClever, which is the startup that I'm part of.

I just really want to spread the love and appreciation for Bit and get more people using it.

Brian: Yeah. I've seen Bit, I've toyed around with it, and I think I even used a Bit component.

I'm not sure if you call them Bits, but I've used it in one project that's like a test.

I didn't move forward with that project. It was more of a, "I need to ship something fast," and I needed to pull something off the shelf.

But I was not familiar with ClimateClever and its association with the product, so I'm curious, could you explain what that is and your influence there in that start-up?

Alexander: Yes. ClimateClever is a startup in Australia and we help schools and communities reduce their carbon footprint and save money on utility bills.

We're all about helping drive a low carbon future, and we do that through our apps. We have a school app, a home app, and we partner with local governments and stuff like that.

I'm the co-founder and CTO, so I head up the development team. I've been working with ClimateClever for a few years, but I came on full time last year.

We needed to rebuild the product and we had more than one app to build, and I was looking for a way to speed up development.

I somehow found Bit and we started using it. We got stuck in errors, issues, problems, but eventually we came out on the other end with this better system thanks to Bit.

Brian: I'm curious, I assume the way you explain it, that you're not the creator of Bit, you just happened to stumble across the project?

Alexander: Yeah, but a real advocate for it. A few of my co-workers have wrote blogs on it and done tutorials on it, because it really is at the core of our product at ClimateClever in terms of front-end.

Brian: I'm pretty sure the listeners at this point, they are curious what Bit is and what we're actually talking about. So, do you want to explain what Bit is?

Alexander: On the surface level, I think I like the way you described it. It's like a marketplace for components.

So, you're building a project and you're like "I don't really want to rebuild authentication."

You go to GitHub and you find a library that does authentication, install it and Bob's your uncle.

Bit is like "What if I just want a spinner or a button? I don't want to have to install the entire UI Library of Google just for that one button."

I can go to Bit, find that button and just install the button. That's the surface level of an open marketplace.

Brian: Which is super fascinating. I'm curious, is there anybody else doing this?

Because I know about, there are a lot of design systems and libraries and Google has a big one, The Material-UI. Where you're all-in at that point.

Bootstrap is another one where you're also all-in. Like, I need some quick and dirty UI components, CSS, all of it. Kit and caboodle, and I want to ship a product really fast.

I'm going to opt into this thing and now I'm stuck doing updates for the rest of this project, or until we want to take a couple sprints to fix this.

What you're saying is that if I just want the one button, or the one loading spinner or the one animation thing or whatever it is, I can just pull that one thing in?

Alexander: Yeah, that's it. That's all you need. A real good example is, Bootstrap is a perfect example.

We were using React Bootstrap when we first did the outsourced version, and it was pretty painful.

It was painful, and then we needed to get rid of it, but we couldn't just delete it.

React Bootstrap was on Bit, so we went and we uninstalled React Bootstrap and just installed the components we were using.

Then we just slowly removed them one by one thanks to Bit, because it was like "We don't need that one anymore. Just get rid of it." Our whole entire package and bundle became smaller, quicker to loa d. It was much easier to manage the migration away from React Bootstrap.

Brian: That's wild. It's almost as if we took NPM, but only for UI components. Is that a good summary?

Alexander: Yeah, it works with React, Vue, Angular. But then you can also put JavaScript functions in there as well, and stuff like that.

It doesn't just have to be UI components, but it's predominately UI components.

Brian: OK. To better understand this too as well, because you'd use the example of authentication.

This is not just UI components on the design side of things, this is also JavaScript that powers these things as well?

Alexander: Some people put logic in there and stuff, but I think that's more getting into the internal version of Bit that people use inside their companies.

But the external market price is available for everyone, it's mostly UI component scientists.

But they do come with Logic, too. You can get different load-in states and other Bits and pieces like that.

Brian: "Bits and pieces," I see what you did there. I'm not sure if that was intentional.

Alexander: That's literally the name of their blog as well. They have a blog called "Bits and Pieces."

Brian: Really?

Alexander: Yeah.

Brian: This is fascinating, I'm curious of who is running this? Who's paying for the hosting and for all this free components for the world?

Alexander: Well, it's actually open source. You can just get Bit, set it up on your own server and it's all good to go, no problems.

But they do have a cloud service you can pay for where they will host your components for you and stuff like that.

Now it's free if you're open sourcing your components, like if your components get out to the world, it's free of charge.

But it's when you want to do private collections, they call it "Collection,"then you have to pay.

Brian: You bring up collections and my mind goes to CodePens.

Because CodePen is something that I, as far as front end stuff, that's a place for me to sandbox and work through ideas without doing it in public or doing it in front of-- Like blocking people on my branch, or anything like that.

Not only do you have open source components that you can pull into your project, but also there are just "Collections," or I assume there's collections of Bits and pieces together, so if I wanted to build a portion of a UI I could put all these Bits together.

Then as you mentioned, you had a bunch of different projects, so are you using Bits or reusing Bits throughout these projects?

Alexander: We've got four web apps and four mobile apps.

That's massive, and the basic principle of programming "Do not repeat yourself," and I'm sitting there going "We are just rebuilding the same components over and over again, and maybe the colors are just slightly different ."

We found Bit and we just started putting all our UI components into Bit and just sharing them across all our apps, because it's really hard to build components and then share them across products. What do you do, set up loads of NPM packages yourself ?

Brian: I've been there.

Alexander: Bit does all of that for you. It's all managed for you, and you can use your own package manager with it. Whether it be NPM or Yarn, it's totally up to you.

Brian: That's wild. So ClimateClever, did you have an organization on Bit and then everybody just pushes there? Alongside of their UI development feature development or feature development?

Alexander: Let's say we're working on a button, we'll develop the button in StoryBook.

StoryBook goes really hand-in-hand with Bit, they're just perfect together.

I will develop it in StoryBook and then when we're happy with it we'll push it to Bit.

Just a simple CLI command and in two seconds is done, then it's in Bit for everyone to see, and it's versioned as well.

Every component's got a version number. Maybe app two is using version three of the button, but app four is using version five because it needs the latest features.

Every time you make changes it automatically versions the component for you too.

Brian: That's intriguing, but also is that not confusing though? If you--

Because if I'm using React Bootstrap version six or whatever is out there right now , my expectation is that everything that I'm using will be version six.

Do I have the button version six, but then I have the nav bar version four? Is that going to cause issues?

Alexander: I think when using the overall marketplace, you normally just stick all versions.

But I think it's also another way of thinking about development. Like, your nav bar should work perfectly regardless of what other stuff it's being used with. It should be completely, solely dependent. That's the whole idea of components.

Like, "I build a button. It doesn't matter what happens externally to it, that button works by itself. It has all the dependencies it needs to work."

Brian: That's fascinating. That's also fascinating because I've built a couple of projects in my days, and I'm at the point in my development career where I just don't even care. I know that my button is going to be five pixels, right.

If it's my side project I'm just going to create the same button over and over again.

Because why? Why change what's broken? Almost as an artist, the amount of pixels that I put on my button for a radius is my artwork.

I'm just going to continue to do it until someone tells me this is out of date.

Knowing that and knowing that I don't have to actually remember if it's five or six pixels and just pull it for a Bit.

Actually, it's really intriguing. I'm not sure if I went down the rabBit hole that deep when I was doing the exploration into Bit, and roughly six to eight months ago.

But now I'm intrigued if I can start, because I use StoryBook for my projects as well. Because I want the consistency.

I want everybody to walk into the project and be like, "This is exactly where it should be and how it works."

But knowing that I can now take that same, and not have to copy and paste my StoryBook over and over and over again.

But actually it's pulling the Bit and just recreating the StoryBook with hopefully a CLI command.

Alexander: Yeah, that's all it is. Just one CLI command.

The real nice thing is Bit takes all your tests, all your documentation and builds it as well into this really nice library that you can just search through, find the components, see the documentation.

We use it for React so you can see all the prop types and an example of the component. It's fantastic.

Brian: I'm curious of the platform. Bit itself is a paid product, but it's also free for open source people, just so there's no confusion around that.

But how do I distinguish my components? If I upload it to Bit and then I can leverage that in any GitHub repo or whatever source control solution you're using?

Do I then push that same repo or component up to GitHub, or do I just stick it to Bit and then I'm good from there?

Alexander: You just stick it in Bit, Bit becomes your source of truth.

Brian: Gotcha. OK, so basically it's replacing the need to actually have a whole other folder for just components on GitHub, which maybe will run out of date.

Instead, if you're going to have version six going back to version six of the button, Bit is your source of truth.

Alexander: That is the source of truth.

Brian: So your front end team is going to log in to GitHub maybe, but also you're definitely going to log into Bit.

Alexander: Bit is always there.

Brian: Interesting.

Alexander: It's more pushing towards that micro services on the back end now, split up your business logic.

It's starting to approach that microservices front end, so when we want to build the school version of our app we go and we grab all the components we need and just orchestrate them together in a project and then push that project out.

Then the best thing about Bit-- There's so many good things, but you can, say you're like "Right. I need to upgrade this component."

You just simply import it into whatever project you're working on, update the component and export it.

Then that update is available for anybody or any project that wants it, so you can import it and update it and export it in any project you're working on.

Brian: That's wild. I'm not part of this project, but I'm a consumer of this project, so I work my day job at GitHub.

Which most listeners know at this point, but we've done this new UI update, which is the enterprise GitHub.com/enterprise and GitHub.com/teams.

A couple of pages that we're iterating this new design UI and it's been fascinating to seize the next refresh GitHub.

Actually, there were some tweets of us refreshing the UI, so get ready for that.

Alexander: I'm excited. I love GitHub.

Brian: It's not going to break the way you do GitHub, but it is going to be a nice hopefully appeasing experience and when you actually get access to it.

But I've been playing around with it for the past week, week an d a half, and I love it.

I love that someone from the design systems team did this "Flip a switch and then everything changes for you without you even touching it."

The way we explain it, if some of the design gods or whoever is making the designs decisions, me as a developer I can tinker with the design, but I don't want to make the decisions.

So, this person can just say "Today we're doing seven point pixels for radius."

"Cool, whatever. I'll just update the version number," and then magically everything updates? Is that the way it works?

Alexander: There's two ways. Let's say I update the radius of the button, then you've got two choices.

The first choice is you go into every project that is using that button, you've just run a script to update NPM packages and it installs a new version. It's all good.

Or, you can integrate Bit more heavily into GitHub so that any time you update a component, any project that's using that component automatically gets a pull request to merge the update in.

It just depends if you want to be fully automated or a little Bit more manual, it's up to you.

Brian: That makes sense. I assume there's some sort of integration on the GitHub end?

Alexander: Yeah, there is.

Brian: That's very cool. Then the integration for StoryBook, I am curious if there is one to keep your StoryBook up to date with Bit itself?

Alexander: There isn't a full-fledged integration for StoryBook and Bit yet.

But it's more like they're just really good companions to use side by side as development tools.

Because I've really j ust grabbed hold of that philosophy of when I'm working on whatever component it is, whether it's just a button or it's a form or a page, it should just work by itself.

Develop it in StoryBooks, get it in Bit, and then we can just use it all over the place.

Brian: So I have to ask, it sounds like ClimateClever is actually a paid user, is that correct?

Alexander: To use our application, you have to pay. We have variable pricing, it's different for homes and for schools.

For homes, it's cheaper, because it's just an annual yearly subscription.

Then for schools it's a Bit more, but that's because we provide learning materials and stuff for the kids to do and things like that.

Brian: OK. So, more than likely probably a profitable business.

We don't have to get into that, I don't expect you to go into all the financial stuff like that right now, but I assume that you're also a paid customer for Bit itself.

Alexander: Yes.

Brian: When I look at the features, I imagine the collaboration thing probably makes a lot of sense if you're going to have a team of people doing it.

But there's things that I've always been curious about Bit , when I first looked at it, the idea of private collections--

Alexander: Yeah.

Brian: Are you actually, are you leveraging private collections today?

Alexander: Currently we have, I think, 50 or 60 private collections.

Brian: OK. So, what's the purpose of having private UI components?

Alexander: They have all the secret sauce of our app essentially on the front end, s o we originally just had a school app, so I'll t ell you a Bit of the story.

We had a school app and we were starting to move into homes, and me and one of the other engineers that was pretty close with me, Brian Forte, we were just examining a lot of the logic that was going to be shared between the apps.

A lot of the UI, even though the color schemes were different and the theme was different, we were like "We've just been repeating ourselves,"and we were just looking for ways to share components.

Everything just seemed like such a hassle, like it was going to cost us more time to share components than to just rebuild the whole app. Then we found Bit by accident.

We were like "We want to put stuff in Bit, but we don't want the rest of the world to have our code. Because it's our secret sauce."

So, we started creating private collections, and first we created collections like just general components.

So, buttons and drop-downs and inputs, because they 're all specially styled to our themes.

Then we started creating collections for pages. Let's say we've got a section of app called "Measure" where we collect your utility bills.

We started creating components just for Measure, and we would share the UI between the apps because when you collect an electricity bill it's the same no matter where you are.

We created the UI for that, whack it in Bit and then it's in all of our apps. So, that was phase one.

Brian: Yeah, that makes sense.

Alexander: It's a little crazy when you first start doing it because it's very counter-intuitive to normal ways of developing.

Brian: Yeah, it is. The way I approach it today is I'm using style components pretty heavily.

So, the context of Bit and having your UI come through components like a third party service-- In my mind it actually looks pretty similar, because I have done--

My style components are written all in styles file folder. I think it's actually, it wouldn't be too hard to actually ship that to Bit.

I'm curious, what is Bit looking for? Are you just sending them React components? Or, is it--?

Alexander: We're a full-fledged React house at ClimateClever.

Not that it's the best framework in the world, it has its pros and cons , but it suits us just fine.

To start off with we were just shipping UI components, just that's it.

Although we've gone a little further down the rabbit hole now and everything is in Bit, not just UI, which is a little crazy.

Brian: That sounds insane. But I guess if you're just sending React components and if the y're "Functional" or "Reusable" components then you just plug and play at that point.

Alexander: Yeah, so we decided-- We were sitting down and we were like, "The UI sharing is going great."

We were like, "But some of this logic that we share, we should share as well." Like fetching bills from the server, maybe there's a few parameters that are different.

We were like, "What if we just had this global configuration and theme file in each project? Then we just convert all our networking, databasing, app logic into hooks and whack the hooks in Bit."

Brian: OK.

Alexander: So we just put all the hooks in Bit, which was a task in itself, like half of the platform was using hooks. The other half was using React classic components.

But we just went nuts, we went full hooks. Everything became a hooks. But this changed the way we componentized our UI components, because originally we'd import the components and they'd all have an index file that would initiate them and pass logic in.

But now we didn't need to do that, we could just have this component that displays your bills that has hook components that are in it as well as dependencies.

We started doing that, and then all of a sudden we'll build this new page that verifies your email, add it to Bit and then two minutes later we'll just go to the home app or our social service version of our app and go "NPM install, verify ClimateClever email page," and all of a sudden we've got a page in there that just verifies the email, and it took us two seconds.

We didn't have to write any logic, we didn't have to integrate it, it's because all the logic is in there now too.

Brian: That's fascinating, that approach too as well, because I think-- I'm sure your development speed, once you-- There might be some investment in getting all this stuff up in Bit.

Alexander: Yeah, definitely.

Brian: But I think once you get to that point where everything is there and you're basically in maintenance mode, or maybe you do a refresh and an update it, then that might be a little more of a heavy lift.

But to be able to pull stuff down that's already existing sounds lovely.

So actually, I was building a mobile client for one of the projects I was working on.

Actually, one of the companies I was working at, and I need to recreate that mobile view but in an iOS app.

But there was no cross contamination, there was nothing I could use to repeat that experience.

Mind you, I was building in a React native, so it was already, the app itself was in React and I wanted to build a React native app.

I knew how to do that JavaScript and the CSS, but there was a lot of copy and pasting happening.

A lot of, "I don't know if this is actually going to work in this element."

For the most part it did, but it was a lot of figuring out and making sure that all the mobile responsive stuff translated to React native well on the phone.

But it would have been much nicer if I could have just said, "NPM install that stuff," because where it's talking literally JavaScript to JavaScript there's no reason I couldn't just do the same thing over.

But it is intriguing, and it makes me very intrigued to really get my hands dirty with this thing.

Alexander: I think everyone should.

Because for us it's just more than UI. We used React native for our mobile apps, so some of our views we share between the web and the mobile, but some of them have to be rebuilt in React native because they're very different.

But because all our logic is in Bit, we can just be like "OK, we'll just drop this hook in there that gives you all the bills for the screen. Or, gives you all the actions."

I don't have to worry about redux or networking or anything like that, because that's all taken care of the hook."

It makes it really easy to onboard new developers because you feel like, "Right guys . Here, build this new component. When you want to add bills or you want to add some data to it, you just need to implement this hook. You don't need to do anything else."

Like all our hooks, they return the objects and then a refresh function for automatically refreshing them too, so it makes onboarding a dream.

Brian: I did spend some time building a hook for, not stashing the token for a login, but it's a JAMstack app and it's just front end only.

I happen to be talking to third party APIs, so I don't have a server to leverage passing tokens back and forth.

I'm actually getting the token from the API and then leveraging there, s o I had to figure out what to do with this thing.

I built a hook and built it three different times, because I'm like "I don't know if this is right."

It's not too hard to build a hook at this point once you've done it a few times, but if I could be able to be like "This looks very familiar. Let me just pull it from the component library that I've already solved."

Because instead, I think as engineers I think we figured out that we're basically building the same features over and over again.

Alexander: All the time.

Brian: My first engineering problem, junior engineer, I worked at some marketing firm.

I had to build a Twitter client to send photos, because Twitter-- sending photos in Twitter, a lot of people take for granted.

You could not do that, it used to just be text. So the API opened up and you could add photos.

"OK, Brian. First day on a job, we need this feature to add photos to our Twitter tweets on the platform." "OK." One month later, I did it.

Then I go down the road, Instagram adds videos. Like, literally two months later. I'm like, "This looks very familiar. OK, Brian. You've got experience. Go ahead and do it again."

I built the same thing again, but with Instagram.

Then because it was a social media marketing platform, so literally the circle of all the social media sites back in 2013, I just implemented all of them.

I was like "This looks-- Once you figure out where the bells and whistles are, everything looks exactly the same."

My first year was just "Work with these third party social media APIs, build features around those on our platform and then go home, and then come back tomorrow and do the same thing."

I think as engineers, we realized we were doing the same thing over and over again.

That's why Stack Overflow is made of senior developers, is because we can legitimately copy and paste.

I'm looking at Bit with all these fancy animation stuff that's already solved for me, and I'm like "I'm going to look like a wiz tomorrow when I start adding a bunch of spinning donuts and stuff like that on my home page because I can do it."

Alexander: Yeah, that's it. You don't need to reinvent the wheel, but I think it's the other part of it as well as it allows you to focus on building a great product.

I feel like coding is like composing music. You're just picking the right notes and putting them together to make a good piece, but why do I have to rebuild the note every time? I know what a note is. There should be a place I can just pull it from. Now, that's how I think about it.

Brian: That's a good analogy too, as well. I play a Bit of music myself. Knowing that there is with the Nashville number system, or just the pop music scales.

You play the same progression over and over again then you have a pop song.

I think what we're as React developers maybe, or even front end developers, we're just creating pop songs.

If you want to create something fancy and super indie, that's for you.

But if you want to get paid and go home and play video games, maybe pull the pop songs off a Bit.

Maybe I hammered that analogy too hard into the wrong place, but hopefully the Bit developers and the maintainers are appreciative of my explanation.

Alexander: I think that's a good explanation. I don't think you need to worry about annoying them, I spent all of last year just logging bugs on GitHub.

Brian: Nice.

Alexander: Because we were exporting hundreds of components at one time, and it just couldn't handle it and it kept crashing.

But they were really great, they were responsive, they fixed those issues. They didn't hunt me down and murder me for logging too many bugs.

Brian: That is excellent. I'm looking at the loading spinners and they're fascinating.

Something that I could probably spend some time on, maybe a couple of days in making SVGs animate.

But, why? When this is already a solved problem for me?

It really hit me too as well as you were explaining it, it gives us room to solve harder problems, which day by day I am solving problems that I've never solved before.

But when I spend way more time trying to, again, make the radius either seven or six pixels and then get code review to actually take up that time, it would be perfect just to go ahead and solve the problem and just install that and put it up there.

Alexander: Yeah, and that's what it does. For example, we migrated networking library to improve caching and a few of the Bits and pieces.

We upgraded the framework we were using, we added some more logic in, and then we just updated our API hooks in Bit.

Then every other hook or component that was dependent on those API calls got all the fresh networking with the better caching and better speed and response instantly. It was just fantastic.

Brian: Yeah, this truly is fantastic. I think we've rounded the bases on the product that I've been exposed to.

I don't know if there's anything else that we should chat and talk through that maybe we missed.

Alexander: I know, I don't know. I feel like we've really winded up, because that's it. It's just a different way of developing.

I think it takes a while to get your head around, but it's like "Why are we focusing on building a big monolithic front end anymore? Let's just make sure your part that you're building works better."

It's better because we just brought on two new junior developers, and day two they're already coding.

They're building because they can work in isolation on stuff without crashing the whole system, they can understand that you just understand one thing at a time. That's really powerful, because it also empowers them. It empowers that barrier to entry to become lower.

I think that's really important for the coding community, to get more people involved. That's why I always liked the create React app.

You don't have to know anything, you just type in this command and you've got a React app you can just start playing with.

You don't need to know about configs or set up or web pack, and it's the same thing.

You don't need to know about our entire project at ClimateClever , you just need to know that you need to make this form for putting your email in the best form in the entire world.

Brian: I think the adoption curve in React in general, I think really started skyrocketing around create React.

Because they took away the need to know wetback and the need to know all these other--

Even service workers, because you have a service worker running by default, maybe that's actually-- Maybe that was a mistake.

Maybe it's actually a great thing. Who knows? But you didn't have to know a lot about it, you just knew that it existed.

Then when you had to solve the problems, like "Why is my site not clearing the cache? I keep seeing old stuff. It's the service worker, OK."

Or maybe you didn't know but you Googled it and discovered it inside your workflow.

But anyway, I'm not going to hark on my personal problems in discovering React on my own, but being able to remove that barrier of entry I think it's the unintentional gatekeeping.

It's something I've been thinking about a lot.

I don't know about network caching or know about surface workers or how to invalidate caches, then I'm opted out of being able to advance my developing career because I'm going to have to spend more cycles or take time away from senior devs to understand this problem that maybe everybody's assumed that it's a solved problem.

But if we have things like Bit where day one, you can come in and be like "Look at this page. Here's all the visual elements that we have, build this feature using these elements. Here is maybe a design mock, go and have at it."

It's no longer like, "I don't know if I can make this box the right--" I don't know why I keep harping on the radius of boxes and buttons, but sometimes making things the right purple or making the right radius , it's a half a day worth of work.

Alexander: Yeah, it is.

Brian: But now it doesn't have to be because it's already done.

Alexander: Just one line of code, and that's it. It's everywhere.

Brian: Excellent. With that being said, I'm going to wind us down into picks. These will be jam picks, or these could be jam Bits.

Who knows, if you have any cool Bits that you want to share with us. But these historically have been music, food, anything that keeps us going.

I know recently, with isolation and sheltering in place we've been doing a lot of new hobbies and tips and tricks.

I don't have a ton, but if you don't mind, I'll go first and I'll explain my pick.

I've mentioned a few times on the podcast that I've been doing some live streaming on Twitch, which has been a lot of fun.

I had a couple episodes about my foray into it and finally getting consistent, but I just recently shipped a new little side project which is called BeyBot.

I did a conference call and I alluded to this previously, p eople followed me on the internet.

But anyway, it's called BeyBot and it's a Twitch bot to basically interact with your listeners, or watchers or viewers on Twitch.

Twitch is really cool about community, where you engage the community and it's not really just about webinars or you doing your own thing, but you engage in the community in having that camaraderie around something.

Maybe it's Rocket League or maybe it's Elder Scrolls or whatever it is, Fortnite season, whatever. I'm not sure what they're on.

But anyway, I created this bot because I watch a lot of Twitch streamers and a lot of them use Stream Labs, or Stream Elements or something off the shelf, like a Bit but for your bot.

But they're super limited, and I wanted to build my own because I wanted to do something very specific that I've seen other people do, but no one really talks about, which is weird.

People figure it out, but they don't put their code on GitHub because it's Twitch. Not everybody actually wants to share.

They don't care to share, so I had to figure it out myself and I ended up doing that. Now I have a template basically, which is BeyBots.

If anybody wants to have a Twitch bot, you can go to MutualFun/BeyBot. It'll be linked in the show notes as well, but you can just literally-- It's a GitHub page.

The way it works is that OBS takes browser sources, so if you have a GitHub.io URL you can actually link that directly to your Twitch, so you're OBS, and then interact with the chat through simple commands.

Open source code, you can look at it. It's all just simple HTML and JavaScript as well.

Then for my second pick, I'm just going to mention the reason I found the actual chat bot is because of one Twitch streamer, which is InstaFluff.

InstaFluff is the creator of this chat bot called Comfy.js, and he's got this whole brand. I don't know, you'd just have to watch InstaFluff.

Great guy, great streamer, and he's done a great job of solving the problem that I've had where I don't know how people do things unless they open source it, and he open sourced all of his bot frameworks and stuff like that.

So, definitely check out InstaFluff on GitHub and on Twitch and check out the BeyBot.

Alexander: I'd love to see competitive coding on Twitch. That would be like, teams coding against each other to try and build a product that gets user feedback and stuff. I feel like that would be interesting.

Brian: I might take you up on that think, our education team has been doing some Twitch streaming because they've gone fully remote as well and I think the way university is going to happen next fall in August, it's going to be a new school year and it's probably going to be remote, or mostly not in person.

They've been doing a lot of things of engaging their students and developers in doing hackathons.

Alexander: That's pretty cool.

Brian: But kids love e-sports these days, if everybody gets together and tries to solve some test or algorithms or whatever it is, that would be super interesting.

Actually, I know exactly what would be a good idea. Which is Battle Snake.

It's actually a hackathon that happens once a year, which should have happened a few months ago. I don't think it actually happened. If you remember the Nokia phone games.

Alexander: Yes.

Brian: Snake?

Alexander: Yeah.

Brian: So, basically they recreated that game in JavaScript. Or maybe it was Python, I'm not sure which one it was. But basically you have to build that game using code.

Then what they do is they call it Battle Snake, so then they put all the snakes on the one screen and if your snake, you set the algorithm for your snake to battle the snake.

You lose part of your snakes-- Anyway, you should check it out. Maybe that will be a third pick too as well, since we've been rolling into waiting for the internet to come back up.

Alexander: That sounds awesome.

Brian: But yes, that summarizes my picks. Do you want to share your picks?

Alexander: Yes. I'm not really in quarantine anymore in Australia, but while I was I got into pie making . Like raspberry pies, blueberry pies, apple and blueberries--

Brian: You mention Raspberry Pi, I'm like "Is it fruit pie? Fruit pie? Or is it actual code?" Yes to both .

Alexander: It's yes to both. That was good, but my top pick at the moment has to be Stripe, they have this blog called Increment.

It's just amazing, and they release new issues quarterly but you can also get it in book form so you can subscribe and get a book of all these really good blog posts posted out to you four times a year. It's got blogs from people from Facebook, Google, Airbnb, MailChimp.

From smaller startups to IBM just talking about loads of different subjects. It's a really great read.

The current two ones are on software architecture and front end development and they're just fantastic.

It's great to just have a coffee and read through the book, and actually have something physical in your hand.

Brian: I've not heard of that. I'm actually surprised I have not heard about that one.

Alexander: This may seem a little out there or bold as a statement, but I think it's the best tech blog around.

But especially since you get it in book form, too. Then my second pick would probably be Chromatic.

I'm always looking for ways to integrate the development side of the business with the rest of the business, and Chromatic is a really good way for you to share all your storybooks from your projects and let everybody else in the business just comment on them and give you feedback without letting them into your dev systems, and stuff like that.

It's definitely-- Those two are my big picks at the moment.

Brian: Awesome. I've also never heard of this one as well, which I'm super impressed.

Alexander: I feel like I'm contributing in a good way. That's great.

Brian: You're expanding my horizons. Who would've thought I had to go to the future and to Australia to learn about some of these really cool things?

Alexander: I think when you're a startup, and we're not a startup like Google with billions of dollars, so you've always got a small team.

You're looking for ways to iterate as fast as you possibly can and do as much as possible with as little as possible, and the only way to do that is to constantly read and find the best tools . That's just literally it.

Brian: Yeah, "Learn from others." What a great statement to end on too, as well.

Summarizing this entire conversation and all these tools through Bit, but also learning about Increment in Chromatic.

I am now going to fill up my Monday morning reads with some of this stuff as well.

Alexander: That's great.

Brian: Alexander, thank you very much for coming on the podcast, talking about Bit and talking about the JAMstack.

Listeners, keep spreading the jam.