Jed Bartausky:

Welcome back to another episode of the React Native Radio Podcast, episode 3 38 React Native Enterprise Framework with Michał Pierzchała.

Jamon Holmgren:

Robin. As far as I know, Zen's Baby has not arrived yet.

Robin Heinze:

That's what I've heard.

Jamon Holmgren:

So why is he not here? He should be here helping us right now.

Robin Heinze:

Well, he actually is here. Spoiler alert, he's not recording. I'm looking at him. He's listening. He's just kind of in those last phases where it could be today, it could be tomorrow, it could be two weeks from now. Who knows? But it's easier just to clear his plate as much as possible.

Jamon Holmgren:

Did you go over your due dates with your two kids?

Robin Heinze:

I did not. I had one kid show up on his due date, which is actually pretty rare, and the other showed up two days early, so they were actually pretty close. Oh,

Jamon Holmgren:

That's pretty

Robin Heinze:

Close. Pretty

Jamon Holmgren:

Prompt. Yeah, I'm pretty sure that my four kids were all pretty close to their due dates. I don't remember though.

Robin Heinze:

Kyra probably does.

Jamon Holmgren:

She does. Oh yeah. Yeah, I'm sure she does. I dunno, I have a hard time remembering stuff like that,

Robin Heinze:

But yeah, you probably won't hear Mazen on the show for a few episodes at least.

Jamon Holmgren:

Yeah.

Robin Heinze:

But then we'll be happy to have him back once he is a dad Times too.

Jamon Holmgren:

Yeah, probably tired. Really tired and a little bit incoherent and stuff, so he'll just sound a lot more like me then. Alright, well we do have a show to do here and we actually have a guest as well. So I'm Jamon, she's Robin Zen's out. We're React Native Radio, and today we have a very special guest, Miha pwa. Okay, how did I do on that? That sounds pretty good. Pretty good. It's close. I did better in the practice, I'm pretty sure.

Robin Heinze:

Well we weren't recording then. I

Jamon Holmgren:

Know. Yeah. Alright, go ahead and say your name and go ahead and introduce yourself, Mike.

Michał Pierzchała:

Yeah, so hey everyone, I'm Micko Koa, a principal engineer responsible for open source at Cold Stack. I worked there for over seven years now and pretty happy doing the open source work, working in the field of testing cli, generally doing tools for other developers. This is what I find pretty satisfying, impactful, and I just enjoy doing. So it's great to be on this podcast with all of you here, Robin Jam and all of the people backstage that you're probably not here in this conversation.

Jamon Holmgren:

Yeah, unless something goes horribly wrong, then you might hear us hear them. No, we appreciate all. We appreciate you coming on too. Of course. I've known you for a long time. I wonder, did we meet probably at one of the React native eus back in the day or maybe Chain React or something, but I feel like we've been connected for years and years. At least six, seven years probably maybe longer.

Michał Pierzchała:

Probably around that.

Jamon Holmgren:

Yeah. Yeah, very cool. And of course you've posted us over in Poland a few times. Won't make it this year, which is sad for me, but I always really enjoyed going over there to and hanging out with you folks.

Michał Pierzchała:

And next time when you're going to be there, I hope it's going to be next year, I think we're going to extend your trip to go to Krakow where I live on daily basis. And I can tell you there is this great little craftsman workshop that this guy is doing his custom chess boards and chess figures. Oh,

Jamon Holmgren:

That's cool.

Michał Pierzchała:

So I figured

Jamon Holmgren:

That I would love that.

Michał Pierzchała:

Yeah, that will be something that's going to interest you. So hope you going to

Jamon Holmgren:

I really should. Yeah. I've been three times to, but I've never been to Reho and I've never really gone anywhere else in Poland. I think in 2019, which was my first time there, I actually took a train down to Prague and then I rented a car and went across Germany and stuff and took a week doing that and that was really cool. But I didn't spend a lot of time in Poland other than for the conference itself. So that would be a lot of fun.

Robin Heinze:

And Jamon loves chess and woodworking to some extent. Your dad's a woodworker.

Jamon Holmgren:

Yeah, it's more my dad. He would love, he actually made me a chessboard. Lemme grab it. The listeners can't see this, but my dad

Robin Heinze:

Made this chess. Oh, I didn't know that. I knew he'd made you cutting boards and other stuff. I didn't know he made you a chessboard. Pretty nice.

Jamon Holmgren:

That's pretty cool. Yeah, it turned out really amazing. I don't get a chance to play over the board really except for against my son Cedric, who's like almost an 1800. So he just destroys me every time. I just hit a thousand again last night. Somehow two guys just resigned in the middle of probably beating me and so I ended up bumping up to a thousand. But yeah, a thousand is basically, if you don't know chess a thousand is basically, if you're a really casual player who just played it in middle school or something, I will destroy you every time. But if you're any sort of a serious player, then you'll destroy me. That's just how chess is. I don't know. No matter how good you get, unless you're Magnus Carlson, there's always someone who can

Robin Heinze:

Destroy it. Did Magnus Carlson just get beat by somebody a couple weeks ago?

Jamon Holmgren:

Yeah, it's huge news. Anytime he's

Robin Heinze:

Ever beat. It's just huge news. I was like, even I heard about it now

Jamon Holmgren:

I think that the best player in the world is Magnus Carlson and the second best is Drunk Magnus.

Robin Heinze:

Magnus drunk Magnus Carlson.

Jamon Holmgren:

Alright, anyway, enough about that. Before we get too much further, our sponsor is Infinite Red. We are React native consultancy located in the us. We have a team of 30 senior plus React native developers and support staff and have been doing this for almost a decade. Go to Infinite Red slash Radio to I guess get in touch with us. Don't forget to mention that you heard about us through the React Native Radio podcast. Alright, let's talk about our topic. We are talking about RNEF and everybody knows what that stands for, I'm sure RNEF, so I don't even have to say no, I'll say it. React Native Enterprise Framework. So a while back, the React native Core team said we encourage you to use React native with a framework because if you don't, you're going to build one every time. I suspect that Mike, I bet you're going to be talking about how with actual clients, you ended up building a lot of this stuff over and over.

And so that's where this came from. Of course, the most famous and probably first framework is Expo and that's what everybody's kind of used to hearing about, but it's really nice to see other options popping up, maybe aimed at other use cases and things like that. And so of course I want to give a little background too before I hand things off and start asking questions, but Call Stack built the original React native command line interface tool or the React native community CLI, which it's called now. And you've maintained it for years, Robin, you knew that, right? Did you know that?

Robin Heinze:

I don't know that I knew that Stack Built actually. I bet bet. There's a lot of people that didn't know that Calsac is behind the reactive CLI because I mean it's always under the React native community repo. I don't think I necessarily put two and two together, but it makes a lot of sense.

Jamon Holmgren:

Yeah. Yeah, it was actually built into the core for a while and then removed, and I think Mike Grabowski made that originally, right?

Michał Pierzchała:

Yeah, it was RNPM, another great

Robin Heinze:

Name. We were talking about RNPM and the days, it's like the days before auto linking and after auto linking, I remember having to run rrn PM link and all that stuff.

Jamon Holmgren:

Exactly.

Robin Heinze:

Different days.

Jamon Holmgren:

We should probably have Mike Vasque on to talk about that history. It'd be kind of fun. But now you've built a new CLI and actually the whole framework React native enterprise framework and it's pretty impressive. On our prep for this, we read through all the documentation. We looked at a lot of the, there was a lot there already. I was surprised how much was there. It is clear. You've been putting a ton of work into this and we'll go into the why and the miha. Can you give us the elevator pitch for what React Native Enterprise Framework is? Assuming your audience is React native developers?

Michał Pierzchała:

Yeah, so React Native Enterprise Framework or RNEF Ford, and we treat it as a code name for now. We have a new exciting name for this project, which we going to reveal in somewhere in July, I guess when I'm going to be back from

Jamon Holmgren:

Vacation maybe about the time that this is released. Yeah,

Michał Pierzchała:

Yeah. Hopefully

Jamon Holmgren:

If you give it to us before we release it, we could actually update the title. And so for those of you coming in, if the title's different, that's why we don't know the name yet, but we may get it before we publish.

Robin Heinze:

He doesn't trust us to give it to us. Now

Jamon Holmgren:

I won't leak it, but

Robin Heinze:

Thank you. Promise

Jamon Holmgren:

Can't do it yet. That's okay.

Michał Pierzchała:

Yeah, but I hope it's going to stick.

Jamon Holmgren:

Oh, by the way, this happened to us for radon, the editor as

Robin Heinze:

Well. Yes, we did an episode about, but we just called it the React native IDE and then they named it Radon.

Jamon Holmgren:

Yeah, right after

Michał Pierzchała:

We released that. The

Jamon Holmgren:

Title is wrong.

Michał Pierzchała:

Anyway, I would say we were in a pretty similar situation.

Jamon Holmgren:

Yeah, yeah.

Michał Pierzchała:

Anyway, so as the name implies, it's a framework for building React native applications that we target for big companies or enterprise as we say. And we have basically two kinds of users. First kind is the users of Community CLI that are building a lot of the tooling on top of that set of tools related to publishing, to building in the release because there is no good way to build release artifacts with the community CLI. And we want this kind of user to have better experience working with React native. And what we are actually after is that the user of our library is likely a small infrastructure team in a bigger company that is providing tools for those dozens or hundreds of developers out there who just want to work on the JavaScript parts of Tive applications. They don't want to deal with exco, they don't want to deal with Android Studio.

They want to switch quickly between projects, between branches, maybe between web and mobile. So we are building a tool that's optimized for that use case. And the second kind of user is the native iOS and Android applications that want to incrementally adopt React native, something that we call a Brownfield development. Something that's been possible with React native from the very beginning. But historically it required anyone who would like to adopt React native and native application to adjust their folder structure, add a bunch of JavaScript tooling to their repository. And for iOS and Coco pots where most of the projects already moved on past that, they're using SBM maybe cart, but I think it's not really used anymore in most of the cases, at least we haven't seen that. SBM or Swift Package Manager is universally used in almost any iOS application. And for Android it's also a lot of internal react natives dependencies that someone would need to adopt as their own dependencies, which makes it really hard to maintain when upgrading React native.

So our framework has a set of tools and something that we call a packaging approach to treat all of your React native application as a single library, single framework artifact that you can just import without JavaScript, without Coco pos. You're basically linking that framework you're installing as a part of that, our runtime helpers library, which is called Tive Brownfield. And this gives you a way to easily start new React native instances and instantiate React native views, whatever you like, however you like. It doesn't have to be an app delegate, it can be in scene delegates and it can be in some Swift UI views or in regular Swift controllers part of navigation or not. So essentially the framework is giving you easy way to start up in display, react native application and treat it as a whole thing. And whenever you need to upgrade React native, you're just asking your new React native team for a new package and you just use that so you can distribute it through Artifactory or through GitHub module or anywhere around that. So these are the two kinds of use cases and users that we are currently focusing on. And there is actually a third kind of user, which is universal cross platform apps that are available for any platform outer, including tv, desktop, mobile tablets.

There is a big variety on the TV space alone, and this is something that fundamentally we've designed the framework to be compatible with all of that, but we were not in the place where it's ready to use. So currently I'm talking about those two kinds of users At the same time, it's very important for us that this framework allows you to build those universal perhaps that you could run on any platform out there. And overall, we are treating that framework and I heard it's not the best way to this private it, but internally we treat it as a spiritual successor to the community CLI. So there is

A lot of ideas that are transferring. We want this tool to be easy to migrate. So migration shouldn't take more than 10 minutes and then probably a few days of testing. That's a reality. And we want to give those bigger React native users a really pleasant experience working with React native where they can own the whole infrastructure because it's all open source. Some of the features that we've built around the framework such as remote caching of the native artifacts, native binaries as built around self-hosting, the over dear updates that we're going to integrate soon is also about choosing your own infrastructure. So we're not a server company, we don't provide any kind of ready to use service like servers for you to run your code. The users that we are targeting, they usually have their own infrastructure.

Robin Heinze:

They're already using GitHub actions or whatever. Usually GitHub actions, what I've seen

Michał Pierzchała:

Or Google Cloud or Azure or anything out there or usually all of that. And what we find, this is like the elevator pitch,

Jamon Holmgren:

Long elevator.

Robin Heinze:

Now this is the escalator pitch.

Jamon Holmgren:

I just keep hitting one and 39 over and over and we keep going up and down. That's all right though, Mike. It's okay. It I'm taking a bunch of notes is what I'm doing. One thing that really stood out, I mean there's a lot there that is very interesting, but one thing that stood out is over the air updates. I think that's something we've been hearing a lot from our enterprise clients is what options do we have? Because obviously there's expo, but that doesn't always match with what they're trying to do. As much as we love Expo, and I know you do too, but there's sometimes just a mismatch on certain vectors around it and the over-the-air updates has been a big question now that Microsoft's like app center is no longer a thing and how do you deploy this? And you can kind of do it yourself and there's some others that provide it like code Magic and whatnot. But what if I have my own servers in my own data center? What do I do? Or however you want to handle that. So that is something that you're targeting with this then?

Michał Pierzchała:

Yeah, that as well. And what's interesting is that often the users that we are targeting with our framework, they're somewhere deep in the company structure. They don't have all the ownership of the tools they're using or the power to even add new tools. So adding any other third party self service like expo app services where to run EAS, even locally, you need to sign up for their cloud service, which sometimes is a blocker for those. Some companies that we were talking or we working with, at the very least, they're essentially then blocked from this great user experience of using a S, but they have their own infrastructure and they can run a lot of that themselves and they're usually fine with doing that for various reasons. So we try to make it a little bit easier for them, for us, create a interesting base and space for innovation and react ecosystem because we have some ideas that may end up being super experimental or controversial even, and we want to have a testing ground. And I guess that kind of answers a maybe unspoken question on why we're not just evolving that community CLI and instead of we're doing own thing, we found there is a tremendous level of freedom in doing so. Something that we haven't really realized and we felt like we are in a really good position to grab it.

Jamon Holmgren:

We had something similar. We still have something similar with our Ignite like starter kit, which is really aimed more at expo users than enterprise.

Robin Heinze:

And it's aimed mostly at the app development itself,

Jamon Holmgren:

Right?

Robin Heinze:

Yeah, the JavaScript,

Jamon Holmgren:

But we had our own CLI and we were able to do some kind of innovative things that probably wouldn't really work with more of the community CLI. That has to be.

Michał Pierzchała:

Yeah. Or with Expo.

Jamon Holmgren:

Yeah, and necessarily more, there's more stakeholders and so you have to navigate that where if you do start something new. Yeah, that makes sense.

Robin Heinze:

You talk a lot about how you're specifically targeting enterprise companies and their unique needs. Is this a tool that you would recommend anybody pick up? I mean, is there someone who's just building an app on their own or with their small team of two or three developers, is this still going to be a useful tool for them? Is it going to be maybe too big of a hammer? The people who are listening who are like, Hey, should I pick this up and use it? What's kind of the answer to that?

Michał Pierzchała:

Yeah, and this is a simple but tricky question. So I'll start with are you able to use it in a small team or being a solo developer es you can do that and it's actually pretty unpleasant to work with it. I'm doing some small example projects and I love how quickly I can iterate because of the two layers of caching that we have first for

Local belts. So once you've built locally, when you don't have a remote cache set up, next time you're building, we're going to reach through from that cache. So are storing your A PK for Android or IPA or a PP? Actually most of the times on iOS we store it in our cache and when it's there and it matches the project's native fingerprint, which is like a representation of its iOS and Android folders to make it simple and describing it as a single number and the five hash, this gives us this certainty that when this hash matches with what we have in our cache, we can grab that version instead of rebuilding your Android or iOS project from scratch or even leveraging their cache. So it's super fast this way. So you can just N-P-X-R-N-E-F, run Android or run iOS and you don't even need to. Previously I would rather start Metro Server and open up some cached version of my app on the device or emulator and then refresh a bunch of times so that metro kicks in, et cetera. And now I'm just running those run commands and it just works and it works really quickly. And when I have access to the remote cache where someone on my team or

Me from yesterday for example, is working on something on their branch and it triggers this build on the continuous integration server somewhere in GI actions for example, I can use the same command and as well, instead of reaching for local cache, if it's not there, use the same mechanism to calculate this caching, this fingerprints representation of the project and just check if it's there on some remote server. If it's there, it'll download and install my device and run again. So it's pretty pleasant to work even as a solo developer and you don't need to configure anything else to leverage that local caching, we have it built in to that project because we figured we could make it configurable as our remote cache provider, but not being remote but rather local. It is the same concept. So we could use that, but we figured everyone should have easy access to it unless they want to opt out, you can always run the local flag and it'll build. So yeah, it's usable for cell developers. And for the further part of the question, who would I recommend using it? I would say that if for any good or bad reason, because there are good and bad reasons, you cannot use expo and expo app

Michał Pierzchała:

Services

Michał Pierzchała:

Or even local version then having an alternative or NEF as gets you in a pretty similar experience. Although we are far behind in terms of the overall DX that expo has, but we're getting there. So when I would want to start a new app, I would start with Expo, but if I would start a new app as a enterprise engineer, I probably wouldn't have that much freedom. Yeah, exactly.

Robin Heinze:

If you're building an app at scale at huge scale and you have, you're going to have certain needs and we have plenty of clients who can't use Expo for lots of reasons.

Jamon Holmgren:

Yeah, that's the main thing. You still need a lot of this stuff that expo is building and I'm sure it the same with Call Stack. We have deployed expo with large applications and many, many users. So it's not like it's impossible to do,

Robin Heinze:

But we also have clients who still can't use it for any number of reasons and we kind of work around it. But having a tool like this I think would be pretty useful in a lot of cases.

Jamon Holmgren:

I don't know if I should say that. Well, I'm not going to say who it is, but we have a client that actually asked us to use our own expo account, our own Everything account.

Robin Heinze:

We literally do their development builds on our EAS

Jamon Holmgren:

Because they can't get it through their system. So they're just like,

Robin Heinze:

Can you just do that and charge us? They can get their security team to, I mean they use SSO and all this, this stuff and there's all these steps to get something like that approved for you. So they're like, can you just do it

Michał Pierzchała:

And share the mail with us? Seems crazy,

Robin Heinze:

But yeah, it does.

Michał Pierzchała:

But it's the reality of working with it's reality big companies.

Robin Heinze:

Exactly. Yeah. But it sounds like there's not so many, I mean there are some tools out there where the benefit for a really large organization is enough that you put up with maybe a lot of configuration and some pretty extensive setup to get those benefits, but it sounds like this is a tool that even though it's kind of targeted for those advanced use cases, even if you're a smaller company or a solo dev, it is very easy to use regardless.

Michał Pierzchała:

That's the goal. So what we see, and I suppose this is something that you also observe as a similar type of company that is working for those enterprise companies, is we are building this for, I like to say for power users, for those infrastructure teams that are either internal or external in forms of call stack experts or innovative red React native experts just filling out this gap in the engineering side of certain companies. And these developers usually know what they're doing and they have team members that often don't really know what they're doing in terms of native setup for React native and for a good reason because React native engineers, we super skew towards big complexity and switching between languages, environments being like web, Android, iOS desktops. And it starts to be, I mean to me as an engineer, it's pretty exciting and refreshing, so it keeps me sharp I guess over the long run. But for most of

Robin Heinze:

Engineers, not everybody is

Michał Pierzchała:

Like that. Yeah, they just want to ship features with React. So the infrastructure teams are responsible for providing those feature teams. That's the usual setup that we see and that actually works pretty good. So if we don't see it, we try to make it, those teams are making UI libraries are making SDKs to some standard things to interact with state, with networking with analytics, a lot of the work that should be abstracted away from the feature team so they can iterate quickly, experiment, right, those AB tests or whatever they need to actually keep the business alive for that particular application.

Jamon Holmgren:

I just have to really quick jump back to something you said earlier in case I maybe misunderstood you. I want to double check something. You said something about potentially not needing Cocoa Pods. Did I mishear that or are you going to have linking without Cocoa Pods with the CLI?

Michał Pierzchała:

The thing with Cocoa Pods is that we still require it. There is we vastly rely on almost the same template as the reactive community slash template. So it's Coco Pots there. Coco pots are heavily ingrained into core of React native and there is a initiative in the core React native team decouple the core from Coco Cobots. And we are doing this clever, let's say clever trick. And in the Brownfield environment specifically, we rely on the fact that there are actually two apps. You have iOS for example, like Native app and you have your React native app. And this React native app is using Conco pods, it can use whatever they like. And as a enterprise framework, we are providing a single command to package it all together as a single artifact or a bunch of XD frameworks for iOS. And so that iOS app doesn't really care about the build system that we have. It's all obstructed away. But it's a fair question because we currently rely on the auto linking that is built into the community CLI, and we are probably going to explore our custom own way of linking stuff automatically. It's not like a big priority for now, but we see some use cases where this could be helpful.

Jamon Holmgren:

Yeah, there's a Ruby Gem called Xcode Proj that comes with Cocoa Pods that I know provides a lot of the xcode editing tools, which is a very difficult thing to do scripting wise if you don't use this. I know I used it for my sort of auto linking library React native of Colo Loco, which essentially allows you to put your native files alongside your JavaScript files and then link them in. Yeah,

Michał Pierzchała:

That's pretty cool. I think this is what we leveraged or the Xcode NPM package as well and the legacy CLI in RNPM basically

Before the auto linking. And then we move to the newer system. And I think for RNEF, we want to adopt another idea from Expo, which is continuous native generation or CNG. We're using the expo conflict specification. We will allow to recreate basically iOS or Android or other platform folders using those config plugins and some configuration. So we want to make it compatible with Expo, that's for sure. So that existing expo config plugins are, I mean they're going to stay and our users will like to use, let's say community expo libraries, not only expo is decay. So yeah, this is probably one of the most important features that we'll need to implement in the upcoming months.

Robin Heinze:

Yeah, for sure. I think continuous standard generation is one of the key reasons that Expo shifted from something that people were hesitant to adopt to something that people were like, oh, okay, yeah,

Michał Pierzchała:

I think that was

Robin Heinze:

Now pretty much everyone's using it.

Michał Pierzchała:

That was pretty game changing for them. And there is actually a good prior art, I want to give a shout out to the project called r and DA or tive app or Tommy from Microsoft to the Microsoft's project. They're using that internally to Power Office, I think Surfaces, this is what they're calling it. I dunno if it's because of the Surface laptop or I

Robin Heinze:

Was going

Michał Pierzchała:

To

Robin Heinze:

Say it was like the Surface computer

Michał Pierzchała:

At Meta. They called experiences I think, or vice versa actually. Yeah, I think meta called it Surface.

Jamon Holmgren:

Oh,

Michał Pierzchała:

Okay. Interesting. And Microsoft calls it experience. So yeah, that was the Windows surface or whatever it's called. It's debunk, I guess. So this tool anyway has integration with expo config plugins. They make a pretty creative use of it. So we essentially want to adopt the same way, the same idea of doing that, which is actually pretty core testament to the design of expo config plugins on their own because we can use them in a non expo specific scenarios. Similarly, the expo fingerprint library, which we are currently using for fingerprinting, although we are experimenting with replacing that with some of our all libraries.

Jamon Holmgren:

I have a lot more questions, but Robin just reminded me that we're running over for our usual podcast length. So the good news is that I think Call Stack has some media out about this. There's the new name of the podcast, I always think of it as the old name.

Michał Pierzchała:

We have the universe on our Air

Jamon Holmgren:

Podcast. Yeah, on air. That's right. So go listen. Meow has it, we'll link to it in the show notes, but there's an interview there where he talks about this framework. I'm sure that you're going to be putting out more information about this over time, and I want to just say thanks to Call Stack for investing in these types of tools as open source, I think it helps the whole community not only as the tool that we can use, which I'm sure we're going to be looking at, like Robin and I already have some potential use cases for this, but also I just think it helps the React native community in general to have more viable paths for more companies. There's a lot of companies that are like, well, react native is fine, but we end up having to do a whole bunch of extra work because we can't use Expo or something. And that's a reasonable criticism, but this gives another path and this gives another option, another framework that we can look at and you can kind of build on this foundation. So appreciate all the work that you and who else is involved in the project over there at Call Stack?

Michał Pierzchała:

Yeah, so currently the team is me and we started in a small team of three developers, ky, who is also maintaining the reactive testing library and reassure and Oh yeah, Shimon, who is doing a lot of different things recently, local AI or offline AI models on device. Pretty cool.

Jamon Holmgren:

That is cool.

Michał Pierzchała:

Yeah, so we started as this team of three where combined we have one full-time equivalent of ai. So now it's a little less because as you can imagine, I have some other things that I'm focusing.

Jamon Holmgren:

Other responsibilities,

Michał Pierzchała:

Yeah. Oh yeah. Other than the RNEF, although I have fair bit of time on that. So as an engineer, I'm pretty happy about it and at the same time pretty pissed that there's always something more to do, something that I could improve. So I guess it's just the way it's right. The projects are never done, design is never done, and I learned to cope with unfinished projects.

Jamon Holmgren:

It's so true, especially in software, but I think anything, maybe even a chessboard, there's always something you might want to do differently. Yeah, appreciate you coming on and talking about this, and it's always great to catch up with you how won't make it this year, but hopefully, like you said, next year hopefully can get back over there and also check out your home city. That'd be fun if people want to ask you questions or just follow along with how things are going. Where are you at on socials?

Michał Pierzchała:

So on X or Twitter? Formally and on GitHub, I'm under Di Mikey handle T-H-Y-M-I-K-E-E. And you can DM me directly, you can find me on this board as well. We link to the Discord channel, the ED Enterprise Framework, GitHub. You can go to R Dev, which is the documentation for the project as well. So you can find, I guess most of the necessary information out there. I appreciate you Jamon saying it's very thorough. I think there's still a lot of things missing there as with any documentation and we'll still need to find some sweet spot about documenting the tool versus some good practices around building stuff. That's one of the reasons that we're apart from documentation. We write books on good practices in performance development, or recently we finished a small book on Brownfield integrations. Awesome. That's we're going to reveal on today's meetup in New York.

Jamon Holmgren:

Oh, cool. Yeah, we're looking forward to that as well. Your performance guide is amazing, so definitely looking forward to that.

Robin Heinze:

Read it every year.

Jamon Holmgren:

Very

Robin Heinze:

Cool. Thank you. Appreciate it.

Jamon Holmgren:

Well thanks a lot, Mike, appreciate it. And as always, you can check us out online on Twitter and whatnot, so follow us for other updates. And I think that's all we have time for today, so thanks everybody. We'll see you Allall next time. Alright, bye. Thanks for having me. Yep. Bye bye. Hi,

Jed Bartausky:

As always, thanks to our editor, Todd Werth, our assistant editors, Jed Bartausky and Tyler Williams, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Heinze and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.