FastUI - panacea or pipe dream?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 131 | |
| Author | ||
| Contributors | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/69442 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Ordinary differential equationObject-relational mappingCodeWeb applicationState observerComputer animationLecture/ConferenceSource code
00:25
Point (geometry)Computing platformProcess (computing)BuildingGoodness of fitSoftware developerView (database)Web 2.0Source code
00:48
View (database)WindowEmailEvent horizonInformationAddress spaceData managementAuthorizationHand fanOperations support systemGodIntrusion detection systemMaizeCompilation albumElectronic visual displayComponent-based software engineeringPascal's triangleDesign of experimentsBookmark (World Wide Web)Web applicationCartesian coordinate systemCodeProcess (computing)Endliche ModelltheorieWeb 2.0BitBuildingElectronic mailing listMereologyError messageAuthorizationMobile appMultiplication signMedical imagingInterface (computing)Open setGoodness of fitVariable (mathematics)SoftwareType theoryBridging (networking)Electric generatorDebuggerComplex (psychology)QuicksortServer (computing)Front and back endsWeb browserForm (programming)Table (information)Validity (statistics)NumberFrame problemPoint (geometry)Different (Kate Ryan album)Element (mathematics)Library (computing)Reflexive spaceGame controllerAttribute grammarWeb pageEmailWebsiteContinuum hypothesisFormal languageField (computer science)CASE <Informatik>Direction (geometry)Link (knot theory)RoutingSpectrum (functional analysis)Data managementRight angleView (database)Scripting languageoutputEvent horizonSynchronizationRange (statistics)Software repositoryStreaming mediaLecture/ConferenceComputer animation
08:45
Communications protocolIndependence (probability theory)Operations support systemVideo GenieCross-site scriptingInterface (computing)Slide ruleTable (information)Mobile appFunctional (mathematics)Cartesian coordinate systemType theoryObject (grammar)Right angleWeb serviceTouchscreenNormal (geometry)Front and back endsBitUtility softwareEndliche ModelltheorieLogicInternetworkingDebuggerFormal languageProjective planeTheoryDemo (music)Link (knot theory)Form (programming)CASE <Informatik>Tangible user interfaceWeb browserPoint (geometry)Design by contractMultiplication signWeb pageElectronic mailing listConnectivity (graph theory)NumberBuildingSoftware frameworkInformationArtistic renderingCommunications protocolUniform resource locatorException handlingUser interfaceView (database)Default (computer science)CodeFeedbackVolumenvisualisierungStandard deviationService (economics)Element (mathematics)Revision controlKey (cryptography)RoutingWeb 2.0Computer animation
16:34
Design of experimentsComputer-generated imageryGEDCOMTouchscreenType theoryComputer-assisted translationServer (computing)Medical imagingGodMultilaterationComputer animationLecture/Conference
17:27
WebsiteReceiver operating characteristicComputer-generated imageryAbstract syntax treeTimestampElectronic mailing listWeb pageData Encryption StandardComputer-assisted translationCodeView (database)1 (number)Type theoryBitComputer iconMedical imagingCartesian coordinate systemFlow separationLogicElectronic mailing listDefault (computer science)Scripting languageSystem administratorMoment (mathematics)Proper mapComputer animation
19:13
Web pageLink (knot theory)Design of experimentsKeyboard shortcutDivisorWindowComputer fileDemo (music)Euclidean vectorComputer-generated imageryTimestampRouter (computing)Coma BerenicesEvent horizonCodeCartesian coordinate systemCombinational logicAsynchronous Transfer ModeForm (programming)Link (knot theory)Normal (geometry)Electric generatorCASE <Informatik>Web browserStandard deviationRouter (computing)Medical imagingTotal S.A.View (database)Web pageField (computer science)Home pagePower (physics)Endliche ModelltheorieoutputError messageTable (information)Connectivity (graph theory)Demo (music)DatabaseEvent horizonSummierbarkeitElectronic mailing listTouchscreenMobile appComplex (psychology)Electronic visual displaySubject indexingData conversionLecture/ConferenceSource codeComputer animation
23:00
Revision controlSoftware developerMultiplication signProjective planePlanningPresentation of a groupWebsiteLecture/Conference
23:38
ExistenceCodeOpen source1 (number)System administratorEndliche ModelltheorieProjective planeInterface (computing)BitRight angleLecture/Conference
24:30
Ant colony optimization algorithmsVolumenvisualisierungPoint (geometry)Mobile appSoftware frameworkEndliche ModelltheorieSet (mathematics)Connectivity (graph theory)Level (video gaming)Default (computer science)Functional (mathematics)Lecture/Conference
25:29
Connectivity (graph theory)Multiplication signRight angleType theoryMathematicsFormal languageScripting languageChannel capacitySlide ruleBitReal numberoutputQuicksortUnit testingFront and back endsLetterpress printingInterface (computing)Client (computing)LogicSoftware testingInstance (computer science)Real-time operating systemDebuggerLecture/Conference
27:38
Point (geometry)HierarchySet (mathematics)Software testingUnit testingWritingUser interfaceConnectivity (graph theory)DebuggerTheoryInterface (computing)Multiplication signServer (computing)LogicGoodness of fitProjective planeExecution unitRight angleFront and back endsGraphical user interfaceLecture/Conference
28:34
Optical character recognitionMaizeScripting languageLevel (video gaming)Multiplication signConnectivity (graph theory)Web browserLecture/Conference
29:13
Multiplication signLecture/ConferenceComputer animation
Transcript: English(auto-generated)
00:04
I'm going to talk about fast UI but also generally about rendering web applications in Python or code that starts in Python. So who am I? I'm Samuel. Years ago, I created Pydantic. That's now a company, and we're currently working on Pydantic Logfire.
00:24
Anyone who's interested in what we're building, Pydantic Logfire is an observability platform. Anyone who's interested, please come along at 3.30 where I'm talking about that in more detail. Now, I want to start with what I think is a, well, controversial point of view, which is
00:41
that we've done a terrible job as software developers of providing a good way of building web applications. What we want to do is to de-duplicate, to avoid people having to repeat work that someone else has already done. And in many places, we've done a really good job of that. In Python, I think we do a really good job of that.
01:01
But when it comes to building common bits of web applications, we do a terrible job. So here are some examples. This is, I don't know what it says, but it's part of the Prague City website for registering for a parking permit. This is an example from the Montana government of paying local taxes.
01:22
This is an example from a big company, from Eventbrite, of registering to join an event. This is an example from the UK government of getting a driving license. This is an example from IBM of registering for an IBM ID, whatever the hell that is.
01:41
Now, what do they all have in common? They're all basically the same thing. They're all a form. They're all fundamentally defined by something like this. And I've used a pydantic model here because I'm pydantic, but like you could think about other ways of defining this schema in other languages or even other ways in Python. But really, all those forms come down to a definition of what the fields are
02:03
and what the requirements are. And yet, I bet you every single one of those things has been written out manually. And if I take the one example of the code for the IBM ID form, this is the actual code. It is, I have managed to compress it somewhat, and I've got rid of some of the extraneous stuff.
02:25
This is the actual code for that form. And from the way it looks, I would say someone manually wrote it. So, I think we have done a terrible job as an industry of providing, of deduplicating the work of building these forms. And it's not just forms.
02:41
It's tables where everyone is going through and defining them in different ways. It's list views, which are, you know, similar to tables. You can think of the GitHub list view, GitHub issue list. You can think of column layouts, item details, modals, like, navigation, even stuff like auth and session management, sure.
03:00
Applications like Django do a reasonable job of taking care of some of that, but they're not perfect. Even text, right? Like, we've sort of unified around markdown, but there is still an enormous amount of complexity about how do you render that. If you try and put user variables into markdown, it doesn't work, so you end up going back to HTML. We have no good ways, basically, of building these applications in a way that deduplicates the work.
03:24
And lots of you will be saying, but React to the rescue. Sadly not. This is roughly the world we live in when we go and build something with React. I spent a very long time trying to get OpenAI to generate this image for me. It's not quite right, but you get the idea that we have these two sophisticated motorway networks
03:43
in TypeScript and in Python, and yet they're joined by a rope bridge. In general, we define our type in Python, and then someone else, or maybe the same person, goes and defines our interface in TypeScript, and we basically, fingers crossed, that they're unified. Yeah, there are some ways to go and generate interfaces from open API schema,
04:05
but it's far from trivial to do. Even doing that work is often more work than building the form, and that is generally repeated on every app people go and build. And so my conceit, effectively, is we have done a terrible job of unifying, building these things, and deduplicating,
04:21
to the point where even within one app, we have stuff duplicated. We end up having a typed interface and a pynantic model defining the same thing, both written out, both requiring work to be kept in sync, both causing errors when they're deployed, even if you do it right. Even if you do it right, you set up the two models correctly, you deploy your whole application from a monorepo,
04:41
one of those two things is going to deploy first, and for a little bit, your app is broken. So there's already a landscape of different Python packages which try to go and solve that. And they all kind of sit on this continuum from the most abstract through to the most, giving you the most control.
05:00
I just heard this morning about LTK, which is another one, which is a kind of special case because it is written, or you write the code in Python, but it runs entirely in the browser using MicroPython and PyScript. But yeah, we have, I guess, Streamlit, it's probably the best known of these, because it was acquired by, they're a company, and they were acquired by Snowflake a few years ago.
05:22
Then we have, at the other end of the spectrum, we have, for example, Dominate, which doesn't have that many stars, has been around for 15 years, effectively allows you to define your DOM directly. Then there's a bunch of libraries in between, including FastUI, which I built.
05:43
Worth noticing, Reflex on there as well, also a company, enormous amount of hype around them, 18,000 stars, virtually no downloads. But again, based like FastUI, using React on the front end and Python in the back end, doing it slightly differently.
06:01
To kind of make that concrete, how they work, if we look at Dominate for an example of how the fine-grain control apps work, you can see in this code, where it's obviously Python code, but we're literally defining item by item, every element in the DOM. So we're allowed to define style sheets,
06:22
we can define headers for the page, and then we can go and insert links, and we can define attributes on the body and we can set text. We're literally writing out HTML, but using Python. I think this is quite neat, I can see the uses for it, it's often not what you want. One of the problems with this and almost all of these tools,
06:43
and one of the reasons I went and built FastUI is that to use this, you have to abandon, effectively, all of the front end technology. You can't integrate this with React. Sure, I suppose you could load a JavaScript library somewhere in here, but you're kind of on your own if you take this route, you can't leverage everything else that's going on. At the other end of the spectrum,
07:02
in the most, I guess the most abstract, we have Streamlit in this example, so sure, we can define title in a relatively similar way, but from there on, we're doing stuff that's much more abstract compared to writing the HTML. We're telling Streamlit, give me a number input, do the validation that it's in this range,
07:22
I think that will give you an up-down clicker that will let you choose the number in that range, we can write out content, it will take care, I guess, of rendering the markdown, of making the page somewhat pretty, you can do more complex things like defining a data frame and loading that directly, you lose the control, you wouldn't ever be able to use Streamlit
07:41
to build a kind of end-user application, but in exchange, you get a lot of stuff that's really easy if you're a data scientist trying to get something built quickly. So that's where I came and built FastUI, and again, as you can imagine, I had fun trying to get OpenAI to generate an image, but the idea of this is that instead of having to duplicate
08:03
all of our definition of schema, we have effectively schema defined in one place in Python that can then go and be used in the frontend. So we have effectively, let me go, I've gone the wrong way,
08:20
I've gone the wrong way, I'll try and get back, that's what I'm trying to say. So the idea is we have one unified motorway network where we have typing that is consistent across the frontend and the server where we define types once, and they can be reused in the browser.
08:42
And so here's a really brief example of using FastUI to kind of make things a bit more concrete. So here we have a normal FastAPI app. Again, one of the things I found very problematic about lots of the other apps for building these UIs was that they required you to go all in with them. They didn't allow you to extend an existing application.
09:03
They effectively said you use Streamlit or you use Reflex, and that's it. That app, that service has to be entirely built around that piece of technology, whereas FastUI is a normal FastAPI app that we effectively can define some endpoints on to do stuff with FastUI. So we have a normal FastAPI app.
09:21
We define a standard pydantic model, some data for it, and then we define a standard FastAPI view. Here, a route to API slash users. Very frustratingly, slides.com thinks that decorators are comments and so mutes them, but there's a decorator there which defines our endpoint.
09:41
And then we have effectively what we're returning here is a number of pydantic models that define the view that we're trying to show. So on the outside, we have a page which effectively sets you up the basics of a page, and then that contains components. Those components are heading, and then a table,
10:01
and that table contains data from the users that we defined above, and we do some more work to define exactly how we want to show the columns. And then most importantly of all, we define this path, which is the path colon path. It's saying collect all remaining paths and render the pre-built HTML.
10:21
So that is one way of using FastUI, where we have pre-built the React app that's going to go and render our table list in this case, and we're just returning that from all views, all URLs, obviously all URLs except slash API slash users in this case. And the way that FastUI works, it will basically,
10:42
for any URL where the pre-built HTML is rendered, it will go to, it will prepend API onto that path and go and try to get data from that API endpoint to render. And so what's beautiful, well, what I think is good about FastUI is that the fundamental contract
11:04
between the front end and the back end is just some JSON with a predefined type, all defined via pydantic models, which then are replicated into TypeScript interfaces as I'll show you. So that page we've just seen, this is the complete definition of it. We have this first object.
11:21
All objects have the key type, which defines effectively what the type is. It contains components, and here we have a heading, which has some text. We say it's level two because we want to define an H2. Then we have a table. That table contains some data, which is effectively arbitrary. It's from the pydantic model, and then we have some definition
11:40
of how we want to render the columns. So, yeah, we have the type on everything, and then we have, yeah, a type on table. Why is that? Have I gone the right way? Sorry.
12:00
And then we have the TypeScript interfaces as defined for that example, so effectively when we're building FastUI, we go and define interfaces for all of the different types that we've designed in Python. They're automatically generated. And so, yeah, we have types for things like page and heading and table.
12:27
I think I left all of the fragments on from the previous slide when I copied that slide across. And so what's great about FastUI is that in the end, to go and customize how it's rendered, all we have to do is implement one function
12:41
where we define custom ways of rendering each of those components, and because each of those components has this type key that tells you what type of thing you're rendering, it's very easy to decide how you're going to go about rendering each element. And, of course, FastUI provides a default for all of those things that will mostly just work for you so that you don't have to go and implement everything,
13:01
and then we have the pre-built version where we have implemented absolutely everything and given you some default styles. But the idea behind FastUI, and I'll be the first to say that hasn't happened yet, is that effectively it is a framework on which to go and build end-user applications where you can define your own React front-end
13:22
or whatever you want using this effectively contract between the browser and the application code. So the principle is, as I said, to have good defaults but also to be independent of React. So one of the bits of feedback I've had quite a number of times
13:42
about FastUI is, ah, but the front-end is React and we want to use HTMX, fine. In theory, as I've described, what really defines FastUI is this contract between the thing that does the rendering and the thing that implements the UI you want to, or returns information about the UI that you want to show.
14:02
And so it can also be independent of the front-end framework. It can even be independent of Python. It would be kind of trivial to go and implement, I don't know, a Rust web service that returns that same JSON definition to render the UI. And it can even be independent in theory of the browser. So in principle, we could go and build, for example, a TUI app
14:23
that basically consumes that same definition of how I'm going to render a UI, and it could be fitted into any Python application or even the Rust application. As long as they use that same definition in the middle of how to define what a UI is, we've separated the two things in a way that, I guess,
14:42
in theory, HTML does the same thing, right? In theory, HTML says we don't care what language we're going to use to build a web service, we're going to use a unified protocol for rendering a UI. The problem is that that is quite low level, and so we get back to the situation I showed at the beginning where everyone has had to implement their own way of then going and using HTML to build forms or whatever else.
15:04
So the idea is like a single declarative protocol for defining UI. I'll be the first to say that hasn't happened yet with FastUI. I started the project at the beginning of the year, and I've been busy with other things. I hope to put some more work into it.
15:22
But the point is that might never happen with FastUI. I accept that, but what I really want to do is to persuade someone out there to go and build that thing. I don't even care if it's based on FastUI. I don't care entirely how it's done. I just think that there should be a better way of building all of the utility internet
15:40
that exists out there that is currently done in a thousand different ways and often very broken and where we should have one beautiful way of rendering that UI and then arbitrary logic to effectively... Yeah, effectively you can define the backend very easily in any language you like. So we've got ages left because I've been reasonably quick.
16:01
I've got an example of FastUI that I can walk through that I was actually building for my talk later on Logfire, or we can take questions. I guess given the time, I'll start with giving a demo of FastUI, and then I'll take questions. Unless there's any questions right now that kind of link to what I've just said.
16:23
I've confused everyone by saying I'm going to do two different things. I'll do a demo. So I don't know how to do a demo because I'm on two screens, and I need to get onto one screen. How do I unify the screens? I should probably have checked how to do that before we started,
16:41
but I'll try and do it over my shoulder on this. This is harder than you might think. This is a very simple UI built with FastUI. What I think is impressive about FastUI
17:02
is I built this this morning in an hour when I suddenly realized I had to give this talk to Logfire later. I could not have gone and built this UI I think with any other tool that was as flexible but also as quick to implement. So the idea here is this is called CatBacon, and the idea is it will generate an image in the style of Francis Bacon of any animal you like. So I can come in here and I can type cat, for example,
17:25
and the server's not running, so I need to get the server running. Oh, God, just a minute. There we are. And then if I come over here and I type in cat
17:42
and we get the loading icon, well, OpenAI goes off and generates the image, and in a minute, with a bit of luck, we'll get an image of a cat. And there we have an image of a cat in the style of Francis Bacon. Now, we can also go and look at the previous images that I have generated.
18:02
So there's a bunch here of ones I tried before. This was a horse that isn't loading anymore because the image is expired. But we have this list view is defined entirely via fast UI, and I'll show you the code in a minute, and we have nice things like pagination. Now, if I had gone and set up an example in an hour
18:21
of how to use Logfire, I would not have been able to have nice things like pagination on the view or a nice UI like this that takes care of the loading icon when I run the script. All of this is just given to me by fast UI because we've gone and implemented decent defaults. At the moment, fast UI realistically
18:41
is mostly for internal admin applications. I can't pretend that the UI is pretty enough that you would go and use it for an end-user application, but I think it is entirely possible that someone... It is entirely possible to build that thing, whether that is continuing to extend fast UI or whether I can just inspire someone to go and build something like this
19:00
where we separate UI and application logic properly. I strongly believe it's possible. So I will try and do my having stuff on one screen and show you the code for that because I think it's probably helpful to look at what this application actually looks like.
19:21
That code is probably way too small for everyone, isn't it? It's way too small for me for a start. Oh, what's the combination? Anyone know the combination to it?
19:51
I literally can barely read it on that screen. Oh, oh. Ah, is that better?
20:02
Okay. I don't know what that is, and I definitely don't want it. So this is the body of the fast UI app. Again, this is just a perfectly normal fast API application, so we're just defining a router with API router, and then we have up here in the... That's completely the wrong code.
20:23
Here we've defined effectively that we're going to load this main router that I was just showing you at the API prefix. So we have an animal model, and so this is effectively the index page or the API that powers the index page, and we define a heading saying generate image.
20:41
We have a paragraph which in this case is just text but could be marked down, and then we define a model form. We give it the pedantic model to define the fields of the form. We give it display mode, the URL it should submit to, and we say we're going to load a spinner saying generate images while it's loading. And then we have an endpoint. This is, again, perfectly normal fast API endpoint.
21:03
In this case, post endpoint. We do something slightly funny with annotated to define how to load that form, and that's basically telling fast API to load that from an HTML form so we don't have to bother with any fancy stuff in the browser
21:20
to convert form data into JSON. We're just getting standard form data and encoding it into a model. This will also take care of if you try and submit the form and it's invalid, it will take care of returning a definition of the error to the browser which the browser will then take care of or the React app will then take care of re-rendering. So all of that complexity of how do I render errors
21:41
when someone inputs the wrong data is done by fast UI for you. And then we go off, get a database connection and create the image, and we return a component called fire event, which in turn has an event which says go to the image, and then this is our list, our table of images,
22:02
which I can talk about if anyone has questions, but then more importantly, here we have the actual image view that we've just been redirected to. So again, we get a database connection, and we go off and we get our image, and then we define effectively our page. In this case, we have a link, which is the back button that I...
22:22
So we have the back button up here, then we have some details on the particular image, and then we decide to show an image. So yeah, and you can see the items exactly match that. So we have the link, then we have details, which defines the pedantic model that we want to render, what exact fields we want, and then the image to show,
22:40
and then we have a title for the page. So yeah, that's FastUI. That's I think the sum total of what I have on the demo. Thank you very much, and yeah, if you've got any questions, I can take them now.
23:01
Thank you very much for your excellent presentation. We have time for some questions. I see someone at the mic. Please ask your question. Yeah, so recently I got into a situation that I was looking for something like FastUI, and I was trying that, but in the end I finished with using NiceGUI because it had something which I needed.
23:22
And my question is how much you are dedicated to invest your time into FastUI, or is this only the site project to prove something? Yeah, what are your plans for further development? If someone comes along and builds a better version of it with the model that I think makes sense,
23:40
I would happily give it up, or say it's better to go and use that project. I have enough other bits of code to maintain, but right now that doesn't exist. We're using FastUI internally within Pynantic to build our admin interfaces. The team, I think, were generally skeptical. They were like, oh, Samuel's gone off and done another side project. And actually, Hassan was saying to me this morning,
24:01
he was like, oh, I have to use this thing Samuel built, and then actually used it and was like, oh, yeah, it actually is a really easy way of building that kind of interface. So I think, which is my assumption, that no one's going to come and build this soon. We will continue to work on it. We just have lots of open source that we have to maintain and commercial, so it's not the top priority, but we will put more work into it.
24:20
Okay, thanks. But also, if you know exactly what the thing you need is, come and talk to me afterwards, and we'll try and get it done. All right, thank you very much. Next question. Hi. I think you probably already mentioned it, but with this FastUI, is it possible that, for example, I can use the components that are defined in material UI
24:42
or any other React framework that already exists, can I just pick those up and then reuse them here? I wouldn't say it's just pick them up and use them, because you have to basically, when you define your own React app that uses FastUI,
25:01
you effectively have to implement this function, which basically says, return me a custom component for a given set of props, which is effectively those models I defined, or return null and we'll render you the default one. So you would have to go and implement your own component, because you would have to implement something that takes heading, for example, which takes text and level and renders it,
25:22
but the whole point is not to effectively abandon all of the existing technology that exists, instead to build a way to leverage all of what exists in React. So, for example, we have a markdown component that renders markdown. We haven't had to go and do much work to render markdown, and we just use the React markdown package to do that for us.
25:43
Okay, thanks. All right. Yes, we have time for a few more questions. Please go ahead. Hi, I've actually got two questions. The first one concerning maybe even this slide right here. So how would I go about implementing custom client-side logic?
26:02
I mean, if I want to, for instance, React to user input right away, provide suggestions when the user is searching for something in real time, how exactly would I do that? I suppose I would still create a React component
26:21
and then connect to some backend, and then I'm basically to square one when it comes to matching TypeScript types in the frontend. Yeah, so one of the things that's hardest to do in FastUI that basically required some changes in Pydantic
26:41
to make the schema more general was basically that we have whatever it is, like 20 different components we've defined, and there's effectively a custom, which is kind of you're on your own with your own data and there's no typing. That was one of the things that my team was like, this is bullshit, that needs to be fixed. Excuse my language. So we have actually, it's now implemented in Pydantic.
27:00
We need to go and implement it in FastUI. We provide the capacity to effectively define your own components. Then we have a script that effectively FastUI generates, which will generate you the TypeScript interfaces, and then you can get full typing end-to-end with custom types. I think there's a bit of work to be done, but the principle is there, if that sort of answers your question.
27:22
Yes, thank you. As for my second question, I wanted to ask, what is the story regarding unit testing your interface? So one of the great things about FastUI is, because it's just returning JSON, it's pretty easy to then go and write a unit test that basically decodes the JSON and checks it is as it is, is as it should be. Whereas if you're returning HTML,
27:41
it's much harder traditionally to write full unit tests that like snapshot without being, without enormous churn, so effectively. Right. Maybe I should clarify. So I'm talking about unit testing your user interface, which is very common in front-end projects where you take a set of React components,
28:01
like a whole component hierarchy, and write tests. Right. So the theory is that because you've separated the two and you just have the definition of your interface, you can go and implement your own data for that interface and write the unit tests in the front-end that you want to do, because it is separated from the logic of making requests to the server, if that makes sense.
28:20
I can talk to you afterwards. Yeah, sure. Sounds good. Okay, we have time for a final question. I'm wondering if this first UI would be a good starting point if you want to build a GUI builder for PyScript.
28:41
I mean, I think the question is like what is the thing that you want to build at the highest level, and what's the UI you want? PyScript is one of the components you could use to do some of that, but I think there's nothing to stop you from using FastUI in TypeScript to generate this data, so the whole thing runs in the browser.
29:01
That would be entirely possible. Whether that's a good idea is a whole other debate. Okay, thanks. Well, thank you very much. I have a small present for you. Thank you very much. Please give it up one more time for Samuel.