 All right, I'm going to be rolling my sleeves up and writing code all day. And I was shocked to see that like most of my time was spent in user studies. Historically, we've been designing and developing sites where you load everything you want to go. But that doesn't seem to make much sense. One of the challenges for designers and developers with PWAs is like, Google's been pushing that this is a great way to make your site behave like an app-like way. There's lots of APIs that you can access, like for mobile devices especially. But it's really hard to do it. The entry barrier is really high. And I know Firebase is working on ways to mitigate that and making the entry really low and easy to use. How is Firebase doing that? Like how you said, there's these app-like things. And so you kind of think, okay, well, what do people expect with apps? You usually see things that are 60 frames per second or things that just feel very instant and just like you tap it and it's there, data updates. And like with Firestore is this database where you just update one thing and then almost immediately you see that other device just update and went through the cloud and everything. And whenever one change happens, it just synchronizes across all these connected devices. And that is one of those things that gives you this app-like sort of element that you see things change immediately, that your data is sort of ubiquitous across all your devices. And also with apps, you expect them to just work offline. Yeah. And if you install an app, just for the most part, it's all there. And Firestore does the same thing. Whenever you make a change, it will actually save it locally. So when you go offline, I built a camera PWA. And I was really trying to find these instances where like, what's something that I can build that works the same offline that it does online? And if I'm just doing it online, I see changes across. So like a note-taking app, but with the camera app, use the web, user media API, built a little camera, take pictures, and then it saves it and this photo feed. And the cool thing is, is like, I'll go on an airplane, I can take pictures, it'll keep it on the local device. And then once I get over the network, just start syncing. And that wasn't something that like, I didn't have to install my own database on a server or like locally or set up, you know, all this talking to index DB and all this stuff. And it's just like, I just use the Firebase library and I just sort of get these features out of the box and it kind of just get rolling. And I get to care about building my app and not caring about like, how does offline work? How does this data connection work? I get to kind of focus the things that I would rather be doing. So in terms of like using it, I mean, one of the like, one thing I've been speaking about was like, say Alex Russell, was like, tall adoption is all about ease for the developer or the designer. Like, so the WordPress was like the one install made it. Five minute install. Yeah, like, even though I mean, and it's like fashionable to hate PHP and WordPress and whatever, but it's designed as a tool for someone to use and get off the ground just to do the job they want to do without installing a hundred different libraries. It was really good at that. I mean, I mean, Firebase presumably is following that same kind of philosophy. It's just really simple to sell. I mean, from like the, I've been working on Firebase just like, like two weeks ago, it was like my fourth year on Firebase. And like, even my first week there, we spent the, we were actually trying to launch Firebase hosting. And we like, all I did was spend all this time in user study meetings. And like, I joined this company we're building real-time database and JavaScript libraries. And I thought like, all right, I'm going to be rolling my sleeves up and writing code all day. And I was shocked to see that like, most of my time was spent in user studies. And I would just sit in like that double pane style window. I mean, not literally, but it felt like that because you would look at the user and they would just be struggling trying to get something set up that you knew exactly what they needed to do next. You're like, click that, click that button. Just please click that button. And they look at you and they're like, what do I do? And you're like, I can't help you. And so watching users not get it and shows that it's a reflection on you. And so we've been focusing from the very start. Like if you can't just get up and running in five minutes, it's not going to work. And so like the whole point we always saw is like we sort of paint this picture of what we want to achieve. So in the beginning was let's drop this JavaScript library and now we have this real-time connected app and you didn't have to set anything up. And now then we evolved onto authentication. And it was like, okay, I want to be able to log in users with Google, with email password and all these different types of providers. And I want to run a server. I'll also drop in a JavaScript library and now you have that. And then with hosting, it was the same thing. Like how fast can we get that site from like not existing on the internet to deployed with SSL on a CDN? Like just like by default just has a fast performance. So all those things are just sort of like in our blood and it's just always been our number one like guiding principle is like low barrier to entry get started in five minutes and just go. So say like I wanted to, I'm a web designer who's not very technical and I just wanted to get my site up like a custom domain. I bought my, I don't know, davidshop.com or whatever. How quickly can I get that web, you're all that custom domain and my server up together? Well, I actually own davidea.st. I was very proud of that one. And so like, yeah, so like with Firebase Hosting, if you like, it doesn't matter who your domain provider is, if you with Google Domains is really easy because we, you know, have worked with them, but pretty much you deploy out your site with Firebase Hosting and you get, you know, whatever your project name is dot Firebase app.com. And that's like SSL out of the box. Like, you know, you have your green lock automatically. And then we have a sort of like web UI where you say like, okay, I want to set up a custom domain. And pretty much we say, okay, you have to put these records into your domain registry and then you click this button and we'll check to see if they exist. And when they do, that's it, your domain needs just set up that fast. That's amazing. I mean, there is some critique of Firebase though. And a lot of it is to do with speed because it's like we always push use vanilla JavaScript, go like the basic minimum, get something painted on screen as quickly as possible below three seconds. And there's critique there. The Firebase include is quite large. So it's almost like there's two conflicting things from our point of view. And what can developers do to solve that problem? And what does Firebase do to? Well, I think like the web is, it's kind of like this weird point where like we're trying to do like so much with the web. Like you're saying, like we want it to be more app like. Well, with apps, they have this, they can include a 50 megabyte library that goes through and install time. And it's just like, you know, it goes over Wi-Fi, I know, sweat off someone's back. But the web like that's unacceptable. Like, you know, you could never have 50 megabytes of anything on the web. And so we're in this battle of how do we get more features but yet not lose this foundational principle we have of being like fast loading. And so like what I've been doing is like kind of thinking about, okay, well, what is the first thing you have to do to load? So you always need, you know, this like really minimal viable part of your app. And so like the Firestore library is, you know, it is a larger library because it does so much. It's basically like your own little database and the browser. And even for a database, it's still I would say really small. But yeah, it does a lot. But you don't want that, if you're like, you're serving content to users, you don't want that library sitting in your critical path. You can render HTML on the server, send that down, and you just have HTML, CSS, and this really minimal layer of like JavaScript to do your like rendering. And then what I've found is, is that when you run sort of Firestore in this way where it becomes an enhancement on top of that app, then when it loads, the real time kicks in, the offline kicks in. And if with this architecting with your app, your user continues to use it and then as they continue to use it, just get that enhancement to it. And you don't want to say, okay, my app is only available once every single asset I have is needed for it. You have to have those like progressive bootstrapping of your app if you're going to combine like having features on the web and also being performant. I mean, I know you're working on like an architectural concept where you're splitting things into three. Could you explain a bit more like that because there's an app that you're working on? I thought I was coming up with my own thing, but it's kind of like, if you think that you've done it, you just have to go see if Adi Osmani has done it first, which he has. He even has a word for it. So like progressive bootstrapping is sort of the way to think of it. So like the very minimal thing you need for your app is just HTML and CSS. Like that will get you really far. And then a having a JavaScript like sort of like layer on top of it where they're using a framework like React, Preact, you know, Angular, whatever, that can just be an enhancement on top of the HTML and CSS. And at that point, you have this app that can function every time it receives data. So something comes over the network, the view changes, or user interacts with it, something in the app, it becomes more dynamic. And it doesn't really matter where the data comes from. The app can be fairly like agnostic of that. So if you architect it in a way where if you just progressively load Firestore into it, when Firestore is ready to be loaded, these features just, you know, they just kind of like trickle in. And then the user just now all set and might see things animate on the page when they like appear in real time. Then when they're like, they go offline, that data is then cached on the device. Like quite often, I mean, historically, we've been designing and developing sites where you load everything you want to go. But that doesn't seem to make much sense. So it's what you're advocating that you're only calling for features as and when they're needed. So you're not loading the whole database if it's not required. You're not loading the notification bit if it's not necessarily in that particular point. I mean, and code splitting in some ways works really well for that. You're basically saying like, okay, if you divvy your app up into separate routes, like I don't want to load my slash profile code on my home page. Like it doesn't make sense. Like it's, you know, I can have a performance game by just not including that when it's not needed. This is more so of a way where you're saying, like I will need Firestore, but I don't need it immediately. And if including like this JavaScript in my run, my critical path is going to cause the app to take longer to load, then let's find a way to sort of ease it up. So we kind of, we progressively give the browser what it can handle. So let's start out with HTML and CSS. That appears. And then we have our like our, our JavaScript that enhances it. So it becomes very easing. And so we do intend on having all these things, but if something happens, the user's not running JavaScript. Okay, that's fine. We still have content for them. Or let's say they're on a really slow connection. Well, we did get the initial content and then we also got the JavaScript framework, but it's going to take longer for Firestore to load. And maybe that times out and that never loads. But the app still is usable in each one of these forms. And so we aspire to get all three of these on the page, but we sort of have these like escape patches where if, as long as we get to one of these points, we're going to be okay. Wait, okay, you know, there's a heartbeat. I think there's a whistle. It might be someone just using their lawnmower. Yeah.