The rise of serverless fullstack with Brian LeRoux === Noel: [00:00:00] Hello, and welcome to PodRocket, a web development podcast brought to you by LogRocket. ~LogRocket provides, ~LogRocket provides AI first session replay and analytics that surface the UX and technical issues impacting user experiences. Understand where your users are struggling by trying it for free at LogRocket. com. I'm Noel and today we're joined by Brian LaRue, he's a co founder at begin. com. He's here to talk about a talk he gave recently called the rise of serverless full stack. Welcome to the show, Brian. How's it Brian: Thanks for having me. ~Good. Yeah. How are you doing?~ Noel: ~I'm good. I'm good. Or we're just, we're just back. Everyone's kind of coming, coming back, at least in the U S after long weekends and stuff. So we're, we're getting back in the swing of things here.~ ~Um, yeah,~ Brian: ~It's like a vacation for Canada too. It's kind of~ Noel: ~Yeah, yeah,~ Brian: ~American colleagues light off fireworks and do whatever it is you do. And we, we can just enjoy the silence up here.~ Noel: ~yeah. Yeah, exactly. I get it. I know my dog would appreciate a little bit more of that around the fourth It's always like it'll be over soon. My dude. Don't worry. It'll be fine. Um, Yeah, but your your talk is interesting I didn't I didn't like watch the talk but I read through the slides and I think i've got kind of an idea Of of what this covers, but I think this will give me a good kind of point to jump off and ask some questions um Yeah,~ Yeah, can you ~kind of~ kind of go over? ~You This is a big question, but~ some of the like big checkpoints, the phases of JavaScript, ~kind of ~the evolution that you see in the past ~20,~ 20 years, maybe starting in like the mid nineties up till today. Brian: Yeah. That's where I got started. I ~kind of ~accidentally was born at the right time for the web and,~ um,~ fell into it,~ uh,~ pretty early and at that time, In the late nineties, JavaScript really wasn't a thing. ~Um, ~it was created in 95 by Brendan Eich in 10 days, famously with no coffee. But, um, Noel: No [00:01:00] coffee. Yeah. Yeah. Brian: the answer he was drinking lots of Cokes. ~Um, ~but people didn't really write JavaScript then client side scripting was not really a thing. Thing, uh, it was generally maligned as possibly insecure and dangerous. And that was the case actually until the probably early mid noughts,~ uh, ~around 2005 or so when,~ uh,~ Google maps happened, suddenly JavaScript was a plausible thing to use in a business context, but before that, no one was really doing that. And it was ~very. Um, kind of, uh, ~considered a dangerous thing for non existent security reasons, but also,~ uh, ~the browser compatibility was really poor back then. And so ~we, ~we needed to rely on a lot of different techniques like polyfilling ~to, ~to get some kind of baseline working across browsers. So the early years ~were, ~were rough ~and, ~and they were largely rough. Frankly, because of Microsoft. So this isn't ~a, ~an editorialization. This is kind of true. The browser wars, when they started,~ uh, ~with,~ um, ~basically Netscape getting bought by AOL [00:02:00] and Microsoft releasing IE5,~ um, ~at that point,~ um, ~Microsoft had a real stranglehold on things and ~they, ~they didn't have a strong web culture. In fact, they ~kind of ~were belining it from the very beginning and ~they, ~they held it back. ~Uh, ~there was no updates to IE for years between IE five and six, I think it was like four years. And during that time, there was a lot of stagnation. And JavaScript really only got its feet going after we started to see things like Gmail happens and Firefox happens around 2005 or six. Firefox finally starts to get some real appreciable market share. Things like,~ uh,~ Dev tools became a thing. There's a thing called fire bug, believe it or not. We used to just throw darts, ~you know, ~like there was no console log. We would do alert debugging at that point. And ~it was, ~it was pretty rough. And so as soon as browsers started to pay attention to developers,~ um,~ Firefox was a breath of fresh air. And I'd say after that point, things really accelerated. We started to see huge growth,~ uh,~ in both browser engine [00:03:00] capabilities and frameworks that targeted them. Client side development was no longer a dirty word. ~Um, ~you would admit to people that you knew and wrote JavaScript and you wouldn't be ashamed of it. ~And like, ~and by 2008 it became cool. And that's,~ uh,~ where the modern era really kicked off. Noel: You know, maps as a kind of inflection point in your slides. This, this like slightly predates me, at least definitely ~like~ being in the dev world, I don't remember it just like as a, whatever I would have been a 16 year old at the time, ~like~ really feeling like maps, ~like~ totally blew my mind. I remember it ~like~ being around me, like, this is kind of cool, but I guess you having been there ~kind of, you know, ~Having a little bit more,~ uh,~ perspective,~ did you, was, was it, ~was it more ~kind of ~astonishing for those that kind of technically realize what was happening? Brian: We had a thing called MapQuest and,~ uh,~ I'm going to really show my Canadian now, but,~ uh,~ there was the BlackBerry phones. Back then,~ uh,~ had GPS and had a, of something similar to what you would consider maps, but the user experience was terrible. ~Um, ~it was usually geo locked. And so you'd have ~like ~a page and it'd be like, here's [00:04:00] your map at this resolution for that place. But there was no scrolling or zooming or directions were not a thing. ~Um, ~or if they were a thing, you'd print them off and you'd get Noel: Yeah, I remember those step by step. ~Yeah. ~Like print off the map quest list. Yep. Brian: was profound and it was client side. ~And that was the, the, ~from a programming perspective at that time, ~that was very, um, that was a,~ that was a real step forward. Like people didn't do that before. And if you did do that, it was ~like kind of, uh, ~considered possibly insecure or dangerous or bad. And,~ uh, ~of course, none of those things were true. ~It was, ~it was just a great step forward from a user experience standpoint. And because Google did it, it ~kind of ~gave everyone else permission to start doing it. And,~ uh, ~Gmail was another one that was starting to go down this road where it had ~like ~a little bit more client side functionality ~and, ~and richness. ~Um, ~but I would say even then up until 2008,~ uh, ~we were all still mostly on desktop and most of the web development we were doing was very desktop centric. So the real. Push for the client side stuff really didn't start kicking until around 2008, interestingly. Noel: ~Gotcha. Yeah. ~Yeah. That's, that is interesting. [00:05:00] Do you think ~that ~that Was ~what, ~what ~kind of~ got people thinking about ~like~ the web and responsive design or ~was, ~was that kind of a different journey ~that,~ that happened a couple of years later? Brian: ~Well, ~we had the Ajax things happen, which was,~ uh,~ an acronym that stood for asynchronous XML,~ um,~ over HTTP. Noel: Yeah. Brian: which is funny because like we don't do XML anymore either, but you know, that, that was, that was. What we did back then that was a moment where it was like, okay, client side, but maybe we'll just do it for like little progressive enhancements. And then around 2008, once iPhone came out,~ uh,~ we finally had a good web browser and we were all very shocked to realize how bad our websites were in a mobile web browser. The form factor didn't work. You had to do a lot of pinch zoom stuff. The best connection you could get back then was three G. So clicking any link forced a page reload that you felt and saw. And that really. I think precipitated a lot of people to either,~ um, ~decide to go to native development or how do we make the [00:06:00] web,~ uh, ~a more mobile friendly world. And yeah, Ethan Marcotte coined responsive design standards were at this point, really moving fast with a Chrome browser, finally around really kicking competition, both to Apple and Microsoft finally,~ um, ~and bringing some competition even to Firefox. And so performance on mobile became. The thing, and there was more questions than answers. And I think that led to the explosion ~of, ~of techniques and frameworks that we saw,~ um, ~happen after. Noel: In flipping through your slides, I think it was ~kind of ~an interesting exercise. I'm like, man, ~like~ we did go through so many frameworks so quickly. And I think ~it's, ~it's ~like, ~it's interesting from a couple perspectives. One, it's just like interesting to reflect. Like, oh yeah, we had this era and this era and this kind of wave of thinking about things. And then, ~It also kind of gave me a,~ it checked my, ~like, I dunno, ~perception of how long React has ~kind of ~had as strong a hold as it seems to us, like React's ~like ~been around for 10 years now, and it's ~kind of ~been like a pretty big player for a long time. And ~in, in, ~in terms of web frameworks,~ that's,~ that's ~kind of ~profound, like at least it's new. ~Um, do you think that there. Like, ~do you think [00:07:00] we're settling a little bit more now than we were before? Or do you think ~this is like, ~we're ~still kind of in the era of figuring out, or are you ~still in the process ~rather~ of figuring out the best way to,~ uh,~ and remove elements from pages? Brian: Yeah. And that's the funny thing. I think with the full lens of time, you look at these things and you're like, Oh, these are just ways of adding and removing elements. And that's a really pretty trivial part of the whole problem space we're dealing with when you start looking at like ~a, ~a fuller application or full stack, you've got things like DNS and databases and networking and. ~Uh, ~CICD systems and queues and let's just goes on and on and on. ~And, ~and really your front end logic is going to comprise probably less than 20 percent of that. And yet everything we talk about seems to come from that lens. I think it's because it's what people learn first. ~And, ~and I think a lot of people forget that they probably learned HTML first. And then they learned CSS and then they learned JavaScript. They learned how to draw the rectangles and hide them or text or whatever. And then when you're combining these things, it can be challenging, especially like native DOM manipulation. So, um, tools like react make [00:08:00] that easier. There's no question. I don't know that they,~ um, ~ Like the React of 2012 is a lot different than the React of 2020 form. And so ~the, ~the statement that React's been around is true, but mostly in logo form, not necessarily in code I write for them, because that changes quite a bit profoundly over the years. And that's okay too, because it's learned a lot. And, ~you know, ~now we have server components, for example, coming into the fore and that's ~a, ~a neat new kind of way of doing RPC ~and.~ And I think that's great. ~Uh, ~more options is better. I don't think we're seeing anything slow down. ~Um, ~but one thing that I will point out, if you wrote,~ um, ~just a regular HTML, website in 1996, it would still work today. ~Um, ~but a react app that might not be true. You may not even be able to compile it today from six months ago. And that's just worth noticing. I don't think ~that ~that's ~a ~bad or ~a ~good, that's just, ~you know, Is ~how it is. And,~ uh, ~there's trade offs there. If,~ uh, ~things are changing underneath you. ~Uh, ~that's probably got a lot more to do with your dependencies than it does the runtime. ~And, um, that's, ~that was one [00:09:00] sort of, ~uh,~ maybe not direct point. I was trying to make in this talk that while there appears to be a lot of change and fatigue in our industry and a lot of churn, the primitives are actually pretty stable browsers. Don't break AWS, doesn't break. Node doesn't break, JavaScript doesn't break. So if your app is breaking all the time, that's because you've chosen poorly and the dependencies that you have. And,~ um, ~ yeah, it's a poor craftsman who blames their tools. And so ~like, what's, ~what's the answer? Well, the answer is choose better tools. Noel: Yeah. ~Oh, for sure. For sure. Yeah. I think, ~I think it's interesting in that,~ like, we don't, we don't, I think ~we don't reflect a lot upon that, ~like ~trade off we're making when we reach for these libraries and things like, sure,~ I'll, ~I'll use react and ~like, ~I think that ~there ~for some devs ~there ~that have been around a while, there's an acknowledgement of, I'm like ~kind of, ~I'm not using the primitives. So things can change out from underneath me. And I'm aware that ~like, I'm,~ this is giving me quite a bit of, ~you know, ~Power, but I'm acknowledging that,~ like, ~I may Brian: But if it got you there quicker, Noel: Yeah, Brian: end of the day, it's all about shipping. Noel: ~exactly. ~Exactly. ~Well, ~you mentioned there ~kind of how, ~how much ~react.~ React has changed and we have server components and all this stuff now. I feel like that's a reasonable segue into the meat of this talk, or maybe the point of [00:10:00] this talk in this kind of the rise of serverless and ~this, ~this maybe ~kind of, you know, ~this thing that everyone keeps talking about where like the server school again, all that jazz,~ um, is there like a. Kind of, I guess ~from this lens, from the perspective we're coming at this here, we're like, is this a good abstraction? Is this ~a, a, ~a reasonable thing to ~kind of ~jump in and invest your mental time to figuring out and thinking, and do you think serverless is one of those abstractions that's ~like, you know, ~worth ~kind of ~bringing to the forefront ~and, ~and focusing on and spending energy on Brian: I do. ~Um, ~my, and my perspective is coming from, ~you know, ~the traditional load balance monolith web server thing. I used to rack servers actually in my first job. So I'm, I've ~like ~done the actual physical version of this and then the cloud version. And,~ um,~ A lot of that in the cloud world, we'd call undifferentiated heavy lifting, which is a really fancy sentence to say I'm doing work that someone else should do.~ Um, ~if my core business isn't racking servers, like if I'm ~a, ~a food delivery service, my customers don't care how many servers I have in my cluster. They don't care. [00:11:00] They just want food. And so by that logic, should I care? And probably not. Probably I should outsource that. ~Um, ~there's ~various, ~various Degrees or a spectrum of,~ uh,~ suitability. So if your shop is not comfortable working in the cloud at all,~ um,~ I would argue that serverless is going to be really good for you because this is going to be the most gentle introduction of the cloud you could have.~ Um, ~if you are super comfortable with deploying a cluster of servers, it might be a slower for you to get on serverless cause you're going to have to unlearn a whole bunch of stuff. And,~ um,~ those are just simple, ~you know, ~those are human problems, not necessarily technical ones. From a technical perspective, I feel serverless is kind of an inevitability. And so, ~um,~ it's industrialization. So when the industrial revolution happened,~ uh,~ one of the characteristics of it, we saw,~ uh,~ things got smaller, faster, cheaper with time as more and more,~ uh,~ resources or capital expenditure was Put into,~ um,~ developing the industry that we got better at it. At sometimes they call us economy of [00:12:00] scale. If I'm making widgets of some kind of like a gear or something, the more of them I make, the better I get at making them, the cheaper it'll be for me to make them. The more material I can bring in at a better buying power cost. And it's the same with servers. And so,~ you know, ~when serverless ~kind of ~really started to get. ~Uh, ~steam, it was all about utility compute and billing per second. ~Um, ~fast forward to today. And now we have utility compute the bills per millisecond, just remarkable. And sometimes people will say, well, it's just CGI bin. You know, I just give it some code and they run it. And it's like, well, that's true, except for they also scale it and they also patch it. And they also keep it running for you. So ~like, ~you don't have to think about anything, just the code that you wrote. This doesn't necessarily appeal to the old school. So if I'm a, ~you know, ~old school dev, who's used to racking servers, I kind of like my job and I'm good at it. And this serverless thing seems like a way to lock me into the cloud. But if I'm a front end developer and I'm trying to get my job done and I don't give a shit about how it works under the [00:13:00] hood, well, serverless is incredibly compelling because it gets me to that same level of capability with a far less overhead or operations cost. ~And, um,~ this generation gets that and front end devs get that. And,~ um,~ one thing about our industry is there's more new devs every year than there is. Previous devs that have always been there. So we think in 2010, there was around 20 million developers, but if you listen to get hub today, they say there's a hundred million developers. So we grew that much in 10 years. And I guarantee you every one of those 80 million developers started with HTML, CSS, and JavaScript in the front end. Cause that's the easiest thing to possibly learn to get in. And then once you're in and you're responsible for building out these workloads for, ~you know, ~solving business problems and you got Kubernetes on one side and you have like serverless on the other, it's really obvious. To you, to most people that, Hey, this serverless path is going to be a lot less work to get me most of the way there. And if I do happen to blow out all the limits on serverless, I have an extremely high class problem on my hands [00:14:00] that, ~you know, ~we can afford now to maybe scale it beyond that, but I think it's more rare than not,~ uh,~ to run into that. Noel: Oh, for sure. Yeah. ~I think, ~I think I agree just ~kind of with, ~with the thesis that a very small percentage of developers need to be spending time or, ~you know, ~should be focusing time. Probably they're trying to be as effective as possible on ~like ~scalable infrastructure because like you said, ~it's like a, ~it's like a repeatable problem. I think just maybe zoom out a little bit. It feels to me like there's ~kind of yeah. A couple, ~a couple distinct waves of serverless. Cause we've had like Lambda and cloud function. Like we've had this a long time. Well, I don't Brian: Yeah. 10 years. Noel: Yeah. Like a while. ~Right. ~And I think that there was kind of an initial wave. There was some people were like, yeah, ~right. It was like, ~Oh, I'm going to not write APIs anymore. I'll do everything serverless. And like. That worked kind of well for some people. And there was some horror stories where people had these like crazy bills because they like had a million, ~you know, lamb ~lamb to call the lamb to call the lamb to call the lambda for every single web request. ~And it~ Brian: It's a rite of passage. ~Yeah.~ Noel: sure. And like you very, you clearly see how one gets there. And I think one can empathize with the logic on either side, but I think that ~there,~ Now, when we say serverless, it feels like ~the, ~the [00:15:00] lexicons ~kind of ~shifted where maybe we're still talking about that, but it ~kind of ~feels like we're typically talking about like that, plus ~like~ a wrapper, like a layer around it that does some of the abstraction for us. Do you think ~that ~that's accurate? And why do you think ~that ~that's happening now versus like originally in this first wave of serverless? Brian: Yeah. ~So, well, ~terminology definitely,~ um,~ changes over time. So like a good recent examples, JAMstack, that used to have a very crisp definition and over time it became everything to everybody. And I think that's pretty common, actually. That happens a lot. And it's happened to serverless too. It started off, serverless really used to be about no servers, utility, compute, and as it's Audience and capabilities grew that got really blurry fast and some of it ~kind of ~maliciously, I think. So we had a lot of cloud vendors that would try and brand,~ um,~ Kubernetes as serverless, which I don't really know how they got there. If you're deploying a container that's running a server, then you're, Noel: Yeah, if you tilt your head and Brian: servers, Noel: say, you [00:16:00] know,~ Yeah,~ Brian: branding will brand and marketing will market, and ~they, ~they definitely muddied that water. The more recent I'd say kind of serverless nerds. We'll say it's more of an ethos. It's more of ~a, ~a way to practice your business. And so it's about outsourcing non core functionality. If I sell ice cream, I shouldn't be concerned about racking servers. I should just worry about the logic to sell ice cream and let someone else deal with the scaling of it. ~And, um, ~ and that goes in a whole spectrum of ways. Like maybe if I'm hosting a web blog and I'm just doing like Jekyll or something like that on GitHub pages. ~You know, that, ~that is serverless, but there are servers obviously running that behind the scenes, but a more serverless way might be to use wordpress. com. And just not even have to deal with anything. You just write content and there is no concept of scaling or anything. I'm just paying ~for the, ~for the blog that could be serverless too. And I think that's all right. There's definitely ~a, ~a need for a framework or a rapper too, like you mentioned. ~So.~ This stuff gets complicated fast. There's lots of moving parts [00:17:00] to orchestrate, and you probably want to use something called infrastructure as code to deploy to a cloud, and you've only got a few options there and none of them are great. ~Um, ~they're all very verbose and difficult. So there's a few frameworks that make that easier and wrap that stuff up into ~like a, ~a nice tidy package. And I think,~ um,~ like ours is called architect or architect codes. It's good. It generates CloudFormation, which is Amazon's kind of native thing. There are other ones out there like Terraform,~ um,~ which work quite well. If you listen to Vercel, they'll say a build step is the same thing, but that's not true. if I run a build step against my NPM modules and then you run a build step against your NPM modules is really low probability we have the same. Output like almost none. And that's not very deterministic, which is not infrastructure's code. So infrastructure's code is deterministic, explicit,~ um,~ very much like a package. Jason,~ uh, you, ~you list what resources in the cloud you need in, you check it in with your code and that means that [00:18:00] version of that code will run with that version of those resources. Happy days. Determinism ~is, ~is a thing. Noel: Yeah. Brian: ~And, um, ~You need that. So like you, you have to have that. You can't just click. Sometimes people will do what's called ClickOps or the click around in the web console to set up a deployment. And that really only scales to a team of one. As soon as you have two or three developers, ClickOps will fall apart really fast, ~so it's a. ~Yeah, it's, it's evolved. It's gotten a little more mature ~and, ~and there's definitely a need for like a framework level,~ uh, ~answer for serverless for sure. Noel: ~yeah,~ Brian: a front end build step. I'm sorry for so. Noel: yeah. ~That, that was, I was, ~I was gonna kind of ask about this. So do you think verse, I guess Versal is maybe a weird pinpoint, but ~let's say, ~let's say like One Rights or React app uses a bunch of React server components for servery stuff. Does that fall into your definition of serverless, if even if servers are running React server Brian: Yeah, ~I mean, ~I think so for sure. Yeah. Yeah. ~Um, ~Yeah, to me,~ you know, like ~there's still wires and wireless. It's kind of the joke. There's still servers and server, like S3, for [00:19:00] example, is considered the largest microservices architecture ever built by humans. ~Uh, ~it's got the best,~ um,~ level of consistency and availability of any service in the cloud. And the technical talks in AWS reInvent on how they pull that off is great. I think almost as close as we get to ~like ~the most advanced engineering for distributed systems in the world. S3 is many servers, but you don't touch or deal with any of those. And I think similarly,~ uh,~ where react is moving towards the backend, they're not going to expose that part of the sausage to the end user. You're not thinking about how many instances are backing your function or whatever,~ you're,~ you're just thinking about writing the function, which is great because ~that's, ~that's where we want to be when we're writing code. Noel: Yeah. ~How about, ~how about these, like the one off tools,~ um, that are, ~that are ~kind of, uh, ~provider specific, but can help one ~getting, ~getting code. ~I'm free.~ I'm blanking on the one that AWS has. I, and I feel it's not Brian: There's [00:20:00] CDK, there's Amplify. Noel: maybe amplify is what I'm thinking of, or even something like,~ like, uh,~ cloud flares Wrangler, right? So it's like, okay, I can like to spin this up and deploy ~like, ~I feel like ~there's, ~there's those, there's ~kind of ~like this reacts if there's like manually writing and deploying, whatever, pick your cloud function provider of choice. And ~then, then like ~all the way at the other end, there's these ~kind of like~ hosted code platforms that are a little bit more hands on,~ um, like~ Firebase was maybe the first one. Now, ~like~ super base is a little bit ~like~ more kind of open and standards driven. ~Like, do you, like,~ do you think these are all ~kind of.~ ~Like ~part of this journey ~or, or, ~or is there ~like, ~like a specific piece of that pie that,~ uh,~ when we talk about the migration to serverless, you think is the most,~ uh,~ interesting or ~like~ noteworthy, Brian: I think it's similar to other trends that we've seen where we've got an explosion of options, a lot of diversity of,~ um,~ approaches and,~ um,~ we haven't really consolidated,~ uh,~ yet in any way. And I think that's because the primitives across these clouds,~ uh,~ aren't normalizable. So Cloudflare worker is just not the same as,~ uh,~ an [00:21:00] Azure function. Like not in any way. There's no semantic parallels. They both execute JavaScript, but in different run times with different guarantees of scaling and scaling down and errors. And because there's no semantic substrate that is similar, there's no real portability, which is.~ Kind of ~a bummer. ~Um, ~if you're just dealing with get requests, then you're probably going to be able to ~pay ~paper over it. Remix as this. ~Um,~ but like, as soon as you get past a get request and you start doing anything remotely,~ um,~ involved,~ it's, it's ~It's going to end up being pretty specific to a particular vendor. And I think that's okay. I think over time we might see that normalize. I think having a bunch of options is better than having none and,~ um,~ and different, you know, workloads or different businesses are going to have different requirements. And so it's like, if you're Walmart, you're unlikely to want to use Amazon because they're a competitor and that's okay. ~Um, ~so use Azure in that case. And Azure is going to have, ~you know, ~different.~ You know, ~problems and different [00:22:00] strengths than AWS for the foreseeable future. It's,~ um,~ unlike with,~ uh,~ just hosting a VPS or like a basic server, ~you know, ~there's not a lot to normalize on in this world yet. And so you really got to. Pick your battles and decide who you're going to lock in with similar to mobile or even,~ um,~ operating systems on your desktop. There's a few options and they all got trade offs and they're not really compatible, but there's ways we can make them compatible and yeah. And,~ um,~ it's ~kind of ~just where we're at, I think in 10 years, that might be different. We might have probably more. Parallels between these systems and maybe the build portable systems, but,~ um,~ not in the foreseeable future. So, Noel: Yeah. Yeah. I think, ~you know, it's, ~it's kind of a bummer, right? Like ~it'd be, ~it'd be cool ~if we were, if this, ~if this journey were one of like, oh yeah, ~you can kind of just like, ~there's vendors that just, everyone's got the same primitives, but it ~is, ~is really like a, there's a pragmatic problem there of ~like, no, these are like very, like~ we're getting strikingly close to the metal on what these things can do. Like a Cloudflare worker was fundamentally very different. ~At like with, ~with what it was ~designed, like what those are ~designed around the problem they [00:23:00] were trying to solve originally at least versus ~like ~a cloud function elsewhere. ~So it is a,~ Brian: And that's okay. ~Like, ~and, ~you know, um, ~for us, it's an embarrassment of riches. So I think a lot of devs will immediately go to the fatigue and, ~you know, ~the decision fatigue and all the complexity, but,~ um,~ Really? This is just great. ~You know, ~like we can figure out like which one works for us. And,~ uh,~ it's a two way door, ~you know, ~you can change that decision later. If,~ um,~ yeah, if you're writing good JavaScript, it might even be somewhat portable. I wouldn't say it'll be totally portable, but parts of it should be. Noel: But ~if you're, if you're, if you, ~I think if one goes into it with that mentality of ~like, ~okay, ~this is an abstract,~ this part may switch. So I can like in my code, at least get ready to have that abstracted and swap that out. But I think that does lead to an interesting question. I like to ~kind of ~always ask. People for advice, if they've got it, ~like you, like I said, ~like everything, most of these things work, like you're going to be able to build a thing and have a product deliver. But I think, ~I think it is, ~it can be a little bit daunting. Like I'm fortunate enough to spend a lot of time talking to a bunch of people and thinking about these ~like~ different options and stuff ~in the, ~in the marketplace. But you know, you're starting up a side project. They're like, yeah, this may be a thing that ends up becoming [00:24:00] something big and building out.~ How, how do you, ~how do you begin to parse this? ~Like what, like what, ~what abstraction do I make here? ~Like, where is there, ~do I just go all in and like, again, I don't want to solve problems, so I'll go with something fully managed. I'll go with super base and ~like not have any, not have, ~not have code, not have a database, not have anything and use their primitives and build, or ~like, ~I'll take a little bit more and like manage my deployments. ~You know, ~if I'm not doing it manually, like use ~some, ~some tool off the shelf that gives me a little more control. ~How do you, how do you, ~how do you do that? Brian: Yeah. ~I mean, ~I think it's a team situation. ~Um, I, ~I personally would just build on AWS and do the serverless thing. Cause that's what I am most comfortable doing and having the experience of ~going, uh, ~going from the other way. ~Um, ~I know I'm not going back to that. I definitely do not want to SSH into a server ever again, if I can avoid it. ~Um, ~but~ you know, ~it, it's,~ uh,~ That's because I got that experience and I, there's no hill to climb. I think if you're a dev, who's just starting out in the front end, going with ~like ~a easy off the shelf solution that,~ um, ~promises you the world is fine to get going. ~Um, ~I [00:25:00] think if it's a serious business application where uptime is. Important and things like data integrity and persistence and durability are important. You're probably not going to want to go with a venture backed startup. You're probably going to want to go with one of the big clouds and it's going to be painful. And you're going to have to learn some new stuff and you're going to have to factor that into that. But ~the. ~The payoff on the other side is that you get better availability and maintainability in the longterm. And maybe that's not a goal. ~Like, ~I don't know many businesses that would say that's not a goal. Noel: Right, right. Yeah, Brian: For the most part, they're going to say, I want this to work forever. And I want to add features fast. And,~ um,~ I think an investment in one of the big cloud players is really good for your career in the long term. And it's really obviously why, ~you know, ~most businesses choose one of these big players because it's going to get you more stability ~and, ~and capabilities,~ um, ~out of the box. But,~ um,~ by all means do a bake off. Like I remember early in my career, it was considered. ~Kind of ~bad to do this, but like, you know, it's pretty cheap and easy to find [00:26:00] out. Like you could probably today within an hour, have a hello world running on each cloud, like you probably could. And yeah, you're going to have to, ~you know, ~fork out the credit card a few times, which, ~you know, ~might make you sweat a little, so maybe use the company card for that, but,~ um,~ it's very doable. And then, ~you know, make it, ~make the call then, ~like get, ~get some direct experience, don't listen to some guy on a podcast. I will say this though, in all cases, whatever cloud you pick, the observability and,~ um, ~the ability to debug is pretty ugly and pretty bad. And so like ~one,~ well, this is why we see so many solutions around logging. So ~like, ~yeah, try out a pod rocket while you're at it. Cause you're going to need it in the end. Noel: yeah, yeah, yeah, yeah, yeah, there's, I think, ~you know, people, ~people spend a lot of time on that and trying to figure it out. But I think that, ~yeah, ~like the capacity ~to be ~to debug and more broadly, just like maybe the dev experience at large. This is what you said,~ like, we're kind of at a, we have a, So ~we have so many viable options that it's ~kind of like, well, ~like it, it's hard to say, but ~like ~whatever lets you move Brian: We think also often in terms of how quick it is to get started. But I'd [00:27:00] like to challenge the audience to think in terms of how quick it is to fix a bug on Saturday morning when you don't want to be working, because that's really when it matters the most. And you definitely don't, you're not going to have a situation where there's no bug on Saturday. That's just, ~you know, ~put that idea out of your head. There's going to be a bug and it's going to be when your time's off and you're going to be on call. And if you're making decisions for that moment,~ um,~ you're going to be a lot happier in the long run ~as a, ~as a software engineer. Noel: Yeah. ~Are there any, ~are there any kind of recent releases ~or, ~or tools or,~ um, Even, ~even like trends in particular that you find interesting or exciting ~on, ~on this front of like moving things to the cloud, but having that same kind of, ~you know, ~capacity to debug and a good local dev experience ~and,~ Brian: ~Well, ~yeah, I was going to say local devs key. ~Uh, so, you know, ~look for that and build for that. ~Um, ~local dev is not a replacement for a staging environment. So ~you, you do, ~you still need a safe place to deploy that is identical to production, but isn't production because you're going to need to reproduce bugs. ~Um, ~the faster you can reproduce a bug, the faster you're going to be able to [00:28:00] fix it. And yeah, the other one, and ~I don't, ~I think this is Wild West, but,~ um, our, ~our errors are bad. Our errors are really bad. We get these obfuscated, no stack trace, source maps didn't work, ~you know, ~undefined is not a function, line one, column 5, 000, and like, Noel: layers deep in some node module. You're like, I don't, I have no idea. Yeah. Brian: but we can huck that in an LLM now and it can decipher it for us and reverse engineer where that line number is. And ~I, ~I like that,~ uh,~ idea. So the. The fact that we have bugs is not going to go away, but can we make the time to fix those bugs? ~Um ~as small as possible ~and ~and ideally prevent them ~but you know ~That's not going to happen all the time. We're still going to get them and when we do get them ~Um, ~the goal is really to resolve them as quick as we can and hopefully not impact customers along the way So yeah, I think there's ~some good ~Some good tools. I wish our errors were better out there. I don't have an awesome solution for that. I think part of the problem is transpiling. Noel: It's a language problem, right? [00:29:00] I would say ~maybe, ~maybe transpilation in particular is that we go through all these steps in the, our local code is so different from the code that's running. It makes it tough. Brian: yeah. And in back end dev, that is always considered a bad thing. ~You know, ~the code you write should be the code that runs and your stack trace should give you a meaningful result. Line number, but,~ uh,~ we kind of lost that in the last few years with a lot of the front end tooling. So my hope is we start to move away from that, but I'm not seeing it quite yet. Noel: Yeah, I mean, like there's source map support, like, you know, even like log rocket, we have for source map support and all that, but I agree. It's like imperfect. You have to do additional work as a developer to make errors good. And that's annoying. ~Like,~ Brian: Yeah. It should just be the default. I know TC39 actually has a proposal to ratify better source maps soon. So ~there ~there's good news on that front. I think the challenge I would have is ~like, ~do we even need to transpile? Because a lot of the times that we were just doing it because we think we need to, but I don't think we need Noel: It's the default in your build tool. Yeah. Whatever. Yeah. Yeah. Whatever's there for sure. [00:30:00] Cool. Nice. ~Well, we've, we've covered, ~we've covered a lot already. Is there ~anything, ~anything else you'd kind of implore listeners to check out or think about, especially if they're like ~kind of ~in this space and looking for cloud tools to play with, or they've got things like, yeah, this is a problem that I don't want to have to keep solving myself. Is there anywhere ~you'd, ~you'd point them in particular? Brian: Well, definitely check out ~our, ~our stuff,~ um,~ which is arc. codes and enhanced. dev. Those are our open source projects. ~Um, ~there's discords and. What not, and we're always happy to help Noel: show notes for sure. Yeah. Brian: Yeah. And ~I I'd let them,~ I want everyone to know. So the three big takeaways from the talk,~ uh,~ were,~ um,~ front ends taking over backend and they're doing it by ~a ~serverless. So ~there's a, ~there's an opportunity there for you as a front end developer to,~ um,~ grow. So check out serverless stuff, be it our stuff or not. ~Um, ~the other thing I'm noticing, and I don't know if everybody else is noticing this, but,~ um,~ it looks like CSS has started to take over JavaScript. Noel: hmm. Mm hmm. Brian: of things that we used to think we needed JavaScript for that we don't need it for anymore. We got view page transitions, API landing. Now we've got all kinds of animation tools that are declarative. [00:31:00] So there's a lot of reasons to remove JavaScript now for CSS. So that's a, it's a thing ~to.~ To notice, ~just notice, maybe, ~maybe figure your career trajectory around both serverless and getting better at CSS. And the last thing I'd point out, I see in here, a lot of people complain about the change over time. And that was something that I wanted to address in the talk. There does appear to be a lot of change, but if you look carefully. There's a lot of stuff that doesn't change. Browsers are very stable. Node is very stable. ~Um, ~JavaScript, the language is very stable. AWS is stable. And,~ um,~ if you can really master those things, dare say those fundamentals or those basics, you can write applications that are incredibly maintainable over extremely long periods of time. And that compounds,~ uh,~ in value for you over time, instead of spitting your tires, rewriting your front end, because some new react primitive came out. You can build things, you can deploy them. You can be confident in two years. They're still going to run the same way. And I think that's,~ um,~ compelling. Noel: ~hmm. ~Oh, for sure. For sure. Appealing. Yeah. ~When one is, ~when [00:32:00] one is already,~ uh,~ the backlog's already full and then you got to go update something because something's being deprecated. It's just ~like, uh, ~yeah. It'd be nice if this didn't happen. Yeah. Brian: we already wrote that feature and like the business is going to be on my case about this and ~like, ~yeah. ~Yeah,~ Noel: thank you so much for chatting with me, Brian. It's been a pleasure. ~It's a, it's a good thought provoking. Uh, ~it's a thought provoking talk. We'll have a link to the slides at least, probably if we can. ~Uh, ~is the talk online anywhere? Brian: it is. It's on YouTube. ~Uh, ~but ~they, ~they recorded the whole day, so you can fast forward to mine and fast forward past it. Noel: Yeah. Brian: ~Yeah. ~Yeah. It was a great conference. I really recommend if you're in the Pacific Northwest going to a Cascadia. Noel: Nice. It's ~got a good, ~got a good name too. ~Well, ~anyway, thanks again, Brian. ~Uh, ~it was a pleasure. Brian: Thanks for having me. Noel: Yeah, of course.