When react Js became popular, front end web development became easier. But react is just a view layer. Developers often came to react, expecting a full Web development framework like ruby on rails or Django, and they were required to put together a set of tools to build their own framework and satisfy that purpose. A full stack JavaScript framework has numerous requirements. How does it scale? How does it handle server side rendering versus client side rendering? Should graft que el be included by default? How should package management work? Guillermo Roush is the creator of next J s, a popular framework for building react applications. And he's also the CEO of Zeit, a cloud hosting company. Guillermo joins the show to discuss Next Js and his vision for how the react ecosystem will evolve in the near future as features such as react, suspense and concurrent mode impact the developer experience.

Guillermo is also speaking at react a thon, a San Francisco Java script conference taking place March 30th and 31st in San Francisco. This week we're gonna be interviewing speakers from reactive on, and if you're interested in Java script and the react ecosystem, then stay tuned. You can also hear Mawr podcast episodes about React by listening to the Reactor Thon podcast, which is available at React a thon dot com slash podcast. If you hear something you like, you can check out the reactive on conference in person when I'm building a new product. G two. I is the company that I call on to help me find a developer who can build the first version of my product. G two. I is, ah, hiring platform run by engineers that matches you with React React Native Graphic UL and Mobile Engineers who you can trust whether you are a new company building your first product like me or an established company that wants additional engineering help. G two.

I has the talent that you need to accomplish your goals. Go to software engineering daily dot com slash g two. I toe learn more about what g two I has to offer. We've also done several shows with the people who run G two. I gave Greenberg and the rest of his team these air engineers who know about the react ecosystem about the mobile ecosystem about graphic ul react native. They know their stuff and they run a great organization. In my personal experience, G two I has linked me up with experienced engineers that can fit my budget, and the G two I staff are friendly and easy to work with. They know how product development works. They can help you find the perfect engineer for your stack, and you can go to software engineering daily dot com slash g two. I toe learn Maura about G two. I thank you to G two i for being a great supporter of software engineering daily both as listeners and also as people who have contributed code that have helped me out in my projects. So if you want to get some additional help for your engineering projects, go to software engineering daily dot com slash g to R. Marash. Welcome back to software engineering Daily

Things were having me again.

We're about six years into the release of React. How has react change Web development? I've

been saying for a while now that I think broadly, the most exciting paradigm shift of react has been moving away from templates into components. If we had to summarize the great innovation anything has been to create a workflow for teams. Teoh see the rise of the sign systems to give people greater Reese ability, composition, power and ultimately empower in the front of developer. I think before, especially with templates, were confined to servers surrendering things that would dio, you know, like spin a ba JV m box and write some template ing language and then just, you know, not care of the front. And it's much anything React has made people gravitate in the opposite direction. You know, even teams that were not that fun of Js realize Hey, to build a world class front and would really have to use this reacting.

The development of a react application has gotten easier over time. What was the boilerplate that was historically needed for starting a react application? How has

that gotten simpler? That's a great way to put it. I think there was a lot of boilerplate. In fact, when we started Next Js, which was solving the problem, making a reactor application top to bottom entire experience, we were seeing a lot of get up repos floating around that were basically copy pastes of boiler plates. They weren't providing a framework on an altogether solution. They were like, hey, cloned this boilerplate and then start making changes and then you'll diverge from the border. Played at some point because you're not emerging changes back in. So we created next us to solve that problem. Exactly. It was okay. React started as avian NBC. It was kind of like a component specific library and wanted to create an entire obligation with react. And actually, it's kind of became that

thing. Many applications start out static. You have the term static website commonly used today. Over time, they become increasingly dynamic. What are the issues that develop over time as an app that might start out as quote unquote static evolves to become or dynamic?

Yeah, disagree, way of looking at it. I think going back to the origins of react, you start with some HTML, you know, even when whether it's created by a server, not, and they're just throw in your Js. And then we're like, Okay, let's create the whole thing with Jess, and, you know, in that world from the front world, you think about going static first because you think about driving the entire app with J s. So I think what's happened over the years is that because of this need and want to use react to drive your entire business or whether it's the you know,

your marketing page or whether it's e commerce, whether it's your dashboard as an S p. A, we won't really be there. We want that component model will be there. So things have evolved in such a way that they become hybrid. So we called Nigeria's a hybrid framework because you can say a certain pages fully static, for example, at certain pages fully dynamic and certain pages air in between

order the other scalability issues of react applications that develop over time as an application grows. Well,

going back to this idea of pages one of the things that react developers and in general, I would say everyone that makes this transition to front and heavy Js architectures faces one of the first ones you phase is you start with this idea of a monolithic app, a monolithic bundle. In fact, the word SP a single page application kind of already is leaning into that and that really hasn't scale. Well, because you started shipping, I lost a lot of Js just t to drive what you think initially Oh, it's gonna be one page or maybe a handful of pages. And then as you start adding features, that bundle of Js becomes kind of very hard advantage and it's very takes very long to download. It takes very long. Two parts compile, Evaluate. It takes long to hydrate So kind of one of the downfalls that we so early on with the kind of front and fat client or Js heavy front movement waas were spending a lot of time looking at. Spinners were spending a lot of time in what chrome engineers, for example,

called time to interactive. Right? Like when you go to a website, well, you want to a see the content right away and be you want to interact with that content right away. So with react, that kind of became a problem early on. And this is one of things that we spent a lot of time and engineering with Nick Js fixing which is can we have reacted the engine but always have very fast page loads? I would say this is probably one of the most important challenges that people face when they make this make this transition is how do we retain that really blazing fast page load? How do we make it interactive right away? And it's still retain all this great developer

experience. Primitives. As you mentioned, the rendering forgiven Web page, a developer has a lot of options today and next. Js accounts for some of these different options, and I want to get into that. But first, the motivation for different options of rendering if server side rendering of client side rendering you have some options in between. You can use things like service workers to get some flexibility there. Describe the different range of options for how a developer can render a page. Yeah,

so this is actually another one of going back to your question of lake water tow difficulties that developers face. I would say this is a pretty big one. So, like, how do we render? Do I use client fully clients I to a use a static side generation? What do we do it build time? What do we do at run time? So it brought me say that there's a very large category of pages where U. S. A customer and a user of the Web. You want to go and immediately get the content, and the best way to do that is to give the customer HTML with the critical CSS in lines. So we accounted for this with Js with our support for a static sigh generation, even though originally next year's was all about okay, you define your get initial props data fetcher, and then we'll do several rendering.

We looked at the problem. Realize well, there's a lot of different ways of tackling this problem in one fundamentally strong and very scalable way was what if we just produced HTML at Bill time? So the categories of pages were That's a really great fit range from marketing landing pages, things like logs swear, You know, again, you go to a block post, and if you think about it from the perspective and SP A or a single page application, you would think, Oh, I'm going to see a spinner that I'm going to see a skeleton than the block Post content would come in, and that's a very rare sight, right? Like I don't think anyone in the Web it's used to that kind of experience. Instead,

not only because of making crawlers happier because crawlers is still today. Like Google will execute Js but of course will make them happier if they can crawl the entire side faster, right and not executed, as is also for the end users sake where you goto page and just want the content fast. So that's why we're calling it increasingly this hybrid solution Because we realized, like with that ability to generate content and pages at Bill time, you get this incredible benefit of great performance cdn distribution off your content where you're not confined to riding the user, always to a single server. But then, Okay, how do I go beyond so this kind of the next problem that comes up we're like users Air used to very, very long Bill times sometimes how do we go beyond that? And this is where I think Jam SEC has offered a very compelling solution where you can compliment what you've generated a bill time with clients. I j s so really interesting pattern that we've seen is okay. You know, you can generate sort of the going back to the gym. Second, you can journey the m the markup off your pages and X rays offers you this multi page system where the market of different pages is gonna be different. And then you put into clients I Js to complete the experience, to give

a little bit more detail on that. The term hydration is often used in the same context as this rendering process. Hydration refers to filling an object that has been Stan Shih Ater exists in memory, but it doesn't have the data yet, so you want to hydrate it with the data. How much control does the developer actually want tohave over that process of component hydration? What defaults do you want to give them and when do you want to give them options to hydrate with, perhaps application specific preferences?

I believe strongly that developers want full control over the amount of data that comes pre hydrated or Priebe rendered with the page. And I think that's where we'll see a lot of interesting application to sign preferences that stem from so an example is, as I mentioned, when you go to certain categories of pages, that you can have data that is very critical to render immediately. I called this type of page a commercial transaction page where, for example, you get a product and you want to buy it right away, or you get to the page of your startup and you want to sign up or learn more right where we are contact sales or whatever it ISS. So we want to minimize the time to that transaction to occur. So that's why, with next raises hopes for static side generation, you can say the markup comes pre hydrate ERP refilled with the data. But then there's a hydration process that happens in the client. So this is where the react engine will try to re conciliate. Everything has come pre rendered with, you know,

event listeners and trigger animations and mounting hooks and so on. So what will want there is to minimize that time to. For example, if you click a certain button, we want to give you a result right away. So that's why it's so interesting to discuss time for first content full paint, but also time to interact anything. Those are very important and going back to okay, where does the developer gain the flexibility? I think in some cases developer will be able to pretty generate markup that optimizes a lot for that time to content full pain. Because again, the famous Amazon rule is, you know, every 100 milliseconds you got. You started selling like less or in general, just doesn't feel right await for a content that could have been cashing the pup public city and network.

That sort of one of my takes there. But then, on the other hand, there's more specialized types of applications where, for example, the content cannot be easily cashed or there is interesting concerns with regards to privacy or data ownership, Right? So a great example that a percent here is, for example, you were rebuild that whats app application, which is, I believe, easels already built with react that page like, let's say we call it a slash chat or slash groups or slash threads. That page will probably only comment pre hydrated. Let's say,

with the data off, you know, maybe your logged in or you're out or this is the thread. Listen, it's going to render a shell on Lee, and then client side code needs to boot. In the case of WhatsApp to actually establish end to end encryption to be able to get the data and render it on the screen or talk to even a mobile device. So in our view of the world, the developer will make this decisions on a per page basis or what we call the entry point. So maybe you know what's up there come slash. It should just be a static page that comes pre hydrated and refilled. Well, it's data, but then a slash child will be this shell that then requires clients. I j. Has to boot up really quickly.

Still, because again, we still want to make the users happy spots as fast as possible. But the sort of rendering a decision has shifted a little bit, and the data is now owned by the user. So that means that we probably don't want a server to necessarily touch it or see it or deal with it because we increase the service for security promise. Rules exist, So this is the beauty of reactive. It's proven that it works remarkably well to pre build HTML and delivery at scale, but also to prevail, to breathe very basic HTML that then boots very rich Js on the client side to create a very immersive application like experiences.

I like that example cause you're citing a reason why you would want to do client side rendering. That's not explicitly for performance

corrects. I think this is one of the ones that has become very clear over the past few years to us as we work more with next yes, users that are operating a very, very large scale, and then security becomes the concern, right? So, like if you're ever subscribing to a world view, if I only do surrendering, then you started increasing the surface off complexity of your application because what happens is, let's say something a simple as error tracking. You now have to deal with the error tracking lifecycle for the server part and the error tracking lifecycle for the client part, whereas if again we go back to this WhatsApp example, they have the ability to now ship the shell of the application as static. HTML. It gets downloaded from us, closes the user responsible in an edge cdn network,

and then the only security air tracking in the bugging context who were about is a client side. And now, if you ever talk to a security engineer, it's It's a dream like situation because jazz is running in a sandbox environment, which itself the browser processes sandbox environment. There is only one piece of code audit, and it gets even more exciting. And to start thinking about multi platform J s. I truly think that react will get to the point where you write what's up once and you deliver it to. You know, four or five major platforms today is like kind of blurry, like even Facebook built. What's up the web, that what's up? That calm And they still have native clients. But I think over long periods of time,

this sort of amazing, economical advantage off you analyze the security of your application once in one context, you're right. One unified component system. You write one set of data fetching hooks. That and this is a man. Get excited about a lot is that Maria has made the data layer reusable. Now? No, just the you I layer. So imagine that you're like, you know, creating the next What's up. You now have this uniform view of the world. I use one technology. It's secure, scalable in multi platform.

The concepts we've been discussing, how have they inspired? Next Js

very concretely. A think next. Yes, has made a lot of progress in this hybrid view of the world. We know that each page is an entry point into the application for those who haven't used next year as we we like to give you the two second story of how to start, which is you. Create a pages directory and then obviously add a yarn ad. Next, recreate dumb and then inside the pages directory every file every great in exile. Js about Js Abdullah Js settings are Js becomes an independent entry point into your obligation. So it's a little reminiscent of how PHP is to work. Were like each file becomes an entry point a page on your URL. But what's exciting that's happened lately is each page can now be compiled smartly by next year's that bill Time to, for example, maybe your index is a fully static page, so there's no data fetching a top level. Therefore,

next year's will output in exotic HTML. Maybe you have blawg, which needs to come pretty aggerated with data. So like you have blogger Js, next year's will give you a hook to obtain data at Bill time. And maybe you have again the ability need to. When you're browsing a page, get all the data from the client side, then use real cooks. And then it's kind of this very comprehensive model. And then, if you have a very, very specialized pages, say I need to use the server lifecycle here next year's Consejo. This page on Lee does serve a rendering. So because of this flexibility, nexus has become appealing to lots of lots different answers. Whether you're creating your first page or you're creating a very massive,

dynamic obligation, it's worth pointing out that you are on site, and I just love to get like, What's your perspective? Why would you start in next? Js is a job script for him or for people who don't know it's a it's a framework for building full fledged react applications. Why does it make sense for a hosting company toe work on a JavaScript

framework? That's a great question. So the mission of our company outside is enabling a workflow for front and developers and the entire company to develop preview and ship. So we think of this life cycle is a true game changer because typically when you develop, it's very hard, like shared a progress of that development with your team so that the way that use our platform issue, install, get, have app, and then every push and every PR and every deploy you make gets a previous. So this is something that other like legacy technologies or even when you use thick Ma or things like that. Your use like previewing your work all the time, like seeing it live and site gives you this incredible feature off every deploy you make every change you make to your app, gets this preview euro and gives the workflow for the company. Now collaborated across working on an extra zob working on even like a symbols, fully static website. And then you have to ship that right lake.

I think we can have gotten used to separating all this concerns. And, you know, the front developer does some work on local host and then hands it off to someone else to ship it and or make it riel or make it live. But we think that by integrating this technology into a workflow, you get the ability to make software faster and better. Something that we've seen that's emerged as the consequences. You start working on X rays up you, of course, push it to get, have or get level bid bucket. And then you imported a report or platform and then you start working on software differently because what happens is and this is broadly enabled by this front and heavy applications is that instead of focusing so much on the code, you start focusing on how the actual product works. So you start, for example, would start working on the new software engineering daily website.

We say, Oh, we're gonna use next. Yes, and funny enough if I'm working on it, having a local host 3000. But how do we actually bring it to the cloud? How to actually collaborate with you on building that website? And I think what's exciting about this is that next year s already in this low code category were like, You don't have to write lots and lots of kodo making up. So by integrating into a need workflow like this that makes that brings in excess to the cloud, it almost feels like you're working on a no code tool like it just feels like you're just editing the product directly. And this is truly how I think product things would be built. I think as developers, we tend to over index so much an abstraction. We tend to think like what's the best way to especially in the real world,

was the best way to store state. What's the best way to make? ST Scale was of his way to introspect state. But this really changes their minds that I think combined with next yes, giving it some good defaults and opinions it kind of and going back to why we think this is a responsibility is like we wanted to work on your product so that part of the develop readership lifecycle developed next she s is a great answer there to lake become really productive

and then just work on your products. Today's show is sponsored by Data Dog, a scalable full stack monitoring platform data dog Synthetic AP I tests help you detect and debug user facing issues in critical endpoints and applications, build and deploy self maintaining browser tests to simulate user journeys from global locations. If a test fails, get more context by inspecting a waterfall visualization or pivoting to related sources of data for troubleshooting plus data dogs. Browser tests automatically update to reflect changes in your you I so you can spend less time fixing tests and more time building features. You can proactively monitor user experiences today with a free 14 day trial of Data Dog, and you will get a free T shirt. Go to software engineering daily dot com slash data dog to get that free T shirt and try out data dogs monitoring solutions today from a strategic point of view, do you worry at all about what happened with meteor? Like with meteor, they built a technology meteor Js that was awesome toe work with very popular, but in some ways maybe ahead of its time or just went in a certain direction. That ended up being perhaps too opinionated, and they had constructed the entire company on entire deployment system around a framework that ended up not being popular enough to support a company. Now that said, they've pivoted pretty gracefully towards graphic ul infrastructure. So maybe that's not even a cautionary tale. But it seems like you're kind of in the same neighborhood where you're trying to design a front and framework and a back in deployment platform at the same time. What are the risks there?

So I think that's an interesting story. Like you said, I think there was a lot of learning involved for them, but also for the community at large anything. One of the primary things that I take from that is the need for focus. So from the very get go nauseous said we are We don't care about the data layer whereas meteor was all about like, Oh, we're giving. We're gonna give you the entire solution, including Mongo, db and the back end, and going back to like, how has an extra has evolved in. What we've really learned is that in order to serve the front and developer, you have to be true fraud and technology, so there is no back end involved. Increasingly,

there is no again data layer preference. There is just a tool that'll occupy the last mile of the application development life cycle. So this is kind of what I think the community at large has really discovered with the rights of jams stock where a you need a very, very scalable model of development and deployment. So one of the goddess was with meteor was that if you were building a single page, you were running even in the media. A cloud You're running this container with running a server running mongo db running all this things. And at the end of the day you would goto the website and for several in a in an external global market and would probably be slow, any expensive and it wouldn't scale. Now we've shifted the equation entirely, toe worse, not deployed with server. But here's the main distinction is were deployed of the Etch we're making front of development scale. From an economic standpoint, it's highly available. It's incredibly cheap to scale,

and now it's getting really easy and cheap to develop its The Primitives, for it are very, very simple. And I think another thing that's been really beneficial for us has been companies had already started this move towards decoupling front in the back end. So I think meter was stuck in this in between of Lake. We need to be like ruby on rails, so we need to give you back and then front and altogether. But at the same time the industry was moving towards. Actually, this Iowa's thing is coming up in this android thing is coming up. We're gonna need a segregated A B I We're gonna need rest where any graft girl, we're going in micro services. So I think that's a larger trend that we can't ignore. And this is a trend that jam sex so gracefully ATS itself into So the a of gems like his a b I so little you're just writing the Js and the markup to Korean AP that already exists. So I'm a really big fan of thinking about the broad economic landscape. And I think,

Why would I give someone a tool to rewrite the back end that there are? Companies have already been rewriting for years. They, like everyone's coming out with the rest. Maybe Iran's coming out with a graphical FBI. So what? It's a missing piece. Well, the missing pieces to produce pages from those a b ice and to do so at scale, especially now that so many other people are providing a P. I says the service. So when you think about headless, CMS is when you think about war bris that WordPress rest a B I. The world at large has decided that the AP eyes now the adapter into the data layer of the world. So anything this is why the media or graphical transition made so much sense. Because now they're saying,

OK, we're going to focus on answering that side of the problem and win a true focus manner. There's gonna be lots of people that want exposer, data and exposer mutations through on a B I. And now they fit into these gems at the model wonderfully where you build and they play to the edge with next. Yes, and you're actually not writing the A P. I necessarily write like you're acquiring an A P I. That already exists. And it's exciting to see because now there's also back in since a service that give you a graph delay B I or arrest FBI. So if you think about focusing on the front end developer like we are, it's looking really good for them, right? Like they can produce so much awesome stuff without doing any of the work involved in Lake actually running a server.

The distinction between the ruby on rails world and the world that we're living in today. While I guess in some cases we are still living in the ground. Plenty of people are still gonna be on rails, of course. But the direction that I guess Jam stack represents of less monolithic, less tightly coupled workflow Implicitly there is less strong opinion about how to do things, But you're building a framework. Next Js must have some strong opinions. What are the strong opinions that you're baking into next? Js

Yeah, So when it comes to what the customer ultimately wants is build great absent websites, right? Like that's why Ruby on rails Even though it's not the best solution available, it still has traction, right? Like people want to build things easily in rails in it is a great solution. Now when you run, create next stop, which is our equivalent of rails in it. MPX create action accession app. You'll get an example Nigeria's obligation and what you find inside is this pages that can do their own data. Fetching this strong opinion that we have in there is that you can define this data fetching hooks like get static props, get initial props or maybe no, not doing any data fetching it Also that you all put html and then you have the query may be either. So you can then use fetch and get data from your rest. Fill a B I you can use Imagine,

get data from a graphical a B I. So the strong opinion has really been around your building pages and you're gonna want to be in control of the rendering lifecycle, as we mentioned earlier. But that's kind of where the opinions end, you know, like we want to stay very, very focused on this front and specific problem. Now, where things get really interesting is okay. And I'd like to remind people that when d a change injuries is ruby on rails. He built a blawg engine from scratch. So he builds a whole leg back and for the Blawg, including, like, he shows off the Esca folding feature. He uses active record to save posts,

created pose, lists, pose and then he doesn't front and bit. Obviously, we're like, OK, I'm gonna runner to post. And if you think about that from the perspective of today, most people using next yesterday didn't have any interest whatsoever in building the admin panel off their blogged the engine off the blawg. They probably were using a well established blawg engine. So in those data fetching hooks of the luxurious pages, you could query the WordPress a B I. And then I'm sure like you're, you know, editors air happier to use the WordPress admin panel. Then they are you saying something that you put to their in the five minutes ruby on rails,

screen cast. So I think the strong opinions have been to actually not fall into the temptation of trying to answer the back and needs strongly that ruby on rails provided because we're living in any world. And this is kind of where next year s Chinese is that, like, this is kind of what the front of Albert's looking for and coupled with our platform for quickly previewing and deploying. You know, you're actually beating the h a suit that not five minutes by light, you can do it in a minute and get a live your l of your outcome. So I think the bassett he could do after the ruby on rails, screen gases I get like, you know, the local host 3000 server running. So with this, your little pushing your patients of the edge and just sharing them with anybody.

To what extent has the jam stack community consolidated around data fetching work flows involving graphic? You well, does every jams dak application want to use graphic? You go.

I don't know. Believe so. I think the flexibility of data fetching strategies remains incredibly useful. As an example, our dashboard and marketing website and blogging everything see one Nigeria's obligation fully Gem stack 99.9% of it is a static, and I believe we have, like, a couple service functions. And when you come to our dash ward, we give you this shell that it begins doing data fetching in parallel with react hooks. Actually, and we carry a bunch of different rest endpoints that we already had built that are the same endpoints that we exposed to our enterprise customers when the when he was an A B I for advanced deployment needs or the same maybe ice that we use for to get having get 11 big bucket integrations. So we already had this rest ful FBI, and we had to solve the challenge of how do we present the data to the use of really, really fast and hoax actually were an incredibly suitable solution. We do data fetching in parallel for certain parts of the obligation. We subscribe to the Web sockets descriptions for accelerating events.

It's super real time, and this is kind of how to come. Works like a lot of people think. Oh, like in order for Twitter come to be real time, for example, Lake. I'm sure they use a graph deal subscription. No, they use rest, and then they re fetch the data upon certain actions, like focusing the page coming back to the app over time so you can get really, really far to build applications that are really time engaging and incredibly fast, like Twitter, com or whatever have your building with Let's call it good old rest. I think what's what we're going to see over the next few years is obviously a combination off ref uel.

I believe we're going to see a return to some extent to just using functions for data fetching where you think about like I don't like use get user session and that you think of you of your hook as a discrete function that does data fetching and the implementation details of that hook don't matter. They could use anything underneath, and you mentioned service workers earlier. And I think that's the nice thing about abstracting data fetching and not marrying yourself only go one way of doing data fetching because, for example, you can use hoax that get data from the offline storage of the device or your computer. You can subscribe to changes over time inside that hook. I've been really excited about hooks and reactive specifically because of this encapsulation ability. They kind of look. What's fascinating hooks to me is that they can look synchronous like notice that there's no a single weight but dirty, ultimate form of facing granny. When use of ria coca, say, use, get user session or something like that. And let's say that that's backed by Auth zero.

You go in that you make an A B A called Orry, goes through your rest back in or makes a graphical query. And then not only is it then returning the data against they subscribed to the changes of that data point over time. So not only does it not have the await in front. It also is goes beyond what a promise can dio. It goes into the terrain of what an observable can do right, which is you. State subscriber changes. And then there's a cancellation function. So I get excited about that primitive, more so than a prescription for a certain protocol. They should be. Get away the sign and so on. I just like the from the developer, thinking in terms off. I need this data,

and, by the way, I need updates to the data over time. So that's what's exciting because, like with Just react hooks, you can create the most compelling real time alive Web application. And you ask me about meteor and think that Meteor was trying to deliver on this stream, Uh, with a coupling to mongo DB with a copy into a Web socket server with a cobbling, too, you know, a green threat approach, you know, just it was like I think that they were right about what they wanted in the outcome. But there were such simple solutions that were actually client on Lee to get there. So we're really happy that, like we've been able to get old his goodness with very simple technology that runs in the client.

Can you describe the implementation details of hooks A little bit more? I don't know that you've looked into,

but yes, So going back to that image of, like, I carry my pages directory accurate in exaggerate s what doesn't exaggerate as contain Well, you export a react component, so you go export default. And that's a div. Hello, world, Def. So that doesn't do anything right? It's got If you run next, Bill, do you get in Exotic Seemingly just says hello world. So how can they actually bring data fetching to this? And this is where hoax air so exciting, Like the function that returns your JSX Your your page can no say.

In this case, let's say cause to user whatever equals use is logged in. And now that cook will return the Valley of that data point at a given point in time. And when you first call it most likely what are you going to get? Nothing. You're gonna get I loading stayed, and then you're gonna fire an effect, and you're gonna go and get the data. But inside the hook, there's this technology for being able to return values over time. So the hook and do fetch that. Who can look at local storage, the hook and look at index T B. The whole can do graphic yield hook into Web socket. The implementation details own matter. But every time it returns the value,

the whole page will. And this is the magic of react You don't worry about like we did with Jay Query. Oh, when I read Irving the Web socket, use that dumb selector, whatever. There's this, like, mind liberating idea that when the hook gets more data, the full thing rear enders and then you now paint your template with the user being logged in or not. So this is just so simple and so compelling because again that you might start with a very simple implementation. You, maybe you had on a P I for getting the locked in state or what not, But then you can get really ambitious with with what that hook can dio and one of the things that we use it for designed dashboard that's really exciting is hooks can fetch data in parallel, so the data needs air kind of somewhat cooler gated with components. Interestingly enough,

something we do that's really cause at Bill time. We know that we query like three or four AP ice, and then we will hoist those data fetching requirements, and we create in the fixed HTML that comes with the page. We have link pre low tax. So asi html begins to be streamed in are the browsers are sparse ing it. The link tax will start making fetch requests to does data portions that are then gonna be needed by the hooks. So you asked a good question. What are the challenges that Richt developers Phase One that I've found that it's really interesting is you have to wait for reactive boot up to do all your data fetching? Think about that, right? Like you know that when you go to slash shop slash cart, you're going to go and get the CART state from a server, and now you only have It's an HTML page that then have to download a pretty sizable Js bundle re ignites a boot your Hockney's to execute. So one way of sort of circumventing this problem is because an exegesis building the page it can now embed in the HTML that data requirements of those hooks later on. So we've really fall in love with a signature.

Because when we got rid of SSR for the dashboard, we actually found that are natural became faster because we started thinking about, like, what can the brass or do if all you have? If all you're armed with this an HTML page, What can the browser start doing? A head off, everything booting up so we can get data. We can render the shell, we can render some animations and so on. And then when Bria kicks in, boom, you get all your data. And the beauty of this do is that that data because of hooks can update over time. So not only did you get that discreet initial data load, but it kind of accomplished the quote unquote meteor dream of fully real time applications with basically no technology, just like smart jazz.

Since we're talking about react internals at this point, we should just talk about the newer features of react and something. I know you had some part in the at least the conversations around his react Suspense suspense gives the developer some control over rendering items that have not yet finished loading some asynchronous data. What are the ways in which react suspends addresses asynchronous data handling that has historically been difficult to

work with? Yes, So the main idea behind suspense is so there are intervals of time within which you know that you can do lots of work without necessarily committing a change to the to the view layer so that the best example here is when you're transitioning between pages, you might want to coalesce changes together. And there is an A B I called suspense list. That sort of enables this to say, Well, if I have three portions of the page that need data, can we sort of aggregate them within a threshold so that they all render at once and they can provide a much better experience? So that's kind of one of the big product needs that people have had over long, long periods of time, which is One example of this is that we've seen is when you go and load a new page, any triggers, some data fetching. Let's say that you're a B. I's Russia really fast. Well,

you might be used to the experience of light. You click on something and it shows something and then immediately changes into something else. And what's interesting about this is that when as your company or project evolves, you start getting a really good handle on how long data fetching takes from from server of choice that you have. So, for example, for our case because our a b I's enterprise grade. We look at the p 99 times like we basically obsessed over how fast are all this AP eyes responding to ensure great quality of customer service, and we actually alert on a p I is becoming slower and so on. So when you think about okay, now I'm in the front and and I'm gonna get data from the I don't know, get projects a p I How long does that on average take and was the worst case scenario? What's the basket scenario and what we found with our own experiences that we can answer that really, really quickly, sometimes in under 100 milliseconds, once the initial page load happened.

So what we're currently investigating is what are the opportunities to like take advantage of this knowledge not only the knowledge that we have data fetch a data fishing layer that's really performance, but also that the users perception of performance is also not as granular as, like 50 milliseconds, Right? So, like I user will feel something as instantaneous if it happens in like, let's say, 200 milliseconds, right? So suspense in combination with hoaxes, something we're researching right now, which would allow us to say, Hey, I'm in a transition to this page, But let's start. Let's Onley commit aggregated changes at once to provide a better experience of the user.

So another example of this is when you're dealing with dependencies between components where maybe showing you let's say that you're rendering the your bank's dashboard. Maybe you have to independent data fetching hoax one for getting the balance and one for getting and they user information or some like that. So could you suspend easily between both, so that you rendered those two pieces of information at once? Well, ah, lot of product designers will tell you yes, so I think suspends will become this other tool in the tool shed of the front of developer to coordinate with the product designer on like What is the expectation around what we should present on the screen? What we should block on, what we can do ahead of time as well, so that the product feels great. So it's interesting in that I mentioned earlier that before we started both cast what I love about Jam Sack. What I love about next yes, is that it's really shifting the conversation into How can you build a better product, I suppose. Lake,

How can they do you know, better state management or hiking? What router should I use and things like that? And as a result, you start like going deeper into this concerns that perhaps earlier we were oblivious suit because we were just happy that you actually were reliably data fetching. Okay, so now we've sold that Rome we can reliably and fast data fetch what its next. I think what's next is that we're thinking about ways that we can transition between pages in ways, at least for my perspective, to feel more app like What do you mean by up? Like I mean, in a lot of cases, when you goto a native app and you tap on something, the APP has already fetch the data for that. There's no there's no so much an expectation of like, Oh,

you're gonna wait or you gonna render a Spain or No, because they thought a lot about the experience. Another one is animation. So until today, next year, as provides you a model for switching between pages. And you can actually retain some sort of layout between pages as well. But kind of animating a lot is on you. So I think was interesting. Else that Spans was interesting about like Where we're headed is we're now elevating the bar of product quality and we're thinking about things like data fetching ahead of time. We're thinking about aggregating data fetches together so they commit all at once to the screen. We're thinking about animating transitions, and this is kind of the next big minds, and I think suspense is still early. We are not using it yet. One of the things we're looking into now to solve the problem off patio a transition to a page,

and it already has the data that I need is we're looking into just like I said, we hoist the data requirements of a page so that we can preloaded even with just HTML, we're looking into applying the same for transitions between pages so that when you're gonna click on settings, even when you hover on settings were gonna ready kick off the data fetching needs of the setting speech. And that actually is kind of solving a problem that, as a measure is pretty big today, which is like, we want instantaneous page transitions. But we want the base do not have this jitter of like skeleton like move around and like Dando data fetching and it seems very promising. So far we're currently experimenting with it. Our data fetching hoax lie referred. Those that are curious called SWR Is that your dog? Now they're this age and it it plays really well with next. Yes, because it's literally just Ria cooks And this Rick Hook libraries really enabling a lot of this coal use cases in a way that again it's like data back an agnostic Jemsek friendly. You can do lots of interesting things with pre loading data, and we've built our entire Dashwood with it. It's just really phenomenal. As

the company grows, the software infrastructure becomes a large, complex distributed system without standardized applications or security policies, it can become difficult to oversee all the vulnerabilities that might exist across all of your physical machines, virtual machines, containers and cloud services. Extra hop is a cloud Native Security company that detects threats across your hybrid infrastructure. Extra hop has vulnerability detection running up and down your networking stack from L two to L seven, and it helps you spot investigate and respond to anomalous behavior. Using more than 100 machine learning models at extra hop dot com slash cloud, you can learn about how extra hop delivers cloud native network detection and response. Extra hop will help you find miss configurations and blind spots in your infrastructure and stay in compliance. Understand your identity and access management. Payloads toe Look for credential harvesting and brute force attacks and automate the security settings of your cloud provider integrations. Visit extra hop dot com slash cloud to find out how extra hop can help you secure your enterprise. Thank you to extra hop for being a sponsor of software engineering daily, and if you want to check out extra hop and support the show,

good extra hop dot com slash cloud Just Teoh, connect the conversation right hooks and the conversation about suspense. Correct me if I'm wrong. It sounds like hooks are a way of decoupling, the application that you right from the way that variables are getting their data, whether they're getting in from a cdn or an A P I or the cash or, you know, whatever implementation details you want to add now or later. And suspense is a way of accounting for whether or not the data has successfully been loaded into

your application. Correct. So they're addressing different needs today. In the future, they might merge more closely. So, for example, one of the options that we have in the in our data fetching hooks is we can say, suspend true or suspense, really believe. And then we can then link it into the suspense subsystem, which works on this idea off promises that are thrown and waiting on them and blocking on them and so on. But today they are a strictly separate. So if I had to give you the recipe today for data fetching in a gem stack application, absolutely. Just use a hook, and again you can do You can get really far with just hooks on this.

All this data needs, like cashing real time subscriptions, pulling over time, tolerating errors, retrying onerous is sort of what s L. E. R. Gives you out of the box. But then we're still dealing with layouts, and you I issues right as I mentioned, one that happens is that there is this idea off transitions that are not as graceful as they could be because hooks air so fast they're trying to, like react immediately to every change, and they make coalescing changes a little bit harder, like in some games is very desirable. So, for example,

when I use twitter dot com, I just care about the timeline loading us fastest possible right? And then, for example, there's a cyber work of recommendations that can load later, and it would never suspend on quote unquote suspending, both coming together. It doesn't benefit me as a product designer, but there's an alternative universe where again there's two components they're doing data fetching, and they both need to work in unison so they can. They could still use different data fetching hoax, but they needed kind of all runner at once, and I think really can evolve to make this in easier task, like the coordination off blocking and it. And it doesn't even needed deal necessary with data fashion right like you can suspend on any asynchronous flow. But broadly,

that's the separation that we have today. And I guess that suspense is still sort of experimental, but that shouldn't, you know, stop you from actually doing data fetching with modern techniques

like hooks. Job script, a single threaded. If the React Team puts enough effort into building the right AP eyes and abstractions, can we attain an experience that actually feels

multi threaded in react? Absolutely. I think the idea of Js is single. Threaded is well, First of all, he has to stopped being true for a while because there are ways of you know, when you delegate data fetching to a service worker, for example, or even when you, specially there's so much is happening behind the scenes in different threats. This similar how no Js is a threat pool for all the heavy singers blocking started the to turn synchronous blocking work into a synchronous work and delegating off the main threat. I think the fact that react is doing all the scheduling, and it sort of managing our obligation will allow developers to even have this like multi threaded world under the hood or even the even if it's the illusion of a multi threaded world under the hood for free. You're just thinking about components and you're thinking about side effects. I think hooks are the right I have said in the right direction, because they're started, including constraints that allow for the Reik schedule er to do smarter optimization,

sundered hood. And ultimately, I think it's also helping platforms like React native, where you know there is more interrupt with the operating system, there's more interrupt with you I components that are not governed by the same system. So I'm really happy that reacted sort of starting to introduce constraints to ensure that over long periods of time it can be optimally parallel for every step of the painting rendering layout execution. And I think what happens today frankly, is developer sent to be oblivious to the fact that certain AP eyes are just slowing down their rendering. The most common that A C is a uses usage of local storage. Local storage is a blocking a B I. It's synchronously reads from the file system. If your visitor has an hard drive, you're blocking on spending a physical disk until you continue rendering and keep in mind. You can put local stories anywhere, and even because of Muslim memory, might have you mentioned they're All you get is a hook with local.

Sorry, no, you shouldn't. But the interesting kind of lesson there is, as you mentioned, the fact that J. Esus still has oldest blocking AP eyes are easily accessible, and then you can invoke them from the main. Let's call it quote unquote. The you I thread has really noticeable drawbacks. Even today. I saw recently a bunch of hooks being open source. They'd use local storage extensively, and that's something that you know, basically shouldn't happen. I think it shouldn't happen from an A P I perspective.

Like I think, one way or another, the engine itself should make this an impossibility, almost like an impossible state like oh, local storage within the U I threat. Oh, delegated to some other time to some other threat. And likewise, I think the Web has been pushing forward for a singer's FBI's existing, but I think discipline is not quite enough. So in this case, you're prescribed to use in next TV instead. And I think this is something that's just broadly a very, very interesting thing to think about. And this is also why I get so excited about deploying next Js to the action network and networks becoming so fast in five G and just like, sort of like becoming one with the computer and just getting But when I get but not really we're going.

Why we're the network is what I'm excited about. We run this experiment with SWR where so the a b offensively are taken goto swr dot Now they're this age or another similar project called React Query by 10 or Lindsley. You basically say use as that we are and you go and you use us a key any a p I like you say, like slash tweets and then a function to get that like fetch. So the easiest way in the world to get data is used as that we are slash tweets comma fetch, but you can use any sort of a single is functionary as there sort of data fetching function. So we built our entire dashboard off of this in their entire website. Even when you like good or marketing pages and on the top right, you see you're logged in state. We're using a hoe called and we wrap them so we use a local like use locked in or whatever. So the one of things we realized there's a summation early hooks, air. So, like that I would call them anxious. They're like, anxious to return and give you what they have,

right? So the first time they hope executes, he has nothing. So we started thinking about Lake. There are a lot of cases where we could be returning something especially now that were equipped with in next TV. So we're like, OK, like, let's say that you have a list off your like CART states for a shopping cart or a list a wish list like you're you're saved. Books inaudible dot com We're like, What if we could just, like do like uses ugly R slash books and then a finding cigarettes function called fetch with cash so that what we do is we essentially read from a cash like in the TV or whatever and then fetch the rial like most up to date data, and then continue to fade over time. But we found that this is like what's surprising Going back to like Why I'm so excited about the global network is that we shipped telemetry on the client side and we found that the cash was actually kind of like not helping us that much because a lot of our users were either on like disks or or local device that were busy. So perhaps in exhibit was taking a long time. We found that lots of in Exit B that reads concurrently were kind of getting throttled.

Were like some people have just really slow disks. So they were like, Oh, maybe we have do a data race between the disk And then we'll realize, Wait well reasoned data hoax to get fresh data. And the network is actually really fast and becoming faster with HDB three with databases that are global, with databases that can shard customers by country. So we realize it's just go to the network as fast as possible. Then network is the computer like son used to said so funny enough, we ended all those efforts in, like doing, like, smart, like local data cashing. And we move Teoh just hitting the network really quickly. And the kind of sort of story here is It's amazing what clients had abs that download and load really fast from this edge network and do. And I see the future is being getting data and committing data to the edge network incredibly fast, and then will truly build applications that are sill very easy to write and deliver. But that just Brenda and Low Data and instantly and I think reacted so well positioned to sort of capture

that future. You've spent some time talking to the react team about some of this concurrent stuff, I believe partly, I think, because you usedto used to work with them right on the you because you were in mood tools. Yeah. How come you never joined Facebook?

The story is really finding, because when I was working on mo tools, I believe I started when I was 16 and it was in Argentina. I've always made it my mission to not share my age publicly because I've I've always truly believed in, you know, results over anything else, and I think I always saw my age is being like, sometimes over blowing result so out of proportion, like the story of like, Oh, wow, he's doing that and his Onley and years old, But also, sometimes he was kind of like the opposite, like it would drag me down. Oh, he could not be hired.

He is 15. So it was like both things in one. But what happened was really funny is when the modules teams were started moving into Facebook. I remember getting paying for jobs that Facebook many times and one serious offer involved, like a recruiter being involved, like in the they probably wanted if in fact, one of the early face with murders, and then they can have found out. Oh, not only is the in Argentina and he would have to move to San Francisco, which was like a core tenant at the time, Like I think obviously there was someone office, But also I believe that when I did get that offer, I was probably 16 or 17 still, so it's basically impossible and it was really funny. I mean,

it was really over. The years has been really flattering and makes me really proud that I've been closely with stories and a obviously could have been a bigger part. But now, being in creating an independent project than any of the been in company also see the value off growing the entire react ecosystem. I see the value on building more opinionated takes on software development. I see the valley on closing the loop. I think one of the most interesting loops to close Is that okay? You get excited about this open source library? How do I actually publish it to the world? And this is why I look also always to apple for inspiration because they built a platform and we all agree, Okay, Super closed. And it's not great, but they're giving you the ability to reach the world in a way that they've basically removed almost every question from your head. Right? Lake The apple actually downloads all the app blobs from a cdn.

Sure they're not Js yet, but there, you know he download this native APS from a cdn. The other son know that that they worked really hard and creating this ach network for application delivery. They get there given the tools that they recommend and they're giving a fair amount of flexibility. They're giving ways to build and publish them. They were given feedback, right? Like if you publish a bad app, this is what happened to more exactly. But right, like he published a bad app and he got her ones that reviews. So I look to that for inspiration. I think by having a more opinionated take on the software development life cycle but still being very close to the open source community, we can push the Web forward to get to that level of end to an amazing experience. So nowadays,

when I think about what I would love to improve in the reactor ecosystem, I look to native for inspiration, look to animations. I look too compelling experiences. I looked too fast, data fetching. I look to, you know, simple things. Like when you go back and forth in the nap, you don't re fetch data, and that's one of things that you can do with hooks today. So Alex Russell had this funny bio. He were said at school and chrome or so in weather. Sanders, actually,

And here this funny phrase for many years is like every day working hard to push the Web into the nineties or something like that because his thing was with you. What you could do with C plus plus in or in G, T, k or Q T or whatever in the night is the Web always would take longer to reach that level of performance or a B I access or whatever it is. So the Web historically has been lagging behind a little bit on like the A P. I said You get, for example. But what the Web has that is truly amazing to me is just how broad the ecosystem is, how much of the building blocks are open and accessible by everybody, but most importantly, the fact that you can reach so much further than what Apple can do with IOS. This year, Els that you published this deploys that you make can truly reach the entire world, and then they down with the code time bits of code lazily, and that code can be updated much faster than native up could. So I think what I kind of see happening this decade is we're gonna continue to make this software development loop really, really amazing. I believe strongly that Reigle played a major major role in making that happen. And then we'll get to this sort of point where we're building the highest quality experiences when you compare Js and react to any other benchmark that he could imagine. And today I still think we're lagging behind and we're

getting there. Do you think it eventually goes as far as react native and totally pervades

the motorcycle racing it happening? So there's plenty off very popular APS that are shipping Reeg native, with a combination off there even exact same rare code base wrapped into like a react. Native web You to the hybrid mechanism of you putting to react native and some things their web and some things are calling into the native component AP Eyes to fully react native were like every single component is using the operating system component like the native you. I component that Apple or Andrew have already built. And in my opinion, this is only going to accelerate because of the underlying economic advantage that you get and just like product development and product design and engineering advantage that you get from one unified code base and one unified ecosystem So like I said it, it took a long time for Electron to be the way that a lot of companies like Slack have chosen to right their clients. And now this would be unthinkable that they would write to other APS one in like the Windows you y a B I's and one in, you know, Mac OS wants and so on or limits right, for that matter. And I think the same is gonna happen to Mobile. I think little by little, like mobile websites were getting better. POWs are getting better. Google has great data showing that pl ease can be even more engaging and compelling than native counterparts.

What we need to work hard as a community is on being very cognizant off our benchmarks of performance. Right lake? You know, what is the experience on you know, the first base load, Like, what is experience on how long it takes to render his experience as compelling from in user interaction? Perspective. So I think once we started working on those things more consciously, we're definitely going to

get there. How will the jam stack look in five years?

I think gems that is going to be the enabling technology because when I tell someone like, hey, just hopping react and they've never used reactor. Maybe they're still running at JV M monolith that several very and like react is too specific of a prescription. But it's also not complete enough off a solution. It's not a stack you're being told. Use a library, right? And that's not how you build software is. If I tell you again, you're gonna build the biggest next big social network. And you're like, OK, I'm gonna build an IOS app. You kind of get this idea of there's an entire sort of prescription, for it would react is more of, ah like and this kind of the thing that we're solving with next.

Yes, we're saying Next raises a framework for jam stack. Really? Because we're we wanted to take and adopt the best way to build software and we by saying jams like we say implicitly cdn network, we say implicitly, no overhead on operating and running your code. We say very rich experiences because the presence of javascript includes Oh, you're going to do a lot of interesting stuff on the client side were saying up to my server markup. We're saying, Take advantage of the A B I's that you've already built. So imagine they just tell you Use react. You're like, OK, do I write my A B ice and react is not enough of a solution. So what I like about jumps a saying like this is a very concrete answer to what the future looks like to how we build my next app. And even if frameworks change over time like I don't start with next, yes or I use view or I use this Valdir sapper. What's more important is that you are still using that better programming model, and that as a result, your users will get a better experience.

Next often gets categorized side by side with Gatsby. How do you see next and Gatsby diverging or converging?

I think next, yes, is less opinionated and more flexible. So Gatsby has always prescribed the usage of draft. You know, for example, gassy has a constant of themes. Next race has always been more deliberate and careful on staying closer to the bare metal of react. So, for example, we thought about creating a theme abstraction, but they would realize well components provide a solution for theme ing react context provides a solution for theme ing. Even CSS provides a solution for seeming so we want to say, closer to the native Web as well in that regard and the abstractions that we percent are as a result, lower level. And we think this is a better bet, longer term with regards to how industries evolve with regards to how reacted self evolves for assemble.

That's what it's saying. Like you know, for most actually say, for all our client side data fetching, we use hooks we don't use, like some new way of doing data fetching that is unique to next year s when we use static side generation or we need to fetch date at the top of the page, we do have an experience, a specific cook, But that data fishing hook that Nigeria's provides the only contract is that it's a promise gets resolved. So you get to data however you want. So I think that's a very important pilot or because we see nauseous as a platform for the future of reactive element and platform seems to stay very, very flexible, and the opinions that they provide have to be battle tested. So for example, when we started now Js we create react up didn't exist But we were docked Fuding next. Yes,

internally, A lot. And I remember we're starting to strive to do a lot, Everything with react. So finding enough The first page that I built for my company was the logo. Welcome. Leave your email And then I remember early on I was like, Okay, if you're gonna put in personal information that have to at least have some terms of service and and some privacy information and so on. So those s so I thought, OK, what is the minimum viable company website and had, like those three or four pages And when a first building with realize like, Whoa, I'm shipping the content off the terms of service in the Js bundle together with the first page and the input for that page was like there has to be a better way and a one back to the principles of the web of like the Web. It is a bunch of Urals that download html.

And when you go to CNN dot com, you're not downloading the terms of service So one of the in variants that we found was well, there will always exist multiple pages, multiple Urals and multiple entry points into your application. And then we started evolving in that direction. A rumor when create react up, came out, create a reactive, was even lower level then next, which is a great thing. And it's a great on ramp into react. However, I decided to still open source and Jess because it was like, You know what? Like I know that people will figure out how to solve this, but I know that every single developer will want that a specific feature and the same happened with a few other things,

like importing CSS, the router, the router, a p I. So all the AP eyes that we've built into next have been carefully considered in terms of those in variants, things that are not going to change. And I think, broadly speaking, that's what's going to determine the evolution of next on the evolution of Gatsby, where next year is going to become more of a platform, whereas gas is gonna become more opinionated around a use case like I need to run there a specific block post, and they know that I want to use graphical. But I think ask companies evolved to become a lot more dynamic and versatile, and I think God is kind of optimizing more for the less dynamic and versatile use case, which is also fine. And I think there will have a lot of usage for those things. But it's just strictly less flexible.

The deployment medium of a container that may be executing serverless functions or perhaps a Web assembly module, thes air, different architectures there, exemplified by AWS, Lambda and Cloudflare workers, respectively. Tell me your perspective for how the deployment medium for service applications is gonna look in the limit

as far as we know. Yeah, So what I mentioned gems like that I like is that if you've heard previous sort of summaries of our platform, we've always said it were server lis and server less as attorneys Super loaded, right? Like what is it? No servers or service, but they're abstracted and hidden or like, What is it? So what a Lego jams that it's a more opinionated take on how you are serverless gems like it's obviously server list, but what I really really like is this idea that you don't deploy to a specific location. You deployed an ACH network, and as a result, what going said that I'm addressing the first sight of the comparison, like, how is it different from container? It's cost prohibitive.

And I would say nearly impossible to say I'm gonna deploy my server to 20 locations immediately in a way that's fast, cheap, etcetera. And even then, when the request comes in, do you always want to make it go through a server? Especially since we just discussed. There's so many types of pages that it can be basically narrowed down to a bunch of HTML that got me to return immediately. So you probably don't want to use a server or container, even if the containers serving static files this, find anything to carefully consider if you have a server that it's serving static files and even if you throw a cdn on top, you're just adding more steps and more places where things can go wrong and most likely or not, actually optimizing correctly for the fact that you're dealing with static files. So I love this idea of pushed to the edge, especially for all the parts that can be decidedly static, where we already know ahead of time that they're static.

That's just like the beauty of that model. Further going to like the worker type abstraction. I think that you should avoid that. I think that if you're receiving a request from a visitor, why would you want to run code at the edge if you can avoid it? So I mentioned some strictly tactical and operational reasons for doing so. Like Oh, now you have to worry about coded executing a server context and called Mexicans in a client context because the code will run in both right because the Japanese have become alive later. So I'm running exception handling with century, for example, and putting it in my worker. But then putting it in my page. I'm doing telemetry. I'm doing Goal Analytics on both sides. I'm increasing that surface for security problems like a worker, and this way I actually don't love the name of it is sharing traffic and putting it all in one worker right is bringing back this process abstraction,

and I strictly dislike that. From a security standpoint, I don't like the shared memory architecture. Basically, the idea of a V eight isolate is let's share a memory space with everybody else, which can basically create lots of bleeding off sensitive data. I just love my edge to give me the the thing really fast without executing any circuitry. I look at it as strictly a cost saving mechanism for transferring the job. That is inevitably gonna happen on the device to only the device. So it's going to save me. Money is going to make me sleep better at night. And this is why I love the idea of next year's becoming the Jam SEC framework because it's hard to capture all this subtle new ones and all this technical like enlightenment of the pieces. But if you just use this framework, you're going to get all this cost saving, simpler engineering, simpler deployment all in one package and going back to why I really want to invest in making next year's the platform.

I still think anybody in the world should be able to technics, dress and run. It s a container if they want. Is that the way that I think the future's had it? I really don't think even the present. It's not there, but you should be able to do so. So we need to retain this ability to take your luxurious project, run it locally, run it remotely, and what I like to say is not run it. I like the idea of not running code at the edge and running lots of tiny little pieces of code in the clients so that your page loads fast and start doing things really fast.

Guillermo. Thanks. Come

on. The show. It's been great talk. Thank you so much.

Apache Cassandra is an open source distributed database that was first created to meet the scalability and availability needs of Facebook, Amazon and Google. In previous episodes of Software Engineering Daily, we have covered Cassandra's architecture er and its benefits, and we're happy to have data Stacks. The largest contributor to the Cassandra Project since Day one is a sponsor of software engineering. Daily Data Stacks provides data Stacks Enterprise, a powerful distribution of Cassandra created by the team that has contributed the most to Cassandra Data Stacks. Enterprise enables teams to develop faster scale, further achieve operational simplicity and, sure enterprise security and run mixed workloads that work with the latest graph Search and analytics technology, all running across hybrid and multi cloud infrastructure. More than 400 companies, including Cisco, Capital One and eBay, run data stacks to modernize their database infrastructure, improved scalability and security,

and deliver on projects such as customer analytics I O. T. And E Commerce. To learn more about Apache, Cassandra and Data Stacks Enterprise, go to data stacks dot com slash s e daily. That's data stacks with an ex d a t a S t a X at data stacks dot com slash NC daily. Thank you to data stacks for being a sponsor of software engineering daily. It's a great honor to have data stacks is a sponsor, and you could go to data stacks dot com slash s e daily toe. Learn more.