Replicache, Local First, and Sunburns
There are plenty of applications that should be built as a spa. And you could say for the last ten years, people defaulted to building spas when they shouldn't have, and now there's backlash for that. Like, things that should have been websites were built as spas. I'm I'm headed somewhere with this, I think. Hang on.
Speaker 2:You look tan.
Speaker 1:I am tan. Do you like it? I do. Yeah. I mean, it's this is my summer look.
Speaker 1:I I mean, this is every year. It's not a just because I went on vacation. It's like we go to the pool at our we have a community pool. We've been there every day since it opened, since we got back.
Speaker 2:Are your kids tan?
Speaker 1:Yeah. They oh, you've seen my boys. They've got very, like, white hair, so they look really tan. But, I mean, they they do pretty well in the sun. My wife actually she's like looks like she's from Ireland.
Speaker 1:She's, like, redheaded, very fair skinned, but she actually handles the sun better than I do. Like, I'm the worst burner of the family.
Speaker 2:Yeah. Well, I I witnessed that.
Speaker 1:Yeah. No. I I got really burnt, yeah, when we were in Florida. I always do. And then I think after one good sunburn every year, I kinda, like, settle into a tan Nice.
Speaker 1:Which is probably terrible for your skin. I don't know. I don't wear sunscreen. I'm I'm awful. I'm probably gonna die of skin cancer.
Speaker 2:It's gonna
Speaker 1:be really sad when I do. How sad sorry. How sad will it be when I actually die from skin cancer and we we we play this back at my funeral or something? Okay. Sorry.
Speaker 2:I wouldn't play this back at your funeral. I don't know if I'm gonna be in charge of your funeral. Don't know why I said that. Am I gonna be in charge?
Speaker 1:Why not?
Speaker 2:I feel like you need to give me specific instructions for because you're gonna want really good production quality for your funeral. So Oh, for sure. Yeah. Gonna need you to produce it, and I'll just make sure it happens.
Speaker 1:We can rehearse it ahead of time and then after I die. Okay. Cool. Good plan. Okay.
Speaker 1:What were you gonna say? You're going into something much less unhinged.
Speaker 2:No. I mean, I was gonna say I also got my first sunburn ever in my whole life.
Speaker 1:Oh, yeah. Yeah. You said you said in Florida, you can't get sunburned.
Speaker 2:And then
Speaker 1:you got sunburned. We did I guess
Speaker 2:we sat out there a lot longer than I realized. We were just kinda when you're in
Speaker 1:the water in the ocean, you just assume the sun can't get you. I think it still can. I'm not a scientist.
Speaker 2:It can. Yeah. Yeah. I mean, we're you're all like, I got burned just a little bit on, like, the top of, like, my shoulders, like a strip and a little bit, like, down by my waist. And I literally was, like, I was, like, I was at home because I didn't feel it that day.
Speaker 2:The next day, I was like, Liz, do I have mosquito bites on my back? Like, I'm so itchy. Like, what is this? Like, I didn't and I'm I'm like, when I scratch it, it, like, kinda burns. Like, what is this?
Speaker 2:And she she was just laughing so hard being like, you got sunburn.
Speaker 1:Oh, love it. I love that you'd never been sunburned until that moment.
Speaker 2:Not bad considering I wore zero sunscreen that whole day and we were out for, like, many many hours. So
Speaker 1:Yeah. I think I even put sunscreen on, but I still I I don't I hate sunscreen. I the whole thing just feels like a scam. It never actually works for me, but it'll work in random, like like where I was wiping it off on my, like, belly because I just I had some left on my fingers. That spot, I'll have little
Speaker 2:finger marks
Speaker 1:where it worked. But none of the stuff on my shoulders like, I don't know if I was just out there too long, and maybe there's just no way to put enough sunscreen on. But it's just so it's so bad. I hate the whole experience. It never feels like
Speaker 2:you're getting it all over you.
Speaker 1:And with kids, it's sometimes worse because you're constantly stressed about their skin too. They got three sets of skin you're worried about. It's just a it's bad deal. I'm actually going to a dermatologist because I
Speaker 2:think I've got a couple spots on
Speaker 1:my nose that look scary according to WebMD, like cancer stuff. I'm serious.
Speaker 2:Do they have dermatologists out in the Ozarks?
Speaker 1:Oh my god. Dax, come on. We wear shoes too, believe it or not.
Speaker 2:What? You have one dermatologist? Is that?
Speaker 1:I think there's three in Springfield. Okay.
Speaker 2:Oh, Springfield. Okay.
Speaker 1:How many dermatologists do you have? Do you have it memorized in Miami? Do you just know?
Speaker 2:Within walking distance, probably more than one.
Speaker 1:Are you within walking well, how far can
Speaker 2:you walk?
Speaker 1:I mean, anybody could
Speaker 2:Like a fifteen, twenty minute radius, I would say.
Speaker 1:Okay. Yeah. Interesting. Come at me.
Speaker 2:Come at me. For your
Speaker 1:number of dermatologists. An interesting flex. I've not heard that one yet. You're gonna need a dermatologist with all this sun exposure.
Speaker 2:Yeah. I know. Each sunburns. I know. I think I have some things I need to check out too.
Speaker 1:Do you just not go outside? Is that the problem? Is that why you'd never gotten a sunburn? Like, why did you never gotten a sunburn? No.
Speaker 2:I'm outside all I'm outside all the time. Outside all day. I think so when I go to the beach I think I said it to you. When I go to the beach, because because we go pretty often, we don't spend like six hours at the beach usually. We'll spend like two hours and like go get lunch and kind of a more casual thing.
Speaker 2:So I I don't think I'm like in direct beach sun for over two hours. That might be my limit. I think if I'm there for like many many hours.
Speaker 1:No. It's a good I we shouldn't go out in the middle of the day. Like, I don't think even with sunscreen, it's a good idea
Speaker 2:when Yeah.
Speaker 1:The sun's the hottest.
Speaker 2:Yeah, that's true. Just go
Speaker 1:out in the evening. Anyway, let's talk about something other than sunburns.
Speaker 2:Yes. So I wanted to talk about something. I had a topic. Oh. And I tweeted it just now teasing it.
Speaker 1:I retweeted that and I didn't even read it. But I still don't I still don't know what it is.
Speaker 2:So it's about rep I wanna talk about replicash a little bit. Oh, okay. Because it continues to evolve, it continues to get really useful, and it's and with, you know, I'm working on the SD console right now, it's using replicash heavily, for pretty much everything and it's incredible the level of like, UX impact it's having on the quality of our product and how and just how good it feels to use a product. Mhmm. And I'm just like, why does nobody know about this?
Speaker 2:Why is nobody using it? Why are we obsessed with all these other things that have such marginal impact on on UX and in performance? So I just wanna, like, show it a little bit, if that makes sense.
Speaker 1:Yeah. Okay. So I obviously know all about replicash. Being your friend, I've heard about it all the time. But for the people on the show that listen that that don't know what replicash is, could you just give us like a 30,000 foot view and then let's dive into the specific stuff?
Speaker 2:Yeah. So replicash is a primarily a library on the client that runs on the front end in the browser and it handles data syncing with your back end. The thing that makes it unique is it's built around the model of syncing a lot of data to the client locally so that more operations can happen entirely locally. And of course, from things like mutations, handles optimistic updates and and all of that. And what's beautiful about it is it enables these crazy real time.
Speaker 2:So one, enables crazy real time applications. Two, so much of your data is local that a lot of stuff that you normally have to go to the server for for a round trip, can just do locally. So things like fuzzy search, like, you know, command k bar, like jumping to things like that.
Speaker 1:Mhmm.
Speaker 2:And so it makes everything really really fast. But what's great about it is if you look at a bunch of other solutions that are similar and there's different solutions like this for a long time, they're all way more complicated. And RebelCache is really really simple and it has a very different architecture to to everything else that exists that, like, kinda allows it to be a lot simpler and actually makes it possible to use this stuff in practice.
Speaker 1:Okay. So is is, like, the offline first kind of stuff, like, is that a different concept?
Speaker 2:Yeah. I think it is a little bit different because, so replicash can be used to support offline applications, but it's not like they just haven't matured that part of it as much. Actually, the latest release, they've made it a lot better. But the offline stuff is it kind of has a pathway to that but it's not really the focus. Mhmm.
Speaker 2:Because I think what they thought about was so far we've treated this category of application as very specific like, okay, you want application that runs fully offline or you want application where, there's no state and there's just a bunch of people connected to each other that are like seeking state with within each other. And there are a bunch of solutions in that in that category but that's like not most apps. I doubt most of you have built apps that need to be offline first or like are completely peer to peer, right?
Speaker 1:Yeah, right.
Speaker 2:But I think those ideas get conflated when we think about real time or like local first. So I think replicash in the category of local first and I think this is becoming a category that's popping up a lot more. I'm I actually saw like there's a whole like local first meetup that even exists now.
Speaker 1:Oh, wow.
Speaker 2:Where you basically try to build applications that can run locally first for as many features as possible. Of course, some things you might still need to go to the server for but, there's a lot that can be built in this way. So Replicatch really focuses on this local first mentality and so many applications, I think, fall under the category of working really well. The application that I always talk about Linear as being like the best example of an incredible web app pushing the bar on what's possible on web today. Linear is a local first app and that's why it's so fast and so amazing to use.
Speaker 2:Plus, of course, all the details to UX they paid attention to. And if you go to the replicash, homepage, it was a funny experience for me because for a while I was like, okay, how do I recreate linear? How do I have a stack that can let me build something as good as linear? I was like researching this for a while. I landed on the Replicash homepage and their demo app is a recreation of linear.
Speaker 2:So Replicash basically took linear and was like Yeah. How do we make it so more people can build stuff like this and they built a gen a general tool, for that.
Speaker 1:So how does it fit in like, feel like the whole landscape is shifting toward the server.
Speaker 2:Yeah.
Speaker 1:What UX wins do you get if you go the replicash route as opposed to, like, SSR and doing stuff on the server?
Speaker 2:Yeah. So SSR is built, and I'm gonna keep saying this till I'm gonna saying this my whole life, I think, until I'm never gonna stop saying it because no one's it just keeps continuing to be a thing. SSR is built for applications not applications, it's built for websites where people go and leave right away. That's kind of how I think about it, like
Speaker 1:Yeah yeah yeah.
Speaker 2:You don't expect them to explore every single page of your app. They might come in, look at a single page and then leave, so it's short sessions. Yeah. So it's not worth syncing a bunch of stuff down to the client. They're not gonna really be around for that long.
Speaker 2:So for anything in that category, ecommerce sites, websites, just kind of one off things, yes, don't listen to anything I'm saying because it's not relevant. But for productivity applications, for things people have up all day to do their work, you do wanna sync a lot of stuff down to the client because they're gonna be around for a while, it's worth that initial cost. Yeah. And plus initial cost is literally the first time they load the app. From there, it's like kind of incremental sync, so whatever changes on the server the next time you show up needs to be synced.
Speaker 2:It's worth syncing all of that because then a bunch of operations can happen happen locally, right? So in the SSC console, we sync all of your resources and like all the metadata of the resources to the front end. That way when you open up the command k bar and you type in, let's say you're looking for, a function that's mounted at a certain URL route so you can go look at the logs, you can type in just the URL of the function and that search happens locally and literally with every keystroke, instantly with like no perception of latency, command bar is updating with with the results of your search. And the s s c console, that's like a small set because you're gonna have a ton of resources, you're probably gonna have like, even the biggest cases like sub 500 resources, sub 1,000 resources maybe. But for for Boomi, which is the other project I work on with my with Liz, we've done, like, searching on 50,000 records and still been instant.
Speaker 1:Wow. Yeah. How much data like, what is that like downloading that? I mean, like you said, it's worth it because people are sticking around. But is it like megs of data?
Speaker 2:Yeah. It it is. So on the first time a user gets added so in the Boomi case, if you invite a new user because they're a new employee, they join. The first time they load the app, it's gonna be several seconds of waiting because we need to query all that and queue it up and bundle it in the right way. And I guess stream down.
Speaker 2:But after that, it's all incremental updates. So it's only as much data syncing as your business is changing. Yeah. And that's all happening in real time and reflecting right right in front of you. So yeah, it's really not a lot.
Speaker 2:It's a couple seconds waiting upfront for like instant. Every page you navigate to knows we have we have zero spinners in Boomi at all. We haven't had to build a spinner component to load a component at all for anything because everything you load is instant. What you can kinda compare it to is in the RSC model or like in like the traditional model, you might have like, a cache that's progressively built up. So, like, you might go to one page, it might load.
Speaker 2:You might go to the next page and it loads. And if you go back and then forward again, it's instant and you because you because like stuff has been built up. Yeah. It's like that but without having to, like, explore. It's like that from the beginning.
Speaker 2:So it's like everything is fully warmed all the time. So, it's an incredible technology. It's just not very used. Like, I don't see a lot of people bringing it up. I will say it is a little bit challenging to learn.
Speaker 1:Yeah. So that was my next question is like the author time experience, like what is the your code look like with all this stuff?
Speaker 2:Yeah. So I actually think the initial setup is a hard thing to learn. So right now, they have a server side solution called Reflect as well. You don't have to do any of that. You can kind of just plug it into effectively a back end as a service thing.
Speaker 2:Mhmm. I don't use that because I I wanna have, like, a normal application and Replicash is just, like, a thing that I'm adding on top of a very normal application that's built on top of as a team, plan scale, etcetera. So there's an initial cost of understanding the sync protocol and there are certain things you need to make sure you're doing correctly to, like, implement the sync correctly. Because there's a lot of when it comes to distributed systems, real time sync, there's a lot of, like, edge cases where, you know, data doesn't make it to one place and not something else thinks it made it and then you have a desync. They lay out very clear steps on how to do this.
Speaker 2:It might be a little challenging if you're not familiar with distributed system stuff, it's but really not super hard, like, within a couple of days you can probably have implemented. But once you have it implemented, it's so easy. Like, from there, you just have these mutations you can send up, you apply them optimistically on the front end and you apply them for real on the back end. And then any issues that come up, like there's an error, things have to be rolled back, it's all automatically handled by replicash. So I think there's some initial setup learning curve, but, you know, SC console is open source so you can just take whatever we have there if you wanna use it.
Speaker 2:And then from there, like, the the other time experience is fantastic. I even added like an end to end type safety layer on there so it feels a lot like tRPC. But, yeah, it's it's been it's been it's been amazing and I I think more people should look into it.
Speaker 1:Yeah. It seems like if you're building an app, like you're building a spa or, like, some long lived thing, you should always be doing it's like leaning into that to get the best out of that. Right? Is there any reason you're building an app you shouldn't use this local first approach? Are there downsides?
Speaker 2:Yeah. So I I think it comes down to understanding the working set of data that a user needs. If this working set is massive, like it's in let's say it's over a 100 megabytes, it probably doesn't make sense to use replicash because syncing all that to the client is maybe too much. But I think very few applications fit into this, like even something like Linear, you can imagine that, oh, yeah, as a company, you know, makes issues and like over time, they might have like millions of issues. But the way linear treats it is no, the working set of data is just any issue that's open or they keep closed issues around for like a week.
Speaker 2:So your working set of issues is never gonna be like infinitely growing Yeah.
Speaker 1:As part. Yeah.
Speaker 2:Yeah. So anything where you can fit the working set into a reasonable size, you should do this because there's no downside at all. For stuff that's more like analytical or like you're like looking across big data sets and even in Boomi, we have like the day to day workflows which are like a small working set of data. Then you have like admin workflows, we're looking at like reports analytics. That is currently powered by replicash but it's starting to get to a size where it doesn't make sense.
Speaker 2:So that part of our app might still be a traditional server side thing. But it's okay because people aren't touching that every single day. That's something they look at every once The in a part of your app where people are using every single day, every single hour, that tends to be a small working set. So most things can can fit to this model.
Speaker 1:Yeah. Okay. So I have related thoughts on this. Like, as you're discussing all this stuff, it I realized that, like, these topics have kinda fallen out of favor or they're just not talked about as much because of all the RSC stuff and, like, ASTRO and, like, every it's like the trend is moving server side. And I feel like talking about how to make a SPA better feels it for some reason, so off topic, which is dumb because there are plenty of applications that should be built as a spa.
Speaker 1:And you could say for the last ten years, people defaulted to building spas when they shouldn't have, and now there's backlash for that. Like, things that should have been websites were built as spas. I'm headed somewhere with this, I think. Hang on. So that was the default.
Speaker 1:We have all these newcomers coming to the field, building spas with React that should have been a website. Like, it just shouldn't be client side rendered. And now we're shifting to this default world where everything is, like, multiple pages, not a SPA. Okay? And now you're gonna have people building what should be a SPA with those technologies.
Speaker 1:Yeah. So people should be using React and Replicash or whatever, SolidJS, whatever, to build their SPA. And instead, they're gonna use RSCs, we're gonna have the exact opposite problem we've had the last decade. Did I land did I land that? That makes sense.
Speaker 2:Yeah. No. That that that's exactly right. I think there is just there is just no global default, but people always operate as there is as there is. And I think what's sad about this one, I don't think people are gonna realize, like, least with the when you incorrectly use a SPA, it was so obvious that it was a bad choice because like, we've all used apps like it's it'll always be something like, you're like trying to book a flight and there's like a million spinners and like, it's just like, why is this It's like very obvious that it sucks.
Speaker 2:But I think in the reverse case, it's kind of like, it actually feels okay because you're used to it. So I don't think anyone is gonna think, oh, this is like a bad use of of RSCs or SSR because it's still gonna feel terrible, it's gonna be obviously terrible. Yeah. They're just gonna be a class of application that continues to be like magical and mysterious because people are like, oh, like how do they do that stuff and
Speaker 1:Yeah yeah. And that they're using the local stuff.
Speaker 2:Yeah. There's so few. Like, think of all applications I use, I think I always list them. It's Airtable, Linear and Superhuman are the three that I use that are like so clearly a million times better than any other app I use but nobody's copying them for some reason.
Speaker 1:Yeah. So why? Why is this why has this been slow to adopt? What's replicash's marketing problem?
Speaker 2:I have a funny theory that okay. This is gonna be see if I can get this out.
Speaker 1:Do better do better than I did. Sorry.
Speaker 2:I interrupted you. I think I said this before, and you might have heard me say this before, if you are someone that builds an e commerce website, and you're like a pro at building e commerce website, you're like one of the best people in the world that does this. Mhmm. How much can you possibly make doing that? Not a ton.
Speaker 2:There's definitely a ceiling there of how much money you can make just doing literally that job, right? Yeah. But you can make a ton of money by founding Vercel and making it so a bunch of other people can, you know, can can kind of have your skills without having put in as much work. Yeah. So like a Vercel for like the SSR world exists.
Speaker 2:Like there's a company focused on educating people and making people aware of this stuff and, having people build in this way. The flip side, if you're someone that's an expert at building these local first SPAs Mhmm. You're just gonna build linear and be a billionaire. You're not gonna go, like, go and spend your time, like, doing this other thing, right? So the fact that replicash even exists is a miracle.
Speaker 2:So, Aaron Budman is, like, is the founder of it and he made Grease Monkey. I don't know if he used Grease Monkey back in the day. Mm-mm. What what is it? It was like before Chrome extensions really existed, you can, like, inject JavaScript and override stuff.
Speaker 1:Oh, that does sound familiar.
Speaker 2:Yeah. I don't know if I ever really used it
Speaker 1:but I know what you're talking about
Speaker 2:now. And he eventually ended up working for Chrome and like building the Chrome extension stuff. And now he's working on this completely unrelated thing. It's like a miracle that someone is focused on this problem. Yeah.
Speaker 2:Because everyone else is an expert on this, has already, like, built a massive business that they're just, like they're not even on Twitter. Like, they're not even, like, talking at all because they're just, like, we're so successful and rich, we don't have to do we don't have to do anything.
Speaker 1:And you think the key to that is that they built these really amazing web apps, like that was their business's success?
Speaker 2:Yeah. Like, Linear entered a market that is the most, like, fragmented, saturated market in Like, the every engineer is like, I have an idea for our product management app. Like, that's like the default thing, right? Yeah. Yeah.
Speaker 2:They entered there and just killed it just through the quality of the thing they built. Like, compare like the status quo was Jira pretty much. Jira is like the slowest thing in the world. Yeah. Same thing with superhuman, like, what?
Speaker 2:You like aren't even an email provider? You're just like a layer on top of Gmail but all you do is make stuff faster, like, also also keep people are paying I'm paying, what, like $20 a month for it, which is like crazy.
Speaker 1:Powerful. I mean, this is like this idea that you could just come in and disrupt an industry by just having a really good product. What yeah. Why don't more people do that? Why are there so many bad products?
Speaker 1:I don't understand the holdup. Is it that hard to learn? You said there's some initial investment.
Speaker 2:No. It's just I just think it's not well understood. That's why I wanted to talk about it because I wanted to get people curious. I think more people need to be curious about this. We are so used to stuff that is slow that we don't even think twice.
Speaker 2:And once you start using these, like, magical products, you start to wonder why isn't everything like this? Like, I go to GitHub. Yeah. I use GitHub so much. I work on open source stuff.
Speaker 2:I'm always in there looking at issues, looking at PRs. Every time I click on something, there's a delay and a spinner and some productivity too. I'm in it all day. Like, I GitHub kid, maybe don't sync every repo in the world to my machine locally but sync the repos I'm working on actively locally, sync all the issues, sync all the pull requests. I should be able switch between them really quickly and they're starting to do this a little bit, like, new, like, directory explorer is like a little bit more in this direction, like, I'm seeing that be a lot faster.
Speaker 2:But yeah, like, anything that is a b to b tool, a productivity tool, anywhere that working set is small, like, this should really be the default. Yeah. It should not be SSR, RSCs, any of that stuff. It should really be do a ton on the client. And that's why people love native apps.
Speaker 2:Right? Native apps do a lot in the client.
Speaker 1:Right. So can we do like, can we speak about this in, like like, how people would be like Uber but for groceries? Can we be like, Linear but for GitHub?
Speaker 2:Yeah. Exactly. I've I've seen people do this already, actually.
Speaker 1:Oh, like, communicate it in that way? Like
Speaker 2:I think this this there's something. I think actually it's from someone that used to work with Linear, it makes sense. I forgot what I forgot what it was. I think it's a note taking tool or something.
Speaker 1:Yeah. I mean, just like, could someone build GitHub but build a better web app and actually make a dent?
Speaker 2:Oh, yeah. Like a different interface to GitHub. That actually, okay. So here's the thing, replicash needs, like, very strong control of the server. So you can't do it externally, unfortunately, but
Speaker 1:Wait, what? I didn't even understand that sentence. Do what externally?
Speaker 2:Well, I meant, like, I couldn't build a better front end for GitHub without coordination from GitHub. Oh, I
Speaker 1:meant build a new GitHub. Like, could somebody actually disrupt
Speaker 2:I think they're like too big to disrupt. Okay. So there's limits. There there are other things in my way.
Speaker 1:I'm learning the rules here.
Speaker 2:But it's like, there's just stuff that we use every day and we don't think about. Sometimes, some I sign up for some these developer tools like, some of these SaaS products. There's the working set of data is so small. They have a concept like a project and it might have like some configuration like, why are there any loaders at all? Yeah.
Speaker 2:Even something like, say something like cal.com, right? The part where you're managing your own settings, your own configuration, the working set is literally just your own configuration. I bet that's like less that's probably a tiny amount of data that should always be synced synced locally, so Yeah. It's a great thing to explore like, I almost think of it like, if I am building something that is not public facing, it's like you need to sign up for, it's behind a login wall, my default is gonna be this until my working set outgrows then I'll like, you know, refactor that out to be server powered.
Speaker 1:So do you have any open source repos that you've built like or any of your apps that you've built with this open source where I can look at it and steal your code?
Speaker 2:Yeah. So the new ST console which is just at our GitHub slash console, is built with replicash. Perf. Yeah. Like I said, it's I built a little bit of a layer on top to get like some of the type safety stuff I like.
Speaker 2:I'd love to like have some nicer patterns emerge out of this and once they do, I might like package that up into its own library.
Speaker 1:Okay. I'm just going to look now. I'm I'm con I'm sold. Like, I'm I'm sold. I'm gonna build apps this way.
Speaker 1:Right after I get done building a Laravel app, I'll build one like this. While you laugh.
Speaker 2:Alright. I mean
Speaker 1:I I wasn't joking.
Speaker 2:You know, I know you're not joking. The level I take you seriously though It's not that
Speaker 1:I'm joking, it's that I just I'm flaky.
Speaker 2:Believe you think you're serious. Yes.
Speaker 1:Okay. We should end this episode. This has been good.
Speaker 2:Cool. See you. Alright. See you.
