The Infra Pod - Is frontend eating the whole stack? Chat with Kurt (Fly.io), Jack (Amplitude) and David (Stately)

Episode Date: May 23, 2023

Is backend dead? Is front-end eating the whole stack? Ian and Tim invited several YAIGers to discuss about how front end and back end is changing, with guests: - Kurt, Fly.io founder - Jack, Principal Lead at Amplitude - David, Stately founder We all sat in a room with our phones on the table, and recorded this lovely chat before the SF meetup!

So I'm super excited to have all of you here today. This is an inaugural sort of episode, YAG-y, I think that's how we call it, YAG podcast, where we really want to dive into this fundamental question around what's happening on the front end and is the back end being superseded to the front end engineer? Is that folks that traditionally a back end engineer would build things like

queues and APIs and data stores and reactive like ways that create plumbing, but, you know, reactive pipelines. Is that moving to the front end? How are we powering the front end? What does that mean? Right. And then there's this interesting part that's occurring as well around edge compute, right? As we move things to the edge, what does this actually mean?

How does it change the way we build our applications? How does it change the way that we build our applications? How does it change the way that we structure our state? So with that, I'm joined by like a group of like awesome folks that will just like go around the table. By the way, I'm Ian Livingston, a member of the community, done some startups, not a big deal. But on my left with Kurt. Kurt, do you want to quickly introduce yourself and tell us, tell us why you're here, Kurt? I'm not a good friend developer. I work on infrastructure. And so, uh, we're building a company called fly IO right now that is basically

all about running, um, pretty much like your apps close to people. And so there's a fair amount of, a blurred line between, I hate saying it, but like an app on a server that's a few milliseconds away and then like a front-end application. I probably have opinion. These are amazing. I think that's why we're here. All right. I'm David Korshie, David K. Piano, pretty much everywhere online. I started a company called stately.ai and we focused mostly on state machines. More visualizing your application logic and your business logic.

And it turns out that state machines really bridge front end back end because you could reference back end workflows as state machines, front end logic as state machines too, so I'm just obsessed with that technology. I love it. Awesome. And Tim, I started just obsessed with that technology. I love it. Awesome. And then I started this little discord channel, I came up with this, the name as well. But definitely grew way, way, way bigger than than everything else. I've worked on back back and forth. Nothing like

cool. And I'm Jack, I do run and stuff have for most of my career work at amplitude where I lead front end infrastructure. Sweet, which is like a great as you can see, we've assembled a squad of random folks that all have deep opinions in the space. I think like, like one thing I think we need to start is, was it what do we mean by like the front end in the back end? Like, you know-end? Jack, maybe you want to start with your perspective since you're heavy focused on as a front-end engineer. What do you think that actually, when we say this, what does it mean to you? Yeah, I mean, I think that the biggest thing that it means is more business logic is written in code that runs on the client

versus written in code that runs on the server. And it kind of started with single-page apps coming out in 2013, 2014 with Angular and then react. But it really is just who is writing the business logic that matters to the end user. And for the longest time, it was always backend engineers. And I think that the kind of conversation that we're having right now is how much of that is changing. Why is it changing and where does that lead us?

Right. And so what's like been the primary driver? Is this, do we think the primary driver is like a productivity reason? Is it a performance reason? You know, uh, Kurt, I know you work a lot on, um, like building core infrastructure to enable edge use cases from like, from your perspective and what you've seen and what you're thinking with fly, how do you think about like, what is the enabler here? Why do we want this? Like, why is a, you know you know a cto at a company or a cio why would i consider this being like a thing i should really start thinking about um i it's it's interesting because a lot of this it looks a little like a pendulum if you rewind 20 years eight years um and like rails 1., uh, it wasn't front-ending that way.

It's what we now maybe call a backend dev, but these people own the full end of Facebook user database experience. Um, I think we went through this shift of light, almost like, if you imagine like the Facebook architecture pulled everyone apart in some ways, it didn't actually make a lot of sense for a lot of different because like there's one company on the planet that's a problem facebook and the way facebook solves their problems is not always applicable i think a lot of what we think is happening is that the pendulum is going to like someone owns the user data store experience because she, and I think a productivity thing, if you really,

really, really want to iterate on and build an application in like an agile, I'm doing air quotes, agile, like little a agile. If you want to be agile, if you want things in front of users, see how it goes and then make, make quick changes. You sort of have to own the whole, you have to have like exposure and the full widget basically yeah and so um it's it's it's actually great and you're seeing things like it's in some ways there's a lot of new stuff there's a lot of like the real offspring maybe it's with like next of the world and whatever the next next is which i don't even

know i think it's out there but i don't know what it is but then there's like sequel light is all this relevant again which i feel like has been around warm and it's out there but i don't know what it is but then there's like sqlite is all this relevant again yeah which i feel like there's been around warm and it's you're seeing things like the browsers be kind of pick up a lot of the patterns um this is invented getting the cities in some way it's very neat um to watch awesome and so i think like i think the interesting like explore the productivity argument, I think, David, from your perspective in building a state, it'd be really interesting to understand from, what does that mean? Could you give us a lay of the land? When we say where the front ends eat the back, I've got a great answer, or to Jack, I think the reasoning all around productivity, but

why are we here? What's the function? What's the friction that causes us to be like a productivity concern? Right. So I think that basically, there's this dirty word called handoff, right? That was a huge productivity killer, where basically, it was traditionally like I worked in teams where it was like JavaScript and PHP or Scala or.NET developers. And so there was that handoff process where you were like, I need these endpoints. And that's really frustrating. So I personally don't think that, you know, we're going to see a lot of things moving to the front end, but rather we're enabling front end developers to do more. And so I'll give you an example.

For our company, Most of our engineers are JavaScript typescripts of front end developers. However, when it comes to adding new endpoints, we have tRPC, we moved on from GraphQL to use tRPC. And so with things like that, we own the full stack. And so that allows us to move a lot faster. So I think, yeah, we're seeing a lot of that because there's never really going to be a point where the front end owns 100% of the backend logic, because that's actually not desirable. You don't want to expose that to the front end. But you are going to see more front end developers able to do things that backend developers could do. So I, and that's why it's

weird. And maybe we could talk more on this, but like the distinction between front end and back end, right. That's I think, um, the excellent point there is that front end developers are going deep and that's probably what's happening regardless of how you look at this. Um, and a lot of this is them like breaking out of their sandbox and some ways like we haven't trusted them to do things very often. And like, if you look at the class and problems you actually need to

split off into another team, it's, it's like, they're pretty specialized at some point. Um, and it's, it's yeah. The, I, I love, um, the idea of people writing JavaScript, like also doing database schemas and such a neat, such a neat, yeah. Do we think this is like, it seems to me that a lot of this started like in infancy, probably like 10 or 15 years ago, like when Node came out, right? Like it was like, now I could write end to end. We had this idea of I could write front end code.

I could write my back of the same language and you kind of create this like, what we thought was an efficiency. And I think, you know, a lot of companies went after that efficiency and they realized there was like issues with the node engine itself like you went to go scale it it didn't scale very well for various reasons we spent a long time talking about but it seems like that's when this sort of like idea kicked off again like hey maybe you can have one person the full stack developer that can move from front to back and front again and they don't have to do the handoff and then now we're trying to see like maybe a second or third or fourth iteration of an attempt of actually enabling that story.

Right? Like we tried it with node. It was semi successful enough to like spawn a whole slew of startups. Now the next stage is, is what I guess that's the question. Yeah. Uh, no, it's interesting. Um, if you think like nine years ago, I think Airbnb tried to do something called render, there was all the called isomorphic JavaScript app.

This is the write the code that runs on the server. And those are all, those all. I think what, what my, I also have a hot take about there. We'll start with this. Cause it's. No, it happened the same time MongoDB did. And what I think is interesting is no became coupled to Mongo in a lot of ways. It meant it wasn't actually that great platform for talking existing databases.

Because it was like you do the, I can't remember, the stack. Whatever Node and MongoDB. I think it was Mean. Oh, yeah. The Mean stack. And I think what Node was weak on database a long time. When people were talking about isomorphic apps, we're in some ways solving this problem.

I think if your front-end developers are going deep, it's entirely data. It's not exactly the language. It's entirely the data that they're after. And I think most of the really interesting companies here are doing something. They have a take on some kind of slice of what data needs for the front end of. And I feel like that was kind of the critical flaw of note was it just wasn't a great thing to use in front of the database.

Interesting. And, and, and difficulties from database because scale or because it was like the wrong layer of abstraction because like why do i need to go down that layer those this far deep down the stack to then go just get some some data of a database it might have been a javascript thing but programming ux for accessing a database with node was a callback hill pre-formula it was pre-async it was pre all the really good stuff in javascript um pre-typescript pre-pre-type script which sort of polluted api um and i think it just made accessing a database which in some ways it doesn't make sense for a developer that a database is async if you're really thinking about it it doesn't really make sense that you have to jump through hoops to ask for a role from a database all the time.

But yeah, all sorts of hot takes about Node that are probably incorrect, but it is really interesting to think about the evolution of JavaScript here and how that relates to Node's success. Yeah, I think that's like, it's a key thing when I think about where we're going as an organization. I mean, we're going as a community, not an organization. I spent too much time at sneak thinking about these things, but I've been thinking about like where we're going as a, as an industry and organization and as a community, there I go again. It's really interesting to think about, okay, let's bring back 10 years, then draw forward. I think one of the interesting things though, if we go back to the productivity argument just for a second, like I think Jack would be like super interested to understand, like what are like, when you think about building front-ended amplitude and the divide that you have between back and front end, like where's the friction

and why would something like that? David was talking about like stately or, or some of the stuff we're seeing from fly. Why would that be, why would that actually help solve problems? Like, why are these things, things that we want? Sure. I mean, I think that the node point of that being kind of, I don't know, the original sin is probably there's a grain of truth in there. But for me, where my head originally went was that the thing that is different now, and this started, I don't know, with probably with React in 2014 or 2015, is just there is a silly amount of state on the front end. Yeah. And that was never true beforehand. And like when I say silly, I don't mean that bad.

Like it's great. But we all of a sudden now have to manage that the application state and a lot of it is not source of truth state. A lot of it comes from a database, but we're managing this state with nowhere near the amount of rigor that you would manage database state with. And so like the separation between front end and back end

is kind of not really the way that the separation should be. Like it's kind of weird that we're in this state because in reality it should be sort of UI and then state and like state on the client and state on the server. Those two things are way more similar than state on the client is to kind of UI that designers work on or that like more traditional front-end engineers of the kind of 2013 vintage work on. Interesting. So basically what I'm hearing from you to repeat and consolidate that idea is like,

you know, actually the UI, there's the client state and the data state that we have to replicate to sort of like the web browser, right? That we have to get over there. But then there's the UI state itself. And those are separate lines. We actually have more data flowing to the client than ever before. Basically, to get good experience, you need backend engineers for the front end. And that just wasn't true a while ago. That's actually an incredibly interesting point.

Cause like as much as we can throw a shape node, one of the things that happened over, like if you imagine rails to now, I'm like an OG rail developer in some ways is you could actually, you're doing like HTML, like form posts and just speak for every interaction with the server. You should pretend like it's an asynchronous distributed problem. You can sort of get away with just ignoring the distributed nature of the application.

As soon as the thing drives the UI and it's disconnected from the server, you actually have this really hairy distributed systems problem. And so for all, like we can talk about Node being wrong, it might have just taken 15 years to figure out how to actually address this distributed systems problem. And so for all like we can talk about node being wrong, might have just 15 years to figure out how to actually address this distributed systems problem in a way that like, normal development, I mean, I mean, like a way that people who are interested in solving a like a user's problem. And you right. I remember we've talked about early the react, we're looking at this thinking harder than

distributed infrastructure ever. Like reasoning about this and building something that is, is like, manageable. Is incredibly difficult. Yeah, which is which is why we have state machines, right? All these patterns for trying to tackle some of this, I still don't think we know. I don't think we've figured out like the model for this just yet. I think it's there. We just don't know what it is.

I think like the more you move data to the front end, the more complexity you get. It's just inherent complexity because you're trying to do so much. If we're really comparing to like applications where let's say it's fully backends, like all the front end is doing is rendering an HTML page. Back in the old days where you're using a sprinkling of JavaScript to say had dynamic NIST, then it actually becomes a lot more because the logic lives in one place. Again, talking about distributed problems,

you now have logic distributed between the front end and the back end, and you have to reconcile between those two. And it's extremely complicated. And so that's why tools and top tools just to address that complexity. And so do we see the future of this idea of the front end and the back end?

It sounds like this conversation is trying to deal with reconciling the fact that like the front end state, the back end state are actually the same type of state. But it's like we have this hairy tool chain that we've created. And now we're trying to basically consolidate and create productivity that we didn't have before. Is that is that where we're at because it seems like what i'm hearing is as we get to go through discussion is like actually we got here through like this cavalcade of random tunnels right well you're trying to build you know we're trying to break up our our monolithic back-end apps right we're trying to build more reactive um not pun intended but you know more interactive applications that were more data driven and and yeah exactly right and so and now we had these two crazy machines with complexity, but one on the back end and one on the front end, we're realizing actually these things that really are sure more common

than we ever thought. Is that, is that sort of where we're ending up? Well, and also it's a harder problem than we thought because we are like, it's not a, like it's a asynchronous problem. It's a distributed systems problem. And I don't think anyone was thinking about it in that way a decade ago. Exactly. The user experiences that are kind of like driving what feels high quality today are all around like all around multiplayer, all around local first and all around keyboard first. And two of those three challenges

are not design challenges, not UI challenges. They're distributed system challenges. I think one thing too is it's not necessarily that the backend and frontend have the same problem. It's that you need to kind of

make them the same for a human to even be able to keep this in their head yeah and so i think things i think the early isomorphic javascript is maybe trying to treat the back end and finding the same problem i think what's happening now is we're like we have to make these the same problem or nobody's going to be able to address this right and a lot of this is because what said about like it's great to get from it devs data like they should have a they should be able to literally query your source of truth to ship a feature, which is completely impossible. How do we like get as close to that as we can without teaching them, you know, JavaScript and distributed system design and how to like, how to model Cassandra and all of this prep.

It was all the way down to the VM and then even lower if you want to get really and then think of and then think of all the different lossy interfaces that occur between you know the actual data store and the ui the different rest apis all the different places where you actually lose context and you have these different translation layers and that that really to me is when i think of like the layer cake of different technologies between like hydrating like a react component down to like actually getting the data from a Postgres. That tells you everything about the complexity one must understand to actually truly be able to trace the stack. And for another hot take, I think in 2010,

backends were incredibly difficult. And in 2023, you can buy a server with 256 cores, 2 terabytes of RAM. You can build a vastly simpler backend that scales to way bigger than most people ever have. And the world just

flipped. It was like the backend was impossible. And some of this is like the backend is more conceivable now. So we can do a lot with the front end.

But there's no like people building database apps don't have to think about distributed systems anymore the same way. It's bananas. Well, the biggest change is like a rise in the cloud right like you know 15 years ago 10 years ago

even like the idea like yeah it was the back end was difficult because like racking stacking servers was hard and like do you like the idea of do you have a even like spreading a workload across two system two servers right like how many how many of us have built like a lamp stack, you know, 15 years ago where it's all on one Apache instance on one, like reasonably sized, like, like Dell service, spinning desk, right. And now we $30,000 on fusion IO cards that try to spin this. And we had like 60 gigs of storage. It was, yeah.

And so that is the clouds come out, it's actually, to your point, like the backend's gone a lot easier, but the UI is still really hard. And the UI is like actually the moneymaker, right? Yeah. Yeah. No, no, no. It's absolutely what sells an app nowadays.

Like you look at apps like Linear, Notion, really, really good UIs. And it's not just like the, you know, what you can do with animations or CSS or, you know, because Linear has an amazing design, but also you have AI in the mix. And so I think the overall theme is that as we introduce new technologies, we were talking about multiplayer, right? So now we have CRDTs in the mix. Like we have all of this new inherent complexity just because we're like, hey, this is something new we could add to the app.

This is more value that we could provide our users, but it just gets so much more complex. So I just have a question because I, as a backend developer, all I see is just APIs given to me and you don't know exactly nothing about what's going on. And then we're trying to figure out what is the right abstractions to give frontend developers a much better way and chance to maybe reconcile those states. And we're seeing all these new products. There's Instance, you know, LiveBlogs.

There's all these new APIs, SDKs, trying to introduce new primitives or ways to do certain things. And I don't know what will be... It's interesting for me to actually understand what will be the ideal abstraction for new applications. If we can start from scratch, what will be a frontend abstraction for you to handle data? Because from what I can hear, it's just all mess, right? It's all backstage, all that kind of stuff. There's evolution.

If we can start from scratch, is there actually a better abstraction? To give frontend developers a better way to do it back in? Cause I don't know what that looked like. Is it your PC? I mean, it's just music, love congregators, right? And what is actually is that mute should look like. And the problem is it's probably not just one thing and you're going to hate this answer, but like it's the whole, it depends thing.

So for example, if I'm building like something that needs to stitch together multiple services, I might reach for some, you know, GraphQL solution. If I need to do something that, you know, needs more than I need CRDTs. And that's a completely different solution. Yep. Right. Or something that, you know, needs like low latency, I might reach for some edge solution. So really, it depends what you're building. And I think we're building, we're building more than just crud apps. So it's gonna vary. Don't want to crud. Yeah, that's true. So that's why, like, honestly, I've, I actually come from PHP world. Like that's what I started. I'm not even joking. No kidding. For as much, you know, crap as we like to give it just in the mean way. Like, it was honestly amazing. Like, you wanted to like send emails and do caching and the database you havevel and I use like KPHV and Codeignite, like all those old stuff. It's all built in.

But right now in the front end world, things are complex because we have, like you said, so many different services where it's like, yeah, you have a hundred to choose from. So just pick and choose. And honestly, they're all about the same. They're at the same price level, but still we're stitching together multiple services to get what honestly exists in Ruby, in Laravel, in Django. Like it's all just packaged in one. That might be oversimplifying it, but I think it's a, it's a fair take actually, because we're framing this as JavaScript. So we fly, have framework teams that actually go out to these communities and and kind of try and

start contributing content for building we call them real-time apps it's not like the best name but you can kind of imagine what that means um and we don't target javascript we don't target the javascript community at all we like a lot of developers because there's a lot of kind of overlap between communities but the um i think the, and I think it's driven by Phoenix, which is the Elixir, it's kind of like Rails for grown-ups, which is really not nice to say. The Elixir, kind of the Rails equivalent

for Elixir, and they introduced this you'll see, called like HTML WebSocket. And the idea is the exact inverse of everything we're talking about with JavaScript, but it's really the same problem. And what it is, is these people building CRUD apps. One of like app presence to the boring application of all time. But these are features that make sense for back office application.

And PHP has live wire. Wearable has live wire. Rails has hot wire. Django doesn't have one yet. It needs one. It had channels, but no one gave a shit. No one gave a shit. Right.

And some of this is limitation Python and Ruby. I like the stuff you can do with Elixir is just like we can, you can basically build a live view app. And what happens with the live view app is you kind of write your app as if you were writing where and, and what, what happens is you make a change to HTML, literally just syncs to the browser, and there's almost no JavaScript involved. We built this demo app called LiveBeats that was like, do you remember, was it Turntable FM? Yeah, great, great 2012, 2011.

What would a modern full-stack app developer need to be? Those are air quotes again, if you're not on video, what would the modern full stack app developer want to build? Because it used to be like, you wouldn't want to build Twitter, Twitter, like the canonical example, and we're with where it's kind of boring, just not, it is a crud app like Twitter, like database Elon. Um, but like turntables, oh, it's kind of a crud app. It's also got like interactions with people.

This person clicked the button. I want this to happen on this ground. Our kind of thesis with that was like, if you're actually solving the problem that like the most developers have, they should be able to build turntable. And so in some ways, it's still crud. There's still like, there are CRDTs.

I love that. It's interesting because what it is is it's CRUD and you reach for other things, you know, the user problem you're trying to solve. I mean, JavaScript isn't just a mammoth community. It's not going to solve things the same way, like the CRUD backends, necessarily. It's really fascinating to kind of watch this parallel evolution.

Kind of back-end developers coming forward and front end developers went backward and ultimately all they want to do address a user problem. And they're going to reach for whatever helps them address the user. I have lots of hot takes on user. Well, I think the, the print, I mean, this framing is really interesting. Cause like the, you know, being my first language being PHP, you know, when I'm like 12 or whatever it is 20 years ago, you know, the pizza, the myths, amazing about PHP is such a huge enabler at the time. We didn't really have our like JavaScript frameworks were, um, mood tools, right? Like blast from the past. We eventually backbone. That was advanced. Backbone was advanced. J. Curry. J. Curry, right? And our CSS frameworks were inline CSS,

and maybe you pulled that into a style sheet, right, that you couldn't read. And then you used some PHP to string together, like, you know, an experience, and maybe you were cool enough to understand how to pull off, like, an AJAX interaction, right? So you had a little bit of interactivity. But like if you think of it from the context of that, like that was a full stack. You could have an engineer that was full stack and could build a full app.

And a lot of what I think we're saying, what I'm hearing is like really what we're seeing in the front end is the JavaScript continues to go up. It's gotten more sophisticated and we're going and we're trying to basically recreate a lot of the experience we have with PHP, but for a much more sophisticated world in a world that has much more distributed state and that state being a lot more live and online. Right. And as a result of that, a lot of the complexity has moved back to like where user interaction happens on the front end and where that user interaction

happens on the front end, it's like we distill that back and that's having big effects in terms of the demand of what the back end must present. But then also it's what's probably driving this abstraction that we're seeing, right? Where you have tools like Convex or Stately that are coming out and trying to like really offer and empower front end engineers and new experiences they can build without having to like talk to, you know, people like Tim and I. Who are the boring people building APIs. Yeah.

Yeah. Yeah. Boring people. Well, and that's kind of the whole sort of like JavaScript eats everything. Like the thesis is not that the backend stuff goes away. It's just that all of it becomes a service. Exactly. Exactly.

So I guess the question is, okay, let's assume for a second, you know, I think if that's true, it all goes away. What about the enterprise, right? Like this all sounds wonderful. I'm building a new app and I've picked the right technology, right? And I assume all the pieces I've picked continue to work.

Let's assume that's all true. But like, what about the retrofit use case, right? Like, what about, how does this happen? How does this work out in the enterprise where you have massive legacy systems with APIs? Like, can they, how does this, how does that happen? How does this work out in the enterprise where you have massive legacy systems with APIs? Like, can they,

do they get to see this nirvana we're talking about? Or, or is this, like, what happens? I think, I think one of the common things

you hear about infrastructure is it's additive, nothing goes away. And I, enterprise line of business apps will never go away.

Yeah. I don't think they'll become the best front-end experience of all time because it's not it's not always they're not they don't care necessarily they don't need multiplayer in most cases literally the chronical definition of a credit idea is almost every line of business enterprise i don't know that I think what's happening in less that I would call front end is more like because they're taking all the growth. The growth and what's happening is almost entirely dominated by this.

It's replacing anything that's already. It's like we, the company, are not going to replace Amazon, but we'll be successful with a whole new set of customers in some ways. And I think everyone around this table is probably working on the new stuff and the old stuff will stay and there's still Cobalt in over like it's probably a lot of money in Cobalt. Probably really happy. It's probably if you like that, it's probably the most cush job there is. I think there are some vertical apps that will kind of go away.

Not necessarily go away, but like, I think that we saw this initially with like Figma eating sketches lunch, that if the end user, even if the buyer is not the end user, if the end user is like a passionate professional who identifies with their job and the tools that they use, they're going to want to use the best tools. So like kind of the heuristic that I use is if the end user is making six figures, then you probably are going to need to care about user experience as a SaaS company. And you're really vulnerable right now if you don't. Right. I agree with that. Yeah. Which is like a super interesting question because, you know, this creates this sort of this situation for enterprise companies where now there's this architectural change that's happened, right? And whenever you see architectural change, a shift in the way that we build our apps or the way that the user experience, this is where you get incumbents get at risk, right?

And it's not that the spending goes away. I mean, Salesforce still exists, but you always have new categories that are open that it's hard for, like, let's say the behemoth in CRM, like a Salesforce, to go after the new category. They have to acquire or die. So I'm curious, like let's say Expedia, where they are competing, right, for user experience or in a high seat count, high per seat cost experience, like the prosumer enterprise, prosumer area, we have the situation where they are going to be threatened

because the user experience does matter. And so I'm curious, like, what do those companies do? It's like, they're going to want something. So there's going going to be a need and so there's going to need to be a bridge we'll go one a bridge yeah that's true yeah yeah actually i love the idea of um these tools enabling kind of new startups to to really go after boring incumbent companies um a little exciting thing about literally any of that we all work on is in 10 years, there's going to be a company we haven't heard of yet that's threatened Adobe with.

That's right. It's not always bought by Adobe and then rolled up. It's going to be, it's actually going to displace a lot of this stuff. Cool. I think these services should give two-person startups huge amount of ability of building like an excellent UX. Extinctly where it's like this is a this is a huge boost in for where I can really like go on a big company. I think, and I wasn't joking with the p-devs either. I think there's this class of developer

who looks at tools, can use this to do this neat. That's canonically the php dev because why else would you use php? No redeeming. It's a lot of money. And like no one was going to disagree with that. They don't pay HP.

And it's neat. It's neat to give people these tools and really be a little bit disruptive. Yeah. Like, yeah, on that point, I think we're seeing, I just made thisaley is, or our long term hypothesis is, basically, everything is just workflows or state machines or whatever that you just piece together. It's like, oh, I need something to handle payroll. Yeah, that's just a collection of state machines, or I need something to handle authentication. Guess what? Those are state machines. But right now, what you're seeing is that there's a company for you want to add multiplayer just bring in live blocks you want

to add you know uh edge computing or whatever just all these services you just pick and choose from your startups put them together like pieces and just like you you have a two-person startup that's just as capable as you know there's no no one's no code, anything. Code leverage is basically the future. Yeah. Heavy serverless, right? Like, I mean, the whole driving force, like say the business model, if you will, the driving behind all of this is this idea of serverless. That's right.

You know, like I don't run, I don't manage the services. I have a layer of abstraction. I'm working and that gives me, empowers me and enables me, but someone else really takes care of like actually operationalizing that. Right. Yeah. Which is, which is like one of the other functions that's vastly different than, let's say, 15 years ago. Like the idea of having someone else run my code was like an absolute no go. But now we're getting to the point where it's much better understood what that means and

what level of trust I need from the provider to enable me. I think like an interesting question there, though, is like we've talked a lot about how front-end engineers can have a great next decade, but like what happens to the back-end engineer? Like where do they

sit in this equation? Like is everything just services, but like services that I as a front-end engineer stick together and wire up my React and, you know,

like those, like Tim and I here need to go find new careers. Like what's this look like? Yeah. Start a coffee shop. Yeah. We start a podcast, right? That's Start a coffee shop. Start a coffee shop. Yeah.

We start a podcast, right? That's right. We're all going to taste careers. I think front-end and back-end engineers are like a useful option for talking

about things. What you've got, you've got developers who either do things for their users or they're not. Back-end engineers are user.

The front-end team, more often, someone beyond that the really good ones and the new ones no choice but the really smart ones on like what you need to accomplish for the end user how do i use my special set of skills to get there it's interesting we We are hiring like crazy and we can, now we're capable of doing the work that we think we need to do. And we, like 50% of the pipeline probably can work the code that would be necessary to do a job. Why? Probably 2% can make the decisions we expect them to make on behalf of you.

It's just kind of bananas. I think the big differentiator for every developer is like, can you grab a user problem and can you do something about and like, why would you stick to a certain state tool if you need to reach out there for other things? So it's

I don't think anything changes. I think there's deaths and they'll go where they'll apply the tools they want, you know, make the world different in some tiny way. We can, you know, trust me. Yeah. Yeah. I feel like backend developers, we always have to find our niche, right?

Yeah. And the world's, I don't know, I imagine like five to 10 years from now is, you know, all workflows, I really use temporal, you know, databases, every user plan of scale, everybody, everyone runs a flyover. You're left with things that are just still very hard to do. And so platform engineers, we have to go there,

which I don't know exactly what that looks like, actually. If those services take care of a lot of the states, there's still, there's always valuable things back in those times. Right. Actually, a lot more workflow state machines again, but it revolves to stitching another set of stitching. Yeah. Like schema modeling.

I think that's the thing. It's so hard for, I think that's the farthest part of this distinct from front end is, is all right, I have a global view of our data. How do we actually get it out in a way that makes sense? And even the APIs you're talking about are almost entirely very thin things on top of a data store of some kind. And I think that I feel like the whole stack teams are going to be like really good database people and really good front end people. All the stuff in between is not actually super valuable most of the time. It's a lot of it's glue, right? Like if you think about like the Legoification, a lot of what picture of app building.

And I mean, we've been talking about this for a long time, like building blocks, treating like Heroku's. Heroku's biggest thing was like they had, well, we're going to give you a marketplace, a Lego that you can build on top of Roku to couple together some experience. Right. It was very backend orientated experience, but like, this isn't, this isn't new, but I think what's changing is like, we're spending more time on glue, less time on building a Lego blocks. And I think the Tim's point, like there'll still be companies that'll find unique value, like fly, like you rack and stack your own servers, you build a whole bunch of stuff. But, you know, I assume it's because it's based

on some idea that like you're going to create some unique value prop if you're a customer, you wouldn't otherwise, right? And so it's useful for you to like focus on that as an area of competency that makes, that creates leverage for you, right? But there's a lot of, but this, I guess what we're really saying at the end of the day is what all this stuff does is we can focus on the glue that matters and then we can focus on finding the unique value for our business

and buy commoditized stuff for everything else. Yeah. I think the flip side of some of this is actually, I think the most effective front-end developers are going to be the ones that understand data. I mean, it's always, it's all data. They kind of understand the basics of things, joins, they understand what like shared state means.

I didn't see RDT understand how like one way to make a really great experience sometimes is literally connect everyone to the same block of memory and like get rid of all the crap in between. It was what they think my work. Um, and so it's, uh, I think, um, the answer I think for everyone is like, we'll understand the fundamentals of how data happens and how that applies to your world, because I don't know how else you're going to pick the right. Like sometimes

it's like, figure out which calculator to use. Like they'll use a calculator. I'll use ruler to use days. Like, uh, you know, like you still want to play games, snake and drug wars. We have the lemmings on one of those. It was great. Calculate.

Yes. I was in the nineties. So it's different than now. So one of the things that strikes me is like, okay, we're talking about this world where it's, you know, heavy serverless. We're focusing on a unique value prop. We're spending a lot of money on like the commodity things. We don't do things that someone else has already figured out, right?

Initially to the cloud, a lot of the like anti-cloud discussion was about lock-in, right? Like we think about AWS. We think about like even Google's attempt with Kubernetes to sort of disrupt the US by introducing a sort of like monetized layer in which we build our apps on top of, then you kind of move across cloud. Like, where does this, is the lock-in argument dead? Is that what we're saying? Is like no one gives, cares about

lock-in or the ability to move apps? Like, where does that fit in this sort of sum of this equation? I mean, it's for me, it's like a, it's an interesting question. It's a great question. Yeah. Um, and there's a lot of different things happening there. I think, I think there's, um, there's one kind of lock in, which is a behemoth decides

to dictate a new architecture that by lonely beneficial. And so let's just, if you imagine you call it something Lambo, that would be a thing that exists because it makes AWS a lot better that isn't like an organic thing that got invented to help developers or companies do more. It was the flip of that.

I think there's one component of lock-in that's still really kind of worrisome to people, which is is this really the best way to do this? Or is it the best way for the cloud vendor to have me do this particular thing? I think there are other kinds of lock-in people don't care about as much.

I think that multi-cloud never mattered. It just wasn't important. And when we're talking about apps and infrastructure as being active, multi-cloud is frequently like just building your next project on a different place. It's actually a super complicated thing. The shelf life of so

much software is almost six months. It's not as huge of a problem. The other kind of I think the lock-in I've noticed people being really wary of lately are particularly people that are trying to build some examples. Frequently of startups that build on top of a platform of some kind,

and then they, like, wake up one morning and just literally build in a special way, or we just consume this other stuff in an intelligent way. Yeah. And, like, prove the market to ourselves, and now we've got to build our real thing here. I think the idea of lock-in and cloud was just, it's just not a big deal. Right. It's almost, yeah, you was just, it's just not a big deal. Right. For the most part. It's almost, yeah, it's, it's wouldn't, you wouldn't say it's, it's a risk, but it's not

as much of a risk as it's a suggestion. It's not the top 10 things that are going to cause you problems. Yeah. Also lock-in is kind of about like why people are afraid of lock-in is because you're locked into something that a vendor has pricing power over you. If the lock-in comes from the user experience being better and being the thing that you want to use, I don't think that people are like, now more than ever, people are willing to pay for things that are like differentiated

in terms of quality and actually the software that they want to use, the services that they want to use. Like if the lock-in comes from something organic like a better user experience or a better product um i i think that like we're seeing it with bursell a little bit we're seeing it with figma like we're we i mean when people pay more for notion than they could otherwise pay for other note-taking superhuman which i've been using still for some reason. Oh, it's 2023. What's the next email app?

But people are willing to pay for stuff that's high quality. What people are afraid of is getting locked in to something that's low quality and a vendor having pricing power over them. Incredibly good point too because we've also, one of the fixes for lock-in

is almost like usage-based pricing that scales as you get value out of things. You get really locked into stuff because your company agreed to this huge contract that you made those years. You actually get locked in because it looked good enough that you use it a lot. And at some point you're like, well, that was cool. This is what we're doing now. Yeah. Like $40,000 or whatever.

I guess my concern is like, I spent a lot of time in Salesforce and I mean, it's no Cool. Because this is what we're doing now. Yeah. Like $40,000 or whatever. I guess my concern is like I spent a lot of time in Salesforce and I mean, it's no secret that Salesforce and Oracle have an interesting relationship. Salesforce has struggled to get off of the Oracle database and there's been tension in that relationship, right? And there is a real lock in there that does have a sort of pricing power component. And so as a business, you have two concerns when you're buying a vendor. One is like business continuity, which is, is this business going to be around tomorrow?

Right. Cause I actually risked my business. I don't think I can use the word lock, but I think I think of these two things. It's like, how do I retain business continuity? Right. I think the other part of lock-in is yeah, it's a pricing power component. And so I think like this maybe is just a stage of eco like the business community concerns more maybe stage of ecosystem like we're very early in this sort of like shifting more functionality being available to the

front end engineer and a lot of that coming up a little bit than it is more the price and car concern. Right. Yeah. So I also think there's a tension right now between the Lego Blitz and OpenTorch. And so when we were talking about, um, like the community really use third party service, the features that you'd open here. And so in general, you know, post-press, I mean, then whatever we can build on top of that, and we'll grab these libraries, like the commercial version of a library, very, um, it's very no permission necessary. There's's no there's no point to ask people things

the con thing is uh which i don't know if i'm saying that word right it's not really on their radar because they're just by default not picking things they're going right for them versus i think a lot of front-end tools, I think people have to think about that a little harder. If you're playing for multiplayer in your particular application, you really have to worry about how the company is going to continue. One part of lock-in that I think is pernicious

is almost like when you adopt a tool for a problem, you run the rush. It's a little too late. You've gone down this path. We call this the Stripe problem. If you use Stripe's non-core features, subscriptions, I'm sorry,

I don't have any Stripe for you. If you use subscriptions or anything that's not for LIT, almost, you really quickly have limits it's really hard to get away from them I think that might be the developer I might be a little worried about that constraints like being held back

I'd love like David to hear like as you're building out the state how you think about this from like a builder of a Lego block for furniture how do you think about sort of the sort of lock game business utility argument? Like when you talk to customers, what's, what's your thought process on, on approaching this as a builder of a Lego block, much less, less of a consumer. Yeah. So my, uh, I don't know if it's a unique viewpoint on lock-in or not, but um, typically lock-in is, you know, we, you, you have to use our cloud service, right? And if you

don't, then, you know, our product pretty much becomes useless to you. And so I guess that's daily our alternate viewpoint is that instead you pay for the tools and the services, but you own that code, like that code is yours. So I'm saying, I mean, there's so many great startups starting up today, like, again, these blocks like clerk for authentication, and front egg for user management, and also authentication and things like that. But you really have to go through their cloud, but they make it so nice for you to just use their cloud keeps in their cloud, you know, their services. And it's hard to move away from that.

But right now, at the current price points, it doesn't matter. Like, even as a small startup, it's like, okay, sure, $20 a month, whatever. You know, same with Vercel, right? Like, we could definitely take our next JS app and deploy it to our own AWS, you know,

servers, but we won't because for ourselves, so easy. Yes. Yeah. I think one of the things I often think about when we talk about like Lockit is like where I think open source is an interesting item is like, where do like open source standards fit into this Lockit discussion? Like, what are the pieces that like, you know, I assume as the ecosystem grows up, you know,

is let's say Stately becomes incredibly successful. You know, maybe you'd be forced to go to the enterprise to like adopt an open standard so that you get so enterprises are more comfortable buying and having switchability. Right. Like the process model is amazing because as long as I have a POSIX system, you know, Linux distribution on the cloud and like my process should be able to run. Right. And so I think we're still missing that layer potentially. And I guess my fundamental question is like, does that open standard layer go away? Like actually, or are we just searching to find the next one for the next abstraction

that we're pursuing today? Good question. It's tough, right? Because as a backend engineer, we've always been obsessed with OpenStandard. Because we are always afraid of supporting something that just starts good and sucks in the end. You know, Oracle, Teradata, whatever you pick.

And then backend, we're working on Docker data. Why are we so important to come up with you know osi osis and all the storage interface because there was a war going on everybody wants to go and fights and no one knows which vendor is actually the better one yeah and so instead of me trying to choose between all you crazy people and why don't we just come with a standard that actually i as a buyer i don't have to really think so hard. I can adopt a standard. I can always switch.

Versus maybe like a Stripe API. These things we haven't seen, nobody really cracks way wider. I mean, there's a few other alternative paper providers, but Stripe really tuggles. There's nobody actually implements as well as they are. That's true. In the full implementation, so there's really no competition. Yeah. And then there's really no motivation to even do any sort of standard,

I feel like. At least in my experience, I always feel like standard is a way to get away with things that are not as great sometimes than the main. At least you feel more comfortable adopting it. Yeah. The user like the sequel, it doesn't matter, you know, that sequel will look very different to that sequel, but it's still somewhat feel like a safe sequel.

So it's still, there's a standard, there's an FC standard that's kind of pretends most things are the same. But it gives comfort to the user a lot where like, I don't have to relearn a new language or something like that. And so I don't know, there's, it's tough.

I haven't really seen any good story about people worried about standard. As a user, you always love standard. Yeah. But it's always worrisome

is that actually you're hiding too much or a leaky abstraction. Right? Does it truly have all the vendor that that or have all the ecosystem supported like kubernetes become the standard not because it's trying to come up with you want the interface yes because of domination sequels somehow want it through vendor fighting and And in the end, we shouldn't let the user have to also fight with us. Like TPC, we have all these benchmarks plus a SQL. It allows us to fight in the end.

But our users shouldn't worry about all that stuff. And it seems like if there is a lot of competition up front, people tend to want to see that. There's not much. I feel like it's just like over dumb. I think it can also come down to like, which matters more, um, stability platform or iteration. Cause you can't really iterate on standards. Like you can like a product. Yeah. David and I are seeing this in the react community a lot right now where it's just

totally stagnant, stagnant relative to where it would like all of the iteration that's coming from it is coming from companies. It's coming from places where you can iterate on it like a product. And for certain things, you don't want that for certain things. You want to know what you're getting today is going to be the same a year from now. And they might kind of make changes around the edges, but it's about the same. And that's true for databases. That's true for Kubernetes. That's true for a lot of things. But it's not true for everything, you know?

I think there's another component of that, which is, if you imagine one of the interesting differences, historically, we're like tolders in front and then back-end engineers, is a lot of back-end work is actually considered really mission critical for companies in the sense like they're actually really concerned about this stuff breaking and so if you're a back-end developer and you want to do something about the thing you can pull open source because you don't have to go solve this problem ahead of time and you can start using it um if you're a front-end developer Vercel has never seemed threatening to companies just yet. It makes total sense to use Vercel

because it's kind of obviously, it'll probably run better than whatever you come up with. And for some reason, most companies don't really look at that as the same threat. It's kind of the same problem as data. I mean, for some reason, it's like, where does the data live? I think one thing

that may happen, and one thing Vercel might actually have to worry about is the more sophisticated the front-end people get, the more they're not going to fit in Vercel's box and this stuff comes into play. I think you all, this is like your code. We get all this tooling. I feel like that's an amazing model where it's, you run this and if you want to pay us, it's better. If you don't want to pay us, it's still worse. It's still yours. I think that's, I feel like the answer for most future stuff. Yeah. As a crusty enterprise buyer, like just in the way our procurement system would work, I, like, I believe that like what David suggested

is something we'd be comfortable with. It's like, well, even if we don't pay you or you go bankrupt, our stuff will continue to work, right? Like, you know, when you're operating at, you know, hundreds of millions in ARR and you're, you know, going for the IPO, it's like your thought process is

switching costs really matters, right? Business continuity really matters. And so, yeah, we pay a lot more money and we also have expectations of like how we walk ourselves out of this, right? And so when we make decisions, buying decisions or buying decisions are mostly propagated around,

well, is this, how critical is this decision? If this doesn't work out, what does it mean? And how do we do it? And so there's a certain amount of the question of lock-in is always like, how do I don't get fired for buying a Dell computer? I think that's sort of the question of what I'm asking, how you don't get fired for picking up some front-end component that's critical to business. And maybe the answer is loss, which we're really, really early still in this ecosystem shift, but long-term, we believe DX

wins out. And then there is, as you approach different markets, maybe the buyer, as the buyer changes, they force standards to help make it easier to swallow. Well, and it's changing so quickly that the person who could fire doesn't know what the heck you're doing anyway. It's true. That's true. Yeah. They've been laid off since these conversations. Yeah. off since this conversation started. Yeah, one of the things that was really interesting about Vercel that I was thinking about when you brought it up is like, you know, Vercel actually,

today still, Vercel is a very low switching cost, right? Like maybe you can't get the same experience, right, in terms of like the way it's like to use as a developer. But for me to take my front-end code and push it to a Netlify or unfortunately run it myself or use a flight at IO, it's like, it's possible. It's not as great, but it's definitely possible. So there is really a lock-in argument on Vercel because the only lock-in there is workflow. And you're just sacrificing workflow and productivity.

You're not sacrificing end-user experience. Vercel's business is cool because they're a workflow tool that gives your CDN money. Yeah. I think that's a very cool way to do a business.