promise.then(...), by Rich Harris

I hope no one is expecting a a polished presentation, much less a rehearsed presentation, but I do have slides. Um, this is a photo from Barcelona. A couple of months ago, we had um our second inerson conference um in Barcelona and this is me giving a talk about uh a sing uh await in spelt and um the talk was called what spelt promises. Um this was a really great time. Um Barcelona is a terrific city. Uh had

a lovely time like hanging out with everyone from the community, but also the spelt team got together for an in-person co-working session for the first time ever. Um, and some of the stuff that came out of that session is the stuff that I'm going to be talking about tonight. Um, turns out actually being in a room with the people that you work with and having a whiteboard to scribble on, uh, really makes a huge difference in what you're able to achieve. Uh so if you've been paying close attention to the spelt repo, you might know that we merged a very big pull request this week. Uh we actually had

666 commits when I asked for feedback, but we thought maybe that would be bad luck. So we added a few more. Um this is uh one of the most fundamental shifts in what spelt is is capable of. Uh we even have documentation. go over here and if you do the command K thing and search for await, it'll take you right to this page. Um, this allows you to use promises directly inside your components.

Um, and so now that that uh that promise has been fulfilled, uh, let's talk about what's next. Um, first just to recap because you might not be familiar with this work. The reason that we're doing this is like web apps are these fundamentally distributed systems. Um, you have people using the software on their own devices which you

don't control and they're communicating with your origin server which is communicating with the database which is probably on a different computer. Um, and then you have a CDN in between which is handling static assets and maybe you've got some edge middleware and and whatever. And I'm not telling you this because you don't know it. I'm just saying that this is the nature of building stuff on the web. You are dealing with asynchronicity all the time. Like it's completely fundamental to what we do. And yet components are

really bad at async. Component frameworks historically have just not been able to solve this problem in any meaningful way. Probably shouldn't be surprising like when components first came out when the mental model first started to to bed in uh it was around like 2014 2015 and back then promises weren't in the language. Async await certainly wasn't in the language and so the old formula uh UI equals function of state if you've seen that that function is a synchronous function and sorry a

synchronous function not an asynchronous function and so what people would do is you would have some local state indicating the value and the loading state and then an error state and when the state that the async state depended on you would make a fetch request and then if it failed, you would populate the error state, and if it didn't, you would populate the value, all of that stuff. And you would have these spinners all over the page, and it's just a terrible user experience, which is actually very common on the web because we still haven't really solved this problem.

And uh people thought maybe frameworks would save us. Uh next was probably the first example of a framework that tried to solve this with get serverside props. Um and the idea is that instead of doing the data stuff inside the component, you do the data in a loader and then you pass the data to the component. So um who here has used speltkit? A few. Okay. So you're probably familiar with the load function um which looks a little something like this. If I solve this example and hope that it's going to