How Vercel thinks about Next.js
01:11:47 Share

This is jazz party, your weekly celebration of java script and the web. If you like this show, you love the changes, its news on the deal, interviews on some talk show. That's a lot like jays party.

Now i'm thinking about IT find us by a searching for the change log wherever you listen the podcast big things reporters at flight I O launch your APP in five minutes or less all around the world. Learn how F I I O K. Hey, this is .

part time was of nerds. I'm here, the curt magi cofounder and CEO of fly. You know, we love fly.

So curd, I wants to talk. You buck the magic of the cloud. Yeah, thousand is right.

right? I think it's valuable to understand the magic point to cloud because you can build Better features for users. Basically, if you understand that you can do a lot of stuff, particularly now that people are doing elle m stuff, but you can do a lot of stuff if you get that.

then can be created with IT. So you say clouds aren't magic because you're building a public cloud for developers and you go on to explain exactly how that works. Does that mean you?

And some means these all came from somewhere like there was a simple or time before clouds where we get a severe rax shack and we is at tell IT into IT even and put files somewhere and run that web servers ourselves to serve them up to users. Clouds are not magic on top of that. There's just more complicated ways of doing those same things in a way that meets the needs of a lot of people.

And that are just one one of the things I think that people miss out on. And a lot of this is actually because A B O and G C P have created such big black box subtractions. Like land is really black box.

You can't like pick up part land and see how outside you have to sort of just use what's there. But the really is like land that is not all that complicated. It's just a modern way to a loge little bms and serve some request from them and let them like kind of pause and resume and free up like physical compute time.

The interesting thing about understanding how clouds work is that let you build kind of features for your users. You'd never would expect IT, an aromatic version of this for us, is that, like when we looked at how we want to the user code, we decided to just expose this machines concept, which is a much lower level I abstraction of lambda that you could use to build lada on tabo. And what machines are just these vms that are designed to start really fast or designed to stop and restart really fast.

We're designed to suspend sort of like your laptop does when he closes and resume ly fast when you tell them to. And what we ve found is that giving people is permanent is actually there's like new being built that couldn't be built before, specifically because we went so low level and made such A A minimal abstraction on top of generally like linux cornal features. A lot of our platform is actually just exposing a nice U X around linux cornal features, which I think is is kind of interesting. But like you're still need to understand what they're doing to get the most use set of them.

Very cool. okay. So experienced the magic of fly and get told the secrets of fly because that's what they want you to do.

They wanna share all the secrets behind the magic of the fly cloud. The club for production developers, the club for developers who ship learn more. And I started for free at fly dot I O. Again, fly dot I O.

A little party people, is jared your internet friend? And today I have something special for you, a one on one with myself, of course, and with tom oko, who is the chief product officer at versie. Tom, welcome to js party.

Thank you so much. Really good to be here. Preciate you have me on the show.

You I had to check notes, not because I didn't know your position, but because you recently change positions, right? You were previously VP of engineering frameworks and now your chief product officer. Assume that's a promotion.

right? Yes, sort of I think, you know, when I ultimately ended up the senate to join, we thought the right role is probably an engineering leaders ready, got a great VP of engineering, but maybe we could have like two .

sides of engineering .

and platform. And like shortly after I joined, the very quickly became clear that the opportunity was gonna to help engineering product design in a couple of other functions, coordinate and sort of orchestrating the product development process and some other things.

So you talk more about that refining, refining. Well, you go way back with react .

the time I actually .

found you way back. So on another show, we do call the change log. We didn't episode about react way back. Not the beginning. You predated me, but he was twenty and fifteen and actually found you in my email history because you are almost on that show. IT isn't not being Christopher shadow and sensor irans, but your name was in a list of people I were going to be on this show. So you've been you've been doing the react thing for a very long time.

Yeah, I like to say that anybody you can come up with who was associated with react and react native or java script and infrastructure at the beginning, they were sort of like on my team or in my org at facebook OK. So yeah, you don't work with them for a long time. But or arens great guy. But yeah, all the way back to the very beginning, a Jordan walk ended up joining my team, showing me this thing that he had created. We gave in five minutes, and then we returned IT into .

react IT sounds so easy, so easy when you say like that, what we are initial thoughts, were you impressed? Were you scared?

Were you are my initial thoughts very honestly? Oh, gosh, Jordan, please go away. We have too many of certainly don't need another one.

right?

But I think the reason that Jordan, one of the reasons Jordan came to talk to me was because the part of the company that I was, I was part of a, which was called product infrastructure. This was the type of thing we did. We build tools to enable developers to be more efficient.

So it's kind of in my nature of technologists of curious and like, okay, like I don't have time for this button. I want to learn more. And you know, once he started showing IT to me in and once I saw the potential here, I started taking IT much more seriously than just like a little side project. So yeah, my initial thoughts were like, please go away. And after a couple of days, I was like, minute here.

Was that something that you had to advocate for inside of facebook? Because lots of engineering, engineering culture was IT. A bottom of kind of a thing was at a middle out, was at a top down. How did I should get adopted?

IT, yeah, I think product direction at facebook was a combination of top down in bottom up. But certainly engineering and technology choices were very much button on. And so IT absolutely was something I had to advocate for.

And I think the way that Jordan actually made his way to me, he actually was in the ads org, which was there were building some really cool um especially for the time and really sophisticated clients apps. And when he came to me, he was like, look, I talked to everybody in the add ork and they're not interested. We are too much to do. They don't have time for a skunk works. New framework, what do you think? So actually, by the time you gotten to me, he was kind of looking for an advocate internally and yeah we we found on the product infrastructure team a number of uh, folks that would kick the tires and and tested out and sort of validate that there was something important here and then yeah, I became kind of the primary advocate internally for not just react but also eventually open sourcing in which almost didn't happen.

What why not?

Yeah, it's a good question. I think there was as many folks internally, there were as many folks internally that thought that open sourcing something was a bad idea as folks who were very experienced with, familiar with, passionate about open sce that thought this was a good idea. And so the reality was, IT wasn't just like, uh, we built a thing.

It's good. Now we open source IT, right? IT was like, wait, what are you talking about? We had some folks from microsoft to you, sort of a third hundred bill gates.

Bill gates didn't early days, did not like open source. And we had a number of folks who actually thought that, well, wait a minute, IT does seem like we have something here. Shouldn't we consider whether or not this is a strategic advt Lucy decking that we had a number of people who were very passionate is myself included.

And our C T O. Ultimately, you know, when I came back to IT, the C T O was very supportive and ended up through a series of conversations helping us overrule the kind of vocal minority network, anti open source. And then, you know, I think this was the first open source project of the modern facebook open source era. And IT pave the way for lots and lots of other projects, including, for example, PyTorch and and some other projects that came afterwards yeah that .

ever that we did was twenty and fifteen. And we we were talking graphically, we were talking react native, of course, which these are all on the tale of react. But even outside of web, dov, like he said, inside of facebook, there was epic projects like PyTorch, which are really sort of defined an industry or an ecosystem in the open source world as well in their own right. Looking back now because that was I think the first initial release was twenty thirteen, but probably IT was announced that he was a jays conf in twenty day.

Well, J S. Conf U S. Twenty thirteen. But we definitely were working on in earnest yeah.

And then from my perspective, the initial reaction was not overwhelmingly positive because of js x possibly like where kind of what is this thing that .

was really generous, he said. The initial reaction was not overly positive. The initial reaction was terrible.

People hate in IT. Actually, I think this isn't on the audience. This was on us. I think the story that we told worked pretty well for an internal audience that knew where we came from. And the sort of what came before this actually LED to this.

And if you're looking in internal, like, ah yeah, this is the evolution of that other thing that we have. But externally, I think the community is solving a bunch of different problems. They were talking about more efficient two way data binding.

They were talking about constructs like object that observe being programing language features that should be in J. S. And we were talking about like, oh, you don't need any that so we came up and we're like, look at these facebook folks.

They have no idea what they're talking about, the rest of the industries over here and facebooks doing this weird thing, right? And the famous kind of quote was like, look at you guys chAllenging established best practices and IT wasn't until actually the next conference was jays conf eu later that same here where pete hunt actually embrace that. Montreal is like, actually that is what we're doing. We are chAllenging, establish practices is we think they're not good or because we think they could be Better. Yeah, initial reception was not great.

What change the time? I mean, how do they start to take over them?

Yeah, the same thing that changed my perception, which was giving in five minutes and playing with them started to happen in the community and very, very slowly at first, and then all at once. I think there was an engineer at, I think was code academy icon academy logic, a sophie Albert, who just started tinkering with IT.

And we had set up, uh, you know, I R C channels so that people could kind of tinker with IT and give us feedback and play with IT. IT was very early. There was almost nobody using IT yet, certainly nobody using at at scale and production. But sophie alpert not only started using IT, but also started suggesting things to make IT more appropriate for folks and to make IT Better, and eventually became our first external contributors. So at that point, all of the contributors were internal.

But so he became the first external l contributor and started actually like making IT Better and making IT more approachable and starting to answering questions on stack overflow and like you know, getting involved and turning in and do a thing that wasn't just a tool for internal facebook teams to use. So I would say very slowly, over the course of the next six months, they started to pick up a little bit of traction. And then sometime during twenty fourteen, IT started to become real.

And that's when, you know, Christopher shadow on the team was like, tomo, i'm seeing like twenty five tweet a day about react. Can you imagine IT was crazy, were like, wow, who are all these people that are using this thing? He's like, maybe we should start organizing a conference.

And IT, was that organic and that bottoms up and know, one of the things I really take pride is the fact that at no point in the history of react has anyone who worked on react told you, behold, we've solved the internet like, we've done something amazing. You need to try IT. There has never been any amount of uh, sort of pushing react on anyone.

It's always been. Hey, here's something that solves a set of problems for us that we're pretty excited about. Give me a try, if you like, IT too.

Let's talk. Let's collaborate. If not, no sweat. There's lots of great solutions out there. This is just one of many. And so I really love that the whole time our narrative was this not a sort of in your face you must try IT that is to prevalent today and that's what I think LED to the slow burn of adoption, this sort of everybody giving IT five minutes at a time and saying, wow, there's something .

important here. There's an interesting relationship between that organic growth with react and yet facebook's large microphone and not just the microphone, but just the cloud that you guys get by being engineering a scale. And often times with open source projects and small shops or in deaths, we look to a facebook or a google or a microsoft, whoever.

And say, well, this is good because it's good for them. And I think that's true sometimes. And I think in the case of react in in lots of scenarios, that is true, but it's also false sometimes. And I wonder how you see that from me, your perspective because just because it's from facebook doesn't mean it's good. And yet there's people that will think that and sometimes that can help grow adoption as well.

Yeah, I think the perception really helps that. Okay, this is battle tested. They're using IT in production if it's good enough for them, it's good enough for me, right? But the sort of counter to that is that I don't really have their scale. I don't really have their problems of massive engineering teams is just me and in a partner, and we're just kind of building this thing and who knows if it'll even be anything.

So one of the things that I think differentiated react from potentially other solutions was this idea that we always cared about the zero to one case as much just be Carried about the like ten thousand foot, massive team, massive code base situation and and in fact, over time, reacts surface area, API surface area actually tried to simplify itself to lower the barrier entry with every every release lower the barrier entry, rather than saying, like, oh, here's all these net new things we created for facebook scale. So I think we've ended up striking the right baLance between like you get the credibility is succeed with knowing and the confidence knowing that this is running in in production at scale for a behemoth like facebook. But you also get that like very low barrier to entry, easy to get started. Uh, it's at and those two things, I think, combined or what made IT start to take off.

So the rest is history. Of course, there's a reaction as document there at this point, the honeypot folks.

Another, there is a honeypot documentary, right? Very well done by them and that's after I left facebook. It's kind of how I got told back into .

this world where on there I and we .

going to a bit more detail and for some examples and some fun, uh you know anette about the open source release and what was happening internally. Definitely checked that out. If you haven't.

Yes, if you want to deep dive on the history, react. We love those honey pot documentaries for no other reason. Then they are good. And they talk about things that interest me for a long time here.

IT changed like we wanted to do those kind of film documentaries, and we just never had the skill set or the money or the drive to actually get that done. But we wanted something like that to exist, or like we should, someone should tell stories with video, like a note of of, of react of these things. And just happy that somebody did IT because now he just got .

ta wash them when .

they come out right. same. yeah. Super cool.

Was a friends, i'm here, a friend of mine, a good friend of mine, Michael Green, age CEO and founder of work. O, S. Work of us is the all of one enterprise. S, S, O and a whole up more solution for everyone from a brain start up to a enterprise and all the AI apps in between. So Michael, when is too early or too late to be to think about being enterprise ready?

It's not just a single point in time where people make this transition. IT occurs at many steps of the business enterprise single sign on exam don't need that until you have users. You're gonna need that when you're getting started.

And we call IT enterprise future. But I think what you'll find is there's companies when you sell them like a fifty person company, they might want this if especially if they care about security, they might want that capability in IT. It's more of like sb features even if they're tech forward at work or west.

We provide a ton of other stuff that we give away for free for people earlier life cycle. You just don't charge you for IT. So that off kit stuff, I mentioned that identity service, we give that away for free up to a million users, one million users.

And this competes with all zero and other platforms that have much, much lower free plants. I'm talking like ten thousand, fifty thousand, like we give you a million free because we really want to give developers the best tools and capabilities to build the products faster, you to go to market much, much faster. And where we charge people money for the service is on these interpretive things.

If you end up being successful and grow in scale up market, that's where we monodist, and that's also when you're making money as a business. So we really like to alive our incentive across that. So we have people using off kit that are brand new apps just getting started, companies in y combat or side projects, hackston things, know things that are not necessarily commercial focus, but could be someday you're a future proof, their tech sac by using work of us.

On the other side, we have companies much, much later that are really big who typically don't like us talking about them logos because there are big, big customers. But they say, hey, we we tried to build this stuff where we have some existing technology. But out of happy with the developer that built IT maybe has left.

I was talking last week with the company that does over a billion in revenue each year and their skim connection, the user provisioning was written last summer by an intern who's no longer I ve said the company and the thing doesn't really work and they are looking for a solution for that. So really wide spectrum will serve companies. Is that not you know their office is in a coffee shop.

They're living in them all away through they have a know their own building in downtown santo or a new york or something. And at the same platform, the same technology, the same tools on both sides, the volume is obviously different. And sometimes the way we support them from a kind of customer support perspectives is a little bit different.

There needs are different, same technologies, same platform, just like a of right. You can use pay them ten dolla months. You can also pay them ten million dollars a month, same product or more.

Well, no matter where you're at on your enterprise ready journey work, OS has a solution for you, the trust about complexity. Copy that A I alone sale indeed. And so many more you learn more and chick them out at work.

O S dot com. S, W O R, K, O S dot com. Again, work with that com.

So what brought you then? You have facebook for a long time, I think twelve years, if I read your linked incorrectly, maybe more. What brought you to tell them?

yes. So you know, actually during covet, when I ultimately decided to leave facebook and I got my org to a really good place that hired two senior leaders to lead the two sides of the or the react side in the web core web platform side. And you know, this feeling during cover is very isolated.

And I was like, okay, it's been a long run. We've had a lot of fun. I feel like we've gotten do a good place now.

I I can take a break. And I didn't really actually, when I left was very good terms. I still talk to my old team often, but I didn't really have any intention of doing anything else.

I wasn't not ready to go back to work. I wasn't going to start thing. I just wanted to kind of explore and tinker and build things.

I did that for a little while, and I I kind of started to get a little bit anti. Turns out I have a lot of energy left. I have some gas left the tying counter about six months.

But the other thing that happened is actually the because of the filming of the react documentary, I got to like connect again with these old friends and former colleagues. One of those people was sebastian mark bog. He he was was living in new york at the same time.

Know we got got to talking about this sort of like next wave. And here's the next innovation that's coming. And he's telling me about next J.

S. And he was at verizon and he's like, you know what, actually you should join us. So I connected with uh, the C E O K jara rosh, who i've known actually since two thousand six. He and I actually were both core contributors to the bootoolgah strip library.

We go way back, your core contributed to motors.

Yeah yeah, one of the first. Yeah, if we go way back.

that gets you some serious street with me.

Yeah I think i'm actually the one that implemented and ruined javascript. Reluctant even talk about IT. yes. So yeah, I I had known this season some others for a long time.

And so I started talking about what what is IT that for ourselves actually trying to do? Is this just like monetizing and open source library? That seems ill advised and IT wasn't.

It's actually significantly more ambitious. And I just gonna got hooked. So we started talking about, and we kind of opened with this.

We started, alright, if I was a join, like, what's the right role? What's the right shape? And in true shero semble fashion, I was like, look, this is a rocket ship.

Like, i'll take whatever see and i'll figure that out in post. And yeah, the rest is kind of history I think IT IT took about, I was fun employed between facebook and herself about eighteen months, maybe not even. But yeah, then I I was ready, wait back to work. And then I had amazing team here and I really .

love we're doing that actually think that is boring.

pretty great. But yeah, no, I agree. Too much energy left.

Unless you going to find like something completely different that you absolutely love and you can do that. You have to think yourself, and as something othe wise, you know, a lot of people, when they retire, if they don't have something else, then they honestly, they just die prety quickly there after. I think we have to be active and thinking and striving in our lives to have .

a reason to keep the so that is very cool.

Next j is fascinating to me. And a lot of lines draw back to react. Of course, in addition of the tech, obviously, it's a react framework. So it's built on know the same principles. But as a strategic move, my first cell, you know, it's a similar thing as react blood into completely different scenarios, right? Like for a facebook IT was open sourcing.

Maybe IT gets them some maybe he gets facebook some engineering benefits of like making I mean, certainly did making them more attractive to engineers know people are retrained on your technology when they come in the door. That's pretty nice. So like there's a lot of hiring benefits for facebook and maybe some goodwill out there. But for for zl, this is like really great marketing, basically, right? Like this is a really smart way of just getting people on your platform is like build a frame that they are going to use.

Yeah, absolutely. I think there's like a lot of sort of top of fun. All but the other thing that I really like here is and I want get this point right versus reached the point now where we don't build next J S.

To make money. We make money with this managed infrastructure of business in order to keep building next J S. So it's nuon, but it's actually really important.

A lot of people think like oh monodist ing open source can never work at scale long term. And so you have to find a more durable, more sustainable way to fund the open source development. And the most durable, sustainable way we found to fund the open source development is to be really passionate about open source.

And the sort of like I I know rising tide lives, all boats associated with the innovation that you can kind of get back. So the thing that I really like about next js is obviously the way that facebook uses react. They have to fill in a lot of other gaps and answer a lot of questions.

How do you do data fishing? How do you do browsing? How do you do server rendering? And all those things end up being very tired to facebook infrastructure and kind of a spoke. But if you want to use the full power of react outside of facebook, you kind of do need a framework.

I can I think even at the most recent react on the core team is kind of admit, like, look, the best way to use a reactors with a react framework and IT fills in a lot of those gaps for you. The thing that I really love about next J S. Is we can actually build the framework and the infrastructure in tandem.

Turns out we have opinions about software architecture. And at the end of the day, we're trying to enable this sort of like pretty great developer experience that leads to an exceptional user experience and performance is paramount as part of that. And when we build these two things in tana IT, turns out like you get the same benefits that facebook gets from building their own frameworks and building their own infrastructure or that apple gets from building their own software and their own hardware.

So we kind of innovate in tandem, and we create something that is extremely cohesive. If you author your code this way, we can automatically deploy optimized infrastructure that way. And then we're not done once we get IT working.

And we've proven that we have a highly cohesive end to end stack. Now we can actually generalize. Now we can qualify the themes between the front end and the back end and say, okay, we've created something is highly cohesive, but we've given IT loose coupling.

So you can take next J S. And you can run IT on your own. You can self host IT.

You can run IT on other providers. Or you can take for sales managed infrastructure. And you can target the same build output API with your framework.

And you can run IT on ourselves, managed infrastructure. So this kind of like framework to find infrastructure thing, I think, is something that used to only be big tech. You know, google had their version of this, facebook has their version of this, amazon has their version of this. But now we have that for the rest of the world. So yeah, the thing I love most about this java script framework next year, as is that IT influences the the infrastructure that gets provisions on behalf of your application, right?

A lot of those have found that deploying next to us to non vers l things is not straight forward. Now maybe that story has changed and i'm outdated, but i'm curious from your from your standpoint, is that then a factor of that window function between this time when you're building the info and then you're creating the themes and doing the other things and it's gonna Better or maybe it's getting Better.

Can you speak to that? Yeah, it's probably a function of two things. One is that sort of window between ation and generalization, but the other is, is actually the way that you deploy next to yourself and all of the things that you have to consider there actually just is a lot associated with hosting and a sophisticated application.

And so the steps that you have to go through, we can document them all and we have it's gotten a lot Better and even just the past month or so, but IT still is a process. Here's a bunch of different things that you need to set up on your own. And actually, I think that's great for anybody who likes that type of work.

We documented very well, and we will continue to refine and simplify our time. I think it's onna get Better and Better as we go. Like for example, you know, you used to have to install special dependencies in order to do image optimization and taking care for you automatically will continue to refine and make IT Better.

But I think the value proposition of something like versar is okay. There's a lot that was into this, and I don't that's not necessarily how I want to spend my time, if you will love to spend their and that way, that's great. We should compare notes because we have some folks that like to spend their time that way as well.

But for me, i'm like, you know more focused on the end user experience. I really just want to build my thing and I don't want to think about how it's A I I just want to like get post and it's done. So yeah, we're going to drink the right baLance between like making IT fully self service able and fully self host ball.

And for the people who don't want to think about that, here's a great way to host. And we think that versicle is is probably the best waste way to host next three years. But if you want to drink around your own, if you want to host yourself, will provide you with all the tools. And we are committed to continue to make that Better and Better over time.

Coming back to the D X versus U X thing because I think I heard you say something that I tend to agree with, a lot of you'll disagree with, which a lot of people say that development experience and user experience are almost always diametrically opposed like you're picking one or the other. And so you pick developer experience and you don't pick you and you ruin the user experience.

And of course, that's the most extreme side of that particular argument, the shades of grey. I don't believe that's always the case. I recognize our trade office that you can make, but I just love your thoughts on this. I think that we are aligned on IT. I like to have your ammunition for my future conversations.

absolutely. I do not think that this should be a trade off at all. K, and i'll give one example of the opposite case that then what you described in order to enable a truly exceptional user experience, the developer experience was so, so bad that nobody wanted to contribute to the thing.

And so IT eventually just died. Facebook built an APP called paper for I O S. And IT was around the time that the iphone 4 s was released。 IT was such an incredible APP ahead of its time.

Every gesture was smooth. Everything was sexy. Frames per second animation. IT was built on a technology called asic display kid, but I was so manual, everything was very hard to work with as the development is very y to get things wrong. You know, one sort of line out of place. And you were seg faulting the APP and hard crashing because I was doing direct memory access, direct access to underlying you, canvas painted views and so on equipped.

You could use this happen to be like, this is the best feeling up i've ever used, an amazing user experience, but because the developer experience was so that was full of what we call foot guns, or you know, IT IT didn't enable developers to fall under the pit of success developers and you want to work on IT. And so that great user experience, there were two or three people who added in their head that could make changes. But ultimately, the APP kind of just didn't scale, and we kind of a shut IT down eventually took some of the lessons and some of the tack incorporated into the main facebook up, but paper didn't live on.

And then on the other hand, I think every day we're confronted with software that we use that is clearly optimized for a sort of time to market and nobody really put any care or craft into IT. And it's just like, look, I can tell you, just kind of like put this out there and IT solves a purpose. IT solves a nee, but it's not where I want to spend a bunch of my time.

It's not the lightful exceptional user experience. So my strong belief and actually I think that one of the ria conkey notes, I gave us a whole spill about this. The only reason to invest in a great developer experience is in service of creating an exceptional user experience and then being able to evolve your APP and keep IT relevant over time, while preserving and maintaining and enhancing the user experience.

I think that these two things go hand in hand, and you should be focused on, as a framework author, as a platform author. You should be focused on great developer A P. S. That by default, create great user experiences. We've seen quite a bit of this in swift and swift U I. I think apples doing a pretty good job here of making IT so that hey, if you just write your code this way, look at the great user experience you get and you know like, oh my gosh, this code is easier to write.

And that's what I love about react as well because we have this component as the isolation boundary component, as the sort of logical, this is my container, I can optimize the insides of that component and the user experience associated with that component and maintain the same contract with the rest of the application. And then somebody else can work on this piece and that piece. And even though we're working on different parts because we've maintained these contracts, we can have a really good feeling application. I can continue to refine my one component and make IT Better and Better and Better without degrading any of the rest of the APP. So yeah, I think they go hand hand.

Yeah so react really that's what I think reacts legacy will be as IT introduced this component as I think as human S A. Shara who said, like we have a new atomic unit or elemental thing in web development, which is now the component which thanks to react for that, the one way data flow, like all the stuff that comes in the isolation, but there are other ways of making components, and there are plenty of people who are vying for you to make components there.

And i'm just wondering how tied to react next js is as a framework because perhaps something else comes along, which does that thing Better than react is next. And react this point, they've merged into a singular autonomy? Or like is there scams in there? Is there ever a future in which next is an awesome framework but not .

the react framework? Yeah, a good question. I think there are enough themes and there I wouldn't describe them as inextricably couple, but I think like extremely spiritually aligned. And next year as does see itself as sort of filling in the rest of the story with react as as the right permanent.

I actually think like there is no reason to want to move off of react, especially given that there is a series of problems that just we don't need to solve anymore that are solved by react. So my is sort of take here is that would be a huge distraction to try to decouple them. But there are seems, and there are sort of this is clearly next just as responsibility.

This is clearly react responsibility. That said, I think I actually really love to see the proliferation of frameworks and new ideas. One of the things I I loved seeing was the react team leaning so heavily into the compiler. The new react compiler that was just released in beta recently, that work extreme was heavily influenced by the existence of felt.

The react team really looked up to sort of rich Harris and the team working on spell and there were ten a great ideas there and I think they've been influenced in that direction and then also felt was influenced uh from react, of course, right. And then zoom in out even more. I actually very OK with.

There are being lots and lots of ways to do things, including just based on preference and including just for niche use cases. So if somebody else prefers the way that ii code and spell or solid or view, thing that I care most about is that all of these technologies deploy to the web platform, I am a web salt. I cut my teeth making what pages I I believe in, the sort of like openness, infinite availability of the web. So I don't think that would be anything would be a distraction for next time to say that we could be platform on top of some other component architecture. But I love the existence of other component architectures, if that makes sense.

Sure to push the energy forward and all that. If I was too categorized the java script in browser history and eras, maybe you have the mutual era um but now in the last two decades you really had a jake weary era and then you have had a react era and other things are in there but like those two are kind of the foundational things.

backbone in between yeah .

I mean, backbone kind of pointed out why the jail ery style falls short in in in mass, which is why components were so powerful. Jaws ery eventually became part of the web platform inquiry selector, all, I mean the query selectors. And that style of programing really was in the API was spectacular.

Jake queries, biggest innovation, right? And they were smoothly over the refugees. But queries like at all pretty much makes jake query not necessary.

And so building something in, I don't know, web components will get us there. But and like if react could be built in components, if web components could get us, there are curious thoughts on that. Wouldn't react potentially not be necessary like jacky isn't yeah.

I think you I think you could get there. I think it's it's harder to innovate inside of the web platform itself. Then on top of IT.

couldn't they just formalize around the innovation that happened like they .

do with jackeroo? Ah what you could do is you could basically speak the current behavior and you could say like, okay, now we want multiple implementations of react and one of those implementations can be lowered into the browser itself. And so the entire reconciliation process, and in many ways, the optimization that brothers have been making, has made some of the early value propositions of react not necessary anymore.

The domes fast. Now you, the value props of the virtual domo, I want to change the domain slow. And then, brother, like oh, we could just fix that.

So I think IT has pushed a bunch of innovation. I don't know that the API surface area IT makes sense as sort of like first party you know embedded. But you know if there's anything that we can move from the framework down into the platform, that's probably a win for everybody at this point.

I think IT really happens in the sort of primitives that make up react. But you know is an example of one of the things we need to start to do with react is anything that's built on top of react that has to jump through hoops. We used to evaluate all the things we can do in the framework that make IT so that your thing that is on top is thinner and thinner.

So it's truly like your API surface area without all the the guts, right? And there's been a lot of that innovation. And I think like state management libraries and routers and lings have been able to get dinner and thinner as react has exposed new primitives and the web platform could do the exact same thing for react.

So I imagine a world were actually react to get dinner and thinner because the web platform supports more of these things natively. And the good news is all of the people building at all layers of the stack, whether it's the web platform, react core, next J S or the things that sit on top of these, these, all of these, they all talk. And so we are looking for opportunities to kind of move things down in the stack.

Can you speak to the viability of web components as that primitive?

I've never really used them for anything serious. And I think one of the things that people have criticized web components for is being a completely parallel track. So as I talked about, moving things lower in the stack, IT wasn't like web components.

We're like, okay, we're gona take these things that you need inside of react and we're going to move them into the way. Then react could get thinner. IT was, no, no, no, you don't need react.

We're gona do the whole thing. And you know, I for that reason, I think I always felt like a parallel truck. Nothing against web components.

Actually, the underlying initial hypothesis for why web components seem to exist is great. And in fact, I had a conversation with the team building them many, many years ago about how the intention was. To say, look, you have built components like the select box.

We just want to make IT so you can build other building components for the browser, for the web platform. And I love that. That's that's fantastic. There's room for that.

But and anything that was built on top over with, uh, web components, I think this sort of tone was very not collaborate IT was sort of like, no, you're doing IT wrong. You need to do in our way instead. And that created this unnecessary rifts between the two worlds.

One of the things that react wasn't able to do early on, and I think I only got fixed later in the sixteen or or something that, that was support for web components like custom properties. And so that created for a long time until there was a major released where we could do a breaking change that created these two parallel tracks as well. So certainly, we could have done more to kind of collaborate, but I don't think that much about web components as a way of lowering down into the platform. I think of IT is sort of a parallel track.

Was a party people. I am a big fan of notion. I love notion at a very call, very expressive, do so much database pages, dashboards, task less projects. The possibilities really, with notion are endless. And now the new notion, A I IT, has the capability list of multiple ei tls in one single AI toll notion ei.

And this means you can search, you can generate, you can analyze, and you can chat with all that notion context, all of your notion, all the things in notion, all inside notion. And of course, notion is the perfect place to organza tasks, track your habits, build up dashboards, very beautiful dogs, and collaborate with your team in such effective ways. And the more content you at notion, the more notion A, I can personalize it's responses for you, unlike generic chatbot that just give you randomly.

Ss, that isn't really applicable to your stuff. Notion A, I already has all that context, all that work you have inside notion. And IT uses that. Here's the cool thing though, IT uses multiple knowledge sources, IT sources I acknowledge from GPT for cloud, all that to change with you about any topic can search across thousands of notion documents in a second to quickly answer any question you have.

And with ac connectors that are now in bea notion, I can also search across like discussions, ducks, sheet slides and more tools like get up in gera soon. And while notion is such a customizable too, IT can be used by individuals, IT be used by teams, org and even large fortune fauna companies. And a notion, you can send us email, you can cancel more meaning, you can save more time searching for your work, and you can reduce your spending on tools, which helps everyone be on the same page.

Okay, try ocean today for free. When you go to notion 点 com slash G S party。 That's all of our case. letters. Flash powerful. Notion AI today and when you use our link, of course, supporting jays party, and we love that again, notion 点 com flash party。

You mentioned felt as an inspiration for some lower level parts of react and vice vera spelt now a versus back project with terrace works of versie as the chief product officer. Like how do you use felt as a product officer?

Yeah one of the things that is really nice, as I mentioned, about our managed infrastructure as we've created very high cohesion between next J S. And our framework to find infra but loose coupling. So there's a theme that as describe as this spill up.

But if you and because felt targets, build up up A A P I IT works really well on for sale. And we have a number of customers disclose the names, but we have a number of customers at selves that use that I give. So yeah, well, I guess you could go see their websites, but know loge attack is one site that uses, felt and works really well on a market infrastructures.

So I love the idea that customers can come along and say, okay, we wanted use this framework, but we wanted deploy to your manager infrastructure and use your developer experience platform. And we can kind of support that. So yeah, I love delivering value to customers by way of sort of meeting them where they are and enabling them to be successful.

So that circumstance where rich has kind of car belonged to work on whatever once is they're like overside. I don't know how would work inside of an g yeah .

very minimal oversight. I mean, because we believe in funding opens or in a sort of sustainable and durable way. We we check in with the team on the road map and we h connect them with any customers that use felt as often as we can.

But mostly we kind of a let them drive. We would be willing to do this with other frameworks as well. I think we've talked to many other frameworks about if they would want to a similar set up and and most of them are not interested.

They want to to do their own thing. But riches rich in the teamer are great. And the spell five releases extremely exciting. So you play with that yet. Please play with that.

Have way with that with the blog post. Very excited. And one hundred percent agree.

I think that's cool. I think especially if they have a relative amounts of autonation. Obviously, when you work from for somebody, you work for that person slash work.

But certain things just come along with having a job. But letting him I think he's the kind of guy letting him lose is just like good for the world. You know.

that's absolutely right. I think the innovation that the team comes up with that ends up influencing everything else is net positive for everyone. So very excited about that.

So you're fresh off of next. J S. Confident was just last week, right?

That's right.

What's what's t and new and exciting?

What's going on the world? So good. So we went back to sort of two years ago, next, J.

S. calm. I think the team introduced this new router. And really we never really talked about IT this way, but I was kind of her next year, I rewrite.

And because you can kind of use these two things side by side, I didn't appear as as as a rewrite. Basically, we introduced the approach and the approach ter was the first kind of a way that you can use react server components in production in at scale. And and we've been evolving both react multiple members of the react core team work here for self on react.

And we've been kind of evolving next J S. On top of react. And you know one of the early sort of I want to call a misstep, but maybe like oversight was we didn't really think about preserving.

One of those things I mentioned earlier was so paramount for react, which is that really low barrier to entry. So we kind of expose you to the sophistication like all of the complexity and all of the sophistication associated with building something very big, very complex kind of all at once. There was all of these like export cost dynamic.

It's first dynamic, like all this configuration and like this, we are unstable cash API. And there was all this complexity, and even though we had proven in production that you can create an a ic exceptional user experience with this technology, stack IT wasn't as approached as next J. S.

Was known for. The next J. S used to be so simple that, look, put your da fetching code here, use files, each files becomes its own route is so simple. But brother started out a bit more sophisticated, a bit more front loaded of complexity. So what we've been doing for the last two years is kind of refining.

I think in twenty twenty three, we introduced our north star, which is this idea of partial preview dering, which builds on, I could talk for hours just about the evolution of something at facebook called big pipe that turned into something else, eventually will be this partial preview dering. But the idea here is we can give in users the best possible user experience with very minimal developing intervention here. Do I mean we can take all of the static parts of a page, we can render them, we can cash them at the edge.

And then we can as soon as the uh use a loads the page, we can load that static shell and then stream all the dynamic content into the page. This is our sort of north star. You get fast initial render, fast time to first buy, and you get streaming dynamic content coming in.

So we introduce our new star in twenty twenty three. And like, this is partial reentering. This is what we've been building for some time, and this is where we're going.

Then we started using IT more and more outside of just our one or two use cases. And we started getting feedback from developers about how many hopes you had to jump through to make this work. So the feedback was really like, I love the user experience.

It's amazing. But the developer experience is really cooky. It's really hard to get right. And so I don't even know if I want to use the thing. I don't know if the user experience is worth in.

And so just like what we are talking about earlier, if you have a great user experience but a crappy developer experience, you won't get people to be able to use the thing. So we kind of we didn't go back to the drawing ard, but we have just kept for finding and iterating. And what we realized was we needed a simpler mental model for how you determine what static and what dynamic.

And that LED us to kind of what we announced that next year is conf this year, which is internally the sort of body of work is called dynamic I O. But IT manifests itself as A A use cash API. So by default, you can say that my entire page is just static, but this, you know, or my entire pages is just dynamic, as you'd expect.

But this piece is static. And I wanted to be cashed or vice for us. So a much simpler er mental model that people were kind of finally like, oh my god, she've got d of that weird implicit automatic fetch cashing behavior that when I refresh the page, I didn't know why I wasn't getting your data.

We just fixed a lot of the paper cuts and full kung associated with cashing, which manifests itself has a much Better developer experience, ultimately in service of that great, great and user experience. That part of one, I think the other meaningful thing that we talked about actually was self hosting of next J S. Because for the past year and a half ish, the teams being kind of heads down, we're finding this model and making this Better.

We actually haven't focused much on next J S. Outside of ourselves. We just been try to like, prove this innovation, prove this hypothesis. And once we finally got IT to a place where we had kind of exit viols, like, okay, finally we know this is gonna. Then we started like going to the get up issues and like, know, we came up for error, oh my gosh.

Look at all of these quality of life improvements that are missing, like the image optimization when I mentioned a bunch of other things, and look at like how many people are just asking us for a really straight forward guide to self host next to us, out of self. And the team was so excited to work on this. All of them have been working on next J.

S. For, I mean, not all of them, but many of the team members on next have been working on nexus since before of ourselves was even a business. And so they're really passionate about making the framework really, really good.

So the other thing we kind of announcer is both Better support for south hosting next J S. And a commitment to kind of working with other cloud providers that aren't vers l to make IT easier to host next to us. So you know, two very important work streams, one on the innovation side and one on the sort of a generalization side. And actually this directly back to how we open the thing, which is innovation first and the generalization after, right?

I think that's great to hear. I think if you took up polls of the overall sentiment towards both for cell and next, J, S, which are brand a line and linked, that people are happy. But if they're unhappy about anything, it's the hosting story. And of course, when versar is incentivize to make that the best place to host next s or maybe even easier, the only place you host next J S, that starts to like bug people. They started the thing.

I, I don't only want to, I not only do I not want to give her sell my money, but I don't want to use H S, because of that reason, because there are incentivize to make that the only place that even possible or easy to do that. And so the either you gather investing on that both is great for the community. Also, I think it's just smart business by take taking that that whole angst out.

Yeah, I completely agree. One of the things we saw in the early days of react was because react became relevant outside of facebook. People working at facebook believe that their technology stack that they were using in the skills that they were learning, we're relevant.

And so they stayed around a long time. They were they didn't feel like their skills were being sort of like only you. This only applies to this technology.

Technology lies to this company. So they didn't feel locked in. And I think with next shares, we need people who use next shares to not feel like they're locked into versa.

They just won't use next J S. So somewhat counter intuit. But the best thing you can do to grow both next J S.

Adoption and probably resell usage is make IT very clear how to use them independently. And so yeah like that. We've seen lots and lots of companies do different things in the space.

One of the nice features of my background and give your most background is that we both are very passionate independently about open source itself. That's where we started. I started out on new tools and we've been kind of web excEllence. Have a sense. So yeah, I think telling that story is is really important because if the only thing you ever hear is that you know these things don't work independently.

They are just this is about walk or this is about um you can only use them together and this is about funding usage into versa if that's the only thing you hear, you eventually just be like you that must be true but once be like, no, no, actually that here's how IT works and here's how we innovate and then here's how we generalize and here's the proof. And here people are like, oh, okay, great. There is a narrative here.

There is a story here. There is intentionality here. It's not just this sort of like fun, al, so that's why I say, you know, we don't build next to us to make money. We make money to build next as well, then you know other technologies as well.

On the money making front, this is something that I don't think is for sell specific, but it's more like cloud house problems is, you know generous free tears are like zero credit card required. Maybe I put IT in, but just like no cost to get started. And then like so a surprise, bill, when something happens that you didn't realize your side project gets a little bit of of action or whatever happens. And then this is like bad for your overall image because people are posted pictures like all look and resulted to me five five thousand dollars overnight. As a product guy, you certainly trying to solve that problem to.

aren't you? absolutely. I love this topic too. So the way that we think about the phenomenon you have described as like, oh, my APP went viral, I wasn't prepared for IT and versa handled IT really well. You auto scale to make IT so I could meet the demand but now I have to pay for that infection we ve got .

i'd never get the ssh effect and not have to pay right so do you know .

the expression um in life there are no such things as solutions only. We only have the ability to trade off instead of problems. For a different set of problems, I think like there there are no solutions, only trade off.

And and I have attribution for the quote, what we've done as we've traded denial of service, which is, oh, a lot of people visited my my host and they went down, right? We traded that for something that be effectively called denial of wallet, which is like, hey, we're not going to go down, but we're going to provision a lot of computer and that compute t costs money, all right. So here's here's how we were thinking about solving the denial of problem.

The first thing is like we have to have spending controls. If you're building your profile or portfolio website, like there's no world where you're willing to spend more than like twenty box a month to host, this is like, look, it's not a business. So spend management in and like the controls to get IT right. Um and we have some of these things, but I actually don't want that at all.

I want a platform to be so smart that we know the difference and that we alert you when something's happening such that every time you have that, not only at your costs under control because we've reduced the underline cost of running in providing that compute, which we're working on with things like in functions and currency we can get into. But you don't have to think about IT also because um you know what happens when that happens in advance, you're gonna get an alert. You're going to be able to have control.

You're gonna be able to say, I wanna use the firewall to be able to like rate limit or block or slow traffic um but in the fullness of time, we make this zero configuration and we just take care of IT for you. Um and so our platform is getting smarter and smarter to be able to you know not have the denial of wallet problem, actually have a an active initiative around preventing the nail of wallet. So um yeah the sort of like server the original survey less pitt fall, which is like wow, the things working .

too well right yeah yeah that's really cool. Are you still on top of a of the U S? You're a layer two cloud, right?

yeah. We have a lot of underling providers, but we are very much partner with A W S on a lot of stuff. So um in some ways you can kind consider cell or parts of our cell or control plain over A T U S. But um we have other providers underneath that we kind of stitch together seamlessly.

I see. So not, but you're still sitting on top of other people's clouds and some of your competitors don't have that problem or that solution, know they can run their own stuff. And I think if you're trying to optimize for not denying wallets one way you could do that.

Not suggested this is the product. Go back. And I was just curious about IT, like, hey, let just go down a layer and run our own stuff. Is their initiatives for that something to think?

Yeah again, as I said before, there are no such things as solutions, only trade off sure and but we would have to trade off as our time spent building no uh enterprise grade development platform uh and framework to find managing researcher to uh building actual infrastructure. And I think at least for now, we don't see the need.

We actually believe that what's happening is and I don't mean to a grand ize IT, but there's there's this human progress thing that's happening um in the early days of the internet, uh there were a small set of individuals that had like rack mt machines and then um you know I just remember the stories from early facebook where we literally would drive the data centers and like plug machines and then eventually eight of U. S. Comes along and things like A G, C, P as a develops and they say, hey, now anybody can provision, compute from the comfort of your own home or office and then something like myself comes along and says, you do not really have to think about provisioning compute will to do IT for you automatically.

So I think that arc is human progress. So now the way that that would make sense for us to want to provision our own machines and actually recommend our own machines is if we get to a place where that's actually the only way for us to optimize our margins. And we have so much efficiency left, we have so much opportunity to just in the software layer um make our you know margins and our product offering uh more Better margin and more compelling product offering that we don't need to look at harbour yet to no active explorations into harbor. One of the I mentioned this twice now, but you should .

check out the inflection.

That's right. Yeah I mean, you know the for the since the advent of server list, there's been this relationship between one request to one V M, right? I know what we've done as we ve sort just actually take an advantage of the idea that most of the time these workers are sitting idle, the this I O or uh you know fetching from the network or actually nowadays the biggest one is, uh, calling out to L L ms.

These are like expensive, costly wait time. And the cp is kind of sitting idol. What you wait on I O and so what we've been able to do is we can actually send multiple requests to the same vm.

And we're seeing somewhere between twelve point five and forty seven percent efficiency gains just with the concurrency of two. And we have a lot more to do there. So we have another years worth of the road map just optimizing that. So sure, we can absolutely, you know, drive to a data center and start building around the world, and we won't need to do that for a very long time.

Let's finish. You said LLM, that's the magic word. Let's finish.

Every podcast has to have some sort of AI chapter. And this is our AI chapter. V zero tells about the zero.

yeah. V zero, I think, started with this realization that, you know, if I I can ask the L, L, ms. For lots of things, why can I ask them to? I get me started on my APP and not that of v zero o came from and IT turns out like the elements are like pretty good and outputs read code and web compatible code.

So we kind of just started tinkering and expLoring IT. And I think what we initially thought would just be this, uh, this tool for getting started, I used to literally would generate something with v zero copy IT into an APP, and that would be my starting point. And then I would just kind of like continue building from there.

We now see IT as a little bit more compelling than that, and I think we're kind of starting to see this. But this is an iteration platform where I have an idea. And the quickest way for me to sort out of like test that idea is to just tell v zero like build this thing and tweet this way and do that thing.

So we're starting to see not just getting started but like actually full kind of application development happening in IT. And the thing that I think is most interesting about IT is actually not is kind of repeatable. We're seeing something similar.

Get have released Spark yesterday, we think is the same thing claude saw IT artifacts is is kind of something like this and worry I can generate code now so everybody, he's kind of like you first move or doesn't really matter when you're in a saturated space, right? Everybody y's built the same or something very similar. What's really interesting about these is were observing other parts of the organization use IT to build tools that they need that our engineering team doesn't have context on or really doesn't have the motivation to build.

And so it's been really interesting to see how IT has turned many technical leaning but non developers into developers. We have a demo day every friday and every friday. For the past three months, there has been someone from some part of the company saying, here's how the customer success team built this tool to make ourselves more efficient.

Here's how the dog team built this tool to sort of like categories, ze and trios and all of them are using v zero. So we think the opportunity here is turning sort of everybody into a developer with with billboard and safety eco that says everybody can cook. You know, internally, we say let them cook, let them cook like this is is they're working on something.

They are building something and now everybody can build, everybody can cook. So yeah, it's been going really well. We're excited about IT.

We've got a very exciting roads plan. Yeah, what you want to know? Well.

I was that mean you answered most my questions. I was thinking like, you know, I look at something like this from the outside. And of course, like you said, there are A A lot of people are trying to do this same thing. You guys are pretty early on. Doesn't matter when there's hundreds of them going.

And I think not knowing vers l very well from the inside, just as of you are like is this thing a distraction? Like is this like they had to do in A I thing and that's what this is and it's fun and but it's like helpful. This sounds like you like I said, you answers some that question because and you're got a lot of benefits. Even if IT doesn't become a rocket ship product for you, it's still benefit to to the time there.

Yeah absolutely. And I think in many ways used to talk about the fact that I had these two products are manage or developer experience platform and like previews and comments and and preview depot TTS itself. But really all of that was part of the same workflow and IT didn't really work separately like you're using all of this together such that front in cloud.

But v zero really kind of is a second product for us because companies that can't or you know have no need to host their manage infrastructure workloads on vers l are very interested in visio. And companies that are you already using our management for structure can add this on with minimal sort of change to their existing workers. So yes, it's not a destruction. I think IT started out as an exploration that we believe is even more valuable for us internally then we initially anticipated, and we kind of just double down on that.

So is this specifically output in react lash next J S apps? Is that bigger than that? Or is like those that what IT makes by default does?

Um I think it's you you can tell IT output whatever you want, and IT actually generates python now and you can output sort of any code or any framework. But yeah, I define the outputs. H what IT kind of knows the best.

I think the thing that we seated IT with early on was all of ourselves documentation, all of the next J S. Documentation of the react documentation and and like is a little bit self serving. The reason initially was because that's what our stack looks like and that's the stack that we work with most often.

So that's where IT started, but certainly it's expanded over time. And and we can kind of chef more guides and examples and documentation and IT that has taught IT to do other things. So you can like output a simple sfbt APP that does X, Y, Z, or output a sophisticated spelt dashboard that can use this. I know how to do that.

I like the idea of telling, know, that is, generate something that's not sophisticated. You know, like sophisticated thing, please, only terrible code.

This is especially if if you're learning to program, though, actually this is one of the things that really stood out for me was once I started using v zero, I sort of stopped using google and stack overflow to answer questions like I had this very pretty simple but I like my code.

I this APP that's like um I wanted to add a sound to the buttons because when I use the thing on mobile, I wanted to know that I I was tapping the button vibration A P I whole thing so Normally when I would do is just like how do I add sound? You know I done this before, but like, I don't want to, yeah, I just want to look IT up. I just add visor.

Like you, can you add sound of these button? The piece that I didn't remember was like how to synthesize zed, your own sound, rather than loading in A, A, A file and IT just, I just create a simple synthesizer for you. And like, you can copy pieces.

And I took that, and I put IT in my APP. Like, I don't use, I don't really need to look up. I look at dogs anymore, just ask the question. And I get IT so living .

a brother er tab, which is great in your editor.

How do you use IT? Yeah I use IT in a browser tab. I think there's a world where we could innovate.

The editors, I don't know. I think that space is saturated and somewhat and interesting if you're targeting developers and engine developer workflow, that's great. You know I have says one hundred million developers in the world that's impressive.

And I don't know. I got product managers, customer success ribs and sales engineers using this thing and they don't necessarily have the s code installed. So you know, I believe in the web. I think it'll be in a brother or tap for a while, but maybe it'll be a role for a native application or, uh, that top application or A I, D, E and integration soon.

Yeah, we're expLoring all them. I think as IT gets more powerful, you you have more people wanting power tools to use with IT. You always have the people that wanted to using a razer tab. But I think eventually with adoption, that makes sense to go deeper into the integration.

Did you train IT? Then on you'd mention some dogs and stuff, but like that you start how you all build a thing was like a foundation model that you find tune their fresh start from fresh fire apps on A W, C. Two instances with big GPU. Yeah, no.

we we trained our own models and fed them a lot of the context that was most relevant to our initial these cases, and it's just gonna w from there.

So very cool. Well, time has been a blast. Enjoyed meeting you and talking with you. Anything that I didn't ask you that you are hoping to talk about.

And we covered most of IT. We covered a lot of ground. It's a lot of fun.

IT was a lot of fun. Appreciated a to our listener, all the links to all the things mentioned here on today show even you can go back. You want to be a history and you don't want to go through the multiply react documentary.

We have a podcast we did in twenty fifteen, episode one forty nine, which is like six hundred old episode, all about these topics with the people doing tom coworkers colleges. And that might be of fun for a little bit of the raw, unedited history of a conversation. So I put that in there as well. Time so much. Appreciate your work and your thought today.

Thank you so much for having me.

That is our show for this week. Thanks for a party with us. If you haven't checked out our change log newsletter, do yourself a favor and had to change log dot com slash news. There you'll find twenty nine reasons, yes, twenty nine reasons why you should subscribe. I'll tell you reason number seventeen because you might actually start looking forward to mondays.

Sounds like somebody A K twenty .

eight more waiting for flash. Thanks once again to our partners at flight to IO, the home of everything we do here at changed logue over three million apps. I watched on why, and you can do five minutes or less, learn more.

F I D I O. And thanks, of course, to R B freak and residence. We couldn't bump the best beats in the beds without breakfast. Mater cylinder, say that three times fast.

Next up on the pod carmon we do bro joins nick and cable to discuss her upcoming talk at rex m. us. Untangling your dependences a pattern for a well net react project. Stay to you here. Well, that was ready for you next week.