Sami Jaber is a Software Engineer at Builder.io. He joins the show to discuss "Implementing CSS Style Inheritance in React Native". He starts by talking about the inspiration behind the article's concept. He also talks about Mitosis, how to use it, and its features. 

Hey everybody and welcome to another episode of React Roundup. I'm your host today, TJ VanTol, and with me on the panel I have Paige Niedringhaus.

 

Hey everyone.

 

Did we lose page?

 

Can you hear me?

 

Yeah. All right. You just like, you froze it like the exact like time right where I entered you. So I'll just do it from the top. Hey everybody. And welcome to another episode of react around up. I'm TJ Vantolo and I am your host for today. And with me on the panel, I have Paige Neidringhouse.

 

Hey everybody.

 

And our special guest for today is Sammy Jabbers. Sammy, welcome to the show.

 

Hi TJ, thank you for having me.

 

Yeah, so we've got a variety of stuff to talk about today, which is gonna be kind of fun, but why don't we start by just having you introduce yourself, saying who you are, what you do, why you're famous enough to be here today. He, he, he, he, he.

 

Yeah, sure. I don't think I'm famous. My name is Sami Jabra. I'm a software engineer at Builder. Primarily, what I do there is focus on Mitosis, an open source project that we have, and building our SDKs for Builder's CMS, which are built on top of Mitosis. So those are the two things that I primarily do. If I'm on here, it's maybe because I've been dabbling more and more with creating a bunch of content these days. on Builder's blog and maybe something caught somebody's eye. And that's why I'm here.

 

Cool. Yeah. So there's a lot we want to dig into. I know we want to talk builder. We want to talk mitosis cause those are pretty cool, but we'll start. Just you mentioned your content. We reached out because you had an article you wrote about CSS style inheritance in react native. So maybe you could just start talking about, you know, what you do in react native and what specific problem that sort of led you to, to talk about and publish that.

 

Yeah, for sure. So that piece that I wrote was specifically about adding a style inheritance in React Native. And that's something that I stumbled on while I was building out all these SDKs and making sure they all have feature parity. And we had some users who are building on top of the React Native, build their iOS SDK, say like, hey, like my text is not getting styled inside the buttons and all of that. And after, you know, spending a bit of time digging in, I'm not somebody who's written a lot of React Native code. By that I mean, I say... fairly written any, realizing that, yeah, React Native's entire style mechanism just kind of skipped over the style inheritance part of CSS. So they never claimed to be CSS. They don't cascade. So the C is not really there. It's just style sheets without cascading, kind of. But since we're building out this system that should allow somebody to render the same builder content on a React app or a Vue app or a Quick app or a React Native app, the same way, then we kind of have to re-implement cascading in React Native. So I ended up doing that by building out this kind of little trick, this context in React that is React Native, that's kind of holding on to all of the styles and drilling them down on its own and merging them into the child styles over and over so that every child kind of has all of its parents cascading styles applied to it. Yeah, there's more details in there, but the trick is just to use context, and in that case, it works beautifully. And yeah, that's one of the many things and the pitfalls that you find when you're building and the same SDK for six or seven different web frameworks. If you can't react native as a framework as well, then you always find the limitations at the edge where one of them doesn't match the other five or six or seven. and you have to fill in the blanks.

 

So this is super interesting because so maybe you could just describe because so was this work for as part of mitosis? Is that right?

 

Yeah, so I didn't end up implementing it in Mitosis. It's currently just sitting in the SDK code base as a one-off thing. So that's a good question. And to take a step back and explain what Mitosis is to the many folks who might have not heard of it, it's an open source project created by Builder that lets you write a component once, a UI component, and define it once using GSX. or Svelte syntax, which we added recently. And then that file will be converted, compiled into as many other files as you want. If you file a React file, a React Native file, quick solid JS Svelte. And those, I mean, goes way beyond that. You can have a plain HTML in JavaScript, you can have it be a web component, you can have it be lit elements, etc. And so that's the core concept of that MyTosis project. the primary use case that we have for it is that Builder is a visual headless CMS. And people want to use those with whatever web framework they have. And we do need to for folks to integrate it properly. There's a bunch of work that needs to be done that's framework specific, rendering components. There's like server-side rendering things. There's contacts that needs to be like held on to and passed around. There are a bunch of different things that need to happen. And so, After we served our React customers and then we started moving on to other frameworks, we realized just how tedious it is to do this over and over. And so we created a kind of weird, clever trick with Mitosis that kind of lets us minimize that work and have a single code base that generates all of these SDKs.

 

So is Mitosis something that you would actually include in a web app like a React project or an Angular project? Or is it more of like, I need to build a component library, but I need it to work across Vue, Ansfeld and React. And then you just like import the finished product.

 

That's a really good question. It's more of the latter, for sure. Mytosis leaves no trace in the final output. So it's a compile tool. It's a build time tool. So it's kind of think of it as like a Babel plugin or something. It's not that, but it's built on top of Babel and on top of other build tools. And it only exists when the developers is building on these components, but then the final output looks exactly like something a developer would do by hand, it looks like something a React developer will build by hand or a Vue developer or a Quake developer or a Svelte developer. So the end user of your package will have no idea that this was written in Mytosis, save for maybe some like edge cases, be like, oh, this code looks like a little interesting, but 99% of the code would look exactly like a normal code written by hand in there, not generated by Mytosis.

 

So

 

interesting.

 

it is a project that's open source. Is it how, like I'm curious at a high level, because he described it as a build tool, but maybe you can describe a bit of how it works because it's like web components being the glue underneath this. Cause I'm fascinated because it's not easy to make a component work across, like I see, I'm looking at this get every bill. I see a lot of icons here. And like some of them, I don't even know what these things are. So I'm very curious how you pull this off.

 

Yeah, I can definitely go over that and explain the core concept. The core concept, I think, is kind of surprisingly simple and elegant, and then it's just a question of convincing people, does that really go all the way? And the answer is so far, yes. So far, maybe, say for a few tips and tricks along the way. The core idea of how my dosis works is that you write a JSX file. And, well, let's back up for a second. The main realization that we had at Builder about all of these framework frameworks is that regardless of how insanely complex and different they might be under the hood, writing them, the experience of writing a UI component and Vue, React, Svelte, Angular, blah, blah, blah, is surprisingly similar. A lot more similar than people might think. There's a bunch of syntax, you do like equal curly brackets, and then you may do a colon in another language, or you might have like quotes, and then that's where you put your variable. There's some syntactical, does you just have to know the different syntax for each one, that's one aspect. And then kind of the other aspect is, you're gonna have to import something that's different for each framework, but almost every web framework implicitly agreed that they need to allow their users to do the same set of things. So, whether using React, Vue, Angular, or Svelte, or Quake, or Solid, they're all kind of like, well, people need to build, write HTML, and we're going to use JSX or HTML of some kind of syntax, and then we're going to let them style it with CSS, and that's the same everywhere. And then we're going to let them write JavaScript, and it's either going to be properties that you can pass down, or it's going to be state, and sometimes that state needs to update depending on other things that change. And then you need some kind of context sometimes to pass things way down, way down the, like the drill it all the way down and kind of already what I just listed, I think represents like 90 some percent of all code that's written inside of UI components of all web frameworks. Like, yeah, there, there, there are more complex things, but like what I just described is like the vast majority of stuff. And

 

Mm-hmm.

 

if I told you now, like here's like, write me a div that is like a flex with a gap of 10 pixels, and it has loops over children that render spans from this array.

 

Mm-hmm.

 

And then every time the user writes an input, you update that list, you would be able pretty quickly, just from opening the Quick Start tutorial of every framework, to do that. And if you can do it quickly, then you can just encode that into some generators that just spit that as strings. And so once we realized that, the next step became, well, we know that if we want to, like, if our mind like, okay, we want a state that updates every time this other property updates, then we can, we know how to write that every time. And then we just do that over and over for every concept on mount, on mount, on update, props, state, et cetera. What we then needed to do is store all of that in a single source of truth. And... just going for the most easy thing to use as JSON in the world of JavaScript. So just storing all of that raw strings in JSON is good enough for us. Storing like having an array of all of the on update logic, an array of all of the state pieces, all of the props, the neighbor component, all of the context that are set or grabbed from a parent. And doing that... So now that's like, all I'm talking about right now is still how Maitosis is done. So like Maitosis has just a JSON schema and it describes in great detail every aspect of what a UI component is. And then it has like a children array, which can be like infinitely nested with like every child is another thing that gets imported. But then because nobody wants to write JSON by hand to describe a UI component, I mean, maybe some people do it, but that's not really

 

Thanks for

 

ergonomic

 

watching!

 

or convenient. So then we just went back to adding another step before that, which is JSX because that's just all the build tools are set up for that, all the types, then ESLint, like pretty fire stuff. So it's all already there. So we're not going to create a new syntax, for no reason. So then we added the JSX parser so that you can write code in JSX and you kind of import hooks that don't really exist from my toolset. So you import something we called on update, on mount, on on mount, on init. and you state, you store, and then you import all of these, and then our JSX parser finds these, it's like, oh, you want to update something every time something else happens, I'm going to sort that into JSON. And that kind of is what Mytosys is, like I went from the end backwards, but the way it would work is you write this JSX, Mytosys first converts it into a JSON, and then it feeds that same JSON object to in your 15 different generators that you want. then you can feed it to the same generator using different options in parallel. So you could feed it to the React Generator and tell it generate this in TypeScript or just plain JavaScript with styles that are inlined or with emotion styles or with styled components or styled JSX. And that's where the power of it really starts to shine where you can just generate any variation, like infinite number of combinations of variations of a... component for different frameworks at once.

 

I mean, that sounds amazing. And I'm just thinking about projects that I've worked on for companies in the past where they've had like two or three developers who have been in charge of creating the web components design system that the whole company is going to use and how it didn't work very well. And if they had something like this where they could have just generated components for specific types of libraries, this would have saved them. so much time and effort and grief. And it sounds it sounds so great.

 

Yeah, cause Paige, you'd used a stencil before for that situation, right? And I have experience with that as well. And it's I like, you know, kudos to the people behind stencil cause it's, it's really an innovative approach, but the problem I know I had when I've used it before is that because it's like wrap, it's like a web components implementation that they are wrapping with framework specific stuff,

 

Mm-hmm.

 

which is fascinating that it works, but in my experience, the debugging. involved there could get really messy really fast because sometimes there'd be some issue with the communication between the web component and the actual component and then like

 

Yeah.

 

you are in debugging hell at that point because you're like okay is the problem in my component is it in the translation layer how do i fix this and it gets messy and what i like about this approach is it doesn't try to like create this like intermediary format it's just kind of just straight up generating it's almost Really, it sounds like it's a project that's mostly around like, like syntax trees and string parsing, because that kind of seems like what it's doing. And it's you're right. I'm kind of fascinated that this is possible. I'm just looking at it like a GIF you have of your formatter. And I'm kind of mesmerized by seeing the different outputs getting spit out. Cause it's just really cool.

 

So how long did it take you to go from, hey, this would be a really useful thing to have to here's an actual working implementation that you could start playing with and telling us, is it good, is it bad, what needs to be fixed, what's useful about it?

 

So, when I joined Builder, it was already kind of a project that's being kind of used. So, that question would probably have to be redirected to Steve, the founder of Builder who's... Yeah, who's probably who's gotten who kind of took it from an idea to wherever. I don't know what percentage completion we could consider it as when I joined. But when I picked it up in January of last year, it was kind of in this place where, yeah, like this works. Uh, the foundation was all there. And ever since then, it's just been a question of adding more and more covering more and more edge cases. Uh, along with a few, there was a few core features missing, but The foundation of what I just described is so easy to set up. It's so easy to put together an initial idea of, okay, parse the JSX, generate a JSON by reading the AST, the syntax tree that Babel gives you, and then

 

Mm-hmm.

 

once you have that JSON, feed it into this little huge string interpolation, export default function, and then JSON.component name, and then open the brackets, and then you just inline stuff. And it's... What's fascinating about this project is that you very quickly see that it is working, but then with every new thing that you try to do, you go, oh, well, in that case, we need to do this instead of that. And then adding more is just a huge amount of edge cases in whether it's the parsing or the string, the generation of the components. So it's... Yeah, I feel like a lot of these projects are kind of more complicated. Like if you want to contribute to like a framework or something of that magnitude, you just get into the bowels and it's like what even is happening. But here it's just the, it's a breadth. It's a project where the breadth is enormous.

 

Mm-hmm.

 

But yeah, I don't really remember the question, but yeah, essentially, yeah, I didn't start working on it, but ever since I've been working on it for a year and... a couple of months, it's just been

 

Mm-hmm.

 

constantly identifying kind of new things that you have to work around. But it's already working with us, even when I joined, within a few months, we had a Vue SDK set up. So we had an old Vue SDK that we wrote by hand. So we

 

Mm-hmm.

 

did like React, then Angular, then a Web Components SDK, which was kind of, like initially we didn't want to do this. We had a Web Component SDK that we would have like just told everybody to use, and then we found all sorts of limitations. And so then when I joined, they're like, okay, we have this VSDK. Can we prove that mitosis works by getting it working on mitosis instead, get it generated by mitosis. And after kind of going from like zero to one with that, and we already had a React Native kind of very beta SDK working through mitosis, and then adding the view output and getting that working, then we kind of blaze like the path from zero to one, and we started adding a lot of them. So... Yeah, over the last year and three months, we went from React Native SDK that had barebone features to React Native, View2, View3, Quick, Solid, Svelte. And now we have a React Beta one as well that we're hoping is going to soon start replacing our core, like our old React SDK. And

 

Mm-hmm.

 

so, yeah, so it works. It works. You just kind of have to keep chipping away at... this huge surface area of bugs that you just can't wrap your head around sometimes.

 

Nice. That was going to be my next question is you said that there's, you know, between 10 and 15 frameworks or SDKs that you support. So it was going to be a question of what are those and you've pretty much nailed that. Do you have any emerging frameworks that you're looking to start creating SDKs for in the near future?

 

So in terms of SDKs, it's kind of depends on customer demands. Right? It's not we're not going to just flick. Like you can just turn on a switch and generate an SDK for every generator that exists in my doses. But that's not really like we're not going to generate an SDK for somebody that doesn't need one. So that's more driven by demand, because once you do enable that, you kind of have to go in and. you might find a couple of bugs, it's just one extra output they have to support.

 

Mm-hmm.

 

But in terms of how many generators my twosys already supports, that list is at least twice or three times as big as the SDKs we generate from our SDK. And it's surprisingly easy for folks to add new generators. So we've had a bunch of folks add generators for things I've never heard of before. There's something called Taro UI, which is kind of a framework that's popular in China. because it's like a wrapper around React that generates, generates like UI. It kind of does what Metosis does, but only for React and then two or three other frameworks that are popular in like, in the Chinese market. That just completely goes over my head. I'm like, look, if you want to contribute a generator, go for it. Yeah.

 

So to bring us full circle with how we started, because you mentioned there's a React Native generator for this as well. How, I'm curious, because I know React Native is still React in terms of the parser, but since the actual DOM is different, like how is that possible, I guess is what I'm thinking. Or like how does that one work at a high level?

 

Yeah, I mean, we definitely have a few maybe a few React Native specific tricks in there that we needed to get into Mitosis to get it working. But it's, you know, surprisingly simple. Again, you replace every div with a view element and you have an import for that. Because it's all a huge JSON, you just every time you're rendering a block in... in your React Native render generator, like, oh, is this block called a div? Well, then make it a view. And that's kind of the bulk of it. React Native reuses React's DOM generator under the hood. So the main thing that changes is all text has to be wrapped in a text component, like the React Native text component, and then all divs and spans become views. And then CSS kind of, that's another, I mean, that's kind of the whole thing inspired the blog, but React Native doesn't have CSS. It has a subset or different implementations, not even a subset because it has stuff that CSS doesn't have. So you kind of have to just map, go over any and all styles and map those and make sure that anything you're generating kind of makes sense in the React Native world. But yeah, it is still React under the hood. So all the hooks, all of that kind of stuff is just going to... work just fine, state the props and context.

 

Now I'm just still fascinated that this even works, but it makes total sense. It's just kind of toying around with the docs. You mentioned, so you've talked some about options like for CSS and like state management. Are there, maybe you could go over what options you do have for those and like other things, like what is configuration like in general? I'm also thinking like TypeScript, no TypeScript, like how many little like knobs and... What kind of bars do you give people to play with?

 

Yeah, a lot, a lot. I mean, we want people to have that flexibility. And because we're just generating strings, you just add like, if config.thing is different, then just spit this out instead. So, I mean, some examples of stuff that we have is for view, we have view2 and view3, but then we have the options API and the composition API. So that's like the options API is like the old one and the composition one is kind of like their new generation. So we allow both to be generated, TypeScript and JavaScript for across most generators. For React, yeah, we have that flexibility in terms of what style. So we allow you to generate styles that use a specific CSS and JS library, which is really cool because, yeah, if you're using that already, it can allow in the rest of your code, where you're going to import this package, then it would be nice to kind of have that consistent way of styling things. But we also allow plain style tags if you want as well. It really depends on each framework. Every framework's needs are different. You can just easily add stuff. We've added signals, for example, for SolidJS. So initially, we had their store, kind of mutable store thing going on. And then when we wanted to support signals, we just supported that and we support both. We always just keep on adding more and more to see. to allow people the flexibility. Yeah.

 

So if you were a, let's say you were a team, an internal team at a company, and you were tasked with creating the component libraries that you wanted the whole company to be able to use, how would you recommend getting started with mitosis or something like that? Like, do you have quick start guides? Do you have examples that people can look at and build from? Like, what's the best way if you're kind of starting from scratch with it?

 

Yeah, so if you are just starting off with mitosis, I would probably recommend going through our monorepo and grabbing one of the examples there and just cloning that and then from there just adding the output that you want and seeing what that looks like. Also if somebody just wants to see what is actually being generated because they don't really understand yet. what's actually coming out the other end.

 

Mm-hmm.

 

Going to the fiddle, like mitosis.builder.io, shows you your code input on the left, output on the right, and you can toggle between all the frameworks and toggle between all of the configurations for each framework and kind of see, oh, TypeScript on, TypeScript off, this CSS flag, this CSS flag, comparing view to React quick, and you can get a glimpse of what the actual code that gets generated is. Yeah, I think kind of... doing that a bit at the start is useful because folks can frequently kind of, yeah, not like, I get a lot of questions from people that kind of coming in from that web components background where they're like, well, you know, how does it handle like event listeners and stuff? Like it's just, I'm just spitting out strings. It doesn't handle it any special way. It's just,

 

Yeah.

 

you know, how would you handle event listeners if you wrote the React component yourself with it? That's how it's going to do it. And so Yeah, I think getting over that hurdle where people might think it's like wrapping something weird that then gets sorted out by the framework.

 

Mm-hmm.

 

Yeah, going looking at the federal is is important.

 

Yeah,

 

Yeah, and it's

 

I mean,

 

it. Yeah, go ahead.

 

we're pretty used to magic at this point. So not having a full picture of how things are happening is pretty standard, I think, for a lot of JavaScript frameworks. So actually being able to see everything and how it's working is a little more unusual today.

 

Yeah, I mean, that's why we needed that because we, I mean, I wasn't around when we created the Web Component SDK. But I think the vision was, you know, we wanted to support every kind of customer across all our frameworks. And we create this thing, but then there was so many issues just plugging it into somebody's existing web app, along with like missing support for certain features and all that. Server-side rendering being a huge limitation and some other stuff. And ultimately, yeah, we saw that. what we need is something that's as light as possible that just behaves the way if component would in that framework. We want it to be like, okay, we have React users, they're going to import this SDK, it's going to act like React components. That way they can use the context of the builder SDK and the builders can use their data and it's just completely seamless. And it offloads the work kind of to my toes. So that's a trade off. Instead of saying, oh, the... we're going to have to build these really complicated things that are going to work across everything. It's going to be like plain JavaScript. Instead, we're going to go the other way, which maybe a lot of people are surprised by. But we're going to actually go the way where we're going to do exactly what the web framework expects. But then that means that we have to build a compiler that's going to cover all of the edge cases and scenarios that we envision. And so, yeah, but it's served us well so far. And there are different folks out there that are starting to build design systems on top of MyToolsSys, which is really cool. So that's really fun. Yeah, there's like different companies, like the train company in Germany or something, they have like a model, like a repo now with MyToolsSys components. I'm just saying this, like, this is cool. It's definitely like, it's picking up pace. It's still at a stage where there are issues here and there that pop up, Thankfully, we're at a point where it gets used in production by some of our big enterprise customers at Builder with, and they don't even know what my toolset is, right? So to us, it's already a form of success that it works. It's we were able to deploy SDKs regularly for seven different frameworks, where we clean like publishers with no issues. So we're happy that other people are starting to pick up on it as well.

 

So I have to ask, since you have talked about how this is open source and people might not even know that they're using mitosis under the hood, how does Builder.io make money?

 

Oh, I mean, we don't make money off of Mitosis, but we're a headless visual CMS, so pretty straightforward how we make money. People sign up to the CMS and we charge them for it. Yeah, that's like, yeah, it's not like one of those tech companies where it's very unclear what's going on with like a free model. Yeah, Mitosis itself is just something that we need, and so that's why we, and... We open source it because we think other folks might need it. And we've had a lot of folks contribute to it and help us out in the process. Like that's just how open source works. So other companies are benefiting from it as well. Other folks are building on top of it. But yeah, we make money from the SDKs that we generate with Mitosis. But yeah, Mitosis itself is not like a revenue generating. Piece of code.

 

Yeah, no, because it sounds like so Builder.io, you build some, some UI, some components, whatever, but then the people that want to use it have their own infrastructure and they want it to work. Right. Like we built everything on Angular or whatever. So we want this thing that we're importing to work with our current ecosystem. So you can use Mitosis to essentially give everybody what they want more or less. This sounds like is the strategy, is that more or less right?

 

Yeah, yeah. And so you have to talk a bit more about that. The kind of the magic of Builder is that unlike a lot of other page builders or things like that, you can just inject a Builder block into any part of any page that you're rendering. So it's not this thing that's meant to be used by companies without developers, it's very much the opposite. It's something that meant to be built upon by, you meant to build on top of what your web developers have. And so developers would have this like beautifully designed suite of components, this component system, this like product card that's really elaborate, this header, footer, navigation bars and all of that. And then you register them with the SDK. And then you just add like a builder render component wherever it could be the whole page. It could just be like. four of them in different chunks of parts of the page. And then non-developers can go into the builder CMS, like the visual editor, and drag and drop the components that the web team built. And so that's why the SDKs are kind of something that we need to provide, because it's like, this is not something we want every single customer to build by hand. It's kind of complex interactions. Like there's like a bunch of visual editor magic that goes on that allows us to do that.

 

Thank

 

with

 

you.

 

the SDKs, but yeah, you can have anything going on on the web app, importing all sorts of complicated 3D rendering, visual animation stuff, and then you just register it to the SDK, and the SDK tells the visualizer, and then the visualizer is like, okay, I have these components that were built, and I guess you can drag and drop them, and then people can just go wild and build all sorts of experiences with them.

 

Very cool. Now I'm gonna be checking this out and looking at just BuilderIO in general. So this BuilderIO and the visual headless CMS came first and then everything came after that mitosis and these different SDKs and things like that kind of spun off of it as you needed them and as your customers needed them. So, I'm gonna go ahead and go ahead and go ahead and go ahead and go ahead and go ahead

 

Yeah, exactly. We started out by having customers on React, probably. I mean, that

 

Mm-hmm.

 

predates my

 

Yeah.

 

me joining builder. But yeah, React being the biggest kind of framework of the last decade, maybe. We started by having a lot of customers on that. And then as we grew, we needed to support more and more frameworks. And that's when we were a very lean engineering team. So kind of finding a way to have just... Mostly one person working on all six or seven SDKs is worth

 

Mm-hmm.

 

the trouble of coming up with an idea like Mitosis. But I definitely came after. I think also in the past, it's just been, we've had many different experiments and ideas around just generating UIs or moving UIs from one format to another. So there's a bunch of other like. Angular to Shopify, Shopify to Builder, Figma to Builder to React. And I think there's just been so many different things that we've tried that having just like a core that might resist core allowed us to just add like add a different parser, add a different generator, add a different parser, add a different generator. But we've definitely played around with a lot of different things that we get to parse and then different things we want to generate. In fact, we have a Figma plugin. that lets you go from HTML to Figma, so you can import a webpage into Figma, and that part doesn't use Mytosis, but then you can go from Figma designs to Builder, and that goes through Mytosis as well. So you can parse your Figma designs, convert them into Builder JSON, and then go from Builder JSON to anything else using Mytosis.

 

that would be really cool because I've definitely wished that that was a thing and tried different implementations because I know other companies have tried to do like the design from your Adobe Photoshop to HTML or CSS or something and trying to get it to output correctly into whatever framework you're using which is almost never just straight HTML and CSS is has never really worked. So hearing that there is a way or that you're doing the same thing but using mitosis, which sounds like the next generation might actually be useful. Ha ha.

 

Yeah, for sure. We've, I mean, it's also like one of those things that you know, is it ever going to be 100%? That's kind of like where people's expectations, I mean, taking an arbitrary set of designs from Figma and converting them and having them be pixel perfect, that's something that we're working on. And actually

 

Mm-hmm.

 

Steve has been like playing a lot with like AI generation. So having that kind of supplement the deterministic stuff that Metosis is doing to kind of fill in some of the gaps. So that's something that we've worked on, we're working on as well right now. I think we recently pushed actually some of those AI ideas to Figma and to Builder. But yeah, it's a complicated problem. And I won't say that we have it down to like 10 out of 10, but we have a solution out there. And if the main thing you want to do is kind of like go from kind of like a sketch or a mockup and have like a rough equivalent of that in another platform, then

 

Mm-hmm.

 

using... using our Figma plugin would be like a good way to get that far. But yeah, there's this, there's always like, you just never run out of edge cases, it's like, oh, when you have this thing inside this thing, that happens.

 

I'm going

 

But

 

to go to

 

we've,

 

bed.

 

we've, we were always working on kind of improving it and making it work more for

 

Yeah.

 

our users.

 

It's all about trade-offs because it's interesting because my previous job, which I still got the hat on for progress with Kendo UI, we had spent a lot of time working with this because we had a ton of people that wanted to use the components we made in Figma. It's like I think our literal top requested item when I was there. And we initially, it was a whole thing, but we... want people wanted them to be pixel perfect because of course they did. Right. But we found the only way to do that is to basically hand implement everything in Figma that had no relation to the code itself, right. Other than maybe you're sharing like a color something or, or whatnot, but to do it right, you had to like hand do everything. And obviously like for a giant component library, that's like an enormous amount of work and worse the amount of maintenance because then When you change the code, someone's like, oh, we got to make sure Figma is also up to date or the designers are going to be mad or whatever. So, um, we had tried down the automation route and then I don't know, like I've been out of the company for a few years now, so I don't know where they're at, but it's, it's interesting to see just more investment in this area to try to figure that out. Cause I believe the hardest problem is just like the structures of data is just different, right? And like, it's just a huge challenge to translate all of that in an intelligent way.

 

Yeah, for sure. And yeah, what we've succeeded with so far is making sure all of the web frameworks align. And there was always kind of like caveats or exceptions in certain situations. But yeah, Figma to code and like code to Figma is kind of a whole other beast. And we have some work there, but I think there is still a certain amount of work to be done probably.

 

So speaking of that, is there anything else, like what's coming up? What's the sort of stuff, what can you leak to us? What's like the important next things that are coming either for like Mitosis or Builder? What are you excited about? What are you working on?

 

Uh, I mean, we're, we've got a lot of bunch of stuff. I mean, we've been pretty public about it though. Uh, we've been working on a bunch of AI stuff, uh, you know, with the whole like insanity that's been surrounding open AI and GPT and all of like those LLMs. Uh, so we were, we're working on a bunch of that stuff. Uh, and. Yes, he's been leading the charge. We have a few open source projects around there He added like a CLI like an open source CLI where you can Integrate in tech use opening eye through because they have a CLI where you kind of have to get on the waitlist and wait For it and he was too impatient. So he built his

 

Hehehe

 

own So we have that Yeah, a lot of different experiments were trying and I know a lot of people a lot of different companies that are really jumping And seeing like how can they use this? How can they use this AI stuff? But I think in our case there was an incident like, oh, will this help solve these couple of problems that we've been just waiting, trying? We've tried a bunch of different things and we just couldn't figure out how to solve them. And so we have a few ideas there, specifically related to, you know, the visual headless CMS space and having like generating designs that work really well across different spaces and all that. So in different environments. So. We're playing with a few different ideas there and hopefully we'll be able to solve some really unique challenges that people have in that space. And other than that, that's on the builder side, but then other than that, quick is when we put the release candidate out for some time ago, I don't know, like a week or two ago. So that's been really exciting. So it's really cool to see that get closer and closer to the finish line. That's going to be a really cool moment. I've seen the team which is on the development side is Mishko, Adam Bradley and Manu and those folks are just phenomenal. It's really insane how much they're able to get done. When you compare that to other frameworks out there, they created their entire framework and then a meta framework, Quick City on top of it and this kind of... Yeah, it's just kind of we're all speechless and in awe of what they're able to do. Um, can't wait for that to kind of be like hit that, that one point all land, uh, Mark, cause that's going to be really exciting. A really big milestone for that, for my team, that team. Yeah.

 

Nice.

 

Sammy, this has been great. Is there anything that we, before we move into our picks, is there anything that we've missed, anything that you wanted to talk about for Mitosis or Builder or your blogging or anything that we haven't touched on yet that you want our listeners to know about?

 

How nice, I feel like I've talked a whole bunch, I've said everything there is to

 

Hehehe

 

be said. Yeah, if you're at all listening to this and interested in mitosis, please take a look. If you see anything, if you want to contribute, more than excited to have more and more folks join the ecosystem and help us out as we build something that I think is pretty cool. Hopefully, if in the near future, more and more folks start to seriously use it, then there'll actually be like an ecosystem of framework agnostic component libraries, which I, yeah, if we get to that, if slash when we get to that point, I think I'll be really, really stoked.

 

Yeah, we definitely need it. So where

 

Hehe

 

can people get in touch with you if they want to reach out and get more involved?

 

Twitter, I guess, while that's still around. So,

 

Hehehe

 

Yeah.

 

Sammy Jabber underscore, yeah, because the initial one was already taken by this other developer with the exact same name as me, who's

 

Ugh, it's the worst.

 

got a couple years ahead of me on the online kind of snatching handles here

 

Hehehe

 

and there, so I have to stick with the underscore at the end. But yeah, Twitter. Otherwise, yeah, we write a lot of blog. post here and there, try to share everything that we're learning as we're building out Builder. So those two places.

 

Awesome. That's a good segue into our picks. Paige, do you want to kick us off with a pick today?

 

Sure. So my pick today is going to be for anybody who works with raspberry pies on a regular basis, and it is a touchscreen. Because if you have set up a pie and then had to, yeah, TJ is holding one up now, but you basically, once you've set it up, you have to SSH into it to do most anything unless you have some kind of a dedicated monitor for it. So I found this little monitor on the Adafruit website and it's a seven inch monitor. for a Raspberry Pi that also has touchscreen capabilities. So even if you don't necessarily have a dedicated mouse and keyboard, you can still probably do some interesting things with it. And that little thing has been such a time saver because trying to SSH in from my other computer, the connection drops, the IP address of the Pi has changed. There's a million things that make it more painful than it needs to be. So just actually having its own little monitor that I can move around a mouse and do the... do some things on a keyboard has been a really great investment of time and time saving for me. So if you have 80 bucks to spend and you want to use your Pi more, I would highly recommend it as something that is really, really helpful. And it's it's small, it's lightweight, it's easy to get installed and get the Pi into. So I would say it's definitely worth it.

 

Yeah, back when I even used my pie in a while, but that was constantly for me, it was my IP address changed all the time. And then like to get the new IP address, you'd have to like hook up a monitor essentially, which is like me hooking up one of my computer monitors and.

 

It's a pain.

 

Well, cool. My pick for this week is a book called The Silent Patient. It is a murder mystery. It's just kind of like my feel-good genre, just standard somebody dies and you try to figure out what happens, but it was really well done. Perhaps the more interesting recommendation I have is for how I decided to read this. We were talking about AI earlier, so I decided to just go to chat GPT and write out like a paragraph of the sort of books I like and what I was looking for. And I just decided I'm just gonna buy whatever, whatever is on the top of this list. And I did and it was great. So if you haven't tried using AI for just like recommendations, probably, I'm sure it would probably work for movies and shows and stuff as well.

 

Mm-hmm.

 

It's one for one for me so far. So

 

Nice.

 

I'll have to keep playing with that. Sammy, what picks do you have for us?

 

I'm going to go with... Well, so I'm based in Canada and I'm going to go with a Canadian company called Attitude, which does worry-free soap and or like any and all chemicals. I don't know what subset of the demographic of this podcast is going to be like, oh, I need this. But yeah.

 

I think you'd be surprised.

 

It's one of those things where like, yeah, it's like EWG verified. So whoever is like checking the EWG database for like things that don't give you allergies or cancer risk or whatever it is. Every product by Attitude is EWG verified. So it has like the perfect score. So you can just worry free as their quotes. You can just buy anything from there without having to like double check what's going in there. And they're great products. Wonderful Canadian company that probably ships to... the USA so check them out, buy yourself from there, buy shampoo, your detergent and all that. Yeah.

 

They've got somebody there that's good at SEO too, because I looked up just the word attitude and it came up like as the very first,

 

thing.

 

like it was

 

Wow.

 

under the dictionary of attitude. So like,

 

That's

 

Good

 

so it

 

how-

 

deal.

 

was like, wow, that's not bad.

 

That's not an easy, yeah, like rank number one for the word attitude. Do they have the domain attitude.com? That would

 

AttitudeLiving.com.

 

be, well, yeah.

 

Although like your conspiracy theory is that Google's been listening in on this conversation and that when I typed it, it kind of knew what I was looking for already. So

 

Very

 

you

 

possible.

 

never know. With

 

Very

 

AI

 

possible. Yeah.

 

now, you never know.

 

So yeah, their SEO game is strong. Their sole manufacturing game is

 

Hahaha.

 

strong. So yeah, check them out.

 

nice.

 

Well, cool. Sammy, this has been a blast. It's been great talking with you. Mitosis looks really cool. I think it's an awesome idea. And thanks for joining us.

 

Thank you guys for having me.

 

Cool, well, all right, everybody, this has been another episode and see you next week.

 

See you then.