Why Everybody Needs a Framework

Hi! How are we? OK, I'll work with it. It's the last talk of the day. You know, fun fact, I have 25 minutes. It's on 16 minutes. I have 20 minutes, right? But it's the last talk, so technically, I have all the minutes. Cause the after-party from here is at 7. But anyway, I'll try and be respectful of your time. The organizer is looking at me here like, hey, hey, now.

I'm Tejas. That's pronounced, like, contagious. I can say that now cause the lockdowns, for the most part, are over. And I've had the privilege of working in some capacity, either as a consultant or as an employee at a number of different tech companies across my career. And it's an opportunity that I'm really thankful for. And through it, I get to experience a bunch of different things, right? Today, I run a small but effective developer relations agency where we support developer tools, developer-oriented companies, communicate, get their message across, and really refine that developer experience, okay? But that's not what we're here to talk about today. Today we're here to talk about why everybody needs to use a framework. And you might be reading this and going, what does that even mean? Does everybody need to use a framework? Ideally, we clarify some of those things today. I just need to preface. I'm not... I don't work on React. I've been working with React since 2013, 2014, and I deeply love it. I have the privilege of knowing some of the team. And the work they do is inspiring and is intellectual and solves real world problems with high abstractions that just get the job done and make you, guys, the hero. So if we can hear it for the team. I would really... Yeah. Yeah. It has... I think it's an understatement to say that React has revolutionized the way we build on the web. And I think it's worth acknowledging.

So why does everybody need to use a framework? Where does this even come from? Earlier on X, the platform formerly known as Twitter, Andrew Clark from the React team on Vercel posted this in January. He said, if you use React, you should be using a React framework. If your existing app doesn't use a framework, you should incrementally migrate to one. If you're creating a new React project, you should use a framework from the beginning. Some of you might be thinking, but isn't React a framework? Is React a library or framework? We're not doing that today. Let's go on social media and fight. No. But React by framework, what Andrew is referring to is something like Next.js or ReMix, et cetera. And I love this. I use framework. Are any of you using frameworks here in production? Okay, almost everybody. For those of you not, let's talk about why. And this is what I want to do today. This is great, but I want to understand the mechanism that leads us to arrive at that conclusion. Like, why does one say this? And to understand the mechanism, you have to answer the question, okay, what even is a framework? And a framework is essentially a set of opinions. It's a frame within which you work, literally. It gives you opinions around routing, around data fetching, around where do you render the server or the client somewhere in between. And these opinions are handled for you so that you can, you can what? You can build your product with velocity. You don't have to solve these problems individually. So it's the opinions that help you accelerate your development workflows, okay? If we refine that a little bit, what do frameworks do? What do frameworks do? Well, a lot of them have overlap. This is maybe not every framework, but Next JS, Remix.

They'll do server side rendering. How many of you server side rendering in production? Okay. Almost everybody who uses a framework, great. They solve routing but not just on the client side. On the server side as well. Isomorphic routing. And this is useful for a number of reasons because previously back when we were doing only client side stuff, we used to send 404's. I don't know if you all remember this. We used to send 404 status codes from the server side and then a 404 HTML page would pick up on the client side and give you an app. But this is fundamentally a lie from client to server, okay? And frameworks solve for that.

Number three, data fetching is tremendously easier with frameworks. If I ask you, where's the best place and when is the best time to fetch data in your React app? What would you tell me? Would you tell me that I use effect and I fetch inside use effect and then I set state? That's a really common pattern but that's a problematic pattern because it leads to what? It leads to, I see you, this is React Advanced. We're not in kindergarten here, right? It leads to network waterfalls. It leads to slow things. You've got to render first, that takes some time. It's CPU bound and then you've got to fetch and then you've got to render and it's not fast, it's not performant and your user experience suffers. So frameworks solve a lot of these problems for us and more. In fact, they solve all the edge cases that we probably miss because they're built by very large communities who run into problems that we may have next year today. OK.

So that's the theory of it but I'm already bored with my slides and I figure we just do a little demo for that. This is a demo that solves for those things. It solves for rendering on the server side, it solves for data fetching, etc. It's kind of interactive and it's the end of the day, let's just play. Since we're talking about server rendering and data fetching, we need a full stack application. We need a frontend, we need a backend. There's plenty of ready to go backends. If you need a quick API, there's dog.ceo where you can query a bunch of dogs. Since we're in London, I was on the search for a good backend. I happened to find a stealth London based start up that has been very quiet but has been building something really cool. I was so compelled, I had dinner with the founders last night. I was compelled let's just put it in my presentation and show you all this. I have permission for this but I want to just fill out the full stack of the stack. This is the application we have, so if we go to the browser, if we go to the code, OK. So it's a jokes app. It says no jokes. I don't know if you can read that, it's intentionally small but it's essentially going to query a database where jokes live and render them. Client side first, then server side and we'll do that together. But we need to fill this database somehow. Let me walk you through the code a little bit and then we'll fill it interactively. OK. It's the end of the day so let's play a bit. If we look at the code, what do we have? We have a React app here. Is that font size OK? Can you see in the back? Nobody cares? Great. OK. Let's... Boom! There we go. So, very basic React app. We're hydrating the document with a layout and if we have a joke ID, it's an answer, otherwise it's a question. It's a question answer type of joke, right? Like why did the chicken cross the road? Because there was hydration, I don't know. Whatever.

And so this is our application. We have questions, which is a component that effectively fetches data, but there is no data. So let's walk through the back end a little bit. The back end, I'm using this stealth starter, it's called keel. It's a tremendous back end, frankly. This is the website. And what was compelling for me is it's one file. You write one file, you git push and it becomes infrastructure. And then you open a pull request, change the... It's nuts. Infrastructure is code, but you don't bring your own anything. It's fully managed. And it helped me prepare this demo really fast.

So, the back end is essentially this schema. If we go to here... So what do we have? This is our database. We have a joke, it has these fields, a question, an answer, and a source. And these are the things I can do from my API. So I get an API for free. I can list jokes, I can get a joke by ID. I can even validate a joke. Listen to this. This is the moment. I can validate a joke using AI, for real. And so, validate joke, and it's here. And if I look at the code implementation, all of this, by the way, is code generated from this file. I don't really write any of that code. And if I go to validate joke, this is the code here. So, I get the question. And I make sure it has to be at least three words. And then, we talk to OpenAI, and we say, for this joke, does it make sense as a joke? Respond with JSON, true or false? That's the full back end, the full API, running on Keel just with one document. And what I want to do in our time together is actually do that.

So, as you can see, in our app, we have no jokes. Let's make jokes. What I want you to do is create a joke. So, how are we going to do that? Scan this QR code. I promise you it's not porn or anything. Just take my word for it. Code of conduct, I'm sorry. No, but scan it, and that's going to take you to WhatsApp, if you have WhatsApp. It's a Facebook conference-ish. And what you're going to do is text a joke. So, first part, why do developers like dark mode? Send that. And then second part, because it attracts bugs, because light attracts bugs, right? So, something like that, okay? So, you send a question, and then it'll say, great question, and then you send an answer. Experiment. We'll try it. If it doesn't work, the Keel folks are here. They'll just fix it. Anyway, so, let's, I'm curious. Anyone WhatsApp working? Yes? At least one.

Thank God. Okay. So, I opened something up to the internet and I'm scared because I know what you're capable of. Please don't be rude.

Okay. Let's take a look at our jokes app. And if I reload, I should ideally have something. If not, you know what? I'll just go on WhatsApp right now. This is my WhatsApp. Welcome. You can't see my messages. And I'll submit a joke right here. What is... No, no, no. Why do developers like dark mode? And now, depending on conference internet, it should say love it. What's the punch line? There you go. Because light attracts bugs. Hilarious. Please tell me it's a good joke. The thing is, because it's... Oh, great. It saved. Okay. Oh, and there's an ad. Awesome.

Anyway, let's reload. And what we should see now is we're fetching data. Great. A lot of people. Thank you. Give yourselves a round of applause. That's amazing. So... What is brown and sticky? Why? You can never trust people on the internet. I'm not even clicking on... Anyway. So, by the way, I think all of that brown and sticky... Me? Who said that? Depending on what game we're playing. You know what I'm saying? So, all of that came from one file. That whole back-end... And I think this is really awesome. We'll get to the framework in just a minute, but this is the database that we have. So, we go here. These are your jokes you entered. I'm kind of spoiling the punchlines, but I won't see them. But look at this. You invented all of this. Amazing. Anyway. Let's get back to the framework.

So, we have this. Why was Six afraid of Seven, et cetera? So, now, let's look at this. This is fully client rendered. And you can see that by the flash of Unstyle. Look at this. It says, no jokes, and then it fetches and use effect. This kind of sucks. Let's look at the React code that drives this. We go to pages question, and we go to questions, and this is what we're doing. So, we're fetching from here. We're doing list jokes. We're getting the first 10, and then we set state. All on the client side. And this is really not the best way because of waterfalls, et cetera. And then we finally return a map. We basically iterate over all the questions. If you've written React, this is not new to you. The problem is, this is entirely client side. We have this flash of nothing in the beginning, as we fetch. That's the waterfall. But even worse, arguably, is if we view source, the markup is really empty. There's no text. There's no jokes. There's nothing. So, in an environment where JavaScript isn't supported, search engines that maybe don't execute JavaScript, you get nothing. Nothing. Nothing is here. We want that framework solved through what? Through server side rendering. Right? So let's implement that.

Anyone implement server side rendering from scratch? Ever? Yes! My people! Three of you! Fantastic! The rest of you, we're going to do it. We don't have time to live code. We're going to do some git gymnastics, but we'll get through it. Okay? I'm just... A round of applause, because I showed you my WhatsApp and censored my private chats. I think that's brilliant. Yes. Fantastic. Amazing. You can't... Some of this stuff, you shouldn't see, and you don't. So that's great.

Alright. So let's look at adding server rendering to this. What we're going to do is open the editor full time, and I learned a trick in git. This is... I think you all maybe could learn this. So in git... Right? You can check out a commit by commit message. Anyone know how to do this? I learned this from the talk. Nobody! Ah! You're learning stuff! So to check out a commit by message... Look at this. I have a... This is my git log. Whip, whip, whip. I have add permission as my commit message. So if I go git checkout, and then in a string colon slash commit message, boom, I go there. It's fantastic. Thank you. Today, you learned, and if you learned, please go post it on social media so I see it over there. So let's check out the story. We're going to step zero. That's my commit here. Step one, rather, sorry. And in step one now, we have a server. So let's go look at our server, server.tsx. This is server rendering, but like bare-bones, OK? This is just we're understanding mechanism. Don't do this in production, OK? So what are we doing? We're importing React. And this render to string function is not really usable for production today, I would say, because it's synchronous. It blocks. Ideally, you use something asynchronous, like render to pipeable stream or render to node stream, which implements the, or render to readable stream, which implements the browser version of streams. Ideally, you use something stream-based. For the purposes of education, we're doing this for reasons that will become clear eventually. We're using Express for a server, but you could use COA, you could use Fastify, you could use whatever you want. I just like Express and some other dependencies. So we initialize a server. We say read CSS and static assets from dist. And then we do this. We get a route parameter page. This can be anything.

This can be question, answer. We dynamically import something from dist pages, and then whatever is in here, okay? And this is really why inside a framework your page that you export needs to be the default export because module.default is standardized. And if you do a named export like this, it's impossible to predict from the framework. This is why the opinions of the framework help you move faster, okay?

So we get the page component. We wrap it into a layout. And then we just send the HTML over to the client. That's it. You have server-side rendering for you. Finally, we listen, right? This isn't that complex like 25 lines of code. So let's take a look at this now, running in the browser. So we'll NPM run build to bundle everything and we'll just start this up, okay? And now we'll go from port 5173 that's VEET on the client to port 3000. And we have server-side rendering but it says no answer. What's going on?

So we go to slash question and it says no jokes. One really important thing to mention here is we are doing file system-based routing, right? So if we just look at the path and then import the module. So we do indeed have pages slash question and we're at slash question here. But the problem is there's no jokes. Why is there no jokes? It's because we're not fetching data. We're literally just rendering to string. We're fetching in use effect but use effect doesn't run on the server-side. So we now have server rendering but it's a half solution. What's the next half? Data fetching. We have to fetch data somehow. Now there's multiple ways to fetch data. There's get server-side props. You can imagine kind of how that's done, right? I mean we're already importing, if we take a look here, we're already importing the default export from this file. We could literally just import dot get server-side props. This is literally what Next.js does. And we call this function, fetch the data here, pass it as props, OK. It's react advanced. I'm assuming you can get there because we don't have time. But this is essentially how frameworks do it under the hood. I want to look at the new hotness for data fetching, which is server components. Server components is the answer to data fetching. It is the answer, period. I was talking to Satya here who mentioned it's like relay, but for everyone. He didn't say exactly that, I'm sorry. I misrepresented him. He's going to come see me after. But server components is the way. So let's talk about server components by implementing server components from scratch, in whatever time we have. I didn't do this. I am not a React expert. I just use it for a long time. This is heavily derived from the work of one Dan Abramov, who wrote down server components from scratch. Literally, this is the GitHub page that he wrote. You're welcome to read it. It's long and informative. And I learned it, I read it, and I was like, you know what? This should be a talk. And so I asked Dan, do you mind if I... And he was like, yes, do it.

So that's what this is. You can go read that. But this is the interactive, like, I'll show you what it says. Okay. So how do we do server components? Well, for starters, we need... What even is a server component? That's a great place to start. A server component is a component that executes on the server exclusively. It's a... All components are functions. Function components are functions, built-in components are not. Function components that execute only on the server are called server components. They execute on the server. And what do React function components return? That's the question. What do they return? They return JSX. But they return JavaScript objects. Every React function component returns something. Like type is either a function component, like this. And then props, right? And then props is... Oops. Props is like this. And then an array of children. Like, this is most React components. Sometimes with server components, this type can be async. And then you get into, like, issues. Like, because React cannot render promises. So you need to somehow unwrap the promises. And this is where server components meet server-side rendering. If this is unclear, let's just do it. Let's write the code and explore this together. Okay? So, how do we take, for example, our question component and turn it into a server component? Let's go here. Right? We're doing some fetching here. If we wanted to turn this into a server component, what do we do? We get rid of use state, for starters. And we just, basically, come here, and we await. And yes, the component with server components is an async component. Ooh! Fantastic. We get rid of the dependency array. We get rid of... Look at this. Look. Watch. Oof! Okay. So, we... We get rid of a bunch of stuff. And finally, the TypeScript doesn't quite know that components can be async. So we solve it like we solve all TypeScript problems. By doing that. So, this now... Thank you for laughing. It's valuable. So, this is...

Matt Pocock is not here, so we're good. So, this is now officially a server component, conceptually. The problem is what? React cannot render promises. And anything async returns a promise. So we need some process to await everything, fetch all the data, and turn async functions into regular function components. We need that piece to exist.

How does that work? Let's look at it by checking out the next portion. So we'll get stash everything, and we'll check out number 2. So, some things have changed. This is now a full server component, async await. Let's go look at what happened on the server side. If we go to server.tsx, a couple of things. We have this new function now called unwrapjsx. Unwrapjsx, and this again is for the purposes of learning, it's way more complicated, but this is from Dan's thing. Unwrapjsx is a function that looks at your big React tree of objects, right? Every React application, once again, comes to type is, let's say type is a div, and props is something with children, and children could be literally like a deeply nested React set of objects, right? So this is valid. Let's actually maybe give it some value. Okay, so it looks at this. So this function unwrapjsx will look at this and go, children can be a string or a number or a Boolean or an array of things. This is actually legal. It could even be an async function component. It could be anything. Moreover, instead of a built in component that's a string, this is valid. And with server components, even this is valid, right? So a whole bunch of things are valid. So this unwrap function is going to look at all of these cases and return a weighted JSX. Clear? So if our JSX here that we're passing to it is a string or a number or a Boolean, which is valid, right? We could just do something like, like children could be this. It technically could even be this. In this case, we just return it as it is. If it's an array, we await all of any promises that exist in the array fragment. If it's an object, and then if that object is a react element, this property, $$typeoff, indicates that an object is not just an object, but it's a react element. So if it's a react element, then what? There's two kinds, right? There's functions and built in. So we handle the built in case by, if there's any async props, which may be children, we await them. For function components, similar. We await the props, we then call the function with its props. This is react, right? You call your component with its props, we await it, and then we unwrap that. So we just go through this whole long tree and await everything. And at the end of it, what do we have? We have a big tree with all the data dependencies resolved. Is that clear? We just have a tree with everything fetched. Then what do we do? Then, we hand that tree over to renderToString, or renderToPyblestream, or something that will then take the output of server components and pass it along the network. In this case, the server-side renderer, renderToString, renderToPylblestream, etc, becomes a client of the server component renderer. So the server is the client. It gets a little bit complicated, but that's essentially what's happening.

So what does this look like in practice? Well, if we come here to our router slash page, we're dynamically importing the default export. Before we renderToString, we've added another step. We unwrap the JSX. Unwrap just means await all the promises. So we pass in our application. We say, hey, if there's something async here, await all of that. And then give me a JSX tree with all the data dependencies resolved, render that to a string and send it. Let's see how that works. So keep in mind, we're not using React on the client side at all here.

So let's NPM run build, build a server and run it, and we'll reload. And there we go. So we are fetching data on the server. This is entirely server-side rendered. If I open the React DevTools, this page, I don't know if you can see that, but it says this page doesn't appear to be using React. The entire thing is server-side rendered, including the data dependencies are fetched on the server, and we get a full page. And some of you are looking at me going like, wow, you just invented PHP. Not true. And we'll get to that in a minute. This is much richer because if we view the source now, what we see is a big HTML string with all of the jokes. Why was... Gosh, let's make this a lot bigger. So why was six afraid of seven? We see the other joke. What did the left eye say to the right eye? Et cetera. So we have rich markup that other clients can now pick up and read. It's absolutely phenomenal. And also, if we're doing any big imports of massive date formatters and things, all of that happens on the server, we don't ship any of that to the client. In fact, we don't even ship React to the client. There is no JavaScript on the client. It's brilliant, okay?

More or less. What can we do now? Since the React server components renderer gives you a big JSX object, who else speaks this JSX object? React on the client side. Oh, okay. So what we can do now is pick up that JSX object and do things with it on the client side. So let me show you a practical use case. Because of this, because of the server side, the server component rendering, we can now do things like soft navigation on the client side. Let's look at that.

To start with, let's pick up React on the client side. As you can see, we're not using React at all, so let's add React and then go from there. So we'll check out the next branch, number three, and we will once again run everything. But what's happening now is we're taking the server side React and giving it to the client side. So here, watch. So we are on the server, sending HTML. Let's close this, let's close everything and come back to server.tsx. Okay. Let's actually check out number four. What? On the... Did my thing not work? Whoa. Uh, hi. Sorry. You know how it is, log. Git checkout 3. Okay, cool. So what we're doing now is, we have our whole JSX object. We're adding some script tags here to take the big JSX tree we created on the server and we're attaching it to the window object, okay? And then we're also loading React on the client side.

But what's happening on the client side, and this is interesting. So this is entirely client side here. We are hydrating the document, not with some layout component like this, but instead we are reading window.initialjsx. Where does that come from? That comes from the server, we literally hand it off here. Client picks that up and just hydrates based on the server-generated JSX tree, okay? What does that look like in practice? Let's npm run and see. So we'll do this. Reload. Okay. So if we view the source of that, what we can see is window.initialjsx is our big JSX tree that we generated on the server-side. Literally from the HTML, children here is head, et cetera. It's the entire document object, okay? Since now the client and the server both speak that document object, we can do some really great things, and we'll finish with this. And I hope this gives you a nice primer into server components. So we'll go to question. And notice the problem that we face still is we don't have soft navigation. So if I click on one of these jokes to see the answer, for example, how do you throw a party in space? So if I click on this, watch the scroll position. Okay? I click on this, and it resets. Everything starts from the side again. You planet. How do you throw a party in space? You planet. I like that. But watch what's happening. The navigation is not soft, meaning I lose state when I navigate. So again, I click on this link, and what happens is it just resets the whole page. I hate that. I want to fluidly, I want to keep the animation going.

I want to fluidly, I want to keep the animation going. I want a soft navigation. And you can do that because client and server both have the same JSX tree. So to do that, we'll finally check out our last branch. We'll npm run build. And let's look at how we're exactly doing that. So if we look at the code, on the client side, what we're doing is we're hydrating with the initial JSX we get from the server, but we hijack all the clicks on window. And if we click on an anchor link, or rather if we don't click on an anchor link, we do nothing. If we do click on an anchor link, we say hey, browser, don't navigate. We have a better plan, don't navigate. What is the better plan? We pull down the entire document from the next page from the server, and we give it to React. That's what we're doing here. We pull down the next page, we give it to React, and we say hey, React, just re-render with this new tree. So we're not navigating, we're soft navigating, which is just re-rendering. What does that look like in practice? Let's take a look. We'll build and run the server. Let's go back to slash question here. Question. Perfect. And of course, the questions appear. We're scrolling. It looks good. Which one should we... What did the left eye say to the right? Let's click on this. And what you'll notice is we don't lose the movement. It doesn't reset. It just appears. We navigated to another page, but we're still here. Why do developers like Dark mode... And so, what you're seeing is we're actually navigating. But it's one fluid experience. Just to make the point more clear what's happening, we're not going to a new page. But if we look at the network tab. Let's take a look at what's happening. We're hijacking the link click. And we're fetching this, which is just a big React tree. Props, children, props, children. It's HTML, it's head, and it's a bunch of components. And then we're passing that tree to client side React, and we're saying, hey, re-render this. And we can do that because the server gives us this tree, and the client picks it up, and it's React all the way down. This is the power of server components. And this is why we need frameworks. Because it's a pain to wire it up. It's bug prone. And there's really much better approaches this way. I think one more point, by the way, is that... as well on X that if you don't use a framework, you'll probably implement one yourself without knowing it, and it'll have full of edge cases. So ideally, you just use the work that exists. So let's wrap up. Let's revisit the question, does everybody need to use a framework? I think we just saw a tiny glimpse of hacked-together functionality that benefits most applications.

Right? You get server-side rendering out of the box. And it's done better than I could here. You get data fetching that fetches at the right time, which is as early as possible at the server-router level. You don't fetch like a news effect. And because of that, you send useful markup to your users and your applications are more fluid. You get soft navigation, for example. All of this is handled for you. So does everybody, though, need to use a framework? And you know, I think, really, I am not qualified to answer this question. It does, I feel, depend on your use case. Because I know a bunch of people, Kiel. He uses just a client-side Vite application, and it works for them. So I don't know, but I hope in our time together, I've shown you the value of a framework and why you should be using one.

To summarize, we looked at server rendering, data fetching, server components. This is part of a much longer conversation. And I do have a YouTube channel that if you want to see the full, this is like a 45 minute thing. That's the full version. Also, I'm writing a book on React where we go into details like this. And if you're interested, I would recommend checking that out. I'm not here to sell you anything. I swear to god, if you don't buy this, I don't care. But if you're interested in the details, feel free. And finally, I really appreciate Kiel that made this presentation possible. The people are here if you would raise your hand. If you have questions about instant backends, those are your folks. Yeah. Like, it's about local. You know, we're in London. It's a London-based delta startup. I like local. Anyway, with that, I want to say thank you so much for your time and attention. It's been an absolute pleasure to be here. React Advance London. Thank you.

And we have a couple of questions for you. Is this actually a podcast? I think it should be now. Should it show us the noise if this should be an actual podcast? No, it's not interesting. It's not getting off the ground. All right. Let us go into the first question. Now, the thing I do like about the fact that we get these upvotes is there's always a spicy question. Careful. There's always a spicy question in there. So excited there. And we have a question. So you said, like, we should use frameworks. A lot of times smart people are making things so much easier so we don't need to think about all of these edge cases. And the first question is, what's your opinion about Angular? That's a framework, too. First of all, why? There's a name. Denis Kruknit. Dude, you choose violence today, man. Like, why? My opinion about Angular is it's great. It's a Swiss army knife. It gives you a number of things. And honestly for large enterprise applications, I've seen it be extremely successful. That's not to say React has no place. People are, now go on social media, tell everyone I said React is not good for enterprise. This is what you'll do, right? Do I seem cynical? No, but I do say Angular is fantastic. I think it's really good. I think for the vast majority of small to medium applications it gives you a lot of power, maybe too much. So it just depends. It always depends. It depends, I have an it depends counter going on in my head. What did you expect? I think I'm on like a five or six when it comes to Q&A, it depends. But, fair enough. Did Dennis expect me to say Angular sucks and React is the one true gospel? Was that?

I will come back to the question about the joke, don't worry. I won't forget. But for now, let's talk about some tech questions and we'll get back to the jokes at the end.

So would RSC ever be possible without a node.js server? Many companies already have backends in different languages. This is a great question. I just had the privilege of being at React Alicante, a tremendous conference with Daniel Alfonso, with Mateusz, a bunch of people. We're like a family or a traveling circus, depending on how you see the speakers here. But there's a lot of work being done in ReasonML, OCaml, even Rust to add support for server-side rendering in different languages. So no, absolutely not. You don't need a node.js server. Node.js is a runtime, not even a language, so you could do a bun server if you want. Sure. Fundamentally, it's taking a tree and turning it into another tree. You can do that in any programming language. Sorry. I may have oversimplified that for the React folks here. It is very complex. But, yeah. No, I totally get that.

No, I totally get that. Okay, we've got another question as well, which is about frameworks. Have you ever encountered any situation where no framework is actually better? Oh, that's a good question. I'd say proofs of concept before I even know. I've had the privilege of buying many domains and building exactly one side project that mapped to all the domains. And sometimes I just don't know what I'm building, like what the complexity's going to be ahead of time. So then, yes. I guess that's the only situation that comes to mind where I don't know yet if I want the opinions a framework gives me because I don't know yet the structure of my application. So only early stages. So if the question is, have I encountered a situation where no framework would be better in large-scale production applications, the answer is no. Especially... Sorry, I could talk for too long. If there's a team involved, definitely no. I've seen this go very... Because like teams, a lot of people think if I hire like five more engineers, we're going to be 5x more productive. It's the opposite, right? If you hire five more engineers, you're probably going to be a fifth of your productivity. And if you have no framework, and you haven't solved routing or data fetching, gosh! This is going to be like discussions on discussions, which is going to inhibit your ability to ship. Yeah. In the chef, in the kitchens, when you have a really big kitchen, they all do small parts of a meal. They don't work around a plate at the same time. Someone is just like, I work on the meat. Someone's just like, I do the veg. Etc. Etc. So, I totally get that.

All right. We'll do one more question and then we'll go through the jokes. Is that fair? Fair? Okay.

All right. So, this one's actually about Kiel. And maybe, if you don't know the answer, the Kiel folks in the front can maybe shout it out as well. Does Kiel support dynamic schemes that can be updated on the fly? Maybe someone wants to check it out. Yeah. Kiel.so.

I don't know the answer. But what I do know is... It's been largely stealth, so I don't think anyone knows the answer. But also... I do know that they are very... They're iterating really fast. And they told me... I have this on good authority that... If you need a backend for an application and you don't yet have anything and you're choosing, like, SuperBase, Firebase, whatever, they will build you your backend. For free. And so, if you need that... I don't know. Talk to them. They'll find that for you. Go check it out. Was the answer yes, no, or it depends? It depends. It depends.

Another one. Another one. Definitely. Okay. So, now, there are a bunch of other technical questions. But you can come and catch Tejas at the end, after we do the closing ceremony. But I think what you really want to hear are the jokes. You want to hear some jokes? Yes. Okay. All right. Here's what we'll do. We'll go get your laptop, if you just open it back up. And let's see if we can read some of the jokes. Let's put it on the screen. Should we put it on the screen real quick? And while we're doing this, the MCs are just... The rest of the MCs are gonna come over to the side, and we're gonna get ready to close this up. I'm throwing the tech team a random one. All right. Let's see what the last of the jokes were. Should I read the jokes in a British accent or will that be disrespectful? Do it! Do it! All right! Let's do it, then! You're right. Would you like a cup of tea? Is that offensive? I swear I'm not trying to be offensive. All right.

Would you like a cup of tea? Is that offensive? I swear I'm not trying to be offensive. All right. Let's go from... This! The third one I actually read the answer. It wasn't as bad as this. What is brown and sticky? Let's find out, shall we? A stick? Oh, of course! Where was your mind going? Oh, gosh.

All right, what's the next one? Why... It's gone. Oh, it's gone. It'll be back. It'll be... All right, I know someone asked in the chat about... Why was seven afraid of... Wait, why was six afraid of seven? I actually do know that one. It's because seven, eight, nine. Okay, quick, quick. The jokes are back. Last one. You pick one at random. Okay, let's see. What are a web developer's favorite treat? Oh, gosh. I'm scared. Cookies! They leave them all over the browser. It's fantastic. Give it up. I'm really proud.