Gilad Shoham is a developer and open-source leader at Bit. They explore the latest trends and insights in the world of development and technology. The conversation also delves into the complexities of managing and sharing software components, detailing the challenges and potential solutions, and exploring innovative ways to manage components and share code.

 

DAN:  Hello everybody and welcome to another episode of JavaScript Jabber, your favorite podcast on our panel today. We've got AJ. 

AJ: Yo, yo, yo. Come at you live from the purple room once again. 

DAN:  And we've got Steve, Steve Edwards. Hi Steve. 

STEVE:   Hello everybody. Coming from a very cold and clear Portland.

DAN:  Kind of cool and cold in Israel as well, by the way, just so you know, you have to wear a sweatshirt when you go out. 

STEVE:   Oh, wow. 

DAN:  Over your t-shirt. I'm using a t-shirt. And our guest for today, which you just heard, is Gilad. Hi, Gilad. How are you? 

GILAD:Hi, I'm great. It's great to be here. 

DAN:  And I just realized that I forgot your last name, so could you please repeat it? 

GILAD:Yes, it's Gilad Shoham.

 

Hey folks, this is Charles Maxwood. I've been talking to a whole bunch of people that want to update their resume and find a better job. And I figure, well, why not just share my resume? So if you go to topendevs.com slash resume, enter your name and email address, then you'll get a copy of the resume that I use, that I've used through freelancing, through most of my career, as I've kind of refined it and tweaked it to get me the jobs that I want. Like I said, topendevs.com slash resume, we'll get you that and you can just kind of use the formatting. It comes in Word and pages formats and you can just fill it in from there. 

 

DAN:  Yeah, so Gilad, you're joining us from Israel as well, right? Right. 

GILAD:Israel is war. Yes. Still going on. 

DAN:  And we are here to talk about a project that you guys are developing called Bit, B-I-T. But before we do that, can you tell us a little bit about yourself, who you are, what you do or why you're interesting and so on. 

GILAD:Sure, so my name is Gilad. I'm living in Israel, father of three little kids and I'm working at Bit in the past almost seven years now, leading mostly the engineering team and working mostly on the open source part and the CLI and the core technologies. Apart from this, I also had some startup that I built myself in the past and I am a podcaster as well. I have a podcast and a blog and a YouTube channel about smart home and home automation which is in Hebrew so I can share a link later on. 

DAN:  For sure. Can you just tell us the name of the podcast just so that it's out there? 

GILAD:Yes, the name is Dira Le HaSkil. 

DAN:  Oh, so it's a Hebrew podcast. 

GILAD:Yes, it's a Hebrew podcast, yes.

DAN:  Cool. So we'll put a link anyway for Hebrew listeners or Hebrew adjacent listeners. And like you said, we are going to be talking about this project that you're leading the development of, which is called Bit. So can you introduce us to it? What is it? What does it do? 

GILAD:Sure. So Bit is basically an open source tool chain for managing and developing Composable software. It help you to manage components, compose them, share them and reuse them. And during this session, I guess we will talk a lot about composable software and how to make this more approachable and more working in the real life.

DAN:  Well, you know, at least theoretically, most of us are supposed to be doing this sort of thing already. I mean, you know, we're building web applications using components. Preferably it might be react. It might be view. It might be Svelte, whatever. So, you know, obviously, I guess most people are asking like you know, we already have the environments that we're using. It might be just a framework. It might be a framework plus a meta framework like Next.js or Astro or Knox or whatever. Why do I need something more? What do you guys bring to the table that I don't have from, you know, whatever toolchain I'm already using.

GILAD:Great question. So first, that's true. Everybody today are writing component. Doesn't matter which tool or which framework they're using, React or Vue or Angular, everybody write components. And this is great as the first step to begin with composable software. Before I jump to what we had, it's important to understand that when I say component in this context, this doesn't matter to be a front end component. Okay, a component here can be also a backend component, a microservice, a utility function, doesn't matter what, every piece of reusable code that contains business logic and provides an API to the organization is a component and we compose our application from both frontend and backend and other types of components. So back to your question about what we are adding. So we do writing components everyone today. But once we start, once we try to share them and to reuse them across the organization, it becomes a very, very big problem. And while the organization grow and the amount of people in the team or in the R&D is growing, sharing and reusing become more and more of a problem. We all know that today with large organizations. Once you add more developers, you're not necessarily moving forward faster because every developer add a lot of overhead. And part of this is because we are building our components, we are thinking about our components as not as the main entity. What do I mean? We are all our organizational structure and goals are around applications today. We are building applications and as part of this application, we are building components. This leads to a change in the mindset that we are building the components to use it now for our application, but we are not thinking about reusing and sharing all the time because we are always bounded to a specific context. So the first thing we want to do as Bit is not even a technical or technological problem. We are trying to change the mindset, the philosophical mindset about what is a component, how you define component, and how you can make as a methodological structure, you can make your component more reusable and shareable. So we start with this. Then once you're trying to do this, you face a lot of issues. Let me line up the main structure of typical problems that we have today with sharing and reusing components for composable software. It starts with the fact that let's take it apart to three different stages. The first one is the creation overhead. What it cost me to make a component, an individual component, something that I can take it from one project and reuse it as one unit in another project. So creation overhead is the first very big problem, which leads today to packaging many components together or to not share them at all. So for example, if we talk about stuff that are shared in many organizations like design system, many organizations sharing the design system, but the entire design system is one package. This leads to many problems. How do you go back to this? 

DAN:  Before you continue, I just wanted to say that this is exactly what I tend to see, is that organizations either work in complete silos between separate applications and really hardly share anything at all. It's funny that a lot of these organizations are able to in a fairly straightforward way, share like open source libraries or share third party components, but find it very difficult to share the components and code that they themselves create. And you're absolutely correct that one way that a lot of organizations are trying to overcome this challenge is by introducing the concept of a design system as a kind of a cross-cutting concern across the entire organization. I'm having a difficult time sharing a particular component, so instead I'll bundle all of my possibly shareable components together into this one big library and just share that as a design system. So yeah, this is totally my own experience as well. 

GILAD: Yes, let's talk before we continue with the issues about sharing, let's talk about. What does it mean when we are not sharing our components and we're not using them? This means that first we are reinventing the wheel every time. Every team is reinventing the same components over and over again. So first it's a waste of a lot of time and money of course. Second, this leads to many inconsistencies. It can be UI inconsistencies, it can be bugs that are fixed in one place but not in another many other places. So not sharing code leads to many, many business problems. And this is very important. Also, it's important to understand that even though some organization creating design system, design system is not the only stuff that you want to share. So design system is something that is common to share because you know you will need it. So you are doing the effort to share it but other stuff can be shared as well. There are tons of utility functions, there are tons of backend stuff that you can share, but you are not doing the effort because it's always a question about what it will cost me to share this component and what I will gain from it. And if it's very expensive to do this, no one does this in the real life. Then if we go back to this design system that's bundled all together. Let's understand what the meaning of bundle everything together. And why we do this, we do this because it's too costly to take this 100 design system components and separate them so they will be individual components. It's a very hard and long process to do this today. But this means that as a developer in the other team that consume the design system, I have now a conflict because this leads me to not want to use the design system because of a few reasons. One is once I'm using the design system, I get everything. If I only want the button from the design system, my bundle size will now go up with 100 components because, well, tree shaking is not perfect at all. So, well, if I just need a button in the combo box, maybe I will not use the design system. This is the first issue. Second issue is what happens when I need to update. So now there is a new version of the button, which I want to get, but the design system is bundled together. If I'm now trying to update the design system, I will get 100 component updates. I don't know what will happen when I update the design system. 100 components getting update, because I cannot update just the button. It's another reason to not want to use the button, do not want to use the design system from the first place. The third issue is what happened when I have a bug in the design system. What is my ability to change and fix the bug even locally? So it won't be dependent on different team with its own priority, its own timeline, whatever to fix my bug. Because I have a product that pushed me to fix something and I now depend on other team. And this is another very big problem, which leads to eventually one of a few outcomes. One is I'm trying to not use the design system at all. I will just copy what I need and then we go back to reinventing the wheel, not having every all the features that the organization have, having inconsistency and stuff like this. Or I'm using the design system because someone forced me kind of to use the design system but then I cannot move forward many times and I'm afraid and I'm never updating the design system until someone push me again, whether it's like the add a few weeks or something else, security, add of securities that push me to update it. So eventually this is, this is the first big problem about like the creation over ready. 

DAN:  Yeah. So again, it matches what I've seen and what I've basically experienced is organizations usually decide to adopt a design system as kind of an organizational-level thing. Like it's not like two teams say, hey, we've got a lot of shared code. Let's, you know, let's create a design system just for the two of us. It never, it's never like that. It's okay. You know, we're, we've grown enough as a company. We've got enough separate teams you know, we are mature, we need to be consistent, so let's create another team that just builds a design system that everybody has to use. So again, it usually happens at fairly large companies when they reach a certain level of maturity and all the problems that you describe are definitely issues that I've seen around the adoption and usage of design systems. On the plus side, you do gain consistency, like you said like a common look and feel. People usually build accessibility into their design system. So you get accessibility throughout the organization. Yeah, all those benefits. But it's definitely not a walk in the park. It's a big commitment on the part of the organization, certainly at the time of the adoption, but also going forward from that point on. 

GILAD: Yes. And this usually kind of stop in the design system, but there are so much more code to share in the organization, which like how many times you see people from two application team or product team, not the design system, are sharing code. This is much, much more rare because as you know, it's a complex problem to solve. It's a process that coming in the organization level. If I want to just share something that I did in my application and you need it in your application. I'm almost sure not doing this because it's too expensive for me. I need to handle many stuff when I'm doing this. For example, let's try to be more in the ground about what it requires me. Let's say I have a component in the product team, not the design system that I want to share. As a developer, I need now to extract this code to somewhere else, to a Git repository or something like this. Once I'm doing this, I need to build some, I need to build the entire toolchain around it. So setting up a compiler, linter, tester, formatter, bundler, whatever, this is a very long process. Then I need to be able to share it. So I need to publish it to somewhere. I need to find a name. I need to get permission to publish it, which is also a long process. And then I need to use it in my original application, which is also because now I took it to another place. Now, how can I use it and develop it in my application? So the fact that it is possible to share, but in the real life, it's very rare to share components between producting. But if you will take a look on the producting code in your organization or in any organization, you will see so much So it only happened because it's hard and costly. And this is like the first creation of a problem yet between product team, but we want to also share code between product team. The next thing is, let's say you are doing this and you did pay all this extra cost to share something. Now, how other people in your organization can find this code? 

DAN:  Yeah, before we go there, so it's, first of all, I see AJ nodding a lot. So I'm kind of interested in what AJ is thinking about this. But I'm, you know, I have seen organizations share code in certain ways. Like one way is to, for example, create a private NPM registry and publish stuff into there. There's certainly an overhead associated with it. And permissions issues and stuff like that. It's not trivial, but it's doable. Another way is basically not exactly share code so much as share functionality or services. So you need to reuse a particular service, you bundle it as its own microservice with an API and share it that way. Now, obviously, that's at a higher level of abstraction. You'll probably not share codes that, I don't know, sorts a list as a microservice. But you can share certain business logic units as microservices. And now, Ajay, like I said, I was seeing you kind of nodding your head throughout. So I'm curious as to what you're thinking about what Gilad is saying.

AJ: I just agree. There's a lot of tedium, right? If you want... And I was also thinking there's a difference between the type of person that publishes a module and a business, right? So we get a lot of benefit from the people who take the time to curate their own code and to publish it. And some of them do it as part of their arrangement with their employer. But a lot of it is...It's a mentality that not everyone is going to have. And so I was, you know, I was thinking both about, yes, there's all these steps. And I was also thinking, well, there's the people that do it and there's the people that don't do it. And most people don't do it. I mean, we all work with people who don't have anything published in PM and people who do, why do I publish stuff to NPM? Because I mean, essentially, cause I want it to be easier for me to use. And because I am predominantly a consultant. I need documentation for other people to be able to use too. So I publish things because it benefits me and because it benefits, uh, my clients or other people that I'm working with. How do you organize, organizationalize that? Is that a technical problem or is it a, I don't want to say culture, but for lack of a better term, culture, and I don't want to say problem, but for lack of a better term, technological problem.

GILAD:I would call it a methodological problem. 

AJ: Methodological problem, okay. 

GILAD: And this is, right, you're totally right. There are people who are sharing today and do all this effort. But as organization, you have the incentive as an organization that more people inside the organization, I'm not even talking about open source or publishing to the open source, I'm talking about publishing inside the organization in the private NPM or whatever. So as a team in the organization will benefit from it. So as organization, you have incentives to improve the sharing. And there are people who share today. So first thing is to load the barrier, okay? It is hard to do this. If we lower the barrier of sharing code, we will get more code shared. This is first. Second is also about the incentive for the individual about sharing code and why he should share code. And this is also like the logical and technical problem. For example, if you would measure by your organization and you will get like the yearly bonus from the organization, from your employer around the amount of components that you shared and how many people use them. Will this...Incentive you to do more sharing, of course. But for, but in order to do this, you need a way to measure this. You need a kind of analytics tool that know to measure how many components a team or a group creates and how many other teams using these components. 

AJ: I, I'm skeptical because I think that this starts to become a social issue because there are people who have the propensity to do it right and if If you if you start rewarding people internally because open source is something that people opt into right like they decide I want to participate in this I'm okay with the challenges and the risks. No one's forcing me to do it like any burden that comes on because now people want to bug me about issues. I'm opting into that and the fame that I get, you know being able to go on Reddit or Hacker News or whatever it is and get fame. Like I'm opting into that. And in the workplace environment, you are opting into solving a problem for an employer, but it's not the same mentality and the gamification of, you know, show stars, show metrics. I could see that lending itself towards resentment and frustration. More so than in the general open-source community where people are. I, I don't know quite how to articulate it, but it, it feels different. And I'm not sure that I think that it's going to be net positive. 

DAN:  What I would add is that it's an interesting conundrum in a situation where it's actually in a sense easier to share something in certain ways as open source than it is to share it inside your organization as a common library. We've got processes for open source. They're not perfect, far from it. Like you said, AJ, there's a lot of potential hassle associated with it, and there needs to be motivation to justify it. But there are processes. And I do agree with Gilad that we are kind of lacking in processes for sharing stuff internally. Again, it's doable. It's just, you know, the hassle is higher. It's kind of like that funny situation where you blog something for the, you know, for the entire world to see, not so much because you want to share it, but because you know that this way you'll be able to find it yourself later on when you need that information. So it's almost like it's easier certain common code is open source than it is to just share it internally in the organization. The other thing is that open source tends to be projects, not so much components or functions. You wouldn't create this function that does something. Hey, this is really cool. This is useful. I probably want to share it in other places, in other projects that I'm currently working on. Would you really turn that function into an open-source project? I mean, you could, but it kind of seems strange, maybe to me. I don't know. Anyway, so going back, you've really outlined the problem. So what's the solution? 

GILAD: This is only the first problem. Okay. 

DAN:  More problems. 

GILAD: Yes. Of course. No problem. I just want a few sentences closing this. First, it is true, and I do agree that the motivation for sharing in the open source is a bit different than sharing in the organization because of the fame and glory you get from doing open source. But there are many people in the organization today that want to share their code for different reasons and don't do this because it's too hard. It's not like black or white, there are many people in the middle, so you'll get more of the cheering. Second, getting the impact in the organization, so seeing the impact on the organization is satisfying as well from someone that's really doing it for many years and see how many people are using MyComponents, which are not always open source. I feel good that I see many teams enjoying MyComponents. So this kind of motivation is also relevant into the organization especially in large organization. So eventually we want to get more people share code. And it's also, like I said, it's also a mind shift that we are working on. So Bit as a company is not only about technology. It's about philosophy, methodology, and part of what we are trying to do is to change this, to change this mindset and methodology to make it more common. And then we are doing stuff like this creates a lot of new issues that we will discuss soon. And we are trying to have good technical solution for these issues. For example, how you do this in practice. So how do you share so many components from a project? So let's talk about the solution for this first problem. So you have a project. You want to share code from this project. The first thing that you want to do in order to make it easier is to not force you to go to a different context. I don't want you to need to open a new GitHub repository, set up permissions and stuff like this. I want you to be able to share only specific parts from your own project today with the organization. And one of the things we are doing today is with the BCLI is that we are allowing you to create individual components inside your repo or project or whatever. It's a bit similar to monorepo tools. Okay, so you can think about NX or Lerna or Turbo repo and how they connect different packages in the same repo. And Bit in some way is also kind of a monorepo solution as well. So we discussed, you talked earlier about what are the competitors of Bit. So we discussed Git and GitHub and Storybook and NPM, and also the Mono repo tools. So in this regard, the Bit is kind of, is built from scratch to handle many components. So NX and Turbo repo and all of these tools are great tools, and many people use them and love them for a reason. By the way, you can use both NX Learner, Turbo repo, and Bit together, and we do have people and customers usually doing this. But they built to support packages and not components. And this means they kind of built for another level of granularity, which means with NX or Turbo repo, you can manage 50 packages, maybe 100 packages. But if you try to do like 11 packages, 1000 packages, sorry for my hip go in the numbers. If you try to do 1000 packages in the same one repo, it do start facing issues. So we are trying to make it very, very easy to create a component in the same repo project. Another thing we are trying to do to make it easier is to manage dependencies automatically. So one of the main issue when you try to manage many, many components as individual, like doing source control individually for each one of them is how you manage dependencies because now we need to maintain 1000-packed JSONs. This is a very hard problem. This is a very tedious work to do. So, BIT, for example, knows to do static code analysis on all of your components and add the dependencies according to what you are using. And also classify it as dev dependency or runtime dependency according to the files that are actually importing it. Is it a test file or is it a runtime file? So dependencies, automatically managed dependencies is a big part of it. 

 
This episode is sponsored by Miro. I've been working lately on a whole bunch of different projects for top end devs. Everything from meetups to courses to podcasts to the website. And a lot of the things that I've been working on have gotten really, really messy and even though I have some software that helps me manage the projects, one thing that I figured out was that it really helps to have a tool that you can use to manage kind of the layout and the organization of your project, not just whether or not tasks are being done. And so I picked up a program called Miro, and Miro, what it does, I'll just give you an example. When I'm building a course, I sit down and I open up their mind map, and I just put all of the information into the mind map. And I'll do that for probably anywhere from 15 minutes to an hour, just depending on what it is that I'm organizing. And then what I can do is from there, I can actually reorganize it and rejigger it so that it actually makes sense. And it really, really helps me get all of the ideas on paper or on the screen in this case, and get an idea around how these things come together. So if you're looking to put together a project or organize some ideas, you should definitely check out Miro. You can find simplicity in your most complex projects with Miro. Your first three Miro boards are free when you sign up today at Miro.com slash podcast. That's three free boards at Miro.com slash podcast. 
Do more with your error tracking and reporting with the new Raygon API. My friends over at Raygon have filled me in on the endless possibilities created by this recent launch. Have your error reports regularly received, track custom data and so much more. It's easy to use with comprehensive documentation, so getting started is no problem. RayGun is a trusted suite of monitoring tools used and loved by thousands of software teams daily. It is the ultimate developer tool for error tracking and reporting, and they have a 14-day free trial if you aren't already signed up. Visit raygun.com for more information about the RayGun API and monitoring tools to take your software to the next level. That's raygun.com. 

DAN:  So again, pulling back a little bit from what I've seen, and you've got a great video, by the way, on the bit.dev website. I mean, one of the big challenges, of course, in the podcast medium is that you can't really show code and you can't show the operation. You can only describe it. So I certainly invite our listeners to go to bit.dev and watch the video and click the link to the YouTube channel and watch the intro video. It's very clear. But essentially, it's a command line tool. You use it kind of like you would use Git or NPM. You use it to create a new project. Components are what you would expect React components to be. So there is obviously the component code itself, maybe a bit of styling associated with it. You would likely have a spec file for tests associated with, for unit tests associated with that component. So that all goes together but in addition to that, you throw in a lot of additional stuff per component that makes them composable. Like from what I saw, you made it possible to configure distinct workflows or almost you might say a distinct CI-CD per component. 

GILAD: Yes, that's true.

DAN:  So the unit of operation is the component. You use the command line tool to create a new component. You tell it what kind of component you want to create. And from that moment on, your tool knows about that component. And that's what makes it composable, right?

GILAD: Yes, I will elaborate a little bit about this part because this is really a crucial part of both the solution to the problem and like the dev experience that you get that is very important. So we came up with a concept, we called it environments, component environments. Component environments are also components that kind of like satisfy an interface of what is a.. to be an environment and the component environment are managed the entire life cycle for other components. You can think about it as a extendable, composable, custom, create React app. So if you take create React app into a component, then you can extend it and share it in the organization and create another environment based off it. So this type of components are managing stuff like the compilation process, the linting process, the testing process, the bundling process for other components. So the concrete example is I have my organization or my department react environment. What it means, it means I want my organization to use TypeScript. I want to use this configuration of TypeScript. I want it to use Jest, for example, and I want to use ESLint with these specific rules and some other tools. And from, and I have some templates for my React components, template for UI components, template for hook, for React Hooks, for example. And from then on, when I create a new component, I say the type of this component is this React environment which means the component, when we version the component, okay, because we version each component individually, each component has its own history. When we version a component, this unit of versioning contains not only source code, it contains source code, it contains the dependencies, it contains the configuration and the environments. So wherever I take this component, inside the component, I have everything I need to build, compile, test it and I can have many components from different types in the same workspace and get unified experience. What do I mean? It means that in one project I can have one component in TypeScript, one component is in JavaScript, one is using Jest, one is using Mocha, different bundles, one is node component even, and I can tell Bit, the CLI, I want you to compile all my components. I don't need to know the configuration of how you compile them. The original author of these components specify how we want to build these components. And I can tell big compile all the components or lint all the components and each component will be linting according to the original standards that already baked in into these components. So I get one unified output and I don't need to mess with anything. No TS config, no ES config, nothing.

DAN:  So I have an observation and then a question about this. So I'll start with an observation or what I understood from what you said. So the environment that comes along with the component is basically configuration as code. If you take the configuration, you expose it from behind an interface, that interface might have a compile method, and in which if it's a TS component, it would run the TSC. If it's a JS component, it might run something like ES, like a bubble or something like that. It has a test endpoint, a method in that interface. So it's basically just an interface that represents all the things you might do with a piece of code really, you build it, you test it, you bundle it, all of these things. You might preview it. So all of these things. And those are exposed as code behind that interface. So it might be either a custom implementation for that component, or that component might inherit some generic organization level wide, like if we decide that throughout the organization, we basically want to use just everywhere, then I assume it's easy to make sure that all our components basically inherit that rather than each one needing to reimplement that aspect of its operation. So that part I understand. And really in the directory structure, it really like goes together in that same folder, all the relevant stuff for that component, the component code itself, but also the environment that's associated with the component that that's that I also understand. What I'm less clear about is how does this given, for example, that each component is has its own versioning. How does all this fit into Git, for example, like you, you talked about being similar to mono repo tools. So I assume you use similar mechanisms, but can you elaborate on how you manage this stuff in a code control type environment? 

GILAD: Sure. So first let me say that your observation about the environment is very, very correct. It's basically exactly what you said. It is even not visible actually to the end user most of the time, you just want to specify. what is the name of the end and the platform team is managed the environment. And this environment is also just a regular component. So it can also be versioned as well because it's just a component eventually. So the platform that you're using, the tools that you're using is also versioned. Now let's talk about Git and Bit and how they play together. This is a very, very common question. So first, let me start with the fact that you can work with Bit and Git together with no issues. Actually, most of our customers today are using Git and Bit together. Even in Bit itself, some of our projects are using Git. But there are kind of, I would say, I don't know the word in English. There are kind of stress between the two. Because what is your source of truth? So we at Bit, we built a similar version management system, which is similar to Git behind the scene. It's a distributed version control for components, which instead of managing repositories and files, we manage components. Like what I said before, every version of component is the source code, the artifacts, the environment, the configuration, the dependencies. And you can host this as your source of tools in our cloud. And you can also do it in our cloud and in Git together. And in that case, you might need to kind of sync them in some cases. But you can also work in Bit without Git at all. Because eventually, once you have versions for components, you don't really need versions for your project. And this is a very interesting thing. And by the way, our project and in our organization, we build everything from bit, with bit components. We're very radical about dogfooding. So the entire bit cloud, the landing pages, the documentation, the CLI tool, the backend, everything is bit component. And most of the code in our organization does not exist in any Git repository. Okay, so we are working on it without Git repository. And this open, and you paradigm of how you develop a feature, okay? Because this is a very different kind of working thinking. Let's say you have a feature to develop. You need to develop, I will take examples from front-end, but it's exactly the same for backend. It's just easier to imagine when we talk about front-end. Let's say you have a feature to implement. You need to implement a new header for your website. Today world, what you're doing is you clone the repo you have the application, and you start building the header. This leads you to be living in a context of the application. So there are more chances you will kind of rely on outside application stuff. And this makes your components more coupled to the project or to the repo. What we are doing many times is we are using, let's call it disposable workspaces. Okay, I need to build the feature. What is a feature? What is the definition of feature? This is comes to a bit in the methodological aspect. What is a feature? In our eyes, a feature is a definition of set of components. Some of them need to be created. Some of them need to be used. Some of them need to be modified if they exist, but we need new APIs. change API. This is the definition of feature. So we create a new workspace. It's just a new folder containing nothing, empty folder. Then we create the component we need, header. We install the dependencies, let's say a menu item, a button, a search bar, I don't know. Maybe backend components as well, because we need to talk with the microservice. And once this is done, we just export it to the cloud. And this is available it is consumed by the application. So we are building our feature in isolation from the first place. And then the application team is just consuming new versions of new components or the first version of new components in the application. The application is also just a component so you can import the application into your workspace to see it working in action, and then ship it all as like change request for many components. So this leads to a little bit different workflow, which we believe is much more scalable and much more in the organizational level eventually leads to more sharing, more reusing and faster development because eventually what we want to achieve is, you know, faster development team, faster development, better quality code, better consistency. And this is the way to doing all of this. As, as like I said, this is a methodological shift and technological shift that requires you in order to be able to develop components and bring other components like bringing the source code. Okay. Because in B2F the concept import. What is import? Import is basically when you want to take another component into your workspace and modify it in your workspace. Okay, so I'm taking the application and I have the bit will import the source code and we'll do all the wiring. So now I can change the application. I can tell bit compile it and run it without me to need to do anything. I don't even know this component, what tools they are using. I don't care but now I can change it because I'm just working on its source code and I can use it from all over the place. I can change it from any context I want, from any project I want, from any workspace I want. 

DAN:  So when you're talking about changing the component, does that mean that by definition you're getting your own like version of the component that's kind of built on top of but distinct from the common reusable component? Uh, like how, how do I, so let's say, let's get a, let's look at, uh, like a theoretical example, but a fairly concrete one. So let's say there's a button component in the organization that everybody's using. I'm using it in my project, in my kind of the application that I'm building from bundling all these components together but I need to change a certain behavior of that button. Maybe that button doesn't support rounded corners. I need rounded corners. Nobody else currently needs rounded corners. So I'm not going to go, I'm not the original owner of that button anyway. So what do I do? Do I like create a clone of that or a fork of that component? And if I do, how does that deal with the fact that the base component that I built off of might change because it gets a new version. How do I merge potential conflicts that arise from something like this?

GILAD: That's an amazing question, and I'm glad that you asked it. Let's talk about this flow, and it's also like a very important flow. Before talking about the flow, let's see that this specific issue, it's an issue that exists today, right? If I'm using the design system button, and I need to round the corner, what do I do today? And by the way, this is a great example, because I just, last week I...I did a talk in the React Advanced London, and my exact example was like Spotify player controls that they need the circled play button, and it doesn't support like a circle button, so. 

DAN:  Yeah, it's important to say that we didn't talk about this in advance, so it's totally happenstance that I came up with the same example that you did. No prior coordination.. I promise.

GILAD: Great. So today, this is another reason for me to not want to use design system or someone else's code. Because if I need to change this code, this is very problematic. I need to clone this repo. I need to read these contribution docs, to read the setups docs. It can take a long time. Let's say I did all of this. Now I'm... In another context, I mean, repo, like in is repo right? I don't have now the bug. If it's adding a behavior, maybe I can do this. But if it's a bug, for example, in a more complex component, I don't have the bug reproducible in this fresh or isolated repository. How can I reproduce the bug to make sure I fix it? And then let's say I did it. What in the time between it get my change request? and merge it and publish it? How can I consume like this version until then, right? Because I need to move forward, but it might take him two weeks to review it, two weeks to merge it, and then another month to release it. What do I do in these two months until it's available there? And what we are doing, we came with a concept called lanes. A lane, you can think about a lane kind of similar to a branch in repo, okay? but it's a bit different because a lane is kind of a cross repository branch, okay? Because each component is like a mini repository. It has its own versions and history. So when you create a lane, you start modifying or creating a new component in this lane. Okay, this lane can have many components from different teams, from my team, from other teams that I'm changing or creating. Now, at some point I want, and now I can create this lane inside my project. So I'm bringing, I'm making a new lane. This lane is, I'm changing the design of my application. I'm adding the button, this round corners, and I'm using this new button in my application or page or whatever. Now I want to change this. I want to suggest this as a change. And this change request, like a cool request in GitHub, it's part of our cloud solution, is a bunch of components that you changed and you did kind of a fork. Like you said, it's a fork. We do have a fork command. We have an import command. It's a bit different. Do you want to make a completely detached version of something, like kind of use it as a template? Or you want to use it, change it, and then suggest back the changes? So they will at some point merge back to the original component. Okay, so it's a bit different flow depending of course on your use case. New use case you want to modify an existing component and eventually you want this behavior to come back to the main real component. So you create a lane, you change this behavior, you use this new component and now you suggest changes. And this now comes to two different flows. One is the review process that is important to understand. And we built, it's a little bit hard to like describe it without showing it, but I'm inviting everyone to later on, take a look on our change request in the cloud. So you want to review it. This review process, it's a multi-organizational and multi-dimensional review process because you change many components. Some of them are not yours component, are not your components. Okay, you're not the owner of them. You don't have permission to publish them, like to make like an unofficial version of them, let's say, like a semantic version. So you need to get now a review from your team members, like your peers. You need to get a review from other team members. You need to go to get a review from different kind of people. You need to get a review from product team that this looks as they expect. You need to get a review from design system team, like from the designers, like people who are not developing. You need to sometimes get a review from, I don't know, content writer. And so this is like multi-teams, multi, let's say roles in the organization, and also multi-type of changes. Because like we said, we, we version for each component, not only the source code. We version the environment, we version the dependencies, we version the configuration. So part of the review is also checking if you change the dependencies, right? You need to be able to see visibility that if you maybe your button is using, like, I don't know, a basic button, and you change the version of the basic button, or you change version of, I don't know, load-ash inside or something else, so the review process contains not only code changes, but also configuration changes. Maybe you update the environment version that this button is using. Also the dependencies changes. So this is about the review. And all the stakeholders need to approve this in order to merge that. And then you have like an atomic merge across many components from many teams. This is part one. The second part is what happens if this button during this time of review process is getting new versions by someone else, right? And this of course, happens all the time. So we build like emerging tool and conflict resolution tools that knows not only to handle code conflicts, like in Git, we only know to handle dependencies conflict. What if you change the version of dependency and someone else change the version of the same dependency? What if you had dependency, but someone else remove the dependency So we built a merging tool and the UI to see conflict between source code, which is basically very similar to Git, and even use some Git tools behind the scenes, by the way, technically talking. And it also show you the conflicts and dependencies and the conflicts on configuration. So you can merge each one of these parts. And once this is up to date with the main line, then you are able to merge it. So this is part of the prerequisite in order to merge your component or your lane is that it doesn't have any conflict with the main lane right now. Similar to what happens when you do a pull request in GitHub and someone push code to the same file. 

DAN:  So what I am understanding is that your ideal scenario in terms of tooling is rather than using Git or GitHub, I'm using your source control mechanism because it's focused on the component level rather than on the project level. Is that correct? 

GILAD: Yes, but we don't really care about it. So what we see here in practice in real life is most of our customers today are using Bit and Git together. And they do. And we build different tools to make it easier. And we're still improving these tools. So for example, one thing that people are doing, for example, is they want to use bit in order to create new components. So to save the creation of the red problem and to deal with the discovery problem, which we didn't discuss yet, but we can discuss it in a second, discovery problem, but they don't want to adopt the review process yet because they don't want to abandon Git, for example. What they are doing, for example, is they do a pull request in GitHub or whatever Git provider they're using. Regular pull request, someone reviewing this, and once it's merged, their CI, which is not our CI, their CI can do, for example, snapping or tagging a new version for all components and export it to the BitCloud, so they get discovery and reusing stuff. So this is one flow. Another flow is that people are doing like, kind of syncing. So once you create a pull request, we will automatically create a lane by the CI, by their CI, like Jenkins, Gitabection, whatever, Cilkel. It will create, programmatically, it will create a bit lane, push the lane to remote scope in the cloud, and then they do the review either here or here. And once you merge the lanes, they merge the PR, or once you merge the PR, they merge the lane. However, they want to manage it. So we do have many, many automations if you want to take only part of this flow and to embed it, because changing this flow is a long process. And you understand it and it's totally fine. And we don't really care if you use Git as well, where you do this review process. Of course, we optimize the entire experience around components. So another big part of it is, which we also didn't discuss, is CIE. what you do about CI, how you test your components in a CI level. So in today's world, what any organization is doing is using traditional CI, like GitHub Actions or whatever, single CI, which is in the project level. So our CI run when someone merges something into the project level. We came up with a different approach, which is a component-based CI, what does it mean? Let's say you make a new version of a button, okay? Now your goal is to ship this button to the production as fast as you can. But this is a big problem because this button is consumed by many teams around your organizations. They don't even know today that you shipped a new button, right? Especially if it's not the design system, but other components they don't know there is a new version. Who tells them there is a new version? So what we did is, because Bit is aware of the entire dependency graph of the entire organization, what we are doing is we build a CI called the Ripple CI, which basically propagate changes from each node up all the way to the chain. So let's say you change a button. We will test the button in our CI. If the button is good. we will check, let's say, the card which uses the button. If it's good, we will check the gallery which uses a lot of cards with the new version of card, with the new version of button, and everything is like a fake version or like a virtual version if you want it. It's not like a production version yet. So we create mock or virtual versions for each node, and we spread it in the entire organization, which means that you get first a very, very fast because one, we can parallelize the CI process in the amount of components, because each component can run on its own container alone. So you can parallelize to the maximum possible. And then also you only test what is affected by these components because we are aware to the entire graph. So if a component somewhere is not using any of the dependencies, even like down deep in the tree, not using this change component, then we don't need to test it because it's not affected. So we are only testing what need to be tested. And we now also give you visibility to how your change will affect other users. So we changed the button. Let's say you didn't make the breaking change, but accidentally you did. You didn't plan, but you did a breaking change. Now immediately you will see that your button is breaking like the about page in which is belong to a different team. And now you have the visibility, you see the entire graph between button and this page and why exactly it's breaking. You can communicate about this change. Maybe you did breaking change. Maybe they use like internal API, like implementation details that they shouldn't use and that's why they break. But now you can see this across the entire organization. You can understand the impact of each change on all of your consumer before you actually make the, before you make the real version, before you ship it.

DAN:  So we are starting to run short on time. And we are talking about a really sophisticated system with a lot of capabilities. I mean, we've heard about versioning and about control and about constructing components and configurations and code and so on and so forth. So obviously, we're not going to be able to cover everything. I understand that you really wanted to touch on discovery. Is that something we can do really quickly in a few minutes? 

GILAD: Yes. Yes, I can do this quickly. I will try to be focused. So discovery problem, what does it mean? I share the component. Now, if no one can find this component, no one will use this component. And this is kind of pointless. Splitting quickly the discovery problem, I will split it to, let's say, three different areas. The first one is searching. How can I find the component I need? And searching component is a complex problem because when searching a component and there is no real search engine for components today, I want to search components with, let's say, specific dependencies, but with no other dependencies. I want to search by bundle size. I want to search by React 17, but not React 18. I want to search by loaders, but not random. I want to search by APIs. I want to search by test coverage. I want to test, I want to search by many different stuff. And this is the first problem is how you can do like a more contextual search for code. This is the first problem. And we do have like a few patents about component searching. The second problem is like, I would call it experience component. So let's say I find few potential components to use. I found few buttons. How do I know which button is the right fit for me? I need to see many stuff. I need to see docs. I need to see test coverage. I need to see the button rendered. Okay, if it's a UI component, I need to see it rendered. What happens when I do hover? What happens when I do click? Does it have like, I don't know, animations or whatever? I want to see it in various, in various example of this button. I want to experience this pattern before I'm using it. And the third problem is, I would call it like ranking the component. I want to rank components based on different metrics, like I don't know, bundle size, dependency size, test coverage, the author of this component, social metrics, how many people are using it, how many people like these components, like GitHub styles kind of, or NPM downloads kind of stuff, but ranking is much, much bigger than GitHub stars or NPM downloads. All of these are set of problems that in order to do effective sharing and reusing, you need to solve. And we build many tools, by the way, open source, almost all of them, to do different stuff like, for example, automatically extract your API from your components and give you automatic documentation and automatic examples of your components. So someone that sees your component on the cloud can easily see a good fit for him. And this is like the second set of problems in order to do like effective sharing. After the creation of it, there is the discovery problem. And the third, which we already talked a little about, is like how we change something, like the contribute pick, which we already discussed. 

DAN:  So yeah, so we're kind of reaching the end of our time and this is a lot of information and like there's the bit.dev website and like I mentioned before, like a YouTube channel where a lot of this stuff can be seen. So if people want to reach out to you guys or to you personally, specifically Gilad and learn more about what the system is and how to best use it and to see examples and whatnot. What's the best way to reach out to you? 

GILAD:So we do have a Slack channel, Slack server for Bit. You can find it all over the place in our GitHub, cloud, landing page everywhere. So this is one option and I'm very available there. If you would just tag me there, I would see it. I'm there all the time. You can also see also reach out to me on Twitter. I will add the link maybe on the description of the podcast so you can find me there as well. And actually also GitHub issues, we're maintaining the open source so I would see any GitHub issues that you will open. And basically I'm a very reachable person. So LinkedIn, GitHub, Slack.

DAN:  What's your handle on Twitter? My handle is x. 

GILAD: So my handle is shohamgilad. One word is capital S and H. I will try to write it down. 

DAN:  No, we'll put it in the show notes. Excellent. 

Hey, this is Charles Maxwood. I just wanted to talk really briefly about the Top End and let you know what we've got coming up this month. So in February, we have a whole bunch of workshops that we're providing to members. You can go sign up at topendevs.com slash sign up. If you do, you're going to get access to our book club. We're reading Docker Deep Dive, and we're gonna be going into Docker and how to use it and things like that. We also have workshops on the following topics, and I'm just gonna dive in and talk about what they are real quick. First, it's how to negotiate a raise. I've talked to a lot of people that they're not necessarily keen on leaving their job, but at the same time, they also want to make more money. And so we're gonna talk about the different ways that you can approach talking to your boss or HR or whoever about getting that raise that you want and having it support the lifestyle you want. That one's gonna be on February 7th, February 9th. We're gonna have a career freedom mastermind. Basically you show up, you talk about what's holding you back, what you dream about doing in your career, all of that kind of stuff. And then we're going to actually brainstorm together. You and whoever else is there and I, all of us are going to brainstorm on how you can get ahead. Um, the next week on the 14th, we're going to talk about how to grow from junior developer to senior developer, the kinds of things you need to be doing, how to do them, that kind of a thing. On the 16th, we're going to do a Visual Studio, uh, VS code tips and tricks. On the 21st, we're going to talk about how to build a software course. And on the 23rd, we're going to talk about how to go freelance. And then finally, on February 28th, we're going to talk about how to set up a YouTube channel. So those are the meetups that we're going to have along with the book club. And I hope to see you there. That's going to be at topendevice.com slash sign up.

DAN:  So our final part, as usual, of any of our episodes is our pick section So you've been mostly quiet, Steve. Do you have picks for us? 

STEVE:   Yeah. So a couple, I'll do the, just have the dad jokes of the week, which as we all know is the high point of any podcast episode. Without the rim shot effects, I still got to get those back. 

DAN:  Yeah, definitely.. 

STEVE:   Because they make it

DAN:  They make all the difference in the world.

STEVE:    Oh yes. So question, although AJ, I bet if AJ laughs really loud, that'll help. But

DAN:  you need to work for that and the AJ needs to unmute for that. 

STEVE:   Right, right So a question, what do bears call campers in sleeping bags? 

AJ: Burritos, burritos, 

DAN:  I thought candy bars wrapped up,

STEVE:   you know, food, you know, a couple of random thoughts. So if the Earth is the third planet from the sun, does that make every country a third world country? He thought milk is taking milk, but watering is giving water. And finally, needless to say, saying needless to say is needless to say. And then, uh, uh, finally my son asked me the other day, he said, he asked if I was named after my dad and I said, of course I was, he was born many years before me. 

DAN:  Yeah, that's a good one. 

STEVE:   Thank you. Those are my those are my my dad jokes of the week

DAN:  Cool. So AJ we move on to you 

AJ: Give me a chance to wake up, sweetheart. I Don't use that one nearly enough, uh, let's see. What have I got it seems like i rewatched Batman Begins recently and it's a good movie. I like it. I can strongly recommend that. Also, I have continued on with my binging of prime time and I still have to say I really enjoy the primogen. He is a funny guy. I love I love that he's got the chicharrones to throw out some politically incorrect jokes from time to time. That just really makes me feel happy. Because there's too many people in tech that just put up so many pretenses and it's just cool to see him be his authentic. how to phrase this dumbass self. Pardon my French, but you know, he's just, he's a funny guy and he's got that, that, yeah. Yeah, I love it. I love it. I love it when he's just being, yeah. So I highly recommend the prime again and pardon my French, because I know that I don't normally use that kind of language, but it's biblical, so it's okay, right? That makes it moral. 

DAN:  Yeah, well, the Bible has more coarse stuff in it than most people are aware or assume. There are certain chapters in the Old Testament which, you know, 

AJ: are dedicated to what a man is and isn't allowed to do with his farm animals. 

DAN:  Yeah, there's also like this entire chapter i think it's in Ezekiel where he compares Israel and Judah to a pair of harlots and goes into great detail about what and how they do that.

STEVE:   Yes. Genesis has a lot of sex in it. I've had to realize that when reading through it with my son. 

AJ: Yeah, there's a lot of... Well, okay, so now that... I'm just going to insert this since we're here. So I lived in Albania for a while, and I was a missionary there. And their translation of the Bible has, like, they have their version of the F word that, you know, kids will say to you on the street, and that kind of thing. There's another word that I don't know what it would translate to in English, but people will not say it at church. And it's in... in the Bible and when they come to it they just they will not read it they will Mumble they will and and so me being someone who's not really familiar with the culture I just read it and like the whole room just gasps like But I don't I don't actually know what I don't know what it translates to but it's it's yeah It's it's it's something in there along the lines of harmless. 

DAN:  So, you know Albanian

AJ: I do I am actually Um, fluid. Well, not anymore. Cause I haven't spoken it in years. Cause there's not really any opportunities to speak it, but I was so fluent in Albanian that people would ask me if I was from the North, you know? So I obviously had an accent, but they just thought I was from the North. So, but I did, I did serve a lot of time in the cleanest speaking areas of the country. So there's Lushnia and Fior and they speak what they call the juutapasta, the clean language. And so I spent a lot of time there and people enunciate very properly and everything. So I picked up kind of from the... And then I went to one of the other cities and it was as though I was learning a different language. I had... I think I'd been in the country for about a year. I spoke fluently and I routinely had to have my Companion who had only been there for six months translate for me because they had the thickest accent Anyway, you know completely unrelated but since since the time fell there And then I don't know. I don't know what else I have for for pics Just trying to think of something off the top of my head but I know i Mario Kart with the with the you can you can put it in the kid mode where it auto steers and auto goes That's that's gonna be my pick because now that both of my children want to play together You know, it's really really challenging if you remember being a kid and you never wanted your younger brother to play because he would drive Backwards and not finish the race and then you and your friends couldn't continue on but your parents are like well let him play too and with Mario Kart 8 you don't have that problem could you just put it in go forward mode that won't allow him to go in reverse and will steer to the finish line so if he does nothing but hold the controller the wrong way it'll finish the race so that's yeah yeah so that's an eternal pick I mean that that one just that's the gift that keeps on giving I just keep on seeing new scenarios over the years. I mean, it's the same scenario, but. You know, different, different kids, different groups. It's just, it's the gift that keeps on giving God bless Nintendo. They did, they did great on that one. The ACE team. 

DAN:  Okay. So my pick section is also not exactly a pick section. Uh, this is a very emotional time in Israel because as of the time of this recording Like every day a few more hostages are being released. So in the past couple of days like 14 were released and 13 were released. And I think today 11 are being released. And hopefully it will go on for at least a couple of more days. There are a lot of hostages still there are like almost 200 hostages or around 200. hundred hostages still being held by Hamas. And we're talking about mostly civilians and kids and elderly people and women and teenagers and whatnot. So, you know, it's very distressing, the fact that they're being held in the, you know, by terrorists in the conditions that they're being held in. So every time we see like another group of children being released on the one hand, the entire country is a collective sigh of relief. But on the other hand, we also think of the other people that are still being held. And sometimes they're literally splitting up families. I know that there have been a lot of arguments around this. Israel is really trying to push back hard against this. But sometimes you take what you can get. So there have been cases where the daughter was returned, but her mother wasn't. In particular, I want to mention the B bus family were kidnapped, as like the entire family was kidnapped. They're a family of four. So it's the husband, wife, and their two children who are ages four and 10 months old. And they're being held as hostages inside Gaza and they're not releasing them so far. You know, so we are really, really hoping for the best. It's, it's, it's, as I said, it's a very emotional time for the entire country to the extent that it almost like takes, like subsumes everything else. Like it's the entire discourse of the entire country more or less revolves around this, uh, the situation. Um, so it's not exactly a pick, but it's what I wanted to mention. Um, yeah, Israel in a lot of ways is, is like a country that's even a month later, even more than a month, 50 days, it's almost two months, still a country that's very much in a state of shock over this, uh, this whole thing. Um, so yeah, so that, I don't know if I wouldn't call it a pick. I'd call it, uh, 

STEVE:   deep thoughts, 

DAN:  deep thoughts about the current situation. And, uh, so I, but I apologize for like dragging everybody kind of down. But on the other hand, like I said, the children are being released and that's definitely a good thing and we hope it continues. 

STEVE:   Yeah, you notice that they're not releasing any of the men though.

DAN:   And they're unlikely to in the foreseeable future. It'll probably, I don't know what will happen. Nobody really does, but there's a good chance that it would require another pretty significant round of fighting before we get to complete release of all the hostages. I know that some of their like, it'll probably not come about without the continuation of the war. Let's put it this way. I'd be really surprised if it does. Anyway, Gilad, do you have picks for us? Hopefully more. more pleasant ones than my observation. 

GILAD:Yes. So, uh, first, yeah, the, the war is like, kind of really everything I thought about in the last 50 days, it was like very, very tough days for me. So I want to focus on what helped me, uh, kind of, uh, ran away from the reality for a bit of a time. Um, I just, uh, start playing again table tennis, professional table tennis training after I didn't play for like, I don't know, 15 years or something. Today I just got a new racket. That's actually, I stopped this training with the new racket today to come here. So I didn't finish my training today, but it really helped me so much to kind of releasing energy. I guess in general, doing sport and exercising is very good to the soul and to have more positive thinking. But I find it very, very helpful for me. And the days I'm playing and exercising and training, these are kind of the only days in the week that I'm kind of able to get some, let's say, I won't say even normal sleep, but kind of sleep because in other days I'm just, for 50 days I almost didn't sleep because it's, yeah, it's, every night like we are saying in Israel that the parents now in Israel are waiting for the kids to fall asleep so they can start crying. And yeah, this is very, very much true. I see it everywhere, all of my friends are in the war, all of my friends, all of my family. Everyone is now fighting there and every day I'm opening the news hoping that none of my friends or family is is armed there. But yes, trying to focus on doing sport and doing good stuff and try to go back to doing things like this. And that's mine for today.

DAN:  Thank you very much, Gilad. It was really interesting conversation, learning about a different way to manage a software development. It's not very often that you hear about an entire holistic system that manages software and addresses software construction in a totally innovative and new way. So thank you for that. And also thank you for our listeners for joining in. And that's another episode of JavaScript Driver. So bye.