3 – Geoffrey Litt Malleable Software, Local State Management & Riffle

Speaker 1
And sort of the, I guess, the origin story of Riffle is that Nicholas and I were having a bunch of conversations that revolved around sort of this idea of having a personal data store. So one way I think about cloud versus local first is that in local first software, one of the ideals is that you own your data and these valuable thoughts that I’m having and artifacts That I’m producing in the digital world, they should feel like mine, just like a notebook I can carry around and, you know, have with me forever, right? And there’s this question of, great, if you own your data, sure, you get longevity and control, but what about this ability to take arbitrary tools that I want to use and connect them To that personal data? This is something that’s often really hard in SAS because the data is locked away and maybe there’s the APIs you want and maybe there’s not and maybe there’s the partnership you want Between the two tools you use, but maybe not. And we were talking about, you know, how would it feel if you had a local first data store with all your stuff in it and you could connect whatever app or tool you wanted to that existing Data store that has all your stuff, right? What shape would that data store take? How would it work?

Speaker 1
Yeah. So one way that I think about this is exactly the way you put it about the difference between ideology and technical foundations. I think that data ownership, one of the reasons we don’t have it is because it’s hard to build apps that way. It’s not, I think there are often companies that don’t really have a strong desire to build a SAS data moat. It’s just as kind of the default that is promoted by the way we naturally build stuff. And because it’s so hard to build apps with data ownership, we don’t get that many of them. And one of the, I think, most interesting

Speaker 1
It’s not, I think there are often companies that don’t really have a strong desire to build a SAS data moat. It’s just as kind of the default that is promoted by the way we naturally build stuff. And because it’s so hard to build apps with data ownership, we don’t get that many of them. And one of the, I think, most interesting potentials of local first as an area that I don’t think has been fully realized yet is what if we could make it easier to build apps this way rather Than harder? I think a lot of people in this space see that potential for this radical simplification of how we build stuff. I think Peter, who was on the show, I see, has sort of inspired a

Speaker 1
The reality is for many people, these are not the most pressing concerns. What if we started instead from, hey, isn’t it really complicated to build web apps? What if it was just way simpler to build an awesome app that was fast, that was really responsive, that stored all the data people care about was easier for you to develop faster, simpler, Less ops maintenance stuff,

Speaker 1
And in service of that mission, a few of our starting principles were, can you think of an application as one giant database query? What I mean by that is, instead of writing a ton of normal code that produces your UI, could you somehow push a lot of the work into a optimized database that does a lot of heavy lifting and Let it produce UI states for you. Another thing that couples really well with that is fast synchronous reactivity. So we had this idea that the data is already there on your device. Throw away all the async crap that comes with web apps typically, you know, reacts to spend, network requests and work with the data that’s already there and simplify just talking to It and querying it. And the last thing our third principle was, can we take all these different kinds of state that typically end up in different systems and throw them in one. So your react UI state and your persistent local device local state and your synchronized multi-user state, can you just store them in one system and then, you know, we like to think Of it as maybe there’s some setting checkboxes on each bit of state that tell you should you share it or whatever, but just have one system that’s capable of subsuming all those roles. And our hypothesis was that if you pulled all this off, it could feel really awesome to build apps and you would get both better apps for end users because they’re fast and they work offline And they have all the local first goodness. But also you could get a better developer experience because you’ve removed a lot of the layers of traditional web apps.

Speaker 2
And a music client is not nobody talks about Oh, this is the best music backend. People want a best music app. And that has led me to become the first design customer to say first design partner for riffle. And that made a brilliant combination, I think.
Speaker 1
Yeah, I think one alignment and values that has really helped here is that you’re trying to build a music app for power users, right? And I think power users often care about things like data density, latency. You know, it’s funny when you look at apps like Spotify, for example, and we’ve we talked about this many times over the course, this collaboration, Spotify, their desktop app is quite Slow often. And also quite network reliant to a surprising degree. Many page transitions that we’ve encountered, even for data that is already locally cached, for some reason has a lot of network access going on. And you often get multi second loading screens. And I think for serious music, people like DJ is, you know, some of your target audience for over tone. I think of it a bit the same way that serious email people like apps like Superhuman that respect their time and make them really fast at email. A serious music fan wants an app that feels good. And not some, you know, loading screen filled consumer feeling app, right? And I think that was really aligned with some of the goals that we wanted to hit with the riffle approach is basically, can you just throw all the music metadata in a SQLite database, use Relational queries, which

Speaker 1
And we really are interested particularly in the intersection of the local first architecture and the Malleable Software Agenda. And we have a lot of ideas for how those two things can be kind of complementary to each other as I described earlier.