Brian: PodRocket is sponsored by LogRocket, a front-end monitoring and product analytics solution. Don't know what that is? Go to logrocket.com. Thanks. Kate: Hi, David. How's it going? David East: Good. Is this the part where I introduce myself? Kate: Yeah. Please introduce yourself. David East: My name is David East. I'm a developer advocate at Firebase. As of April, I will have been doing the job for seven years. Actually, I think my job title changed recently. I'm a developer relations engineer. I think I've had four different job titles since doing this job. But the job has fundamentally stayed mostly the same despite the title. It shifts, but I work on Firebase. That's what I do. Ben: Seven years. Wow. Were you there before Google acquired Firebase? Or did you join after? I forget how many years ago that happened. David East: I was there six months before acquisition. I joined when ... I was number 16. It was really, really small. They had just moved into ... I think it was the third office, the day I interviewed. It was half of a floor of this really big building in Selma. I just remember, they had had a party the previous night. David East: And they graffitied this wall. They had really talented people doing it. And so, it was really cool looking. But before I showed up, there was 15 people there and it was just empty. I just remember being like, "Wow. This is a lot of space for not a lot of people." They were like, "I know, right? Our last one was like a closet." Ben: That's awesome. You must have really seen a lot in those seven years. It's been cool to watch it from the outskirts and, as someone who has built lots of projects on Firebase, to see how the suite of tools has evolved over the years from ... I think it started with just the real-time database. And then, it's now evolved to everything you need to build a web app. David East: Yeah. The two startup co-founders were James Tamplin and Andrew Lee, they were building a chat widget called, "Envolve," with an E like evolve. Envolve. It was really, really popular on celebrities' websites. This is early 2010s. And so, you would include this widget on the site, and then all the fans could chat with them. That's all you would do. The thing was really fast in real-time. David East: What they found out a lot of their customers were doing was, they would include their widget and then they would disable the view of it. They would just listen for new chat messages, but they weren't sending messages. They were sending JSON. And so, they were listening for them, and then actually synchronizing game state and actually powering real-time apps with it. They realized that, "Oh. This is what we need to do." And so, they pivoted it into Firebase. Ben: Very cool. It seems like beyond just the database now ... I'm just on the Firebase site. In addition to the build, the site divides into three tiers of product. There's Build, Release, and Monitor, Engage. I imagine most people are probably familiar to an extent with Build. There's the database, authentication, I think, is put in that build tier. And storage. Ben: Now, it seems like Firebase has been ingested to an extent into Google Cloud. And so, you have the full suite of Google Cloud tools. I'm curious to learn a bit about Release and Monitor and Engage, because that's a new functionality that I'm not as familiar with. I've never used that. Maybe you could speak a bit to what that side of the tool does and what the vision is there? David East: I can definitely speak to a lot of that. Specifically, my job function is all within Build. I do know a lot about the Release and Engage and app quality and stuff like that. I know more than most people who don't know anything would, but I'm not ... Just as a disclaimer, I would not consider myself an expert in those pillars. Especially, from the experts I know. I'm an expert through osmosis. David East: And so, this isn't our official tagline, but I like to use this. There is a lot of times we have the whole developer-designer dichotomy of, there's design handoff and there are reviews. There's a lot of that. I think that this isn't as prevalent for ... I feel like most developers are going to have that handoff with designers, but not every developer has this with marketing. David East: And so, marketing is super important when you're trying to build an app or a successful business or A/B testing pages. It's not just running ads somewhere, or just setting up content streams and all this stuff. Marketing can be very product-oriented in the sense of, how do we have great onboarding? How do we increase conversion rates and RPU? All the crazy stats that they have out there. David East: And so, the Release and Engage parts. Release is more so stability side of things. Engage is really like, how do I know that customers aren't completely churning at these steps? How do I know that the sign in button is not really working? They're not seeing it. And so, we have a product called Predictions, where you just include the STK in your app. It's just for Android and iOS. David East: The way it works is, it starts collecting data, and then it starts servicing data to you about users' behavior. It's able to tell you, "Hey. This user, they really like your app. And they like to spend in these ways." If you give them discounts, that'll be good for both of you. Because they want to spend on your app, and you want them to. Make it easy for them to do that. Give them a discount or something like that. They give you signals. David East: Or like, "Hey. This person, they don't like this. They hate all of this. They don't like all the ad interstitials. Maybe turn those off." Or "This level's too hard. Maybe decrease spawn rates." Or something like that. It doesn't get that specific where it's like, "Hey, decrease spawn rates." But it shows you, "Hey. This isn't working well over here." David East: And then, you take that inference of, "Oh, I bet you that level is too hard." Or, "I bet you our signup flow asks for way too much. That's really it. A lot of that is that handoff between developers and marketers. Where, I'm not a marketer, but I've worked a lot of really great ones. And I want to be a better designer. And so, when I learned design, I learned how much I don't know. David East: Since I don't know anything about marketing, I can only imagine all the things I don't know. And then, same with business development. And so, having a software developer to be able to implement the tools and implement the processes, but having someone who's really good with business development or product strategy or marketing on that other side ... That's really a big part of the Engage tools. Ben: I'm curious. Does that predictions tool integrate with the A/B testing functionality? Can it help you understand why one A/B testing variant that you're running might work better than another? Is that functionality on the road map? David East: I am not aware off the top of my head if predictions and A/B testing ... One of the things we do is, we have integrations like Remote Config. I call it our key value store with super powers. It conditionally serves things. You can hook it up to any analytics provider. But we have really seamless integration with Google Analytics. And so, you can see, "Hey, if this user comes from this area, do this. Or if this thing happens, do that." David East: We call them user properties. You can tag users with user properties like "Super User," or, "Hates Ads." Or stuff like that. And then, that way Remote Config can sense that and serve something else up. And so, Remote Config has a key, and then it doesn't necessarily have a value, but it has parameters. And then, parameters have conditions. And then, you can have different values based upon those conditions. David East: And so, that really started out with a lot of people who did that to ... It was really common for native app developers, Android and iOS, to not have to republish because there was a typo on a page or something. They were like, "Oh, let's just update that in Remote Config." Or we'll just re-theme, restore the theme of the app, so we don't have to resubmit for app review. David East: And then, It's really evolved into people really doing it for, like I was saying, business development and with A/B testing. Seeing how successful things are. Now, feature flagging is another really big part of that as well. Ben: I'm curious. On the build side, which you mentioned is where a lot of the time you focus on, what is the pitch in 2021? In an increasingly crowded landscape of tools designed to make it easy to launch full stack web applications with all of the primitives you need, like storage and database and auth and functions ... What's the pitch? Why go with Firebase today? What does Firebase do best? Or what type of apps is it best suited for? David East: The pitch is lot similar than it was even back when I started in 2014. We were always very big on the five-minute getting started experience. We were like, "Hey, can someone, when they get on this page, can they go through our steps and have that moment of wow?" When you saw the data changing and flickering between our console and our dashboard and then within your web app. David East: And so, once you saw that connection, people were like, "Wow, that is really cool." And then, people really start feeling the magic, and start thinking of all the things they can do. That permeates through a lot of our services, because we're like, "Okay. We want to be able to get people going fast." David East: And then, what we did over time to build upon that, is a lot of people would be like, "Oh, I want to use Firebase. It'd be so great for a prototype. But as soon as I need to do something serious, I'll need to go lift it and shift. Or I'll have to get Super Systems architect-y on myself." David East: We were like, well, how do we make that easier so that your prototype code isn't actually throw away. That you're building to get on it. We've had really crazy cool stories of really large companies who have difficult release processes. And so, they're like, "Oh, to spin-up this system, it's going to take like a handful of head count in this many weeks or months even. And then, go through this release process." David East: And so, a lot of times they'll come to us because they're like, "We have to build this thing for this event." There's a big sports game or a big cultural event going on and we have to have it done. This has a really big impact for us, so we're going to use you to build all of this. And then, we'll finish it in two weeks. David East: It scales, it's fast, and it did a bunch of things that we didn't have to build ourselves, and then, therefore maintain these systems ourselves years going on afterwards. That's really been the pitch, is that you can just build really fast. And then, you don't have to worry about the actual scale of traffic and everything hitting your app. Ben: One of the products we've talked about in the past on the podcast is Supabase, which is pitching themselves as an open source version of Firebase building on open source tools for each part of the application stack. I'm curious, is open source at all part of Firebase's future roadmap or plans? Or how you coach developers thinking around whether or not they need to go with an open source tool to build their app on? David East: Our hosted services themselves, yes, our database and stuff are proprietary. But we try to open source as much as our tooling as we possibly can. This has been a big debate since early days. We had lots of people in the early Firebase days ask, "Hey, can we just get something on premise?" It wasn't so much ... In the early days, the problem wasn't like, oh, if we give them on premise ... A lot of people are offering us up a lot of money in the early days to do that. David East: But the maintenance for that early on was just going to be crazy to be like, "Oh, what version is it on, on your machine?" To provide support. When it was 16 of us, that was just unreal. We always wanted to provide open sourcing for our tooling ... I want to say all of our SDKs, I know all of our web SDKs now are open source. Most if not all of our Android and iOS SDKs are open source. David East: You can go to ... We have a huge GitHub presence. My setup as a Googler is different than most people's set up. Most people work within Google 3, our internal system. I don't. I just work purely within GitHub every single day. Anytime I have to do something in Google 3, I only have to go to a cheat sheet and, "How does this work?" And map it to whatever I do in Git. I work purely in open source. David East: We have a whole emulator suite that allows you to run real-time database, authentication, Firestore, cloud functions, Pub/Sub. I feel like I'm missing one too. And so, you run all these things locally and you just run it through our CLI tool, which is also open source. And the emulators themselves are open source. You can see a lot of what we're doing in there. Also, the STKs themselves aren't just little REST APIs. David East: Our wrappers, our Firestore, and real-time database SDKs are incredibly complex. Cloud Firestore can do offline persistence. If yours goes offline, the app can continue working as it would be online. You don't actually have to write conditional code for that being, "IF online, do these operations. ELSE, do this." It all just works behind the scenes. David East: It does a fancy term called latency compensation, which effectively raises events locally first. Everything feels really snappy, even if your connection starts dropping. There's so much you can read and see within these open source SDKs that is extremely complicated. It's not just we put out, "Oh, yes. See how we wrapped the Fetch API? It was really cool." No. There's a lot of complexity that we have that's all open source. Kate: David, I'm curious about ... We touched on it a little bit at the beginning, but I'm curious your thoughts on development and design. I know we talked a little bit about this in the pre-interview, but I'm just curious. What are your initial thoughts on it? David East: I think it's super cool. A lot of my colleagues and I talk about this a lot. I think it's really interesting nowadays that ... Interesting is actually such ... I don't want to say interesting. Because sometimes people say, "That's really interesting," and what they really mean is, "That's not interesting. That's actually annoying." I want to use the right words here. David East: I really do think it's interesting. I find it awesome how, when I first started developing, I really was awed by people who created such amazing designs. I remember seeing like parallax effects when they first came out. Scrolling through pages and just being mind blown like, "What is going on?" And then, when you see a really well-designed page, you're just like, "That is awesome." David East: I couldn't do it for the life of me. I remember working with people and there was always this argument of, "Can design be taught? Or do you just have to have it?" Part of me just wondered ... Maybe you just do have to have it? What I like about nowadays is that, so many tools out there exist that introduce you to design. David East: The first one that really was prevalent for me was Sketch. I used to try to do things in Photoshop, and I was just like, "I have no idea what I'm doing. I'm hurting myself." It was all painful for me. It was too much. But then when I did things in Sketch, it just came naturally. It introduced me to the world of design in a way where I could just iterate and iterate, until I found something that looked right. And then, when I started taking design courses, which so much more nowadays exist, I learned that's actually ... Most of design is just iterating until you get it right. David East: And so, what I think is really interesting now is that, as a front-end developer, I don't really feel like there's any of those questions anymore of, "Hey, can design be learned? Can it be taught?" It's like, no, you can do this. And then, we have all these amazing tools that expose us to these environments unlike ever before. It's across all pages. David East: In terms of Firebase, you could be a designer and you can say, "You know what? I'm going to learn some code. I'm going to build an app." Write the actual code, connect to some system, and then you're exposed to Firebase and you're writing Node on cloud functions. Before you know it, in five years, you're a back-end developer somewhere, because you didn't have to worry about all this stuff that it took to get started, which used to be the case five years ago, 10 years ago. David East: It's not like you need a degree, but it's ... You got to read the thick manual, and then, "Hello, world," works. I think it's amazing that we just have all of this exposure to learn these things nowadays. Kate: You mentioned having to read the manual. There is an argument, the purists out there would say there is steps to go, to get to building an app. Do you see that side? David East: I think it's just one of those things where context is everything, because I think there is ... I don't agree with that at heart, but I always am like that in practice. I don't think that you have to learn everything. You can cowboy it and just go in. And then, there's so much to take away from that. I've done that before. David East: But I'm the type of person that, when I go through a course, I literally bring out a composition notebook and I write almost everything that's being said. A lot of that is just because it's the only way my brain will remember it. Because I don't actually go back and look at those pages afterwards. Kate: Right. David East: I do go through everything meticulously, because I'm afraid of missing things. But I don't think it's necessary. I do think that, if you feel inspired or you feel just motivated to get your hands on the keyboard, and turning your keystrokes into pixels into experiences ... It's also an extremely amazing way to go. David East: I think that you should just do what is working for you. Because we all, as humans, learn and experience things so differently. Don't get dissuaded because someone's like, "I'm sorry, you didn't read the whole manual." Or, "You don't have any degree on this." No, if it's working for you, just keep going. Sometimes I'll be midway through writing all this stuff out, and I'm like, "Ah. I haven't written any code in four days on this subject." Because I'm just writing words. Kate: There's a meme that was going around Twitter, and it's the kid stepping over the stairs. I don't know if you've seen it. But it's like, the first stair is JavaScript. And then, the next one was ... I forgot. And then, it's React, and he's just stepping over the first two onto React. David East: Oh, I did see that one. I don't always feel like that's totally the truth though, because I saw a lot of people had reactions to that. I learned a lot of back-end code first. In school, we all wrote Java. Actually, I spent most of my time writing this in this programming language called Ada, which is not very commonly used. It was super used by the Department of Defense, back in the day, as a programming language that had popularity, because it won a contest by the Department of Defense. David East: They had something like 300 programming languages being used internally, and they were like, "This ends now. We need one." And so, they held a contest and Ada won. I think it's still used by a lot of mission critical systems. And so, I didn't write a lot of JavaScript until almost my senior year. And then, when I got into my internships and into my full-time job, the way I got anything done was with jQuery. I learned so much through jQuery. David East: And then, I was like, "I feel like just calling slideUp() is probably hiding a lot. And I probably could really make this bad." And so, I'd look, well, how do you write this slideUp() functionality? And so, I learned a ton from jQuery, not even just going through the source, because I don't think I ever did that to a huge degree. But just by asking myself, well, what am I getting out of this? David East: I think React does that so much. And I think that also ... frontend frameworks have really taught us how to think about state management, which is not something that a lot of people really thought about before. Because when you have a full page refresh in traditional web app development, you don't even have to worry about state management. But I don't even think when you started that term was even prevalent. David East: And they're like, "Things just aren't consistent." Or like, "This says four over here, and it should say seven." You didn't know why. I think the term state management ... You're like, "Oh, okay. Yeah, that's the one we'll go with." I don't know. I think that you can skip around as much as you want, as long as you're asking yourself the questions of like, "What does this provide me? What am I getting at?" Appreciate what it's doing for you. Kate: I'd be curious ... What do you think the future will look like if frontend and design maybe blend together more with who handles middleware, who handles back-end? What are your thoughts on that? David East: I feel like it's going to happen in a different approach than we realize, because I think everyone's waiting for the Figma Sketch export to React components. And then, somehow it's all magic ... And then, I can wire up the interactions. Framer is a really cool example of this. It's the no-code or low-code approach. I think that those tools, there is a lot of feature in them. David East: But I also feel like they're always going to be additive or they're going to augment the way that you write. Maybe get you started or maybe control a lot of presentational components. But I see, basically, however those tools come together, you're going to have people who are more so on, "Oh. Let me make sure this is the right HSL color. Let me make sure that this has enough spacing and it's aligned properly." David East: That designer is also going to be like, "I think I can just write the CSS for that." Because these tools are spitting the CSS to me over and over again. And I actually understand Flexbox, because all these tools follow Flexbox behind the scenes. As I start to write the syntax, I start realizing that I know these things. David East: And I feel like it's the same thing for developers. They're going to be like, "You know what? These design tools are really telling me to space out this stuff. I feel like my UI is a little too scrunched in, so I should have consistent spacing." That's one of the big faux pas that people who are learning design start seeing, is they have inconsistent spacing throughout their whole apps. David East: TailwindCSS is a really great example of this. And I think a lot of people like Tailwind, not because they get to stay in their HTML file, which is very cool ... But I think a lot of people like that they have these atomic units of design in there. It's like I have the spacing scale for my RAMs that go up. And then, also I have a way for things to shrink down properly and everything's consistent. David East: And so, as long as I'm using Tailwind spacing units ... For the most part, you still have to have a good eye for it. But for the most part, things are going to click into place. I think that's what Tailwind gives a lot of people. This sense they had about design and consistency materializes in these little units. That's another great example of a tool that I think is helping developers become designers, the same way that like Figma has helped designers become developers. Kate: It's actually interesting. One of our developers was on a podcast a couple of weeks ago, and he was talking about ... It's called, "Different Flavors of Front-end." He wears the design hat at LogRocket. Or did for the first little bit. And then, he was also a front-end engineer. Kate: I think that's interesting. I'd be curious for your thoughts on the article from Chris Coyier, The Great Divide. I don't know if you've seen it, but- David East: Yes. It's a great article. Kate: ... It's like two front-end developers walk into a bar, and they don't have anything to say to each other. David East: No, this is really true. I've worked in this capacity before, where I worked on the Firestore console, as we call it. The data viewer in our Fire-based dashboard. And it's a really complicated piece of front-end, because it has to visualize and have you interact and edit all of this data that can be updating in real-time. And then, we have to give you visual indications of that. You can be able to scroll through things and search and find things. David East: A lot of the bottle-necking really hard problems of front-end development were really shown there. And so, it was a really challenging, but really fun project. I worked with a bunch of engineers who were really, really good on that. It was interesting how we worked heavily on state management systems, on making sure ... I remember one day, I introduced code that one of our testers was like, "Hey. The data, only on this one thing, it takes like over a minute to load." David East: And I'm like, "Well, that can't be the case." Because I load it up on mine, and it didn't take a minute. It turns out the way I was running animations was locking frames per row. And so, if you have less than a thousand, it didn't really add up. And then, it would get like exponentially larger after that, so it would lock up forever. I didn't know I could do that. David East: I learned a lot about animation doing that. But then also, I learned a ton about actual Bezier curves, of making sure it flickered in right. We worked with a lot of design teams that were like, "Okay. No. It's got to kind of pop in like this." And actually drawing out curves onto screens and looking at sizings of things, that was one project where I really learned about spacing. David East: There was just so much I learned, because I felt like I was writing virtual scroll lists to make sure data was good. And that ... You're not even worried about pixels when you're writing those things. Everything's very abstract in the UI for those. But then, you would get into the sprints where it was just all, "Okay. This has to be consistent." David East: I spent time doing both of those roles, and it was incredibly difficult to switch your brains from those perspectives. I felt like I was never good enough at either one. I don't know what it will look like in the future, but it is very true that there are ... Frontend engineering is truly just that. It's so much of an engineering role. Whether it is you're figuring out layouts in CSS, or whether you are figuring out a virtual scroll list. David East: It's just interesting. I've never experienced ... I used to work heavily on the back-end and things, at least in the apps I worked on then, felt very like, "Okay, this is how we spin-up an app." And on the frontend, I can almost feel paralyzed with all the choices I have. Kate: David, outside of this design, frontend paradigm along with Firebase ... Maybe what are you most excited about in web development in 2021? David East: I have two things. I'm going to go with the first one, because it feels less cliche. I'm really excited about JavaScript Modules, because they've been around for ... At least the idea and we've sort of used them within the context of webpack and Rollup and whatnot. But what I'm really excited is that, it feels like we're getting very good at them. In terms of the way we write our code, in terms of modules. David East: Because looking at the way we used to write our code for libraries, if you wanted to use jQuery, you would have to include jQuery's script. And then, it would be tacked onto window.jquery. And then, that was just sort of the way you consumed any library. And then, you had all these window imports to consume in some other script. David East: It was like, where is everything coming from? How many versions of jQuery am I including? What I like about JavaScript Modules moving forward is that we get to write our code in a very modular way. Actually, their native support is fantastic. I think it's like 92%, 95%. It's pretty much waiting on IE. David East: And so, you could use it natively in the browser. But actually, I'm less so excited about that, and more so about tree shaking from modules, and us getting smarter about the way we're writing our code. At least, in terms of library code to be consumed from developers. I've seen firsthand in a lot of libraries I've worked on, people realize, "Oh. Instead of just tacking it onto this class or onto this namespace, I can just write this individual function. And I can turn it into this like pipeline way." David East: And then, all of a sudden a library that was 100 kilobytes can drop down to 20, 15 even, depending on what you're using. Because we just sort of package everything together and then we say, "Well, here's the library. Everything's here." And then, now we're giving people the import-as-you-use approach. I've seen that light bulb moment happened for many people. It's really exciting, because it's a big win for web performance, a big win for developer experience across all libraries. That's one thing I'm excited about. Kate: Awesome. Well, David, it's been great to have you. Thanks for coming on PodRocket and we'll see you around. David East: Yeah. Thanks for having me. Brian: Thanks for listening. Please remember to like, subscribe. Email me if you want, even though none of you do. Go to logrocket.com and try it out. It's free to try, then it costs money. We'll see you next time. Thanks.