Xilem Vector Graphics @ Rust Bay Area Meetup

WEBVTT

 

1

00:00:02.290 –> 00:00:08.280

US – Frog Field: And as always, if you have talk ideas, or would like to propose a venue.

 

2

00:00:08.490 –> 00:00:10.850

US – Frog Field: If you have a venue you’d like to provide.

 

3

00:00:10.910 –> 00:00:19.860

US – Frog Field: You can contact us@rustareaatgooglegroups.com. You can also contact me directly on Twitter and a bunch of other places with that handle niche earth

 

4

00:00:22.400 –> 00:00:28.990

US – Frog Field: as usual. Thank you to our host for making this possible. They’re providing food. There will be more food arriving, too.

 

5

00:00:29.100 –> 00:00:33.210

US – Frog Field: so don’t worry about that. But thank you, J. Frog.

 

6

00:00:33.350 –> 00:00:37.090

US – Frog Field: I’m. Going to hand it to them to give a short blurb, and then after that we’ll have our talk.

 

7

00:00:40.690 –> 00:00:47.060

US – Frog Field: hey? Thanks so much vanish. So my name is Steven Chen. I run the Developer Relations team

 

8

00:00:47.200 –> 00:01:04.849

US – Frog Field: at J. Frog, and we’re we’re really happy to have and be hosting the rest community here. So thank you all for coming out to attend the great session to network with each other and have good conversations, and we we care a lot about community.

 

9

00:01:05.220 –> 00:01:11.390

US – Frog Field: See? We care so much about community that. unlike the C. Meet up.

 

10

00:01:12.890 –> 00:01:14.010

US – Frog Field: Sorry, Max.

 

11

00:01:14.050 –> 00:01:21.020

US – Frog Field: We also host the C plus meet up here. They’re going to be here in 2 weeks, so that’s a great meet up as well. But you you guys got here

 

12

00:01:25.340 –> 00:01:39.090

US – Frog Field: all right, so so apparently we. We have to up our game because we’re not being fair to to different community groups. But we we’re really excited to host. The rest meet up here, and just a few words about J. Frog in case you don’t know about our company.

 

13

00:01:39.300 –> 00:01:43.170

US – Frog Field: So we’re a Devops Platform company.

 

14

00:01:43.310 –> 00:02:02.670

US – Frog Field: We built a package manager called art of factory, which is used by most large companies. So you probably already have artifactory in your company. If you don’t know about it, what you might not know is that we added rust and cargo support to art a factory. And now you can host your own private cargo registry.

 

15

00:02:02.670 –> 00:02:21.600

US – Frog Field: using the same package manager which you use for for go for Cn. C. Or Python, for Npm. etc. So that’s great. And then also at Rest Nation, where we also sponsored. Recently in the United Kingdom, we announced our new support for security.

 

16

00:02:21.810 –> 00:02:38.300

US – Frog Field: So you can do security scanning of your packages coming from Crates I/O. See if there’s any vulnerable crates which you might have, and our security research team is doing a lot of investigation. They found a big bug in the Https libraries which they reported and got fixed.

 

17

00:02:38.300 –> 00:02:46.390

US – Frog Field: They found other vulnerabilities, and creates that I/O which again we reported to them. They fixed before we just closed it. So we we want to help make rust

 

18

00:02:46.480 –> 00:03:01.760

US – Frog Field: the most secure ecosystem for developers. I was chatting with some folks right before this, and it’s kind of funny that now I I’ve done a whole bunch of languages in my career. I’m probably best known for Java coding Don’t hold me that against me.

 

19

00:03:02.280 –> 00:03:16.860

US – Frog Field: But I’m i’m finding a renewed interest in C, because my daughter is now taking her college courses, and she’s asking questions. and guess what they’re teaching kids now, and c. And C. Courses, which was not the case when when I was in college.

 

20

00:03:18.120 –> 00:03:21.420

US – Frog Field: Exactly so like

 

21

00:03:21.500 –> 00:03:25.260

US – Frog Field: half the curriculum they’re teaching college kids for C

 

22

00:03:25.290 –> 00:03:44.400

US – Frog Field: is how to do memory, safety, security, vulnerabilities, making sure that you’re not like, you know, leaving injection attacks, or being making your code accessible to cross thread exploits. And the this is something which is a huge area of concern for the whole tech industry.

 

23

00:03:44.430 –> 00:03:56.500

US – Frog Field: and I think, which rust solves very elegantly if you’re using the safe. Apis. So again very excited that you’re all here to to either learn about rest or to network with other folks who are using R.

 

24

00:03:56.510 –> 00:04:02.360

US – Frog Field: Or to learn about the great user interface apis, which Ra. Is going to talk about. And thank you very much.

 

25

00:04:02.390 –> 00:04:04.400

US – Frog Field: We’re coming tonight to the meet up.

 

26

00:04:04.430 –> 00:04:19.320

US – Frog Field: and one final word. You probably heard about this when you joined. But please take one of the T-shirts right so we want everyone to go on with the t-shirt, and if you’d like, enter the survey, and we’re going to be giving out a

 

27

00:04:22.560 –> 00:04:29.220

US – Frog Field: nintendo switched drawing which you can enter, so please enter that and then we’re going to announce the

 

28

00:04:29.600 –> 00:04:34.120

US – Frog Field: it’s for all all of our winners. So we’ll now it’s that via email alright.

 

29

00:04:41.680 –> 00:04:51.430

US – Frog Field: Okay. So some will go home with air pods pro pros, and you’re also can enter it to win us. Nintendo switch and Ari runs our meet up program. So thank you very much. Are you

 

30

00:04:57.570 –> 00:05:12.420

US – Frog Field: all right. Well, thank you so much, J. Frog: for hosting this video. I’m very happy to see everybody in the community here today. And so what i’m going to be talking about is xylum vector graphics.

 

31

00:05:12.590 –> 00:05:20.470

US – Frog Field: and this is very much what you’re seeing is very much unfinished work in progress. You’re not seeing a final project.

 

32

00:05:20.560 –> 00:05:26.860

US – Frog Field: a final product. But I think it’s I. It’s interesting. And so I wanna kinda take you along for the ride.

 

33

00:05:26.980 –> 00:05:34.520

US – Frog Field: So so here’s what i’m going to be talking about, you know, in the talk I’m going to start by really talking about the goals and scope because that’s not obvious.

 

34

00:05:34.560 –> 00:05:42.550

US – Frog Field: This question of, you know, if you’re if you’re trying to build a Ui, do you use Dom? Do you build it on Dom technology, or do you not put it on, Don.

 

35

00:05:42.790 –> 00:05:44.420

US – Frog Field: What are the trade offs there?

 

36

00:05:44.490 –> 00:05:53.070

US – Frog Field: And then kind of a picture of layered ui like, how do you factor you into layer so that you can really reason about those individual layers separately

 

37

00:05:53.190 –> 00:05:54.540

US – Frog Field: and kind of.

 

38

00:05:54.550 –> 00:06:03.330

US – Frog Field: you know this question, like there’s a lot of things out there that do declarative ui in different ways, and I’ve kind of divided those into 4 tribes.

 

39

00:06:03.330 –> 00:06:23.090

US – Frog Field: and so i’ll be talking about each one of those in a little bit more detail, and then going much more deeper into Xylum, which is the thing that I’ve been working on for a little while, and i’ll be giving a couple of Demos, you know, including both native and web projection of the same code, and rendering using the bellow to the Graphics Library.

 

40

00:06:23.210 –> 00:06:35.900

US – Frog Field: So this is. It’s a Science project, and there are hypotheses that I want to test. and then i’ll. I’ll close up with next steps and kind of a call to action, you know, really follow scientists.

 

41

00:06:36.160 –> 00:06:43.150

US – Frog Field: you know. Come, come along. So so this is an exploration. This is, basically

 

42

00:06:43.290 –> 00:06:58.910

US – Frog Field: you know, very speculative work. I am not sure it’s gonna result in a usable product at the end. But I want to learn. I want to find out what the parameters are. Is this gonna work? If it’s not gonna work. Why not?

 

43

00:06:59.250 –> 00:07:15.430

US – Frog Field: So the so the goals of this is, I want to be able to write an app in a very nice, clean, declarative syntax. I’ll be showing you some examples of the actual code i’m running. And then the other thing that’s a little bit new to the work that I’ve been doing is that I’ve really been

 

44

00:07:15.580 –> 00:07:33.100

US – Frog Field: wrestling with this question of how do you deploy an app both to a native executable, and in Wazam to run in the browser without compromising like it’s very easy to just run a demo of something. But you know, like, how do you do a good ui to both of those platforms.

 

45

00:07:33.100 –> 00:07:38.470

US – Frog Field: and in particular, how do you preserve the performance and performance? There’s a lot of factors to performance.

 

46

00:07:38.510 –> 00:07:49.990

US – Frog Field: and in order to make this science experiment tractable. I am specifically narrowing the scope that tonight I am only going to be talking about vector graphics. It’s a much reduced

 

47

00:07:50.000 –> 00:07:53.340

US – Frog Field: surface area of the kind of problems that you have to solve.

 

48

00:07:53.350 –> 00:07:58.370

US – Frog Field: and the hope is, if it works well for vector graphics.

 

49

00:07:58.640 –> 00:08:03.650

US – Frog Field: how do you generalize it? But i’m not going to be going too deep into that tonight. We’ll be talking about vector graphics.

 

50

00:08:04.670 –> 00:08:17.700

US – Frog Field: So this constraint of trying to do something that works both on web and non web really create some difficult technology choices, some difficult trade offs.

 

51

00:08:17.810 –> 00:08:22.160

US – Frog Field: And so, if you choose the not Dom approach.

 

52

00:08:22.210 –> 00:08:26.920

US – Frog Field: and you wanna to deploy those applications on the web.

 

53

00:08:27.060 –> 00:08:45.420

US – Frog Field: Then you get a lot of problems. So one of the problems is that you have a much larger wisdom bundle size, because If you’re not using the Dom, then all of the things that the Dom does, all of the drawing and text rendering which itself is a very large, complicated problem.

 

54

00:08:45.420 –> 00:08:55.990

US – Frog Field: Those need to be in the as a bundle, and then you’ll be drawing to some kind of canvas or some kind of Gpu surface, depending on exactly what your you know what your app is trying to do.

 

55

00:08:56.410 –> 00:09:00.180

US – Frog Field: So. even with the we as a bundle size, like

 

56

00:09:00.410 –> 00:09:15.940

US – Frog Field: doing text rendering, getting the text to look right is hard, especially if you’re drawing to like a gpu surface. If you’re using the HTML 5 canvas well, your texture and ring works. But now how do you interrupt that? With the rest of the app it’s there’s friction there, and there’s

 

57

00:09:15.940 –> 00:09:27.520

US – Frog Field: many different choices, and each one of those choices has has different trade offs. There’s no like one clearly good right way to to to get your stuff drawn. If you’re not using Dom.

 

58

00:09:27.570 –> 00:09:44.890

US – Frog Field: What one of the things that I think is actually a show stocker is that if you’re not using Dom, then you just can’t do accessibility. There’s various hacks, but a lot of them really are like. Make a Dom, that’s not visible. But if you’ve done that, then why not just do a real dom with your real app.

 

59

00:09:44.890 –> 00:09:49.660

US – Frog Field: and you know there’s many, many things that that try and project a Ui on the web

 

60

00:09:49.850 –> 00:10:06.320

US – Frog Field: without using the native. You know the dom that’s native to the web, and it just doesn’t feel right. The scrolling is always a little bit wrong. There are there’s thinking there’s proposals about like, Could we maybe fix the web platform so that you would get more

 

61

00:10:06.320 –> 00:10:14.440

US – Frog Field: direct, lower at lower level access and be able to solve these problems. So there’s a proposal really interesting thing here by Ian Hickson.

 

62

00:10:14.480 –> 00:10:16.690

US – Frog Field: but it’s not the reality today.

 

63

00:10:17.520 –> 00:10:30.420

US – Frog Field: Now the flip side is, if you want to do a native application. then one of your choices is that you ship a fragment of a You either ship a whole web browser, or you ship some fragment of a web browser.

 

64

00:10:30.840 –> 00:10:39.600

US – Frog Field: and that solves the problems on the web. But if you’re trying to ship something native, then you now have a whole other set of problems.

 

65

00:10:39.690 –> 00:10:44.260

US – Frog Field: So one of them is that the web dom api is slow.

 

66

00:10:44.680 –> 00:10:50.520

US – Frog Field: and I mean that’s slow. If you’re doing single threaded.

 

67

00:10:50.760 –> 00:11:02.340

US – Frog Field: you know it it. It it may be that there are things that their configurations in which the the Dom is not slow, but basically on the web Today it is slow.

 

68

00:11:02.550 –> 00:11:09.250

US – Frog Field: and all of the other stuff that’s downstream of the Dom is also slow. Css resolution. It’s very expensive, very heavy weight.

 

69

00:11:09.310 –> 00:11:29.230

US – Frog Field: Layout is very expensive, very heavy wave, and so you just don’t get good performance, you know, compared with what’s possible on native. And there’s another problem here which is that the web Dom Api itself essentially forces single threading. It was really built in a single threaded world. It wasn’t designed for multi threading.

 

70

00:11:29.230 –> 00:11:41.720

US – Frog Field: and like one specific consequence of that and rust is that there’s this type for the call back which you use to wire up your interactivity, and that type is is not sent. So if you put it in an arc.

 

71

00:11:41.730 –> 00:11:46.490

US – Frog Field: you’ll get a compile time. Error or not, you can put it in an art. But if you try, and actually.

 

72

00:11:46.560 –> 00:11:51.750

US – Frog Field: you know, move it across the Channel to a different thread. Then you’ll get a compile time error. It just won’t work.

 

73

00:11:52.180 –> 00:12:11.650

US – Frog Field: So then, you know. Then you have this problem of like, Well, what browser, do you? Shed do you bundle Cef? Which is, you know, the that’s chromium embedding framework, also an electron and Cf for kind of 2 2 aspects of the same thing. Large bundle size it. It’s popular, a lot of people do it. It works, it solves a lot of problems.

 

74

00:12:11.730 –> 00:12:26.610

US – Frog Field: And so there’s other possibilities like there’s Tari, which is more popular in the Rust world, and that uses the platform web view. But then there’s other challenges like you. Don’t know exactly what web you you’re gonna get it might. It belongs to the operating system. It might not be up to date.

 

75

00:12:26.610 –> 00:12:38.590

US – Frog Field: There may be some compatibility bugs, especially if you’re trying to use a more advanced features like you’re trying to use web. Gpu! What is the chance that the Platform Web view is gonna support that if you bundle Chrome you can use, you know.

 

76

00:12:38.800 –> 00:12:40.710

US – Frog Field: under the latest, and you get it.

 

77

00:12:41.660 –> 00:12:54.040

US – Frog Field: There are other choices that are out there like. There’s a really interesting thing in the C world called cider, which is really a sort of a mini implementation of a fragment of a browser, and it is popular in some domains.

 

78

00:12:54.040 –> 00:13:02.870

US – Frog Field: but it is missing some functionality, and it’s not plug-in compatible. You don’t get exactly the same experience with cider as a on a real web browser.

 

79

00:13:03.000 –> 00:13:16.960

US – Frog Field: And then in the rust world there’s 2 projects that are worth looking at, I think, when Turbo was happening, you know, in the early days of Russ. A lot of people were excited about like, oh, there’s all this Ui technology, and it’ll do all of the fonts and text layout, and.

 

80

00:13:16.970 –> 00:13:26.880

US – Frog Field: you know. Draw gpu drawing, gpu, accelerated drawing and stuff like that. Let’s let’s make that happen, and then let’s bundle that, or have that as a layer that underlies our applications.

 

81

00:13:27.070 –> 00:13:39.160

US – Frog Field: and the progress on survey has been slow. It’s it’s rebooting. It might yet develop into something that we can use, and there’s a new thing called Blitz and I’m going to be talking about that, and that is an interesting possibility.

 

82

00:13:39.240 –> 00:13:42.240

US – Frog Field: But it is fundamentally in the same category

 

83

00:13:42.350 –> 00:13:50.980

US – Frog Field: of implementing a fragment of a browser. So the Api is Dom HTML nodes, css, etc.

 

84

00:13:52.260 –> 00:14:06.490

US – Frog Field: So I want to give you this kind of picture of layered ui. and this is not the only way to build you. I in particular, this picture is not accurate to immediate mode. Immediate mode kind of

 

85

00:14:06.620 –> 00:14:19.260

US – Frog Field: is the opposite of layered. It’s. It’s using all the different, you know, reactivity and drawing and element. And you know all the way down to the infrastructure all the way down to the Gpu. I mean, you’re basically filling in vertex buffers

 

86

00:14:19.300 –> 00:14:22.100

US – Frog Field: with the with the logic of your app.

 

87

00:14:22.760 –> 00:14:27.430

US – Frog Field: like, I think increasingly, with the exception of

 

88

00:14:27.520 –> 00:14:40.160

US – Frog Field: immediate mode that the rust ui ecosystem is moving towards this this layered model, and there’s even some commonality that’s happening. I I have a slide a couple of slides where i’ll, i’ll go into that.

 

89

00:14:40.420 –> 00:14:58.070

US – Frog Field: So the the top layer is your reactivity, or your declarative. How do you express a Ui very concisely, very declaratively, and that’s involving, you know, these fairly higher level ideas. So that’s where your State management happens.

 

90

00:14:58.070 –> 00:15:15.260

US – Frog Field: That’s where your incremental updates happen that you know usually you don’t wanna when you’re writing a ui and a declarative style, you don’t want to be handling like the dirty bits of oh, this particular label change you just want to say this is what the label says, and then it’s up to the reactive layer to say.

 

91

00:15:15.260 –> 00:15:19.280

US – Frog Field: Did it change? If so, I need to propagate those, you know, down

 

92

00:15:19.520 –> 00:15:24.560

US – Frog Field: into the lower levels which are the element tree, and then ultimately the infrastructure

 

93

00:15:24.620 –> 00:15:43.670

US – Frog Field: and the other thing that reactivity, you know that really belongs at the reactivity layer of this stack is components. How do you factor your application into components that can, you know, operate more or less autonomously, but still interact with each other still still shared. Data, you know, have data flows in the system.

 

94

00:15:43.670 –> 00:15:56.380

US – Frog Field: but have these components that are fairly nicely abstracted and ideally like. If this, if this really sort of in the vision of the future, you’ll have standard components, you’ll say, I want, you know, a font picker, and you’ll just go get a font picker.

 

95

00:15:56.510 –> 00:16:00.390

US – Frog Field: and you know, and that’ll interact with the rest of your application.

 

96

00:16:01.460 –> 00:16:05.280

US – Frog Field: So so that’s the top layer. The next layer

 

97

00:16:05.550 –> 00:16:08.130

US – Frog Field: is the element tree.

 

98

00:16:08.430 –> 00:16:17.180

US – Frog Field: and you know this is where the kind of guts of the Ui happens, so that’s where the widgets are defined.

 

99

00:16:17.180 –> 00:16:29.990

US – Frog Field: and there’s a lot of operations that a Ui does like layout and styling and text editing and handling the the the mouse input and the you know the touch input on a mobile device and

 

100

00:16:30.030 –> 00:16:46.910

US – Frog Field: keyboard and all that stuff. So so basically, this is what the elementary is doing. It. It’s. It’s it’s taking those declarative Ui descriptions from the top layer and making them into widgets that can then be drawn on the screen and interacted with

 

101

00:16:47.030 –> 00:16:49.110

US – Frog Field: through, you know.

 

102

00:16:49.160 –> 00:16:50.910

US – Frog Field: through the Ui.

 

103

00:16:51.990 –> 00:17:04.150

US – Frog Field: And then there’s a layer below the elementary actually, before I go down there I want to there. Another very important part of this is that there’s that there’s that label on that line called the element tree Api.

 

104

00:17:04.290 –> 00:17:13.410

US – Frog Field: because that Api, that interface that boundary that can either be something that’s custom, and bespoke to a particular Ui toolkit.

 

105

00:17:13.430 –> 00:17:28.870

US – Frog Field: or it can be something more general and standardized. You might be able to do mixing and matching. You might be able to say, oh, I want this elementary, but I want this reactive layer on top of it, and I think increasingly, we’re moving toward that. And that’s very exciting.

 

106

00:17:29.760 –> 00:17:42.370

US – Frog Field: The the other distinction, the other sort of boundary in the system that I want to call attention to is that there’s a lot of infrastructure, and I’ve done you like, you know, if you look at my blog post, you know advice to the next dozen.

 

107

00:17:42.390 –> 00:17:54.960

US – Frog Field: Most of that was really talking about all the problems that still need to get solved at the in infrastructure layer. This is still not completely settled. But there, there is a lot of progress at that layer.

 

108

00:17:56.270 –> 00:18:04.650

US – Frog Field: So so this is kind of a model like this. This describes this general picture describes a lot of individual Ui systems. And so.

 

109

00:18:04.730 –> 00:18:14.860

US – Frog Field: if you’re on the web it takes, you know. It takes a particular shape that all of the stuff below that element Tree Api

 

110

00:18:14.870 –> 00:18:20.950

US – Frog Field: is a browser, so that’s all implemented inside the browser. So all of these functions are still in there.

 

111

00:18:20.990 –> 00:18:40.610

US – Frog Field: and you’re defining, you know you’re defining your elementary as HTML. And in this particular case i’m more interested in the spg notes than the HTML nodes, and then you know css for styling, and this there’s a lot more. But you know i’m I’m. Giving kind of the simplified model and the interface

 

112

00:18:40.610 –> 00:18:41.730

US – Frog Field: for that.

 

113

00:18:41.740 –> 00:18:52.040

US – Frog Field: You know the interface above that. How do you access that elementary? Is this highly standardized, extremely well documented thing called the Web dom api.

 

114

00:18:52.190 –> 00:19:06.060

US – Frog Field: and there’s a ton of stuff out there, I mean, there’s massive amounts of stuff out there that is, that is designed to float on top of the web, Dom Api, and I mean, obviously, you have a lot of Javascript choices.

 

115

00:19:06.060 –> 00:19:19.600

US – Frog Field: and then, increasingly, you have a lot of rest choices as well. All of which try this web, dom api. And then you’ve got a browser under that, or or or a browser, or a fragment of a browser. It’s actually implementing that. And

 

116

00:19:19.800 –> 00:19:29.410

US – Frog Field: And so, you know, like all of these infrastructure problems are really well solved in a browser that’s kind of one of the points that I want to make.

 

117

00:19:29.500 –> 00:19:40.940

US – Frog Field: and a a new, exciting way in which that’s true is that there’s no web. Gpu that that’s shipping, and from stable only only as of less than a month.

 

118

00:19:41.240 –> 00:19:47.520

US – Frog Field: So you you really can get access to to pretty close to the full power of the Gpu through your web browser these days.

 

119

00:19:48.630 –> 00:19:56.650

US – Frog Field: Now, if you’re not on a web browser. then the world looks a little bit different, and you have a lot of choices for native ui

 

120

00:19:57.080 –> 00:20:13.070

US – Frog Field: at the reactive layer. You actually the choices are pretty similar like this. You know that you know the access is, is definitely one of the choices. If you’re trying to drive web and dial access is definitely one of the choices. If you’re trying to drive a native. But if you don’t have a browser

 

121

00:20:13.070 –> 00:20:19.630

US – Frog Field: now, we have the responsibility to to to actually do all of these other layers in the system.

 

122

00:20:19.710 –> 00:20:29.130

US – Frog Field: So at the element tree. There’s a little bit of standardization. So a lot of the stuff inside these boxes are like suggestions of creates that you might be able to use to solve

 

123

00:20:29.130 –> 00:20:47.190

US – Frog Field: these individual sub problems, these parts of the larger ui problem. So if you want to do layout there’s there’s this new crate called taffy. It’s used primarily in Debbie the bevy Ui. But there’s a couple of other experimental things that are using it, and we’re looking into it. We’re considering using it for xylm as well.

 

124

00:20:47.340 –> 00:21:02.620

US – Frog Field: If you want to do css styling, there’s actually, you know, because that’s one of your choices like how do you express styling. You might just do it in in Css styles. And so there’s a lot of really excellent code from Stylo, which is part of the servo project that does selector matching, and

 

125

00:21:02.790 –> 00:21:07.830

US – Frog Field: you know, has all the data types to represent your Css properties. And so that’s one of the choices.

 

126

00:21:07.910 –> 00:21:22.900

US – Frog Field: And then, even in terms of the choice of the element tree. Api. That there’s a at least 2 things that are out there, probably more that that are moving towards some kind of standardized documented interface. For how do you does your reactive layer talk

 

127

00:21:22.910 –> 00:21:39.110

US – Frog Field: to the element tree that’s below it? And so one of those is masonry. which is a kind of a outgrowth or fork of Druid. and the other one. That that, I think, is getting a little bit of attention is the dioxide virtual Dom. And so this is. This is an interface

 

128

00:21:39.150 –> 00:21:51.910

US – Frog Field: that could be driving a web, Dom, or it could be driving a native elementary. It’s not. It’s not. It’s web compatible, but it doesn’t tie you necessarily to the same kind of

 

129

00:21:51.980 –> 00:21:59.520

US – Frog Field: trade offs that you have with with with a a purely compatible with Don.

 

130

00:22:00.200 –> 00:22:08.590

US – Frog Field: and then on the infrastructure layer. I mean all of these things At the lower lower level are things that have made huge amounts of progress in the last, you know, years.

 

131

00:22:08.630 –> 00:22:18.240

US – Frog Field: And so for platform integration, you have a choice between minute and leisure. Glazier is the one that we’re using asylum again. You can go to the

 

132

00:22:18.360 –> 00:22:29.290

US – Frog Field: different blogs to see the reasoning of Why are we not just doing? Win it for drawing? There’s toy again. There’s choices out there. This Mtvg. Which is, you know, among other things being used by slint.

 

133

00:22:29.440 –> 00:22:33.780

US – Frog Field: And then there’s Velo, which is the 2D engine that I’ve been working on

 

134

00:22:34.390 –> 00:22:43.390

US – Frog Field: for text that this used to be a huge problem. There is like, how do I do text? There’s nothing that I can do now there’s 2 good choices. There’s cosmic text, and there’s parly

 

135

00:22:43.540 –> 00:22:46.100

US – Frog Field: cosmic text is used.

 

136

00:22:46.340 –> 00:23:01.360

US – Frog Field: I think, increasingly by iced and partly as the one that we’re developing for the for the xylum stack and then other. You know other problems, like if you need Gpu access, You know we have standardized. We had our own custom bespoke stuff.

 

137

00:23:01.430 –> 00:23:20.090

US – Frog Field: and we said, You know what we’re gonna be better off if we join forces with W. Gpu, and that’s starting to pay off, because, like, among other things we’re able to integrate with. So we have a couple of prot types of baby games that are using for the rendering, and I think that this is also really exciting, like if you want to have an app that has an embedded

 

138

00:23:20.090 –> 00:23:34.060

US – Frog Field: 3D view, you know that we like. A year or 2 ago we would have said, You know, we just don’t. This is future work. But going forward, we’re we’re gonna be like, yeah, just just write it in W. Gpu, and then we’ll, we’ll be able to composite that in.

 

139

00:23:34.540 –> 00:23:49.070

US – Frog Field: And then another thing that’s huge progress in the last year is access to it accessibility. You need. You guys need to be accessible. We can’t just leave these people behind. You need, you know, screen readers, other assistive technology

 

140

00:23:49.070 –> 00:24:02.640

US – Frog Field: and access. Kit is a layer that is really starting to be, you know, developed. So it has these accessibility capabilities, and it’s being adopted, most of the I I would say, all of the leading ui tool kits.

 

141

00:24:02.660 –> 00:24:07.440

US – Frog Field: I’ve either adopted access Kit, or are in the process of doing so.

 

142

00:24:08.800 –> 00:24:20.470

US – Frog Field: So I I wanna talk, you know, with this layered architecture with this sort of like reactivity or declarative ui layer, and then an elementary. I want to talk a little bit about this distinction between the view tree and elementary. Because

 

143

00:24:20.710 –> 00:24:28.260

US – Frog Field: when when I talk with people they’re always like, Why do you need both? Why do you need this distinction? Why, don’t you just do everything in one

 

144

00:24:28.350 –> 00:24:34.550

US – Frog Field: type, one trait. and that’s the way that drew it. Used to work. We used to have a widget

 

145

00:24:34.610 –> 00:24:47.560

US – Frog Field: that that had both of the functionality of the kind of declarative ui and the the reactivity, and also driving the elementary handling all the functions like layout, and so on and so forth.

 

146

00:24:47.590 –> 00:24:55.250

US – Frog Field: And so that’s one of the things that’s changed from Drew it to Zylum that now we have 2 different things. We have a view tree, and we have an element tree.

 

147

00:24:55.340 –> 00:24:57.400

US – Frog Field: and the difference between the 2

 

148

00:24:57.460 –> 00:25:04.480

US – Frog Field: is that the view tree is specifically charged with the declarative representation of Ui.

 

149

00:25:04.760 –> 00:25:24.600

US – Frog Field: and so it’s designed to be Ergonomics designed to be easy to deal with. Most of the views in Zylum are just plain, old, simple value types. You don’t have a lot of complicated like context that you need to thread through or access to. There’s no complicated stuff like, how do you? How do you access the

 

150

00:25:24.600 –> 00:25:28.450

US – Frog Field: the kind of state that that is needed to drive the Ui.

 

151

00:25:29.860 –> 00:25:49.130

US – Frog Field: That’s all in the elementary. So the elementary like. When I think about this stuff, the elementary is the messy part. The elementary, like every element, has to deal with life cycle like what you know what happens when you get instantiated and get yourself connected to like layout. And of course you have to do all these other things like drawing and input from the mouse. And

 

152

00:25:49.130 –> 00:25:51.520

and that’s also where the accessibility happens.

 

153

00:25:51.870 –> 00:26:09.710

US – Frog Field: So so these are 2 different types, and you know usually your view. Your view tree is going to be a transient thing that your app just says, here’s the view tree. This is what I want to look like right now and then. You know it updates the elementary, and then the view tree gets gets dropped.

 

154

00:26:09.710 –> 00:26:24.450

US – Frog Field: but the elementary has to be persistent. The elementary, you know, that has like your cursor focus. So you know, that needs that has a lot of state in it that needs to stay, even when your app is generating all these all these views.

 

155

00:26:24.590 –> 00:26:28.340

US – Frog Field: And this is, you know, I’m. Talking in in terms of Xylum

 

156

00:26:28.570 –> 00:26:42.490

US – Frog Field: and the the distinction in Zion between view and element. And, by the way, these names there’s a there is not really super consistent terminology that there are a lot of different things called views. There’s a lot of different things called elements.

 

157

00:26:42.640 –> 00:26:48.400

US – Frog Field: So I think this is a good general pattern, but you might need to tweak it a little bit for specific ui.

 

158

00:26:48.580 –> 00:26:55.490

US – Frog Field: But even aside from xylum, there’s a lot of things that have this distinction. This is a common pattern in the way that you guys are built.

 

159

00:26:55.640 –> 00:27:03.090

US – Frog Field: Now it it it’s relatively new, I mean in the old sort of object Oriented days. You wouldn’t have this distinction.

 

160

00:27:04.640 –> 00:27:05.450

US – Frog Field: So

 

161

00:27:07.310 –> 00:27:14.610

US – Frog Field: you know I I spent a lot of time looking at other systems that are out there and trying to learn from them.

 

162

00:27:14.780 –> 00:27:21.860

US – Frog Field: And there’s a lot. There’s a lot in the Javascript world, and there’s a lot in the Rust world. and

 

163

00:27:22.100 –> 00:27:31.340

US – Frog Field: when I kind of try to get my head around like Sometimes it can be completely overwhelming, like, you know, in the Javascript world. I think they’re probably hundreds of different frameworks.

 

164

00:27:31.390 –> 00:27:35.670

US – Frog Field: and even in the rest world there’s so many of them. Then it’s hard to keep track of them all.

 

165

00:27:36.110 –> 00:27:42.130

US – Frog Field: So I am trying to get my head around this, and trying to understand the space that I have divided

 

166

00:27:42.280 –> 00:27:47.790

US – Frog Field: the declarative Ui systems into kind of 4 tribes.

 

167

00:27:47.850 –> 00:27:59.540

US – Frog Field: and I’ve named in this in this categorization. I’ve named them after a representative, a kind of most famous example, or the one that most exemplifies that particular tribe.

 

168

00:27:59.540 –> 00:28:08.320

US – Frog Field: This doesn’t, you know it again to emphasize that this doesn’t tell you everything about the entire universe. But immediate mode is not in here. This immediate mode doesn’t have that distinction

 

169

00:28:08.470 –> 00:28:16.500

US – Frog Field: between between the the the kind of declarative layer and the element layer. It’s all one thing.

 

170

00:28:18.900 –> 00:28:32.890

US – Frog Field: But in any case there there these 4 tribes there’s solid Js, which is also known as fine grain reactivity. There’s react. There’s elm, which is also known as model view update, and there’s Swift Ui, and each one of these tribes has multiple representations.

 

171

00:28:33.210 –> 00:28:35.710

US – Frog Field: And then there’s 2 things that I wanna

 

172

00:28:35.900 –> 00:28:43.990

US – Frog Field: you know, like if you’re interested in this sort of larger world of like, how how is reactive. Ui, or declared to you. I built both in rust and and javascript.

 

173

00:28:44.320 –> 00:28:51.520

US – Frog Field: Well, both of these videos, both of these blogs resources is a blog and a video really do focus on rust.

 

174

00:28:51.650 –> 00:29:00.100

US – Frog Field: And so the first one is a survey of about 20 different systems. Blog posts came out about a month ago really interesting. I learned from it.

 

175

00:29:00.170 –> 00:29:09.490

US – Frog Field: and the second one is a video that goes Really, it’s a deep dive into the performance of rest driving. So when you’re driving a web browser.

 

176

00:29:09.580 –> 00:29:16.280

US – Frog Field: and that’s by Greg Johnson, who’s the creator of Leptos. So again, really good information strongly recommended.

 

177

00:29:17.550 –> 00:29:20.940

US – Frog Field: So let’s go into those 4 tribes, each in a little bit more detail.

 

178

00:29:21.530 –> 00:29:31.500

US – Frog Field: and I the order, By the way, the reason why I chose this order is that the difference between one, and the next is is less. There’s a sort of a incremental flow here.

 

179

00:29:32.890 –> 00:29:34.810

US – Frog Field: so we’ll start with solid Js.

 

180

00:29:34.880 –> 00:29:49.950

US – Frog Field: so solid. Js. Is again sort of least like Xylam in that it is not doing this transient view tree that it’s throwing away it actually like kind of one of the things that people say, is the V Dom as pure overhead.

 

181

00:29:50.180 –> 00:29:51.860

US – Frog Field: I think that’s

 

182

00:29:52.870 –> 00:29:59.110

US – Frog Field: the the truth is much more nuanced. And again, you know, Go to that talk by Greg Johnson, which will

 

183

00:29:59.350 –> 00:30:01.200

US – Frog Field: help fill in a lot of that nuance.

 

184

00:30:01.450 –> 00:30:12.210

US – Frog Field: It’s all just takes the position. No, we don’t want to build these view trees, and this them. We want to build an elementary once. Of course you have to keep building it more of it if you’re dynamically adding new content.

 

185

00:30:12.470 –> 00:30:17.360

US – Frog Field: But you know generally. You know you build the thing once, and it’s days. It’s persistent.

 

186

00:30:17.930 –> 00:30:36.130

US – Frog Field: And in order to get the updates to happen, because you need to update, you know you need your your what you’re showing is changing. In this tribe. You build a fine-grained dependency graph so basically every piece of information that’s on that screen every property

 

187

00:30:36.170 –> 00:30:52.070

US – Frog Field: has. It is a node in a dependency graph, and then your app state is also nodes in a dependency graph, and you know, when you build your Ui, it is dynamically building that dependency graph. So when some element, when some field in your app state changes

 

188

00:30:52.070 –> 00:31:06.630

US – Frog Field: that’s gonna get plumbed. So those changes are gonna propagate through the dependency graph, and then when they get to the end, they’re going to cause something to change, you know, in the elementary. So in a on a Dom that’s going to be like a set attribute, or something like that on a Dom node.

 

189

00:31:07.510 –> 00:31:12.860

US – Frog Field: So not fine green dependency graph. I mean that’s a hard thing to build. This is the this is the tricky part.

 

190

00:31:12.940 –> 00:31:19.030

US – Frog Field: And so there’s kind of 2 flavors, 2 sub flavors. I mean. Everything has infinite amounts of variation, but

 

191

00:31:19.270 –> 00:31:38.940

US – Frog Field: one of them is that you do all this building of this dependency graph at runtime, and that’s certainly what solid Js does, and Svet has the kind of attitude of like. Well, there’s a compiler. Why not do a ton of analysis of your Ui, so that you. You kind of build as much as possible like there’s maybe some that you still have to do at runtime, but, like

 

192

00:31:38.940 –> 00:31:42.530

US – Frog Field: you can analyze it, you can kind of figure out what the dependencies are

 

193

00:31:42.700 –> 00:31:51.590

US – Frog Field: at compile time, but that requires a compiler that requires a a build step, and in the case of spelled. You know they have a compiler. That does that.

 

194

00:31:52.330 –> 00:32:02.870

US – Frog Field: Right? So so then, this how it works that you know when the input changes, when some part of your upstate changes, and that propagates through the graph. It updates your element attributes, and, you know, makes all those changes.

 

195

00:32:03.180 –> 00:32:15.380

US – Frog Field: So there’s there are 3 really interesting rust implementations on the web that drive Dom, that’s sycamore Leptos, and a new one called Sil silicon web.

 

196

00:32:15.570 –> 00:32:20.960

US – Frog Field: And I would say, you know, Sycamore and laptop are actually pretty similar. Left to this is a little newer.

 

197

00:32:20.970 –> 00:32:29.980

US – Frog Field: A laptop has some, some refinement, is trying to be more ergonomic, but fundamentally the way that it works fundamentally the way that it’s building these dependency graphs

 

198

00:32:30.010 –> 00:32:31.260

US – Frog Field: is the same.

 

199

00:32:31.970 –> 00:32:36.380

US – Frog Field: And then there’s also like you know, one of the things that about these tribes is that

 

200

00:32:36.530 –> 00:32:40.410

US – Frog Field: most of them have both web and native implementations in some way.

 

201

00:32:40.480 –> 00:32:51.570

US – Frog Field: And so again, that there is an implementation of this fine-grain reactivity model on native Ui in in in the form of vizia.

 

202

00:32:51.600 –> 00:33:03.680

US – Frog Field: At first I actually had it in the wrong category, because I looked at it, and I saw that it uses elm style messages to handle. Sort of your your input I was like, oh, it’s in the Elm tribe, but that’s it straight.

 

203

00:33:04.270 –> 00:33:09.400

US – Frog Field: It is, it is. The the reactivity is is definitely fine, grand.

 

204

00:33:09.420 –> 00:33:11.770

US – Frog Field: and it has a little bit of this elm flavor.

 

205

00:33:13.190 –> 00:33:15.950

US – Frog Field: So the next of the big tribes, and this one like

 

206

00:33:15.970 –> 00:33:23.670

US – Frog Field: it’s actually, it’s not surprising that this right exists because react is overwhelmingly popular in the javascript world.

 

207

00:33:23.890 –> 00:33:30.310

US – Frog Field: So it’s surprising that there aren’t that many rest implementations as well.

 

208

00:33:30.670 –> 00:33:38.640

US – Frog Field: But there are some, and the one, you know, I think, the one that a lot of people are really excited about, and for good reason is by access.

 

209

00:33:39.080 –> 00:33:41.120

US – Frog Field: Let’s let’s get into it a little bit more.

 

210

00:33:41.560 –> 00:33:54.280

US – Frog Field: So this one is a transient view tree. So basically you run your app and your app. You know your app is basically a function from the app state to this view tree, which is this transient thing.

 

211

00:33:54.350 –> 00:34:03.870

US – Frog Field: It’s also. This pattern is also known as virtual. Dom. Right? Because you’re you’re building a tree. It looks a lot like a Dom.

 

212

00:34:04.710 –> 00:34:07.040

US – Frog Field: And so in react

 

213

00:34:07.100 –> 00:34:23.570

US – Frog Field: like this is also the distinction between like left us, which is fine green reactivity that in react. You have a fairly coarse granularity it’s really generally component scope to decide when a re-render is needed. You know that you you build you build a view tree for an entire component.

 

214

00:34:23.929 –> 00:34:30.210

US – Frog Field: and there’s a couple of ways that you trigger this right? You don’t always build all of the world on every update cycle

 

215

00:34:30.380 –> 00:34:48.570

US – Frog Field: that you either have a notification like, if you do set state on a component. It causes a component to rebuild. And there’s also a memoization function so it says if the data hasn’t changed, then we won’t re-render. So so you’re not always. You’re not always building and always diffing. There’s a shortcut that says, hey, this doesn’t need to change.

 

216

00:34:49.540 –> 00:35:08.470

US – Frog Field: but when you do re-render you get a new view tree, and then you take that view tree and you do it against the old. So if is basically a function from old tree, a new tree, you know, sitting on some kind of mutable elementary, and and it updates the element tree creates an it either updates it directly by having mutable access to the elementary.

 

217

00:35:08.470 –> 00:35:12.530

US – Frog Field: or create some kind of mutation object, which is the way that Diox does it.

 

218

00:35:13.130 –> 00:35:31.130

US – Frog Field: And you know, like one of the reasons why I prefer the word view tree over virtual. Dom is that it doesn’t have to be just a dom and react really goes very. The react ecosystem goes very far down this line that react has a lot of different types of elementaries, not just the Dom.

 

219

00:35:31.720 –> 00:35:48.350

US – Frog Field: Another thing to say. You know, people are very concerned like React has a reputation, a fairly well deserved reputation for not having great performance. And you know one of the reasons is, you’re you’re building these view trees with early course granularity. And you’re doing a lot of different work.

 

220

00:35:48.360 –> 00:35:52.700

US – Frog Field: even if nothing has changed, or only a very small amount has changed.

 

221

00:35:52.740 –> 00:36:02.820

US – Frog Field: So one of the techniques that can reduce that cost of diffing is that you use templates so that you’re You’re really only diffing the dynamic parts and the static parts, you know, get done once.

 

222

00:36:03.340 –> 00:36:07.800

US – Frog Field: and that access. The re recent release of the access has

 

223

00:36:08.070 –> 00:36:14.240

US – Frog Field: has this template mechanism, and it’s it’s one of the reasons why their performance is really quite excellent.

 

224

00:36:15.240 –> 00:36:29.600

US – Frog Field: And then there’s this concept of you state, because the problem, you know one of the challenges here is that these view trees are transient. So if you have state that needs to be persistent, if you need to track over a longer period of time, how do you do that? And the way react does it in javascript

 

225

00:36:29.630 –> 00:36:39.510

US – Frog Field: is that there’s hooks, and those live in some kind of persistent you state, you know, off to the side, and so that that that you state tree lives and persists

 

226

00:36:40.240 –> 00:36:47.360

US – Frog Field: great. And then oh, when you all you outside, you know mostly i’m talking about rest and javascript, because in javascript there’s this

 

227

00:36:47.370 –> 00:36:50.130

US – Frog Field: extremely thorough exploration of the State.

 

228

00:36:50.170 –> 00:36:56.090

US – Frog Field: but I will also mention that Flutter is fundamentally there. It belongs to the react tried.

 

229

00:36:56.490 –> 00:36:58.680

US – Frog Field: and of course it’s implemented in dart.

 

230

00:37:00.250 –> 00:37:05.440

US – Frog Field: So the third tribe is Elma, and Elm has a great long

 

231

00:37:05.660 –> 00:37:16.180

US – Frog Field: history, and I think the reason why elm is popular is that that it? That the impedance mismatch between L. And R. Is less than, for example, between Javascript and Russ the Javascript.

 

232

00:37:16.210 –> 00:37:26.680

US – Frog Field: you know, access to shared mutable state is no problem, right? Object, Oriented inheritance, no problem. Those patterns Don’t adapt well to rest, but the elm patterns do

 

233

00:37:27.870 –> 00:37:40.420

US – Frog Field: it’s pretty similar to react. It’s the same virtual dom or view tree. You know you build this transient view tree, and you. you know, that gets diff to actually update the element trees

 

234

00:37:40.620 –> 00:37:59.260

US – Frog Field: you. It’s it’s a little bit more reliant on memoization in L. Memoization is the kind of primary tool that you use to decide what needs to get re-rendered. But I think the main difference between the react and the Elm tribe is that in react. Everything tends to be very dynamically typed.

 

235

00:37:59.400 –> 00:38:11.920

US – Frog Field: comes from the javascript world, and then L. The view tree has a type. It is statically typed. So when you have, you know, a column with a button and a slider. Then there’s a type which is some sort of container button slider that represents that.

 

236

00:38:12.730 –> 00:38:18.230

US – Frog Field: Yeah. And as I as I mentioned. You know mostly memoization to control your re-renders

 

237

00:38:18.370 –> 00:38:36.970

US – Frog Field: and one of the other things that’s interesting and unique about the elm tribe or patterns is that you know most of the time, if you like. When you click a button it’s usually calling a call back, and then that call back goes, and it somehow accesses the app state and causes the change to that state.

 

238

00:38:37.090 –> 00:38:54.680

US – Frog Field: And that’s a problem like, how do you represent that like? You know? How do you connect that. How do you get it to access? That? And one of the ways that that’s done very popularly in rust is that you have interior mutability; that you have a shared reference. It might be an arc mutex, or a, or C rough cell. If you don’t care about running in a multi threaded context.

 

239

00:38:54.700 –> 00:39:02.030

US – Frog Field: And so the the call back itself has that reference, and it it reaches into the interior. Immutability makes the change.

 

240

00:39:02.260 –> 00:39:15.570

US – Frog Field: But Elm has this other pattern that works really well in a purely functional language. It says, No. What happens is when you click the button. It creates a message, and then that message gets passed to an update function.

 

241

00:39:15.600 –> 00:39:25.060

US – Frog Field: and the update function reduces. You know it. It basically creates a new app state which is a function of the old app state, and the message that it’s given.

 

242

00:39:25.460 –> 00:39:39.090

US – Frog Field: And so that means that you, you don’t have this problem like you. Don’t have to do interior mutability. So this you know all these problems that you have when you have this kind of soup of tons of shared mutable objects that have references to each other.

 

243

00:39:39.180 –> 00:39:56.280

US – Frog Field: and are constantly trying to mutate each other, you really avoid that. It’s much more organized and disciplined and structured than than. and these object oriented types of patterns. So, not surprisingly, we have a number. We have quite a number of rest implementations of this pattern. So on the web we have you, and so on.

 

244

00:39:56.450 –> 00:40:05.780

US – Frog Field: And then in the native world. And this is these are there’s more. These are just representatives that iced is really based on the elm patterns.

 

245

00:40:05.810 –> 00:40:08.370

US – Frog Field: and you also have this realm.

 

246

00:40:08.790 –> 00:40:13.610

US – Frog Field: which is, I believe, the layer on top of Gtk plus primarily

 

247

00:40:14.990 –> 00:40:30.080

US – Frog Field: so. The last of the 4 tribes is Swift Ui. and this is less known. I mean. One of the reasons why it’s less known is that there is no representation of this at all in the Javascript world. If you come from the javascript world, then Swift Ui is alien.

 

248

00:40:30.340 –> 00:40:38.390

US – Frog Field: and the main reason why that’s the case is that Swift Ui relies extremely heavily on a statically type view tree

 

249

00:40:38.470 –> 00:40:44.390

US – Frog Field: like it goes well. I mean it’s similar to element this way. But it this is really

 

250

00:40:44.430 –> 00:40:50.590

US – Frog Field: characteristic. If you try to do Swift ui without the aesthetically type, you tree. It wouldn’t be anywhere near the same thing.

 

251

00:40:50.830 –> 00:41:01.520

US – Frog Field: So there’s a rich swift, you Swift has a very rich type system. There’s a lot of commonality between a swift type system and the restite system. They both have associated types.

 

252

00:41:01.530 –> 00:41:04.160

US – Frog Field: and they both use associated types.

 

253

00:41:04.320 –> 00:41:15.420

US – Frog Field: Well, Swift, you. I uses associated types very extensively, so that that view state like when we’re talking about, react, and having the hook, there’s this kind of a ray. And there’s this all this sort of

 

254

00:41:15.480 –> 00:41:25.690

US – Frog Field: in, and the end authority where it goes and reaches into the array. And then there’s the rules of hooks that say, If you do this out of order, then you’ll get the State completely scrambled.

 

255

00:41:25.820 –> 00:41:29.800

US – Frog Field: But with you I is again much more organized and disciplined about this.

 

256

00:41:29.810 –> 00:41:47.620

US – Frog Field: that you know that it’s saying, Well, you have this view tree, and then there’s an associated type, which is the view State tree and the correspondence, for, like you know. How do you access that state when you’re in a view? And you’re trying to process it? It’s a very straightforward. It’s it’s statically type. There’s actually a lot less that can go wrong.

 

257

00:41:47.890 –> 00:41:58.210

US – Frog Field: Now, if you, if you do want more chance for things to go wrong. you have that option as well that you can do type, erasure, any view.

 

258

00:41:58.390 –> 00:42:12.410

US – Frog Field: and that allows you that that gets you a note in your static type system that says, yeah, this is any. This can be any of you under that. So this is. This works really well, obviously, for Swift.

 

259

00:42:12.610 –> 00:42:16.820

US – Frog Field: and I think it works really well for rest. Also.

 

260

00:42:18.450 –> 00:42:29.230

US – Frog Field: Yeah, the the actual diffing, and so on and so forth, works pretty much pretty similar to the react and elm tribes. There’s nothing really interesting or new there. Maybe one

 

261

00:42:29.620 –> 00:42:47.000

US – Frog Field: thing mentioned, though, at this point is that because those view trees are statically type, there is a lot less allocation and dynamic dispatch, and so on, and so forth, that you know, if you have like numbers and stuff like that, the the code to diff can just be comparing those numbers and and going on. You don’t need to like

 

262

00:42:47.030 –> 00:43:01.680

US – Frog Field: chase a lot of pointers. So that’s one of the reasons, I think, why it works. If you have a aesthetically type language. so I would say, there are at this point 2 implementations of the swift Ui tribe or pattern in rest.

 

263

00:43:01.880 –> 00:43:11.790

US – Frog Field: and one of them is Zylum, which I’m going to talk about in a lot more detail, and the other is Rui, which is very interesting, and really was, was actually a lot of the inspiration really was before Xylum.

 

264

00:43:11.980 –> 00:43:21.520

US – Frog Field: and then sort of open my eyes. But like wow, this is a way that we can express. Ui really cleanly, like Swift. Ui looks beautiful, much more so.

 

265

00:43:21.560 –> 00:43:24.190

US – Frog Field: in my opinion, than most of these other patterns.

 

266

00:43:24.450 –> 00:43:40.460

US – Frog Field: But there are pretty dramatic differences between Xylm and Rui. And so one difference is that in I’m actually not going to go into the call back as much in this talk. I’m going to be talking about the kind of forward path, the rendering more. But it’s very important to the architecture. And so

 

267

00:43:40.480 –> 00:43:54.510

US – Frog Field: in Xyl it’s kind of maybe halfway between elm, where there’s this pure functional thing where you have to like dispatch back to some function that takes that, you know message and and applies it to this to the at State.

 

268

00:43:54.540 –> 00:43:59.540

US – Frog Field: and you know kind of a react thing where there’s a call back that has it reference and goes directly

 

269

00:43:59.590 –> 00:44:11.550

US – Frog Field: that in xylum there’s a mechanism where the call back is given access to the to the at State. So there’s an and mute t where t is the apps up state that that’s part of the xylum type.

 

270

00:44:12.010 –> 00:44:20.530

US – Frog Field: and then really has immediate mode rendering. And again, I feel like immediate mode rendering has a lot of limitations. I think there’s a lot of richness that you want to achieve.

 

271

00:44:20.620 –> 00:44:26.190

US – Frog Field: It’s harder to do. It depends on what you’re trying to do, though there’s there’s some domains for which immediate mode

 

272

00:44:26.260 –> 00:44:30.940

US – Frog Field: is a really good choice, and there are others, I think, for which it’s just way, too limiting.

 

273

00:44:32.260 –> 00:44:34.480

US – Frog Field: So let me talk about Zealand a little bit.

 

274

00:44:34.580 –> 00:44:44.810

US – Frog Field: anyway. I should also mention. If people have questions like pop up, we’ll, we’ll get you a mic. This is. This is supposed to be a conversation. This is not supposed to be just the lecturing here.

 

275

00:44:47.320 –> 00:45:00.380

US – Frog Field: Great so Xylm: so so again this is a quick overview. There’s some blog post. There’s some more materials out there, and we’re going to be rolling out more as we keep developing this stuff. But I I I want to give it at least a very quick overview

 

276

00:45:00.450 –> 00:45:07.330

US – Frog Field: of what this alarm architecture looks like. So kind of similar like. You know it’s super inspired by with you, I.

 

277

00:45:07.460 –> 00:45:25.660

US – Frog Field: And so each view. So you have this view Trait, which is really the center of the Xylom architecture, and the view trait has 2 associated types, and one of them is the view state. So that would be the same thing that you would use your hooks or in react, and the other is the element. So if you have a button view

 

278

00:45:25.660 –> 00:45:29.870

US – Frog Field: and you have a button element, and the button element is the widget, and it’s gonna

 

279

00:45:29.890 –> 00:45:32.110

US – Frog Field: It’s gonna meet a

 

280

00:45:32.510 –> 00:45:40.420

US – Frog Field: a down, you know for a widget. and and that’s the actual implementation of that view.

 

281

00:45:40.670 –> 00:45:52.000

US – Frog Field: And then there are 3 methods, each of you implements, 3 methods, and the first method is build, and so that creates the element tree and initializes the State for it.

 

282

00:45:52.000 –> 00:46:01.430

US – Frog Field: And if you’re not going to see any changes like, if you’re building something that’s static, and that’s enough. Then you’re done, you have you? You’ve built the you’ve built the element. You’ve initialized the state you’re done.

 

283

00:46:01.710 –> 00:46:06.700

US – Frog Field: But if you do have changes. If you need to update that. then you have the rebuild method.

 

284

00:46:06.940 –> 00:46:11.250

US – Frog Field: and so there. These, by the way, are highly simplified signatures. With these methods.

 

285

00:46:12.830 –> 00:46:26.230

US – Frog Field: There’s a context that goes in, and the nice thing is that that context. It has the context. It can use it. But that’s hidden when you’re writing your app. You don’t need the context. You just write your views and the user address value data, types

 

286

00:46:26.380 –> 00:46:30.140

US – Frog Field: and the context wiring kind of happens under the hood for you.

 

287

00:46:31.040 –> 00:46:50.490

US – Frog Field: So yeah, so if something changes, and you call the rebuild method and the rebuild method is what’s doing the different. So the signature of this is that you got self, which is the new view you’ve got Pre, which is the previous state, the old view. So you’re able to compare those diff them. And then you’ve got mutable access to the State.

 

288

00:46:50.490 –> 00:46:59.430

US – Frog Field: and you’ve got mutable access to the element tree. And again, in zylum like this is actually, I think, a simplification over some other alternatives

 

289

00:46:59.530 –> 00:47:12.120

US – Frog Field: that’s mutable access to the elementary. So when you’re like, how do you? How do you update it? How do you mutate it? In some of these designs, including by access, you actually build a mutation data structure. You know you’re trying to do this batch mutation.

 

290

00:47:12.170 –> 00:47:24.010

US – Frog Field: and there are a lot of advantages to doing that. I had that prototype in an earlier prototype of this thing. That’s what I was doing. But you know, largely largely inspired by Olivia.

 

291

00:47:25.960 –> 00:47:31.220

US – Frog Field: I can’t pronounce his last name, but the author of panoramics and

 

292

00:47:31.660 –> 00:47:39.280

US – Frog Field: and masonry really said, you can simplify this. You can, you can get direct mutable access

 

293

00:47:39.300 –> 00:47:48.320

US – Frog Field: to the elementary itself. And then, when you have a container, then you know, when the container traverses down. So this is all based on recursive traversal from the root.

 

294

00:47:48.360 –> 00:48:02.430

US – Frog Field: And so, when you have a container and the container has mutable access to some parent node, then when it traverses into the children. It just gives the children mutable access to it to their individual element, trees. So that’s a pattern that I think that works really well in rust.

 

295

00:48:02.690 –> 00:48:05.950

US – Frog Field: and the third method which I won’t be talking about in detail tonight

 

296

00:48:06.030 –> 00:48:24.530

US – Frog Field: is the message method, and this is this is the sort of reverse flow. This is taking your mouse clicks and your ui interactions. And when Async futures resolved basically you, you, you know, this is a real graph data flow, incremental computation, mechanism that any time something needs to flow in that direction.

 

297

00:48:24.590 –> 00:48:28.430

US – Frog Field: That’s a a on the message method of the corresponding view.

 

298

00:48:29.940 –> 00:48:42.170

US – Frog Field: So the the other thing, you know, like I I you know I focus on view, but a lot of the actual work that’s been done. There’s been through this very slow but methodical refinement of these ideas over the last few months.

 

299

00:48:42.350 –> 00:48:54.110

US – Frog Field: And so one of the things that’s come into the better focus is view sequence. And so you can think of view as modeling, maybe a parent child relationship and view sequences as as modeling a sibling relationship.

 

300

00:48:54.240 –> 00:49:10.700

US – Frog Field: So these sequences, 0 or more views that are, you know, siblings of each other in that in that tree structure. And one of the things that’s important to get right is that the number of use in that sequence can vary dynamically like that. That’s a little hard, the the mechanism to get that work.

 

301

00:49:10.700 –> 00:49:24.250

US – Frog Field: But I think what we have now works really Well, there’s the specs place it has, you know. You can do. Insert delete, mutate, and skip operations in there. and it’s reasonably efficient. You don’t get any n squared behavior.

 

302

00:49:24.380 –> 00:49:31.480

US – Frog Field: The details of the performance are are a deep and nuanced question, but I think what’s there is good.

 

303

00:49:31.900 –> 00:49:45.840

US – Frog Field: And then one of the other things that’s nice is, you know, a lot of times in these you you have conditional rendering like display. This, you know, display this error. Indicator. If there’s an error condition. and the way you model that is that you just have option. So you just say none, or you say some Error Commission.

 

304

00:49:46.280 –> 00:49:52.510

US – Frog Field: and it’s just a it’s just your pure rest type there. So, as I say, this, this is a

 

305

00:49:53.960 –> 00:50:00.020

US – Frog Field: so. The idea that came together just in the last, you know. Couple of months is.

 

306

00:50:00.480 –> 00:50:04.430

US – Frog Field: you know, if you are trying to drive both native and web, how do you make that happen?

 

307

00:50:04.440 –> 00:50:14.930

US – Frog Field: And the idea is, you have this view, trait, and one of the beautiful things about rust it’s. This is very different than the usual object oriented. You know, model of the world

 

308

00:50:14.950 –> 00:50:25.440

US – Frog Field: is that you can have a concrete data type you can have in the case of vector graph if you can have a circle. and you can say, i’m going to have 2 different traits on that, and one of them is going to be an Sg. View.

 

309

00:50:25.560 –> 00:50:30.280

US – Frog Field: and the other is going to be asylum view, then I’m going to render, you know, with native rendering.

 

310

00:50:30.620 –> 00:50:33.400

US – Frog Field: And so, when you’re writing your app.

 

311

00:50:33.600 –> 00:50:42.820

US – Frog Field: you don’t have to care which back end is actually driving it. You can say i’m going to generate a circle here, or all of the other things that are vector graphics, types, groups. And

 

312

00:50:42.920 –> 00:51:01.060

US – Frog Field: you know you’re gonna put wrappers around them to control their styling and interactivity and stuff like that. None of that. None of that actually really cares whether it’s generating dom nodes that will be interpreted by the browser, or whether it’s generating. You know these structures that will be implemented natively.

 

313

00:51:01.830 –> 00:51:10.940

US – Frog Field: So the thing that makes this work. And again, this is something that really only landed in the last 2 or 3 weeks in the Repo, because we were. We were spending time to get it right

 

314

00:51:11.140 –> 00:51:15.630

US – Frog Field: is the generic asylum core. So this is a crate that’s inside the Zealand repo.

 

315

00:51:15.930 –> 00:51:17.170

US – Frog Field: and

 

316

00:51:17.190 –> 00:51:32.580

US – Frog Field: it is agile over the type of the elementary. So the element tree can be dom nodes in a browser or the elementary. It can be widgets, you know, that you define, for the elements tree can be something else. So that’s that’s usually modeled as a trait bound. So in the case of like widgets.

 

317

00:51:32.580 –> 00:51:44.970

US – Frog Field: there’s a Widget trait, and it says any any, any node in the element tree that you generate has to conform to the widget trade. And then, if you’re a container, then all of your children are basically like imple, you know, ample widget.

 

318

00:51:46.190 –> 00:51:49.120

US – Frog Field: or actually box time with it. But you know

 

319

00:51:49.540 –> 00:51:57.980

US – Frog Field: you actually you get that choice. If you really, If you want the elementary to be statically type, you can do that. But there. there’s some downsides to that. So we have it boxed.

 

320

00:51:58.610 –> 00:52:08.160

US – Frog Field: And so, if you have different instances of this. So this is part of the idea that we do want different instances. We want one instance for web, and we want one instance for

 

321

00:52:08.290 –> 00:52:09.480

US – Frog Field: native.

 

322

00:52:09.710 –> 00:52:16.130

US – Frog Field: and then we actually want other instances for other things that are not widgets. So we want menus to be their own

 

323

00:52:16.190 –> 00:52:21.100

US – Frog Field: view as well, and the element tree is menu items and not widgets.

 

324

00:52:21.330 –> 00:52:39.040

US – Frog Field: And so we we, after considering a lot of different possibilities like we went pretty deeply into like. Can we do this using generics and the type system? And you know that ended up, I mean long story short, it ended up just not you. You could force it, you could make it work, but it just wasn’t the right answer.

 

325

00:52:39.210 –> 00:52:43.080

US – Frog Field: And you, you know you can read what’s on there. I’m not gonna read it.

 

326

00:52:43.210 –> 00:52:55.250

US – Frog Field: So we ended up having Macros so that you just say, you know, basically generate all these traits and generate all these helper methods like type erasure, and so on, and so forth. You sequence.

 

327

00:52:55.300 –> 00:53:11.800

US – Frog Field: you know. So so those are just Macros. But those macros are not exported to users. You don’t have to write macros in application code. This is when you’re implementing something. When you’re you use macros. If you’re applying xylm core to build the Ui framework, so it’s like a Ui framework construction Kit.

 

328

00:53:13.710 –> 00:53:20.000

US – Frog Field: So the prototype that I’ve been using to kind of experiment with this is this thing called Zealand Svg.

 

329

00:53:20.170 –> 00:53:25.620

US – Frog Field: And it’s an instantiation of zone core that generates Dom notes. and

 

330

00:53:25.660 –> 00:53:44.550

US – Frog Field: the the the views are actually just plain kerbushes. Kerbo is our geometry, you know. Create it’s got circles and lines and rectangles and busy ipads, and all those goodies, and those just get an simple view on it. So your app like, if your app just returns to circle. Then that’s something that will

 

331

00:53:44.860 –> 00:53:56.710

US – Frog Field: generate an Sg. Circle node. or it’ll draw a circle using. And so then there’s wrapper views. So those are the clean curb shapes are kind of the leaves of the system. And then there’s wrappers that add color

 

332

00:53:56.810 –> 00:53:58.680

US – Frog Field: and mouse interactivity

 

333

00:53:58.710 –> 00:54:10.380

US – Frog Field: and Zealand, Svg: the actual Zealand Svg. Create itself Everything that it does compiles the laz on, and it runs in the browser, and it’s really economical it

 

334

00:54:10.590 –> 00:54:13.170

US – Frog Field: I’ll I’ll I’ll actually show it to you now.

 

335

00:54:15.310 –> 00:54:26.980

US – Frog Field: So this is a Let’s see how this is gonna work. I need to do this. There we go. So this is a a little

 

336

00:54:27.310 –> 00:54:38.640

US – Frog Field: interactive vector diagram. I’ll show you the code for it, too, if you want to see it. So this is this is gonna be something in a future blog post about how Katharine works internally to fellow.

 

337

00:54:38.800 –> 00:54:48.240

US – Frog Field: and so it’s generating it’s generating these use, and it is those are becoming.

 

338

00:54:48.300 –> 00:54:55.730

US – Frog Field: And if you look at the bundle size. The as a bundle for this interactive example is 120 kB like, you know.

 

339

00:54:55.920 –> 00:55:00.700

US – Frog Field: this is pretty good, and this is just this is just trunk. Serve dash, dash, release.

 

340

00:55:01.080 –> 00:55:02.230

US – Frog Field: Show you the code.

 

341

00:55:05.890 –> 00:55:11.600

US – Frog Field: I’m not going to go through all of it, because there’s you know there’s a lot of complexity in terms of how we’re actually

 

342

00:55:12.350 –> 00:55:26.930

US – Frog Field: let’s see. Where is the code? Yes, so this is the main app right? So you know it’s initializing. Let me show you the app state. So the app state, all of the app state is stuff like that, you know.

 

343

00:55:26.950 –> 00:55:39.850

US – Frog Field: is is what you’re actually drawing, and then there’s a couple of things to drive. Drive the Ui that there’s these grab states for the you know, for the handles that you can grab. So those are all represented in the app state.

 

344

00:55:40.160 –> 00:55:54.210

US – Frog Field: And then there’s some helpers here that basically handle your pointer interaction. You’re down and moving up and so on, and so forth. And then this is I’ll show you like this is you can see this is not a lot of code. I mean, this is calling, you know, a few other things, and i’ll show you most of it.

 

345

00:55:54.360 –> 00:56:01.470

US – Frog Field: So this is the this is the wisdom binding start. This is actually entry point from your, you know, into the app.

 

346

00:56:01.570 –> 00:56:03.960

US – Frog Field: And so it just initializes the app state.

 

347

00:56:04.040 –> 00:56:09.140

US – Frog Field: And then this is your app logic, which is the function from app state

 

348

00:56:09.150 –> 00:56:15.920

US – Frog Field: to a view tree. So this is. This is a real concrete example of what is the view tree? Look look like.

 

349

00:56:16.040 –> 00:56:26.870

US – Frog Field: and so it’s going to do some computation here. This is all geometry render tile. Msa. A. There’s a lot of complexity there, but all of the Ui stuff is really in this part.

 

350

00:56:27.000 –> 00:56:33.920

US – Frog Field: And so now we have a group which is gonna translate, actually show you like I like showing.

 

351

00:56:34.190 –> 00:56:36.240

US – Frog Field: I like talking that I like showing.

 

352

00:56:37.960 –> 00:56:41.030

US – Frog Field: And so this is what it looks like.

 

353

00:56:41.190 –> 00:56:41.970

US – Frog Field: Right?

 

354

00:56:42.160 –> 00:56:47.220

US – Frog Field: You have a Svg: No, you have an Svg.

 

355

00:56:47.570 –> 00:57:02.600

US – Frog Field: You know element, and then you have all these, you know nodes that are under that. So you’ve got G’s for groups, and then you’ve got all these lines and circles, and so on, and so forth. And and by the way, this circles have classes on them might be able to show you this, that

 

356

00:57:03.530 –> 00:57:16.910

US – Frog Field: Yeah, there we go. Yeah, you seem change. So, you know like it’s it’s updating the classes in order to cause these state changes to I don’t know why it’s being bulky. Did it crash? I might have crashed it, anyway.

 

357

00:57:17.180 –> 00:57:18.940

US – Frog Field: Ignore that

 

358

00:57:19.120 –> 00:57:22.420

US – Frog Field: this all this technology is completely 100% reliable.

 

359

00:57:25.150 –> 00:57:41.530

US – Frog Field: I’ll refresh. How’s that? Ha, ha, ha! Okay, Great. So so what’s so? So you saw what the HTML looks like. You saw what the dom looks like. What is the view tree that generates that? And actually it is, you know it’s the same structure that this group turns into a g node.

 

360

00:57:41.580 –> 00:57:53.040

US – Frog Field: These circles which are that this the handles, You know these endpoints here that it’s drawing. Those are just circles. Those are just turbo circles, and it’s just saying, this is the point right, and this is the radius.

 

361

00:57:53.240 –> 00:58:04.450

US – Frog Field: and you know it’s applying a a Css style to it, and it’s also applying this pointer method which causes these callbacks to happen.

 

362

00:58:04.520 –> 00:58:18.430

US – Frog Field: so that when you click and drag and you can. You can see that all this logic is extremely straightforward, that it’s, you know. If you’re dragging, then you just get the event, and it’s just updating the point, you know, with that event there’s not a lot of complex

 

363

00:58:18.490 –> 00:58:29.150

US – Frog Field: plumbing and and infrastructure in here, and then it’s calling like, you know again, like you want to. You want to be able to factor. You don’t want to have one big giant method that’s doing everything. So you want to have helper functions.

 

364

00:58:29.240 –> 00:58:35.390

US – Frog Field: and those are also like, really, really straightforward. But this is just going through your app state.

 

365

00:58:35.400 –> 00:58:52.770

US – Frog Field: and you know, just iterating through. Well, this one is drawing the grid. So there’s no there’s not a lot of data dependency, but it’s just pushing. It’s just making a ve of lines. That’s all it is right, and you’re just computing what are the coordinates of those lines? And then this is the one that’s actually working from the app state. This is coloring all these these circles

 

366

00:58:52.830 –> 00:59:06.070

US – Frog Field: again. It’s just iterating over this thing that you got computed, and it’s just pushing. It’s just it’s a back of circles, and it’s just pushing a ton of circles and an and it’s wrapping them in a class where the class is.

 

367

00:59:06.330 –> 00:59:12.650

US – Frog Field: you know, is dependent on your data. So that’s it. I mean you’re looking at a few dozen lines of code to drive this Ui

 

368

00:59:14.320 –> 00:59:17.610

US – Frog Field: great, so that’s the demo there?

 

369

00:59:18.280 –> 00:59:22.440

US – Frog Field: Question. Yes, Lynn, can we get. Will a Mike? Yes.

 

370

00:59:22.580 –> 00:59:23.480

US – Frog Field: yes.

 

371

00:59:25.040 –> 00:59:25.630

US – Frog Field: Yep.

 

372

00:59:30.980 –> 00:59:49.840

US – Frog Field: Alright, yeah. I’m just curious. What would be needed to eliminate the input? Lag from this example? Is it like the oh, do you render in? The browser is slow. The input. Lag is because of zoom. If I was looking, if you were looking at this on my screen. You wouldn’t be seeing I haven’t been noticing the input like. Okay, Got it. But thanks for pointing that out, because everybody at home is seeing that

 

373

00:59:52.090 –> 01:00:14.770

US – Frog Field: actually on that note. It also looked like the animation was dropping a few frames here and there. Was that also. Just yeah, that’s just, you know. And you know, if you want to. If you want to come up after and see it on my live you, then then we can do that, and also like. This particular example is not open source yet, but everything else is. And so you’ll be able you. You will be able to run this stuff at home

 

374

01:00:14.970 –> 01:00:16.970

US – Frog Field: very, very shortly as well.

 

375

01:00:19.080 –> 01:00:27.230

US – Frog Field: I just wanted to see. How are you like accessing mouse info like position and click? How do you know when it click happens.

 

376

01:00:27.680 –> 01:00:33.280

US – Frog Field: All right, let’s let’s let’s look at that. Because the the application code for that is super simple.

 

377

01:00:34.900 –> 01:00:40.940

US – Frog Field: And then, if you want, we can go into the implementation under the hood, although i’m not sure. I want to.

 

378

01:00:41.420 –> 01:00:47.180

US – Frog Field: Not sure. I want to spend a lot of time on that right now. Where is it? What’s it? Yeah, no, it makes sense.

 

379

01:00:49.850 –> 01:00:51.410

US – Frog Field: Bump the fonts.

 

380

01:00:53.880 –> 01:01:00.470

US – Frog Field: Yes. So so let me. Let me explain exactly what’s going on here, because it might look a little bit mysterious. So so

 

381

01:01:00.520 –> 01:01:07.460

US – Frog Field: so the circle is this circle. That’s just that’s just a circle. And then we’re putting a class on it.

 

382

01:01:07.700 –> 01:01:12.060

US – Frog Field: And Incidentally, that class. Let me. I think I have to focus the window to show that.

 

383

01:01:12.120 –> 01:01:20.290

US – Frog Field: do you? Do you see the way that it like it gets a little bit bigger when you hover. That’s that’s Css: so that’s just a hover.

 

384

01:01:20.300 –> 01:01:22.230

US – Frog Field: What if you call those things

 

385

01:01:23.620 –> 01:01:29.350

US – Frog Field: pseudo classroom? Yeah. So so that’s being done by Css. For you.

 

386

01:01:29.670 –> 01:01:41.920

US – Frog Field: So then, when you say dot pointer, so this is this fluent style, right? And what it’s actually doing is that it’s creating a wrapper. So the type of this thing I get my types.

 

387

01:01:42.710 –> 01:01:45.370

US – Frog Field: There’s a lot of times you actually get

 

388

01:01:46.030 –> 01:01:58.510

US – Frog Field: well. You can see you can see a little bit that it’s creating. You know that this is calling a function, a method that’s basically taking that circle. Actually, it’s a circle wrapped in class. So it’s a 3 level sandwich that it’s a pointer

 

389

01:01:58.690 –> 01:02:07.370

US – Frog Field: view that has a a class view as a child, and then the class view has the circle as the child.

 

390

01:02:07.740 –> 01:02:09.560

US – Frog Field: So that pointer view

 

391

01:02:09.630 –> 01:02:13.610

US – Frog Field: is saying that I am going to.

 

392

01:02:13.760 –> 01:02:27.950

US – Frog Field: I am going to be attaching mouse interactivity to that node in the view tree. And anytime you get pointer events into that node, it is going to call this call back. So that is a call back that’s a closure.

 

393

01:02:28.270 –> 01:02:45.440

US – Frog Field: and that closure is given. This is another part of the magic of that it’s given mutable access to the app state at that point right? So that’s plumbed by the framework. The framework says, You know, when i’m when i’m dispatching a message

 

394

01:02:45.440 –> 01:02:58.330

US – Frog Field: that i’m going to have mutable access to the app state at the time that i’m dispatching it. So that’s given to the closure. And then this closure is going to take that app state which is S. And it’s gonna call this function.

 

395

01:02:58.390 –> 01:03:04.810

US – Frog Field: you know, on the grab, you know, I have this sort of helper structure which is called Grab State.

 

396

01:03:04.920 –> 01:03:16.910

US – Frog Field: Yeah, that grad state is, which is very simple, I mean, look at it. It’s just tracking, you know, with whether you’re down or not, and then which pointer is being touched in some geometry.

 

397

01:03:16.950 –> 01:03:31.850

US – Frog Field: So that’s gonna call. So basically when you click mouse down, then that’s gonna end up calling into this handle method on this scrap state. And this match arm is going to execute this code, and that code is going to be able. This and and mute self

 

398

01:03:31.910 –> 01:03:42.740

US – Frog Field: is actually getting a well. This this grab state is part of the app state. So it’s mutating when it’s mutating itself. It’s actually mutating that part of the app state.

 

399

01:03:48.470 –> 01:03:57.690

US – Frog Field: So every time, every time you dispatch. So the question was, how does the app state know that it needs to re-render? And the answer is, every time you dispatch a message to the app

 

400

01:03:57.770 –> 01:04:01.550

US – Frog Field: that it potentially needs to re-render after that. So

 

401

01:04:05.150 –> 01:04:06.030

US – Frog Field: Yes.

 

402

01:04:06.120 –> 01:04:22.490

US – Frog Field: that’s correct. So so great question. So the the question is kind of what happens after and what happens after is that you know you call that call back, and it causes the mutation to the app state, and then the framework. So the framework is sort of in charge of the overall sequencing of this stuff.

 

403

01:04:22.490 –> 01:04:31.850

US – Frog Field: The framework is going to call your app logic function, and your app logic function is going to return a new view tree.

 

404

01:04:32.150 –> 01:04:37.950

US – Frog Field: and the new view tree will have the new coordinates. If you’re dragging this point around

 

405

01:04:38.120 –> 01:04:48.590

US – Frog Field: that will have the new coordinates of this point. And I’m actually going to show you, because just to make this a little less mysterious, because all this stuff can come across as like super mysterious.

 

406

01:04:51.780 –> 01:04:54.510

US – Frog Field: I will show you what that code looks like

 

407

01:05:04.670 –> 01:05:05.660

US – Frog Field: too much.

 

408

01:05:12.490 –> 01:05:20.360

US – Frog Field: So the call backs Aren’t registered the call backs are just there, right like the view. So this is. This is subtle.

 

409

01:05:20.500 –> 01:05:38.230

US – Frog Field: but, like the view tree has call back in it. It creates a view tree, and the view tree is all of these nodes in it that can that tell you how to actually render you know what should be rendered. But it has these call backs sitting in it just as fields. Right. So when you have a

 

410

01:05:38.310 –> 01:05:43.880

US – Frog Field: you know, like I I I can actually show you this. I can show you all of the code.

 

411

01:05:44.750 –> 01:05:59.540

US – Frog Field: Well, yeah, you you you when you pass in a closure, then you know you get a new value of that closure every time. But that doesn’t necessarily involve a lot of allocation most of the time. That’s just the function pointer that doesn’t necessarily involve like

 

412

01:05:59.710 –> 01:06:04.600

US – Frog Field: out boxing, and so on. And so forth. You’re not registering it. You’re not like mounting it right.

 

413

01:06:04.770 –> 01:06:09.940

US – Frog Field: And then when you get a message, so if you look, for example, the message implementation

 

414

01:06:10.320 –> 01:06:12.300

US – Frog Field: on a pointer.

 

415

01:06:12.510 –> 01:06:28.390

US – Frog Field: A pointer is interesting. So on the web on the web. What happens is that you’re doing all of these closures that you’re that you’re registering at build. But it turns out that you’re not re-registering those closures at rebuild time you’re actually creating those closures once right.

 

416

01:06:28.480 –> 01:06:38.030

US – Frog Field: and then, when when the closure is invoked when the call back. So this is a javascript call, but this is actually javascript at this point, because of the Javascript Blasm Ridge.

 

417

01:06:38.080 –> 01:06:52.920

US – Frog Field: And so when those when those closures are called, when those javascript closures are called what that’s going to do is that it’s going to push message right? So that’s why you don’t need to keep rebuilding these things, but that the message is always the same.

 

418

01:06:53.090 –> 01:07:01.720

US – Frog Field: But then, when you dispatch the message right. so you get a message that says, hey, Pointer down right? This is the coordinates of that of that point.

 

419

01:07:01.740 –> 01:07:20.660

US – Frog Field: And when you dispatch that message that’s gonna go through the message method of the view trait for pointer, which is gonna go into this code. And then this code is gonna call whichever call back is present of the view that’s in place. So this is sort of the most recent view.

 

420

01:07:20.660 –> 01:07:31.650

US – Frog Field: You get the sequence of views, view trees that are created by the app. And this is the most recent view, and that kind of stays around to handle your messages from your interactivity

 

421

01:07:32.370 –> 01:07:33.130

US – Frog Field: right?

 

422

01:07:35.020 –> 01:07:42.610

US – Frog Field: And then, in terms of updating the Dom. Like this is all very simple code. So this is this is line.

 

423

01:07:42.780 –> 01:07:56.630

US – Frog Field: And so it’s just saying, let’s create a Dom element for that line, and let’s set the attributes that’s build. So this is just as straightforward as you could possibly imagine, like, create the dominance of the attributes.

 

424

01:07:56.690 –> 01:08:11.440

US – Frog Field: And then, when you look at, rebuild. This is where the diffing is happening, and saying, If any of these values are different, if the self value, the current value is different than the previous value. Then we’re going to set an attribute, and we’re also gonna we’re also going to be some change tracking on our side

 

425

01:08:11.530 –> 01:08:21.420

US – Frog Field: that something changed. How does it know which element is attached to each view? If you could like drastically change the view between state

 

426

01:08:21.439 –> 01:08:37.630

US – Frog Field: and the answer to that? So there’s actually an entire talk on Swift Swift. You I call like demystifying Swift. Ui, which talks. It’s the the the short answer is that it’s associated types. Right that you have the the element. Tree is an associated type of the view tree.

 

427

01:08:37.760 –> 01:08:41.130

US – Frog Field: and so, if it’s the if the view tree has the same structure.

 

428

01:08:41.180 –> 01:08:45.880

US – Frog Field: then the element tree is parallel to it, because it’s it’s derived as an associated type.

 

429

01:08:47.200 –> 01:08:59.189

US – Frog Field: It’s subtle and as I. If you really, if you want to find out more than the swift you I talk on that actually spends the half hour answering it in detail.

 

430

01:08:59.600 –> 01:09:07.680

US – Frog Field: because this mechanism I didn’t invent this this mechanism is, is is adapted. I don’t want to say stolen

 

431

01:09:07.899 –> 01:09:11.319

US – Frog Field: It’s adapted. Great artists adapt

 

432

01:09:11.660 –> 01:09:14.069

US – Frog Field: inspired by

 

433

01:09:14.240 –> 01:09:16.170

US – Frog Field: strongly inspired by

 

434

01:09:18.399 –> 01:09:21.529

US – Frog Field: other questions. Yeah, I’m: happy to this is a conversation.

 

435

01:09:22.340 –> 01:09:25.890

US – Frog Field: Yeah, I have a question about the mutable state.

 

436

01:09:26.140 –> 01:09:38.229

US – Frog Field: so I have a a use case in mind, and I want to make sure I understand how the pieces would come together. These cases load some data from a server, and then patch that data into the state mechanism here.

 

437

01:09:38.500 –> 01:09:46.160

US – Frog Field: Now, from the code I saw like the pointer handler the mutable state passed in is that where you might perform that network?

 

438

01:09:46.410 –> 01:10:04.030

US – Frog Field: A request? Yes, so when you’re dealing with Async. So there’s a there’s a blog post that has been in the queue for a year, and I need to just finish writing it and publish it, because that will talk about the Async story in more detail. But the short answer is, Yes, it looks very similar.

 

439

01:10:04.070 –> 01:10:20.470

US – Frog Field: There is a view node, so there’s a node in the view tree which is responsible for sending that network request. And then the the fancy part is that that each node kind of has its own, its own executor, right?

 

440

01:10:20.470 –> 01:10:36.110

US – Frog Field: So when that when that network request comes back and there’s a wake event that happens through the you know, through the kind of rest asing stuff that notifies the the view, and so that triggers the whole re-rendering cycle.

 

441

01:10:36.110 –> 01:10:55.040

US – Frog Field: And it’s actually tracking like how many of the requests that have been sent. It’s counting how many requests have been sent that haven’t come back yet, so you can make a decision about. Do I want to do it sort of synchronously? Or do I want to show a you know? Do I want to show a a a state that it’s, you know.

 

442

01:10:55.340 –> 01:11:07.590

US – Frog Field: still in flight. Could we go back to the code you were showing with the like, the dot handle function. Dot and another. Yeah, I think I know you.

 

443

01:11:08.280 –> 01:11:10.260

US – Frog Field: I know which one you want to see

 

444

01:11:11.870 –> 01:11:12.720

US – Frog Field: this one.

 

445

01:11:13.810 –> 01:11:17.270

US – Frog Field: That guy. Yeah. Yeah. So so my understanding

 

446

01:11:17.430 –> 01:11:31.710

US – Frog Field: that that is that mutable borrow is more or less exclusive, and as long as this method is running, nothing else can can touch that. That is exactly correct. Yes, okay. So my naive understanding of looking at this was in a case with that network request.

 

447

01:11:31.860 –> 01:11:47.480

US – Frog Field: More or less, the entire thread would block. The program would block Well, it’s not blocking so. So if there’s a network request, then that’s Async rest. Right? So so those requests go, and you can have as many of them in flight as possible. Now, when those land, when those futures actually resolve.

 

448

01:11:47.480 –> 01:11:59.760

US – Frog Field: then the resolution of those features is going to be in a queue, there’s actually going to be internally a queue, and it’s gonna apply them in order, and it’s going to give mutable access to those in order, as those resolve.

 

449

01:11:59.820 –> 01:12:05.570

US – Frog Field: So if those State updates were super expensive. That might be a problem.

 

450

01:12:05.600 –> 01:12:25.340

US – Frog Field: But if you’re blocking on the network, then the State update hopefully is just like, yeah, I got my result. Just set the results to this new value. But the you know the network request, and you cannot. It’s not just the network request. You can do expensive work like I want to do things like image decompression, and even text layout and stuff like that in work or threads.

 

451

01:12:25.340 –> 01:12:39.850

US – Frog Field: I mean, this is part of the goal. I do not want my Ui to be. you know, pretending that it’s running on a one core computer right? Makes sense. I was curious about this in particular, because I’ve been working on a similar.

 

452

01:12:39.960 –> 01:12:53.020

US – Frog Field: I guess it it felt similar, this mutable state thing. Yeah, how? How you can share access to that yeah, Sounds like the executor kind of behind the scenes is doing a lot of that. Yes, that is correct. Yes, there’s an executor behind the scenes. That is, that is

 

453

01:12:53.200 –> 01:12:57.910

US – Frog Field: sequencing things. Sure. great

 

454

01:12:57.980 –> 01:12:59.850

US – Frog Field: great questions. Yes.

 

455

01:13:00.880 –> 01:13:02.540

US – Frog Field: we for Mike.

 

456

01:13:03.690 –> 01:13:04.290

US – Frog Field: Yep.

 

457

01:13:07.240 –> 01:13:13.810

US – Frog Field: So in that, as in case how are you like? Is there a Async version of handle like, are you? How does the

 

458

01:13:13.820 –> 01:13:27.150

US – Frog Field: future get to the executor? I’m not that’s another talk. Another blog post I’ll keep. Keep. Consider this to be a request to actually get that blog post published.

 

459

01:13:28.210 –> 01:13:29.890

US – Frog Field: cause I got more to talk about tonight.

 

460

01:13:31.750 –> 01:13:44.910

US – Frog Field: And so so I was promising, you know, like I gave you the demo of this thing, rendering on a web browser inside a web browser using Dom. And I also promise that i’m going to show you how it renders in native rendering.

 

461

01:13:44.910 –> 01:13:53.060

US – Frog Field: and that is going to be rendered, and I should, before hyping it up too much that this I was actually working on it today, and it is not finished.

 

462

01:13:53.090 –> 01:13:55.020

US – Frog Field: but I will be able to show you something.

 

463

01:13:55.540 –> 01:14:13.200

US – Frog Field: But the the render Velo is a is a super exciting project. But this is a high performance Td. Render, and that it is designed to be the next generation of 2D renderers. And so it is designed to have a rich imaging model that encompasses pretty much everything that you want to do in a a Ui.

 

464

01:14:13.200 –> 01:14:29.600

US – Frog Field: so it’s very heavily focused on paths stroking and filling it does lift, runs for text, you for brushes. You have solid colors, gradients. You can use images as a brush. It does clipping. It does all of your blend modes, your exclusions and your differences.

 

465

01:14:29.690 –> 01:14:37.490

US – Frog Field: and it does that find transformations. and it’s implemented. The implementation is very interesting. It’s a pipeline of compute shaders.

 

466

01:14:37.590 –> 01:14:41.800

US – Frog Field: and we did have our own bespoke Gpu infrastructure for it.

 

467

01:14:41.860 –> 01:14:54.680

US – Frog Field: But as I mentioned that we decided to join forces with web, gpu and on Rust, W. Gpu. And so all of these stages are implemented as shaders written in Wigsol, the the Web Gpu Shader language.

 

468

01:14:55.270 –> 01:15:12.710

US – Frog Field: So that’s just a quick introduction. You can go to the Velo Repo, and there will be, I promise, a lot more information coming out about the details available in the coming months. I wanted to talk about. How do you do rendering in xylm and kind of like? How do these 2 pieces fit together in a nice way?

 

469

01:15:12.910 –> 01:15:18.760

US – Frog Field: And the thing. That is the kind of the magic sauce. I think that’s really interesting is that

 

470

01:15:18.920 –> 01:15:30.630

US – Frog Field: in this xylum framework, when you have an element, node that contains a scene fragment. So this is another part of the fellow architecture that you that you build the scene like in a classic 2D rendering thing.

 

471

01:15:30.650 –> 01:15:41.530

US – Frog Field: You have a rendering context, and you have all these mutable methods that you call the All these methods that basically mutate the graphics state and that forces a single thread act that’s similar to the same questions.

 

472

01:15:41.570 –> 01:15:51.050

US – Frog Field: And in Velo you you generate these scene fragments, and one of the explicit goals here is that you could be generating different fragments of the scene in different threats.

 

473

01:15:51.570 –> 01:15:58.220

US – Frog Field: But the but specifically one of the things that I think will make the performance much more interesting

 

474

01:15:58.280 –> 01:16:10.460

US – Frog Field: is that if you are not updating an element, right, if that element is the same appearance that it was the previous time around, then you just hold your scene fragment you. You encode that scene fragment once.

 

475

01:16:10.520 –> 01:16:13.130

US – Frog Field: and you just hold it in the element.

 

476

01:16:13.300 –> 01:16:28.480

US – Frog Field: and so you don’t need to re-encode it even when you’re scrolling. Even when you’re changing the transform the clip path, you can animate things like the blend mode and the group capacity and everything sort of under that in the tree you can just hold on to that, to that in pre encoded value.

 

477

01:16:28.560 –> 01:16:48.020

US – Frog Field: So the the overall goal I mean this is details. But the overall goal is You’ve got this extraordinarily powerful gpu that’s sitting there able to do astonishing amounts of work in parallel, and so anything that you can do on the gpu you do on the Gpu, and you try and make the amount of work on the CPU

 

478

01:16:48.020 –> 01:16:52.200

US – Frog Field: to get that encoded, and get that rendered as absolutely minimal as possible.

 

479

01:16:53.250 –> 01:16:56.490

US – Frog Field: All right. So as promised.

 

480

01:16:56.760 –> 01:16:58.580

US – Frog Field: I will show. I don’t know.

 

481

01:17:00.450 –> 01:17:04.000

US – Frog Field: and i’m more than a little nervous here.

 

482

01:17:05.370 –> 01:17:07.130

US – Frog Field: because you know.

 

483

01:17:10.890 –> 01:17:12.180

US – Frog Field: Great. Okay.

 

484

01:17:12.750 –> 01:17:14.870

US – Frog Field: So let’s see.

 

485

01:17:16.720 –> 01:17:18.680

US – Frog Field: No, I need to type with

 

486

01:17:20.270 –> 01:17:22.950

US – Frog Field: yeah creates.

 

487

01:17:24.320 –> 01:17:28.100

US – Frog Field: you know, I should have had this pre count. But I didn’t.

 

488

01:17:29.040 –> 01:17:30.310

US – Frog Field: Yeah, let me do that.

 

489

01:17:45.660 –> 01:17:54.240

US – Frog Field: There we go. So this is not going to be the same demo. I wish I I wish I had had everything done. This is sort of test stuff that’s that’s in flight. But

 

490

01:17:54.450 –> 01:18:05.600

US – Frog Field: you know I just got the interactivity wired up through buttons instead of mouse. But you know it’s very simple. but it’s actually drawing vector shapes.

 

491

01:18:05.910 –> 01:18:20.530

US – Frog Field: And let me show you Code, because I think that makes it sort of more interesting that again, you will be able to see the kind of clean correspondence between the

 

492

01:18:21.180 –> 01:18:26.750

US – Frog Field: there we go. So this is this is the code don’t need to sign into Github

 

493

01:18:28.380 –> 01:18:44.610

US – Frog Field: a little bit more screen space. Yeah. So this is the entire code for the for the demo that you’re seeing. And so you know, the launcher app launcher is just a couple of lines of code. And then you’ve got this graphic state, which in this case is just a very simple thing. Just a ve of circles

 

494

01:18:44.660 –> 01:18:52.590

US – Frog Field: and a an index of what is the current circle. And then the rendering of that is again about the simplest code that you can imagine that.

 

495

01:18:52.630 –> 01:19:05.690

US – Frog Field: And so it’s got both buttons. It’s got both user interface and it’s got this Vg: node. So you basically have. This is also an application on Zealand core being generic. But there are 2 different view node types in the system.

 

496

01:19:05.820 –> 01:19:24.970

US – Frog Field: There’s a sort of a ui node, which is things like V. Stack, h stack, button, and also vg. And then inside, vg. Their vector graphics nodes, and so there’s a group, and then there’s these circles. And so the as I say, this is still very much work in progress. I just pushed this branch.

 

497

01:19:25.010 –> 01:19:27.730

US – Frog Field: I think, around 5 Pm. This evening.

 

498

01:19:28.030 –> 01:19:39.500

US – Frog Field: and but the the goal is so what you have currently implemented, there’s a another thing that you might notice is that colors are concrete instead of css files.

 

499

01:19:39.680 –> 01:19:53.550

US – Frog Field: So this is all sort of an early rough version of what you’re seeing, but the idea of a circle just being a Turbo circle. This is common between the 2, and as this progresses. The goal is

 

500

01:19:53.550 –> 01:20:08.630

US – Frog Field: that you would be able to write this function once, or you’d be able to look at that function that I showed you 15 min ago, and just run that. Just do you know, Basically, say trunk, serve, and it’s on a your web browser or cover run, and it’s rendering natively

 

501

01:20:09.050 –> 01:20:16.660

US – Frog Field: so again early rough. But there is something that shows up on the screen.

 

502

01:20:18.020 –> 01:20:19.150

US – Frog Field: So i’m almost done.

 

503

01:20:19.540 –> 01:20:29.100

US – Frog Field: I did want to talk about a couple of things that are sort of other interesting projects that like this pattern of having something that is

 

504

01:20:29.240 –> 01:20:40.790

US – Frog Field: both native and web that is not just shipping a web browser natively, or, you know, rendering to a low, level surface. There are not that many things out there that do this.

 

505

01:20:40.790 –> 01:20:50.360

US – Frog Field: And so one example, one of the few examples that’s out there that does have this pattern is react Native Svg and react the react. Ecosystem is innovating a lot in this space.

 

506

01:20:50.440 –> 01:21:06.140

US – Frog Field: And so they are taking the Sbg notes. They are taking very similar code that you would write in Javascript react that you would deploy in a browser, and then they are implementing that with native vector graphics renderers. So I I would count that as like very direct inspiration.

 

507

01:21:06.160 –> 01:21:11.390

US – Frog Field: And another thing that’s happening in this space. That’s very interesting is that there’s this dioxus project.

 

508

01:21:11.430 –> 01:21:23.040

US – Frog Field: and they have as their kind of story. For how are we going to deploy d access applications on native. They have a blitz renderer which is under the dial access labs Github organization.

 

509

01:21:23.130 –> 01:21:32.160

US – Frog Field: which uses the D access virtual Dom as that sort of interface layer between the element tree and the the active layer on top.

 

510

01:21:32.430 –> 01:21:46.210

US – Frog Field: But again, if you go to Blitz, you’ll see that. like they want to be driven by lptos as well. They don’t wanna it’s not specific. It’s not bespoke to to to Dioxide, so I think that’s very interesting.

 

511

01:21:46.590 –> 01:21:53.850

US – Frog Field: And then there’s also another project that’s similar to Blitz, although it it’s not quite in the same category, because this is called Freya.

 

512

01:21:53.900 –> 01:22:01.400

US – Frog Field: Frey is not actually trying to be compatible with the web. You’re not there, Don’t. Have the explicit goal that you write your code once and to play the same code.

 

513

01:22:01.520 –> 01:22:05.770

US – Frog Field: both on web and native. It’s more like it, share some of the same infrastructure.

 

514

01:22:07.110 –> 01:22:07.880

US – Frog Field: So

 

515

01:22:08.380 –> 01:22:16.190

US – Frog Field: you know, I said early in the talk, that this is a science project, and like, if you’re really doing science. You need to be thinking about what hypotheses are we testing?

 

516

01:22:16.810 –> 01:22:22.320

US – Frog Field: And there’s 2, I think, that are key to this, to this work. and the first is.

 

517

01:22:22.590 –> 01:22:32.680

US – Frog Field: you know, like I’ve I’ve talked about these 4 tribes, and I’ve kind of presented them as roughly equal, you know, of all being very viable alternatives, I mean, there’s a lot of shipping

 

518

01:22:32.810 –> 01:22:35.650

US – Frog Field: a Ui code in each one of those 4,

 

519

01:22:35.770 –> 01:22:49.940

US – Frog Field: but none, of course, Yet in Zealand, Zealand is still this very early prototype, and we I I personally am consumed with curiosity. It’s like, I think Xylm will hold up very nicely compared with by access and laptos.

 

520

01:22:50.080 –> 01:23:02.330

US – Frog Field: But is that true? And so I want to find out the answer to that. And like when I say good like, you know, there’s a lot of evaluation criteria that you might use. There’s the conciseness of the code, and I hope I’ve showed you

 

521

01:23:02.410 –> 01:23:03.510

US – Frog Field: that you know there’s

 

522

01:23:03.540 –> 01:23:15.140

US – Frog Field: that code does not have a lot of fat on it, you know. There’s no context that you’re threading around there’s no Macros where you’re hiding all the complexity under the under the hood that is as close

 

523

01:23:15.290 –> 01:23:22.310

US – Frog Field: as I can imagine, to the natural way of expressing that in rust. So I think, on conciseness we’re going to do pretty Well.

 

524

01:23:22.480 –> 01:23:40.950

US – Frog Field: performance is another really good question, and that includes multi-threading. Are we really going to be able to do useful work on all these different threads? Expressiveness like these are like so far. What you’ve seen are these toy examples. Is this going to scale to like real, interesting things where you’ve got non-trivial interactions between the components. Right?

 

525

01:23:40.950 –> 01:23:50.600

US – Frog Field: We don’t know yet. And you know, overall ergonomics right? Are people gonna be cursing and pulling their hair out? Or are they going to be saying, Wow! This really is doing what I hope it can be done.

 

526

01:23:51.230 –> 01:24:00.550

US – Frog Field: Most of these criteria we can test in a web context, right? Not that reduces the variables like you’re you know there’s so many other variables in terms of

 

527

01:24:00.620 –> 01:24:11.870

US – Frog Field: how things are being rendered, and what’s of you know what’s been implemented, and what Hasn’t been implemented yet. But if you’re on web, you can say, okay, you’ve got the whole Dom whole web under you, and you can test most of these things.

 

528

01:24:12.020 –> 01:24:15.390

US – Frog Field: with the exception of testing multi-threaded performance.

 

529

01:24:15.650 –> 01:24:27.320

US – Frog Field: But right now, like this is a hypothesis to test that I again like I I wouldn’t be spending so much time on, and if I didn’t think it was promising, but we don’t have any evidence yet.

 

530

01:24:28.320 –> 01:24:35.930

US – Frog Field: The second hypothesis to test is like the motivation for this work, like. If you didn’t care about performance, you would just use electron right?

 

531

01:24:37.670 –> 01:24:51.020

US – Frog Field: So how much performance is possible, how how much faster, how much more through fit, how much less latency, all of these startup time is another. There’s actually like performance is not just one thing. There’s a lot that you care about.

 

532

01:24:51.110 –> 01:24:59.020

US – Frog Field: And so for each one of those performance criteria that you care about. you know how much better are we going to do than the web. And again, I’m really excited

 

533

01:24:59.040 –> 01:25:14.690

US – Frog Field: like this is more straightforward, like some of those criteria and the previous one. Some of them are a little fuzzy like ergonomics. How do you feel about it? Right? And the problem with that is that a lot of it? Well done the familiarity. If you’ve spent 2 years, you know, writing react.

 

534

01:25:14.690 –> 01:25:27.950

US – Frog Field: and then you’re given another model which is more based on swift Ui, and you’re not familiar with it. It’s going to feel less. But this performance stuff is pretty objective. And so we, basically, you know, want to find out like

 

535

01:25:28.030 –> 01:25:36.380

US – Frog Field: when I say Dom and Css are slow, like, how much faster are you going to be if you’re just accessing that directly, instead of going through those layers?

 

536

01:25:36.460 –> 01:25:53.460

US – Frog Field: How much multi-threading are you gonna get? And this Velo render when you’re doing this, Gpu accelerated 2D. Rendering. How much faster is that going to be, and going through whatever you know? And again, even on the web. You have this choices. You can go through HTML. 5 canvas. You can go through Svg.

 

537

01:25:53.460 –> 01:25:59.330

US – Frog Field: But you know how much faster can you go if you have this sort of direct access to the to the Gpu.

 

538

01:25:59.770 –> 01:26:03.670

US – Frog Field: So really. this is the call to action.

 

539

01:26:03.710 –> 01:26:23.280

US – Frog Field: I want to enlist my fellow scientists in helping on this science experiment and getting the answers to these hypotheses. Because I I really want to know the answers. And so you know that’s really what I think. Some of the next steps are on. This work is to do some of these experiments to build out, to kind of

 

540

01:26:23.290 –> 01:26:26.220

US – Frog Field: take the seed and build more of it out.

 

541

01:26:26.370 –> 01:26:40.260

US – Frog Field: I am personally not going to have the time to build out the web side of this myself. I am my day Job is working on, fellow, the 2D vendor and I. I need to be spending most of my time on that.

 

542

01:26:40.460 –> 01:26:43.550

US – Frog Field: But I did right. If you click on this link.

 

543

01:26:43.960 –> 01:26:47.120

US – Frog Field: this will come to an issue that I wrote this morning on the bus.

 

544

01:26:48.800 –> 01:26:50.240

US – Frog Field: And

 

545

01:26:50.650 –> 01:26:54.540

US – Frog Field: why is it taking long? There we go. Yeah, it’s just slow

 

546

01:26:54.960 –> 01:26:56.210

US – Frog Field: web.

 

547

01:26:58.010 –> 01:27:09.040

US – Frog Field: And so so this is. These are the detailed issues of kind of what what is gonna have you know what what would happen next if you wanted to build Zealand core out into a more full, featured

 

548

01:27:09.170 –> 01:27:12.720

US – Frog Field: thing that you could actually use to, maybe build real

 

549

01:27:12.760 –> 01:27:15.040

US – Frog Field: build, real web applications.

 

550

01:27:15.110 –> 01:27:21.050

US – Frog Field: and, you know, like so, for example, there’s a whole thing in there about the Async, and that has, you know, links to other.

 

551

01:27:21.100 –> 01:27:24.860

US – Frog Field: This is the draft blog post that I was talking about. You know there’s an outline.

 

552

01:27:26.380 –> 01:27:33.590

US – Frog Field: and so you know, so that’s a a large part. It’s like I would love to have a collaborator. So if I don’t get a collaborator.

 

553

01:27:33.720 –> 01:27:49.350

US – Frog Field: it’s fine. The work will happen, but on an incredibly slow pace. But I think there’s a potential for it to to go faster if we get more people working on it. So yeah, and then you know the the lowest levels of the stack. The 2D rendering is something that

 

554

01:27:49.460 –> 01:28:03.410

US – Frog Field: you know that I think that this has been making great progress, and it’s got great velocity. I’m not going to make a promise about when I think it’s going to be ready for real use. But I will say that it is a priority it is. It is something that is on our roadmap for sure.

 

555

01:28:03.770 –> 01:28:15.140

US – Frog Field: And then, if you do want to get involved, obviously you can talk to me. But there’s a lot of really good starting points here a lot of resources. We just started this line vendor org webpage. It has a list of all the projects.

 

556

01:28:15.170 –> 01:28:26.450

US – Frog Field: and you know pointers to other resources like the Zulip instance, and so on, and so forth. I will link, I don’t have, yet I will link the slides so that all these links that i’m asking people to click

 

557

01:28:26.480 –> 01:28:34.310

US – Frog Field: are also going to get linked through there and then we have a Zulip instance. There’s really excellent discussion that happens there, and everybody is welcome.

 

558

01:28:34.340 –> 01:28:42.160

US – Frog Field: And then we also have we’re. We’re not advertising this like on social media and stuff widely. But if people are interested.

 

559

01:28:42.240 –> 01:28:48.880

US – Frog Field: and they are welcome to show up at our weekly office hours, which are currently 8 am. On Thursday, California. Time

 

560

01:28:48.980 –> 01:28:57.270

US – Frog Field: and again there’s a a real, really tight knit community that’s forming and really good discussions that happen at those. All right.

 

561

01:28:58.800 –> 01:29:00.040

US – Frog Field: ask questions.

 

562

01:29:08.690 –> 01:29:10.060

US – Frog Field: Yeah.

 

563

01:29:10.090 –> 01:29:11.530

US – Frog Field: here.

 

564

01:29:11.750 –> 01:29:29.330

US – Frog Field: So you you showed us this app States trucks, and how you can store the state of your application in there? Can I still break down my application in components and do things Where, for example, I have a button which, when hover, has a slightly different background color. But I don’t want to

 

565

01:29:29.450 –> 01:29:41.020

US – Frog Field: think about it when building my application. I just care about the click. Sure, that’s a really good question. So yes, the answer is Yes, that part of the Zile architecture is that the app State type

 

566

01:29:41.030 –> 01:29:59.220

US – Frog Field: can be different for different parts of the application. And there’s a view node called adapt, which is basically, something that you know, the node has one type, and the child has a different type, and then you get callbacks that are able to like kind of project. It’s it’s actually a lot like a lens. If you’re if you’re used to functional programming.

 

567

01:29:59.220 –> 01:30:09.560

US – Frog Field: that I kind of projects that outstate into a single field and can also apply logic as necessary. So the goal is that it absolutely will be able to support that kind of component architecture.

 

568

01:30:09.750 –> 01:30:10.380

US – Frog Field: Okay.

 

569

01:30:12.250 –> 01:30:13.520

US – Frog Field: take just 2 more questions.

 

570

01:30:16.530 –> 01:30:17.650

See him after

 

571

01:30:17.890 –> 01:30:19.680

US – Frog Field: my question was.

 

572

01:30:19.900 –> 01:30:41.910

US – Frog Field: How is the compilation performance. And do you expect that to also scale well to larger applications? That’s one of our bigger challenges.

 

573

01:30:41.910 –> 01:31:01.300

US – Frog Field: and the elementary is where all the really grungy stuff happens like a lot of logic that has to be represented. And so the idea is that hopefully you can compile your elementary like once, and as your app scales, you’re not recompiling more and more instances of it. That was one of the flaws in drew it

 

574

01:31:01.320 –> 01:31:05.170

US – Frog Field: that drew it had everything kind of, you know, the type

 

575

01:31:05.650 –> 01:31:07.980

US – Frog Field: basically force, monitorization

 

576

01:31:08.110 –> 01:31:15.110

US – Frog Field: of everything. So the idea is the view tree you are going to get recompiled is is going to get monomorphized.

 

577

01:31:15.120 –> 01:31:26.530

US – Frog Field: The hope is that the logic of the view tree is so much simpler. It’s so much less of it. It’s not doing. you know, layout and text rendering and internationalization and all that stuff.

 

578

01:31:26.590 –> 01:31:27.700

US – Frog Field: So i’m hopeful

 

579

01:31:29.360 –> 01:31:35.220

US – Frog Field: it is. It is a problem in swift ui, though, and so it is something to watch.

 

580

01:31:36.460 –> 01:31:52.870

US – Frog Field: So i’m just curious if what the story is for fine-grained reactivity, something like solid Js or mobex if there’s any way that that could get integrated into Zylum, and what that would look like, what mechanisms are needed if you would need like a change to the language itself, like a new view function, keyword.

 

581

01:31:53.120 –> 01:32:02.380

US – Frog Field: So that’s a that’s a also a really excellent, spectacularly good question, and one of the motivations, like kind of the original motivation of xylum.

 

582

01:32:02.470 –> 01:32:08.090

US – Frog Field: Even before it evolved into its current state, was to be a kind of a

 

583

01:32:08.250 –> 01:32:17.550

US – Frog Field: component architecture where your different components could be built in very different paradigms, so like one of the original goals, was to support scripting in Python

 

584

01:32:17.750 –> 01:32:18.540

US – Frog Field: right?

 

585

01:32:18.690 –> 01:32:26.280

US – Frog Field: And so the when you actually look at the details of the view trade, right? So. So part of it is like, you know I talk about diffing.

 

586

01:32:26.600 –> 01:32:28.020

US – Frog Field: You don’t have to diff

 

587

01:32:28.100 –> 01:32:40.900

US – Frog Field: like the view trade. The definition of the Xylom architecture is whatever implements the view trade. So if the view trade wants to diff, you know declarative States, and it can do that, and that is great, and it will be ergonomic.

 

588

01:32:40.920 –> 01:32:59.310

US – Frog Field: But if if you trade, you know, if the view itself wants to be like a queue of deltas that got, you know, maybe filled by some sort of fine grain reactive mechanism. Then, when you call the rebuild method, you know, then it’s instead of like this thing. It’s like, Take this queue, and apply that to this mutable elementary that I now have mutable access to.

 

589

01:32:59.610 –> 01:33:03.340

US – Frog Field: So I am hopeful. But I think that

 

590

01:33:03.470 –> 01:33:19.340

US – Frog Field: you know, in order to figure out how well this works really is going to take a lot of exploration, and you know it’s not obvious, but it but it was part of the original goals. It was part of the original scope. So I think there’s reason to be hopeful.

 

591

01:33:20.160 –> 01:33:21.320

US – Frog Field: Thanks. Yeah.

 

592

01:33:24.400 –> 01:33:35.090

US – Frog Field: yeah, one to let let some time for people to network and talk individually to rates. So after this, if your questions just come to raise you, should you should be around for a while longer.

 

593

01:33:35.340 –> 01:33:38.430

US – Frog Field: And yeah. Thanks. Oh.

 

594

01:33:45.200 –> 01:33:45.930

US – Frog Field: yeah.

 

595

01:34:04.280 –> 01:34:05.260

US – Frog Field: 17

 

596

01:34:12.260 –> 01:34:13.720

US – Frog Field: congratulations.

 

597

01:34:29.360 –> 01:34:37.780

US – Frog Field: All right. Well, I think we’ll stop the recording. So thanks Every thanks so much to everybody for coming. Thanks for the excellent questions, and, thanks to Jay Frog for hosting.