Nate: the biggest source of complexity, I think in sharing code is. Is the fact that you have two different bundlers, two different routers, two different sets of ways to configure things with two different frameworks, two different sets of documentation to refer to it's just so many things.
Nate: And so that's where one comes from. It's turning two into one.
[00:00:22] Introduction
Andrew: Hello, welcome to podcast about developer tools and the people who make them. I'm Andrew and this is my co host, Justin.
Justin: everyone. Uh, we're really excited to welcome back Nate. Uh, so Nate was on what episode 64, uh, and we talked about Tamagui. it was a really awesome conversation, um, solving a really hard problem. It's like, how do you share components between web and modal? What does that look like? And Nate, you've recently launched a new project.
Justin: Uh, it's called one stack. the launch was fantastic. The site looks awesome. It's really, really cool, uh, super excited to talk about it, but before we dive into that, uh, would you mind telling our listeners a little bit more about yourself?
Nate: Yeah, yeah, well, thanks for having me on again, guys. Um, I, let's see about me. I mean, I guess it was, you know, I'm sort of, uh, been in the react community for a long time. I've been very interested in kind of the intersection of, you know, I started as a young kid and in design, um, because I didn't know how to code and no one in my family did.
Nate: And my uncle handed me a book about like XML and, uh, Okay. What do I do with XML as like a 12 year old that is interested in computers, but yeah, so I kind of came in through design and I think that colored a lot of my experience, which is that I did like Photoshop and then I sort of like figured out front end slowly and then I started to figure it out back in slowly.
Nate: And so I've always wanted to solve, you know, make good products basically and make my ideas that looked good and felt good. Uh, cause I did have that sort of background. So that's kind of like high, high level technical. Stuff. And then I, you know, I got into react early and done a bunch of, um, a bunch of different projects around it.
Nate: I, we even had sort of an early Svelte type thing that we built like a compiler on top of react that looked a lot like Svelte before Svelte around. It was like right before Svelte launched. We had, we had this whole thing ready and we decided not to launch it. Um, but I kind of liked the ethos of like simplifying.
Nate: I think that's been another theme is kind of always trying to like get back to what helped me the most, which was Rails when I was, You know, playing with PHP in high school, college, and just like, you know, I could sort of copy and paste together, uh, an idea, but it took forever and it was very hard. And then when, when Rails came out, um, I suddenly was just making project after project of like all my different ideas.
Nate: And I was very, it was very cool as a kid to like be able to suddenly just be super effective like that and realize that programming wasn't, doesn't have to be, you know, something where you spend 90 percent of your time on painful, annoying things that have nothing to do with your actual idea. Which it felt like at the time, and suddenly with Rails, I was spending 90 percent of my time on actually just, you know, Oh, okay, like, I can actually spend all my time on the creative, interesting parts.
Nate: And I think that's what I'm, maybe that's a good way of framing everything that I'm trying to do now with, with Juan and everything, and with Tamagui, is like, solving the painful parts so that we can get people to just be on the, I think it, there's, you know, the more time you can spend on. On that, uh, creative and interesting parts of your product, the better it's going to be.
Nate: So that's what I, that's what I've kind of kept pushing at.
Nate: I also, I'm in Hawaii and I guess there's other things about me too,
Nate: besides programming, but
Andrew: so I guess.
[00:03:32] Tamagui Updates and Challenges
Andrew: let's start out with like a little update on Tamagui. We talked to you a little bit over a year ago, and I think a bit has changed since then. You've hired some part time people, and you've even proved out the. The architecture at a company. So how has it been going since then?
Nate: So it's, uh, it's been good. Um, actually there are two, we have two full time, um, employees. Um, now, well, one, I guess, you know, one is mostly on the one side and then, um, the other is mostly on Tamagui side. So it's been hard, actually, you know, I had a full time job, uh, I was working at Uniswap who was using Tamagui, something we can maybe touch on, but like, um, it's very, very hard.
Nate: I found to, I mean, it's hard to have a side project, you know, alongside a full time job, especially one that's, you know, kind of has a decent amount of traction that you have to support. It's, it's. Nearly impossible to hire. And I found I had a lot of trouble, um, hiring and managing too. I think partially some of my hiring failures were also just management failures because I didn't have the time to invest into, you know, making sure that they had a clear understanding of what was net, you know, I kind of just needed someone who could just really just ride on their own.
Nate: I think that's very hard for a lot of people. So I had a lot of problems trying to find good people. And I, you know, I ended up going through lots of different people. I think there's a lot of like. Awkward fits. Cause I just needed someone who could output without much direction. And anyways, it was very, very hard.
Nate: Um, but I, I'm very happy to have found a couple of just great people that I work really well with. I really liked them both John and Pokai and, um, and yeah, we've been jamming now for a while. Um, and Tamagui is doing really well, actually. I'm surprised that I'm always surprised at how well it's doing even up until recently.
Nate: Um, it, you know, I think we feel like a certain space that not everyone's in, but no one else is doing it quite as well as we do it in that space, which is this universal sort of, especially just kind of solving every piece of it. Cause it's a style library that, you know, you can use it for web, you can use it for native.
Nate: It's also a UI kit like Radix that also is native in web. And then it's also got, you know, it's even now it's got like. These sort of on top of it as a starter kit, it's got, uh, a bunch of copy and paste components and all this stuff. So tamagui has been great. It's been, it's what's funny and something that I sort of tweeted times is that in a weird way, it's like 10 times harder than, than the framework.
Nate: Um, like. Like the amount of code that Tommy is, is like a thousand times bigger than one, the framework. So it's, it's hilarious. Like it's, if you want to like, you know, make money and have a good time, like do not do a, a, a style library and UI kit. Cause they really are just so much like, just so, so much.
Nate: And I mean, I, I think I, you know, yeah, there's just like, when you get into the details of some of these interactions of components. Um, that have to work cross platform and like you think about how they have to adapt to different screen sizes and, and sort of like change between different, uh, different layouts and, and different touch interactions and different like pointers, cursor and screen size and like animation have to be 60 frames per second.
Nate: And you have to test that on 3 different browser engines, uh, node has to work on SSR with node and different node versions. And it has to work on React Native. It, it's a nightmare sometimes. And it's, we've put in the real, the hard, really the hard work. And it, it feels like Tamagui has gotten stable. I think the story of maybe people who haven't checked on Tamagui in a while is that.
Nate: You know, it was kind of a lot of ups and downs, had a lot of rough edges. Um, and I think we've spent, you know, we haven't done a V2, which we should have probably a long time ago, but we've just been trying to get it to feel good and be stable. And a part of working at Uniswap was doing that, like Uniswap, you know, they really needed us, needed it to be stable and be performant.
Nate: And so that's part of what pushed me to just kind of, kind of avoid. You know, fancy features and new stuff. And we've just been really working on getting it to be as, as like solid as possible. I think it really has come a long way. Like there's less configuration, there's less. Complexity, there's less documentation, you know, weirdness that I think we have a lot of, like, so I feel like it's come a long way.
Nate: It's, it's come, it's come a long way towards stability. So that's kind of where Tamagui is at.
Justin: So, um, you want to talk a little bit about Uniswap, um, so you were a staff engineer there up until recently, um, so how were, like, they were using Tamagui when you, like, started and kind of, like, what was the, uh, what was the relationship that y'all had and, like, how, like, how did that form? Yeah.
Nate: Yeah, they brought me on cause they were decided to use Tamagui and reached out. Um, and I had just, I had left Vercel not long before and, uh, thought it was, thought it was a great chance to prove it out because they're very design driven company, very product driven. And, and I thought that was really interesting.
Nate: Yeah, I have nothing but great things to say about Uniswap. they're a great company. Like just really, they really crash at like care about their products being good. They're using Tamagui now. It's, it's powering everything.
Nate: It's actually, they're, they're even sharing a lot of, cause before it was mostly like the extension that they launched, which is kind of a Chrome sidebar extension and the native app share almost everything. Um, so they're sharing like 90 percent of code. Using Tomagooey, which is really cool, but the web, the website is a little bit, it's like kind of a legacy stack that, that's been around much longer.
Nate: So we helped them get that. And I think a lot of the, like a lot of the, a few of the pages now are fully shared. And not only that, but they actually are fully sharing the swap widget, which was huge. That was like a big thing that they, uh, wanted to try. And I think turned out to be a success because their main thing is swapping, right?
Nate: You know, swapping. That, that widget is sort of the meat of it. And they had all these different features, like the native apps supported this thing that the site did, and they were having to plan to keep them in sync, like launch across them. And yeah, so now, now they are fully moved. I helped them move into a monorepo, which was a huge lift.
Nate: Um, and then, yeah, it was, it was a lot of fun work for me. I mean, it was kind of, you know, the time we got and, uh, but I think that showing that it can be done and it can be done well and it's hard. it does require a, uh, you know, it requires a team that, uh, is, is good and knows what they're doing and can debug all these issues.
[00:09:45] The Birth of One Stack
Nate: And so I think that's kind of leads into almost one, which is like the biggest source of complexity, I think in sharing code is. Is the fact that you have like two different bundlers, two different routers, two different sets of ways to configure things with two different frameworks, two different sets of documentation to refer to, like, it's just so many things.
Nate: And so that's where one comes from. You know, it's turning two into one. And I do think like, yeah, Uniswap is great and they pulled it off, but like not many can. And so, but I, I do, I do definitely tell anyone that wants to like, you know, if you're a doubter and a hater, um, you think that native can't produce a great app, like they prove it.
Nate: so you were saying that, uh, one stack kind of came about from your work at Uniswap. Was it when you were like, when you were supporting that like static page versus like app stuff, or like, how did it come about?
Nate: Um, I mean, in a way it's like, it's almost inevitable cause I, well, we were also selling takeout, which is the Tamagui starter kit that is next JS glued together with like react native using Salido, which is, uh, Fernando's Fernando Rojo's library that I, that he's a good friend of mine. And yeah, like, like that stack also a hundred percent of the problems that we got basically from people coming in, which is, I mean, Have to be it just so complex to deal with all these different pieces.
Nate: And, uh, so yeah, I think it was both like, like Uniswap, obviously, you know, we moved together all these apps and code and it was just, it like, you can just clearly see how much simpler it would be if, if you could bring them into one framework and. And then same thing. Yeah. The, the takeout, like it was really almost hurting me on a deep level.
Nate: Cause it was like, man, this could be so much simpler. Um, not that, I mean, I think it was the best we can do. You know, it's, it's one of those things where it's like, it hasn't been solved yet, I think in a, in a way. So, um, but yeah, I mean, it was clear that that was the way to go. I think like probably some of the lore is that, well, we did the VXRN at, uh, which was just the VT.
Nate: Serving react native library that I showed at V comms, like the last one, a year, basically a year ago. And that was just an experiment. Like I was just curious. Cause you know, Metro is Metro is yeah. One of the creators of Metro asked me to kill it. Like, that's like Metro is a great project for, it works really well.
Nate: And, and like at what it does, which is like native bundling and like, you know, at, at Meta and like for Meta. It's been very kind of. Introverted. I don't know what's the right word. It's like, it's a very like focused on, you know, what met as needed project in a sense. And, and it's also like, you know, for web, it just didn't even work until very recently, I think at all.
Nate: I mean, even until very, very recently, I haven't tested the latest versions, but like, I think even like the, the code splitting was like technically working, but not really like we had a friend who was using, cause you know, I think the obvious. The obvious other project in this space that kind of is doing a universal thing is using Metro and that's Expo Router.
Nate: And, you know, we were already exploring kind of, should we do a framework and like, how do we build it? And I think to us, Metro wasn't really like, there was no way I was going to be able to build a framework on Metro because I think you have to have access to the Metro team and, and like sort of get them to do what you want.
Nate: And like, I just, you know, I'm not going to ever have that. Whereas VEED to me is just. It's so amazing. Like, and I, I had, you know, with Tamagui compiler, we had beat exposure where, um, I had built like the web pack plugin, the Metro plugin, and then the V plugin for Tamagui. And like the V one took like a day and a half compared to like the other ones taking just like months.
Nate: I mean, and again, I'm not done to throw shade, but like the V plugin system is a work of art. Like, I mean, yes, there's, you know, complexity in that they're dealing with roll up for production and not roll up for. Development. And, you know, there's always that, but like the actual design of the plugin API and the, and all the surfaces to like the documentation, the types, the JS doc documentation, like all of it is better than any project I've ever done.
Nate: That's for sure. Like it's just immaculate. For example, V6 actually is helping us out a lot too, because V6 introduced this new environment API where you can like easily configured multiple environments include, cause like, right. I think V. Five basically in forward assumed there's only two, like client and server SSR.
Nate: And then, you know, there's react server components coming out. There's React native, but there's also like people have more than two environments. So they've added this environments API, but even that, like, it just blew me away at how they had this huge documentation, RFC page with like a big PR and the docs in that RFC were like better than any docs I've ever, you know what I mean?
Nate: Like just the docs for that, like environment API, RFC were, were beautiful, like so detailed. So much work went into it. They iterated on that API a bunch of times. So I just, I'm just a V maxi. Like, I think that they really know how to like build open source and how to like design it and how to document it and how to, and like, you know, it, it shows they have, you know, 60, 000 stars or something crazy.
Nate: So to me, like, it was like, if I can do V that's like kind of ideal, you know, like first principles, V is like the bundler I would choose. And so that was, I did this experiment with VXRN, sorry, I'm getting wordy here. Um, but yeah, like VXRN, it, it went well, like React Native is hard. It's hard to, it's very hard to build for, um, I think not like, not necessarily on like a, uh, Like, like, yeah, most of the work I think of this framework is getting it to bundle and work with Vite for React Native, mostly because Vite is ESM focused, which is kind of ironic because React Native doesn't support ESM at all.
Nate: So it's like, how do you do that? And so that was kind of a big part of it. I'll leave that for if we want to poke in, but, but I think the next things were basically once we proved that out at VConf last year, we took a little break. I still wasn't really sure. Um, but I, I sort of like. Yeah, I had a friend that was like using Expo router.
Nate: They were complaining that they had a 10 megabyte JavaScript bundle. And I was like, interesting. Like they still haven't figured out code splitting, you know? And also just, I think it was a fun project. Like, I think it was fun to sort of figure out, like, can we do this? Like how hard would it be? And, and to expo's credit, like I will say that like, uh, one did start, I mean, I, again, I was sort of feeling things out and trying to figure out if we want to do this.
Nate: So part of that experimentation was me taking expo router. Just some of it, just some of the core of it and just saying like, can I get the file system routing to work with our VXRN library? Cause that would be the next step, you know? And then like sort of got that working and kind of kept going from there.
Nate: And so we've diverged, you know, quite a bit, but like, I will say like, you know, uh, some of that core, especially some of the, just like the file system routing logic that takes like, you know, some of the, like, you'll notice that we're very similar and that's on purpose. Like we, you know, I think it's, we're using open source, like we're using react navigation, which I think does like.
Nate: majority of sort of that hard work of the router. And then we're using some of the file system, routing, scanning stuff from, from expo router. And then obviously we've added a bunch of other things and done a bunch of other things like loaders and, uh, SSG SSR SS SBA type style routes. Like we, we wanted to port the tamaguy.
Nate: dev site over, which, um, which is. It kind of, it was a full featured next JS app that had like generate static params and it had like, you know, get server side props and all this stuff. And so we needed all that too, which, uh, which was like kind of table stakes. So we had to implement all of that stuff ourselves.
Nate: And so, yeah, I feel like we've got somewhere where like, we have like a bunch of stuff, like we, we were able to port the Tomagooey. dev site over, have it fully work and not, and I also not degrade the Lighthouse, uh, Speed or the like next page speed and all that stuff like at all. And that took a lot of work.
Nate: Like we had to get perfect, no waterfall loading. We had to get perfect hover preloading for the next page and, you know, preloading of assets, and there's a lot of cool stuff going on. Like it's actually, I think, you know, it's a beta. stack, but it's, um, it's, it's fairly robust in a way.
Justin: So maybe let's like, take a step back and talk about like one. Holistically, maybe in terms of, uh, things that other people would be aware of. So we've talked a lot about like next JS. Uh, so you talked about how like takeout was like Tamaguri and next JS. Uh, and I sort of think of one, what you've built here as a new meta framework.
Justin: I say metaframework in the sense of like Next. SvelteKit, or it seems to apply that layer. So you're using React and supporting React Native, which is the real novel sort of innovation here. Um, but it has a lot of features that people would be familiar with. Client side rendering, server side rendering, static site generation, routing, or file based routing, et cetera.
Justin: Would you like to like expand on that? Did I miss anything?
Nate: Um, I mean, there's a lot of little things, but I think that, you know, on a high level, yes, it's comparable to like a remix maybe, but like it gives you SSG, SPS, SSR and works on native. So yeah, as it is today, I would say, you know, obviously this whole zero thing is kind of where we're. Headed, but, uh, I think we're trying to be slightly fuller stack, but let you eject as kind of like the next wrinkle of it is like, again, the kind of coming back to the rails thing, which is like, I want people to be able to move really fast and I do think this kind of.
Nate: Local first like data solutions like zero are clear. I think they're just clearly the way forward and, you know, a little bit of a corollary to maybe server components where a lot of people are heading. And I, and that was actually, I guess that is a bit of the history too, is that like, I was very surprised to see server components, the way that they're designed and the way that they're implemented.
Nate: It felt to me like a solution that requires you to know a lot of new concepts and do a lot of work for it. In the end, it wasn't clear that it actually, it actually seemed to make your data loading and, and manipulation and data more complex in a, in a way versus like a more local type solution. And so I was, yeah, like there's a lot to talk about there, but I do think that like the, one of the big things that we're not focusing on is server components.
Nate: Like we may want to bring in some of the bundle size stuff, but like avoid a lot of the, like we may implement. Basically a subset and an opinionated limited subset, almost like a more. Like to, in order to get the bundle size savings, but the rest of it, we're sort of like, I think once you have something like zero, it's so nice and like, doesn't force you to think about the server boundary.
Nate: So yeah, that would be the rest of it, I guess.
[00:20:30] Ad
Andrew: We'd like to stop and thank our sponsor for this week, but we don't have one. So if you'd like to sponsor DevTools FM, head over to DevToolsFM slash sponsor to apply. And if you want to find another way to support the podcast, head over to shop. devtools. fm, where you can buy some merch and rep the podcast.
Andrew: With that though, let's get back to the episode.
[00:20:49] Exploring Data Loading and Zero
Andrew: So in the docs, it seems like you allude to a lot of data loading stuff. I don't see any react query anywhere. You have your own use query hook. So how does like data loading work since you support all of these different targets, like server rendered and client rendered, how does it all fit together?
Nate: Yeah. So we have, well, right today we have loaders and that's mostly like for you to be able to migrate from something like Next or Remix, like we needed it to migrate and also cause zero is not like fully ready. And also zero is like zero is more like zero is a company that we are partnered with. The founder lives down the street from me, actually, funny enough, in a small town in Hawaii.
Nate: Um, that was just serendipity, I don't know how that happened, but, um, I mean, that also predates the names, so, it's not like we had one and zero, like, designed and then, like, that happened. Uh, they were working on Replicash, um, and I was introduced to them when I was working at Vercel. And then I thought replicash was really cool, but I, I was like thinking, you know, I tried it out, we were using it actually at Vercell for a project that I was working on and, and I sort of like, my feedback to them was go more, go deeper, like do more, solve it.
Nate: And cause replicash was a little bit more like BYO, you had to glue together a lot of stuff. You had to like, kind of figure out the design of your data model a little bit more, you had to do your own like schema stuff. Like there was just a lot that you had to do. And I wanted something that was more like mad, like magical, but more like, you know, you just have this query, nice querying syntax and it handles all the hard parts for you.
Nate: Um, and so I, I was, uh, a pain in their ass in terms of just being like, do that, do that. And, and they were sort of thinking about doing it. I think I helped motivate them to see how much people wanted that. Um, and so like to, to Aaron's credit, who's, who lives down the street from me, Aaron, you know, I thought it was very impressive that they.
Nate: Took that feedback and they basically were like, yeah, I mean, this is basically like a rewrite, but we're going to do it because it seems like the right thing to do. And so that's what they've done with zero. And as they were building that out and I saw them really making all these like great decisions, I thought, because to me, like the big, like, so yeah, to get into what it is, what it is, is essentially, oh man, there's, it's so hard to like poke in the right way.
Nate: Cause I know there's so many different perspectives here, but. You know, anyone who's used maybe, I think like Firebase, Meteor, ParseDB, um, a native app where you use a local DB that you sync to a remote DB. These are all experiences where you essentially just have a query like syntax, like a, a SQL like or some sort of querying syntax that you just use in your components.
Nate: And they typically handle the rest. Like they give you real time syncing, they give, and like a lot of them, you know, in the ideal case, there's even PouchDB, there's, you know, there's been a bunch of these attempts. That none have fully succeeded. I think modern ones are like electric SQL, instant DB.
Nate: There's a bunch of people trying this and it's not, I don't think it's been pulled off yet fully in a way. And, um, but the ideal is sort of this thing that native apps pull off pretty often because native apps don't have to worry about bundle size and they also don't have that many people. I think typically they're not like these multiplayer.
Nate: They're not also trying to do the multiplayer thing. They're just like you using your app. And what they give you is like amazing. I think they give you much simpler code than say, maybe like react query or something like GraphQL or something like, um, let's just say server components. Like, I think they give you much simpler querying and much simpler code.
Nate: They also give you better user experience. So it's like a, it's like, okay, so how does that work? Is it's a win win. Why isn't everyone using them? Um, because if it's simpler code and better user experience, user experience, by the way, just because they. Because they have a client side database, your mutations are instant.
Nate: There's no server round trip, including updating other queries on the screen. Like I mutate something, it knows, it has to know all the queries, how they work. And so it can actually update, you know, if you have a list over here and a thing over there that uses that query and it needs to update, it needs to actually know how to run the database on your client.
Nate: And that's why they aren't more popular. I think is because the way that people have tried to do that on the web is basically pulling in something like SQL light, which is like a one megabyte. JavaScript, you know, bundle size hit. And so that's why no one uses it on the web because it's like, well, okay, I'm not going to bring down, or they just have weird limitations.
Nate: I think a lot of them, like, you know, pouch DB sort of did this without having a whole big bundle, but it had a ton of weird, I mean, it ran on couch DB. You couldn't delete, like, it just had like a bunch of weird limitations. I tried it actually back in the day. I really, I have loved this stuff for so long that, you know, I tried to make it work for like a company that we were playing with and it didn't, it didn't Uh, you know, Firebase maybe is like, it doesn't give you the local stuff.
Nate: It's, you know, it mostly depends on the network. Um, so maybe that's like a sort of a, it does some of the things you would expect, like with this nice querying syntax and real time sync. Um, so like there's maybe that is like the closest successful version. But to me, what, um, what Xero does that finally, I think gets it over the hump.
Nate: Well, one, it works with Postgres. So. It can work with other database engines, but they're not going to focus on that for a while. But I think it's a huge win that like, you don't need a custom weird database. Another example is rethink DB back in the day. I don't know if you guys remember that, but rethink DB was super cool.
Nate: Um, but also custom database. I just think that's why they didn't, you know, obviously that's why they didn't end up working out. It's too much work. So they work just on Postgres. Your existing schema too. You don't have to like, Buy into some custom weird data layout in your database. You can just use your existing tables.
Nate: So I think that's one huge win. Next huge win is, is that their client side database is custom implemented on top of that so that it's light. Um, so it's not a huge bundle size hit. Um, which is, I think that's a big one to me. That's the reason why it's never taken off on the web. And I think for now, like you can truly make it, you know, work well for, for most websites, even if it's a website that needs to get it like a great lighthouse score, I think that's the key is that they've done this custom database engine, but it looks a lot like SQL.
Nate: It also does nested queries, sub queries, which I think is another big one for, for the modern world where we have react like applications. Where you need to nest and compose queries down a tree, because once you can nest and compose them, you can do something like a relay thing where you can build one giant query and then do no waterfalls.
Nate: I think that's another, not as big, but pretty big. Uh, because it can work on server side then very well without waterfalls. And that's what we're doing with one is we're making it work on server side very well. You sort of asked about like, how do we make that all work? Like, I think some of the stuff that one is doing that makes it work very well is that we are sort of like building out a lot of the.
Nate: server to the client handoff and server side, like functionality that lets you just kind of share your code and it just works. And so, yeah, it does. Like we have the beta that we've been playing with and building out tooling around and, and yeah, like what, what you do is, I mean, what we actually even had like this sort of loader pattern that you had to like glue it into, but we actually found a way to get rid of that.
Nate: So you can't just use query anywhere and then you do have to sort of chain it. Um, to the top, but like, we were working on them with this like idea of like fragment type param type thing that I showed in the demo video, which I highly recommend people, maybe you can like link it or something, you know, but like, uh, I do think the demo video does a great job of showing, like, if you really want to see the code, um, that I did for the launch.
Nate: And yeah, like, it's just very cool. I mean, I just think that like, there's a few more, like, you know, you can talk about like partial sync, smart syncing, deferring the storage to like another big pro I think another huge problem with local first type solutions is that, you know, you run out of storage locally and then what do you do?
Nate: And that's like something that like a lot of them make you do. And they saw, they are handling that as part of it. So again, so many things to poke into. Uh, I think it's very cool, but, but I just think that it, because it solves the bundle size. And works with just your database. Those two things are like the huge ones.
Nate: And then there's like a few other small ones that are also pretty, uh, pretty rad.
Justin: Yeah, I saw Aaron's announcement of this at the local first conf in Berlin, and it's, it's a pretty. I mean, it's a pretty radical concept.
[00:29:06] Partial Sync and Smart Caching
Justin: I think like one of the things that like local first technologies in general struggle with is the notion of a partial sync. It's like you got a big database. It's got a ton of data in there.
Justin: Obviously, if you have, like, you know, a service with a million users or something, you're not going to be able to pull Well, you wouldn't pull in all that data, but like generally just being able to pull in what you need is like a hard problem. It's like a not very well solved problem. And that's one of their promises, which I think is, it's kind of incredible.
Justin: Um, just to think about like, you know, I'm thinking about data, database access. This thing's really going to be like smartly caching data that I look up and is like used frequently. So it's like a big part of their thing. And yeah, just like keeping the partial cache. I think more. I guess more to the point is just you not having to think about it.
Justin: There's stuff locally, there's stuff at the database, and it's just going to do the right thing. Um, that is, uh, that's going to be, it's going to be an incredible API. I'm, I'm really excited for it. I can't wait to try it out.
Nate: Yeah, me too.
Justin: Um, yeah, yeah, yeah. It's so how did you, uh, I mean, when you launch, uh, you, you, you're very much talking about zero sort of in lockstep with one and, and, you know, just as you just discussed, it's like a sort of. Integral part of your long term strategy with this, but what made you decide to like hook it so deeply into what you're trying to do?
Justin: Um, I mean, versus like, Oh, here is a data fetching solution. Um, yeah,
Nate: Yeah. You know, I, we'll see, like, if it turns out to be the right thing. I think what I want, like, I think this is like going back to the rails type thing, but I think why, why doesn't it work? Like, why, why can't we have a modern rails? And I think there's good reasons. Like, I think that, um. You know, like we're solving much bigger and more complex problems with client side apps, you know, than we did back in the day.
Nate: So there's a lot more surface area. There's also just a lot more money in our industry, I think, and a lot more like people solving different types of problems. And so I just think that like, it's a kind of a fool's errand to try and go in and say, we're going to solve everything ourselves and you're going to love it.
Nate: Um, I just don't think you'll, you'll win because I just don't like, again, like look at zero, you know, it's like, it's an entire startup, you know, And maybe more like they may not even pull it off. Right. Like just because it's that hard. And so, you know, there's no chance that I'll ever do that while building a framework, but I thought that's like, I thought it was kind of nice to have this half step.
Nate: This sort of like fuller stack framework, but not full, which is that if you follow this happy path, especially with data, I think is data is really so deep. Like if you have this agreed data layer, I think it unlocks some really incredible stuff at the framework layer that we haven't even shown yet that really will give you like these huge upgrades in, in sort of like user experience, developer experience, like productivity.
Nate: And also I think like being slightly opinionated like that, where we do have this thing, like, you know, zero is still going to require quite a bit of setup and integration and like the server rendering handoff is quite a bit of work to like get right and all this stuff. And, and so like, yeah, I think like we can solve a bunch of like bumps that you would normally run into if you didn't, if you weren't that opinionated and had like, I think we can.
Nate: I think we also like, yeah, can add a bunch of value beyond that. Um, like in terms of tooling and like interfaces for your data, like I think, um, kind of like understanding your schema and like letting you handle migrations very easily. And like, kind of, I just think it like, there's very cool stuff, I think beyond just Zero working that we can do in the future as like, you know, our, our stack understands your, your data.
Nate: And like, I just think that there's, once you understand the data of the stack, there's a lot of cool tooling and like, uh, other kind of benefits that, that come along. And then, um, I think like, yeah, I mean, you can inject, you know, so like we, we don't want to be too opinionated, like we totally want to work just like how any other framework does, but I, Oh yeah.
Nate: So I guess the final piece too, is just like. If we're not doing server components, we do have to have, you know, a solution. And so I think that's why we've sort of come out and said, like, we think that this is kind of the way forward. Um, and then we do, you know, we really do think that that's like the ideal setup.
Nate: So, um, you know, we, we do want to embrace other potential solutions if they do come out and we feel like they're working well, we'd like to make it easy to integrate with any of these other types of local first type, you know, we've talked to a few other people that we're friends with that are working on, you know, the ones that have different trade offs.
Nate: We think Xero kind of solves like the tradeoffs in such a way that it works really well for most things. And so, you know, if they, we want them to pull it off, we we're aligned with them and so that's why we thought it would, it would be good. Um, yeah, if other ones turn out to do well and, and, and solve it in different ways maybe that are interesting to different types of people, we'll try and support them too.
Nate: But yeah, like I just, I just think like if we're not gonna do server components, then we have to have something and, and I think that this is nice. Like it lets our team focus on what we're good at. And, and they can focus on what they're good at. And we do have a good relationship and, you know, so that, that helps it a lot.
Andrew: You said there was some subset though of server components that you would want to support. What, what does that look like?
Nate: Well, cause server components is a lot, right? Like it's sort of an umbrella of things. Um, and so I think like, we don't want our router to fundamentally be server driven. Like that, that would make things a lot harder for us. And I think for our users and for people building apps, like especially local first style, like it just doesn't make sense.
Nate: Like you want the cache and you want your, You want most of your stuff to be running client side, ultimately, um, in terms of like, I mean, yeah, your data is caching there and running there. And if you have your data already instantly available, if you have to do a round trip to the server to pull in like the next page and figure out what you're going to render.
Nate: Then you've kind of gotten rid of all that really great user experience that you get from local type apps. So, so it's kind of like, that's, that's the reasoning. And then I think though, like some of the bundle size stuff where like you don't, you can totally avoid bringing some of the, um, some stuff into your bundle JavaScript and, and, and bringing it to the client, that's what I would like to bring in, and I think, I think that that's doable, I think like.
Nate: What it could look like. Like, I don't know this actually fully yet. We haven't really dug into it yet. We've talked to a few people who work even on the react team and stuff about this. And so we have an idea of maybe how it could work, but, um, it would, it would either be almost like an inversion of the model in a sense, or just like a strict limitation on mixing trees.
Nate: Cause like right now with react server components, you can really mix things. Like you can like pass, you know, a server component to a client component and then pass that down. And like, You know, you can sort of like mix in a very dynamic way. And what ours may be is like, you know, we have maybe even loaders, right?
Nate: I think, uh, remix was playing with just like having loaders. If you return JSX, then that's just like your static stuff. That's not loaded. Like we could actually implement that. We've looked at it. It's, it's not that hard to where you're, you're not able to like mix the trees and like do this fancy kind of like stuff that server components lets you do.
Nate: But you can just say like, here's some JSX. That we want to load in. It's got MDX in it, right? Like it's my static content. Um, I'm not going to be able to like pass props through it or whatever, you know, this crazy stuff that they let you do, but you can still avoid bringing that into your bundle. And so something like that is what I imagine.
Andrew: I really, I mean, a lot of the features that you've sort of like outlined in the docs, I think are like pretty strong. I mean, you've, you've done like a lot of incredible stuff. So it was like typed routes, which I really appreciate. Cause it's like, it's deceptively tricky to like generate types for a router.
Justin: Um, another thing, this is like a, uh, just like a fallout of something that I really appreciate. So you have this way of. You can define like overall if your app is like SBA or service I generated or whatever. But you can also do that per page, which is like pretty typical of metaframeworks. They like a lot of them let you choose, but I like specifically how you encode it in the file name.
Justin: So it's like name of file plus like the thing. Um, that's actually. Pretty incredible because a lot of the meta frameworks is like, you're exporting some variable inside or something. It's like written inside the file. Um, and you have to kind of like remind yourself, or at least I do like clicking back through, it's like, okay, like, what is the style of this thing?
Justin: And like, you know, find the thing. And I like how you've laid it out to be really scannable. Um, what do you think are like other features or other. Things that you have done that sort of like innovated on the way that, you know, people build frameworks. I mean, aside from the very obvious, like, Oh, this works for react NATO, which is like not to be discounted.
Justin: Um, are there any other like big things under the hood that you're really proud about that, like, you know, might not jump out to people immediately?
Nate: Um, honestly, I, I don't want to like, you know, try and reach too much. Like, I, I really think that, um, I mean, again, like, you know, one is early. Okay. And I've been working on this as I had a full time job and a full time side project. So it was my second full time side project. So, so we, we are, I am full time on it now.
Nate: Um, and you know, we've got our little team that's bootstrapped and makes some money. And, and, and so I think we have enough focus to really give it the love that it deserves. Um, but I will, I will, I won't really claim that we have. You know, too much more than that. I mean, I think there's a lot of polish for being an early project.
Nate: Um, I think there's a lot of like refinement. I think the fact that you can get perfect first loads, perfect next page loads with preloading all the, you know, it preloads the loaders. It preloads the next page contents. Um, it's super fast. It's easy to serve in production with a single command. Like I think if you just compare it even to existing framers today, like something like a remix, like You know, I, I think it does really well, actually, it's surprisingly well, um, and it, and it works, you know, really, and like, we've also done things like, you know, we're using react navigation, but it can be a little bit heavy.
Nate: We actually slimmed it down quite a bit by replacing certain heavy dependencies with our own version. So, like, I think a lot of the stuff that we've done comes down to just like refining, refining the, um, kind of what's there and, and actually making it really quite good, um, for being this early. And then I, yeah, again, like, yeah, the per page stuff is really cool.
Nate: I think that's kind of one thing that we really focused on and tried to get it to work really well. Um, I think the, you know, the react native thing was huge. Like that was a huge investment. So the react native support is, is kind of like the big piece. Um, in the future. And then like, yeah, I think again, like leaning on zero, we're trying to, like, I think our, our, our thing in the long run that we want to push is like, this is, we're not trying to complicate things.
Nate: We're trying to keep things simple and give you like this, this, this Slightly opinionated stack that really lets you move fast and do things that you couldn't do before, like, you know, shared, shared cross platform apps. And, and so I think that that's where we're going to stay, you know, we've got loaders from Remix.
Nate: We did implement that ourselves, but it's nothing new. So, uh, yeah, I thought, I think, I think above that, so I've sort of alluded to dev tooling. I think that's something that no frameworks are really doing that well. I think there's some cool stuff to come there in terms of just like great Kind of like tools that will come out of the box, especially if you do opt into zero that give you a lot of like fun superpowers that, you know, you wouldn't have on day one with anything else.
Nate: So I think we'll, we'll have more to come, but I think it's enough that we just have, you know, react native and it works really well, um, for web as well. So,
Andrew: So you said you guys are still in beta, so what, what's it gonna take to get to a V one? And is there like any like critical stuff that needs to be added before then?
Nate: um, I would say web is, it's, it's sort of like one, we need to get 404 pages working, that's kind of the last thing that there's like, it's mostly there, but it's, there's a blocker. So web is like. I mean, if you're okay without a 404 custom 404 page, then it's, it's production ready. Um, and it'll, I think it's, I think it's basically production ready.
Nate: Um, in fact, I think it's like, it's quite good. Um, web. So I'd say web is quite good native. Because we had to implement it from scratch and like including hot reloading. I think it, it's, it's getting a lot better. Like it, it's working on a lot of stuff. We actually got the Uniswap, um, entire UI running with it.
Nate: Um, so like not the, not the entire UI, but the UI package that has most of their UI, all of their UI components and everything. We, we built a sandbox, um, for them to test it. Actually, I think it's a really fun use case, which is like, if you have a company that has. React native and web and a web app separate.
Nate: Like they're using create react app still shockingly. Um, but like we were building a new design system for them. And what I did is I spun up one, I got it to load and then it was really nice. Cause instead of having to like, you know, go in and like run their, their native app and then like kind of carve a hole into it for myself to work in, you know, like just like, Delete the homepage and then like start and then like do that same thing with the web app where I had to like go in and run our existing web app, but then like delete some, you know, just like make like a random test page for me to, so I think that's the use case of almost like a storybook type thing where you can like build, you can plug it into your existing company.
Nate: If you have a react native and web app, I think that's actually a really strong use case. Um, today, which is just like, you can just kind of like plug it in and yeah, it worked pretty well on Uniswap. Um, so after work, we had to like fix a bunch of dependency issues and fix a bunch of things. Um, so yeah, native feels like it's like halfway there.
Nate: Um, the hot reloading needs a little bit of work. Um, it, like it hot reloads single files pretty well. Once your hot reload starts touching multiple files, we need to fix that up a bit. Um, we actually have a good idea of how that looks now. Um, but. You know, um, Metro actually does very good at that. You know, I'll give them props there.
Nate: They're actually probably the best hot reloading bundler I've ever used. Um, it's actually surprising how good they are at hot reloading. Cause I don't think Webpack or even Vite, um, itself does as well, but I think we'll, we'll get there. We'll get pretty close. Um, so it's hot reloading mostly. And then just like, you know, I think we are, we're going to just kind of try and find the top like thousand or something most popular, um, React native packages.
Nate: And just build a big test suite around that and make sure they all work. And I think once we, once we fix up hot reloading a bit more and that, I think we're pretty much like we're, we're, we're closer than it, than I think. It may seem it's felt cause like it took us a long time to get to where we are, but now we found that like the other day I just plugged in this like pretty intense package and it worked on the first try.
Nate: Um, I was very happy about that in with react native. So it's, it's mostly hot reloading reliability and, and I think just like kind of testing things a bunch. So I'm, my optimistic thing is maybe three months until it's like pretty much ready, we won't maybe market stable, but like, it'll be, You know, you can probably deploy a native app to production pretty reliably, um, in about three months, maybe in six months, it'll be closer to like actually where we can maybe a release candidate or something like that in three and hopefully closer to production, uh, ready in six.
Justin: That's pretty exciting. It's a, I mean, it's a heavy lift and, uh, But I mean, it's, it's already looking phenomenal, especially for it to be like, not, you know, not stable or whatever. It's like, it's, it's looking incredible. So really excited to see what y'all come up with.
[00:44:50] Future of Universal Apps
Justin: Um, before we wrap up, we always ask a future facing question.
Justin: Um, and. You've been working in this space of like building universal apps or building the tools to build universal apps for a while, as we talked about in the Tamagui episode. And as you mentioned early in this episode, that is, that's a hard thing to do and to do well. Um, so I'm excited to see one come together.
Justin: Uh, and provide, uh, like a fuller tool set, uh, to be able to solve this problem. But with your, the work that you've done to this point, what do you think is like left to be solved in this space? Like, what other things do we need to solve to like make universal apps just easier to build?
Nate: That's a great question. Yeah, that's a really nice one. Um, yeah. Cause I think I talk about that a bit, like to me, the big problem was Tomaguy originally when I was first building one. And I think it's like, Maybe not solved, but it's hell of a lot better now. Um, and then I think with one, like the, the, the big thing was like the fact that you needed two frameworks, two bundlers, all this stuff.
Nate: So I think we've solved that. I think zero is actually in a weird way. We're, we're getting a free solution to data, which I think is the biggest thing. Uh, Dax, I don't know you guys know Dax. He, uh, I was kind of happy cause he was like, he's been playing with solid on, um, zero getting zero to run on solid.
Nate: And he's actually been running into a lot of problems. And he actually was, he was saying the other day, like, I think react actually is a better model and I may have to go back because like, he's like, I think my beef with react was that the state was so annoying. But with zero, it sort of solves state. So now, like, I don't see why I wouldn't use react actually, especially with the ecosystem.
Nate: And I was like, exactly. Like, I think the state to me, state and react was so annoying, especially when remote state, not just local actually sidebar, but I really want there to be a zero state where it's cause right now zero is tied to the database data, but I think there's no reason you couldn't make some parts of it ephemeral.
Nate: You know, like to where it's just, you can use your zero for everything. And the second that works, I will never touch you state again. I think that'd be awesome. Um, so I think that'd be very cool, but like, I think the data side was actually the biggest, one of the biggest unsolved problems, especially for sharing between native and web.
Nate: Because again, yeah, you want that native speed, but on the web, you can't have a huge bundle size. So I think zero gets us there. I think the last thing for me, the last big area that I see, it's kind of hairy that we are working on. Yeah. Um, and we're working with this very, very talented guy, um, Dominique, who's from the Philippines, uh, who's building some very impressive stuff here, but I think, um, it's kind of this like mixing of native and, and non native UI with React Native right now, you sort of have to like, hope that someone's built tools.
Nate: It's a great library and that you can use it and that it works. And it's also very hard to like mix your views with actual native views. Like it's at least it's hard for the library authors to make it that way for you. And then that makes it so there's not that many of those libraries. And I think in the future, like the ideal would be that I can plug in like a native iOS sheet, a native iOS, like.
Nate: Whatever I need and still have my react content render into that very easily and adapt between the two very easily. To me, that's like kind of the last bridge to make react native apps feel really great is to very easily plug in more types of native UI. And so we actually have, actually, we just launched, uh, we just released the new Tamagui version just the other day, uh, like yesterday, I guess, that, um, landed some huge upgrades to our sheet and our adapt components.
Nate: And then it got it working with Dominique's new sheet that he's been working on. It's really cool. The work he's doing is very cool. Maybe I can send you guys a link or something we can plug. But, um, basically he has like, he built this like very intense, um, bridge that like lets him do that more easily on new architecture and old architecture react native, which was hard to do.
Nate: And it lets you just like mix. So like, yeah, it's a fully native iOS sheet, bottom sheet. You can attach it side, left, right. Like you have snap points and all this stuff, blur background that is native, but you can render all your, you know, react native content into there very easily. And another thing that I think, uh, these, this, uh, I think, uh, Mark has been working on is like react nitro, which makes it easier to like also just drop in like Swift and stuff like that.
Nate: Like, I think that is kind of the last frontier too, where it's like, I just want to like first have better tooling for bridging this sort of stuff. And then second have like, you know, better stuff you can just drop in that works, um, like this react native sheet. And then also just be able to import like a Swift file or something and just have it just work right.
Nate: Like with types and everything. And so I think there's like some interesting projects going on there. And we're, we're sort of working on that. It's sort of, it's nice. Cause it's kind of in between Tamagui and one, two, you know, it's like. Tamagui needs that one also needs it. So I think our goal, one of our goals going forward is going to be making it so that like, we were trying to put together an example app.
Nate: That's going to be really, really slick. That has like a bunch of native UI on iOS and stuff. And Android feels really great. Like I w I want to show, I want to put together this example app for one and Tamagui. That's like, here you go. You know, from day one, you have a bunch of native stuff. You can. Render too.
Nate: It actually feels great on native actually feels great on web and, and is really nice to write. I think that's what we've been trying to do for a while. And that's, that's definitely the last big piece. So we're working on it.
Justin: That sounds awesome and incredibly ambitious. I'm really excited to see what y'all come up with.
Andrew: Cool.
[00:50:23] Concluding Thoughts and Future Plans
Andrew: Well, that wraps it up for our questions this week. Thanks for coming on again, Nate. Uh, the, the new stuff you're doing seems pretty mind blowing and I'm, I'm really excited to check it out every time I, I build an app I'm like, why am I not using react native and this kind of feels like the, the last thing to push me over that edge and take the dip.
Andrew: So thanks for coming on.
Nate: Nice. Yeah. Thank you, Andrew and Justin. I appreciate it, man. It's, it's always fun chatting with you guys.
Justin: Yeah, it's great to have you back again, uh, and hopefully the next time around, you know, it'll be a fuller story and we can like, celebrate some new launch. Uh, it would be really exciting to have you back. Uh, I, you know, just. Tremendous props for this work. We had talked in the last episode, I'd done some of this work at Artsy and it was really hard, uh, and incredibly, incredibly challenging, sort of massive respect for what y'all are doing.
Justin: And I'm pretty hopeful for the future, because if this makes it easier for teams to ship nice mobile apps, then maybe we'll see more of that in the world, which is exciting. So props, good luck. Uh, we're rooting for you.
Nate: Good talking to you guys.