So I'm like, I'm pretty happy with that and it basically means, I think what it means effectively is that we get to build something that is like solid. It has the same semantics solid but it is just happening inside of React fully within the semantics of React and interleaving just fine with React. I think that's pretty cool. And I think like what is awesome, I think in general what makes me like working on it is that the promise of React is kind of like, oh, you basically wrote the function as if you wrote it one time and then it like magically updates for you. But at some point you're not, like when you get deep at the hook land, you're no longer writing like the ORM you would have written on the server, you're writing some very specific React thing and it's complicated and hard. And like what I like about this and what I want for a start to begin, like what makes me happy is it gets you back that again, right, you can basically go, like if you look at the implementation of, for example, the users object, like what is, yeah, there's a resource here, but it's like a map, like you could literally have written this in, you could literally have written this in a node thing and it would make sense, it just wouldn't be Reactive, right, but now it is.
Okay, I think one last thing I wanna say here is, the resource API as I'm using it here is kind of going with the grain on how the ecosystem is doing stuff. However, now that's stage three decorator have landed, I intend to like, it's on the docket for me to implement a class-based version of all these APIs and there's a lot of cases where it's very nice. So like, I'll just show an example. So here we have a, where is, I don't actually have a great example in this case, but basically if you were going to put a cell somewhere, then you would be able to write like something like at reactive like user colon like equals something like colon users, like, and that basically that behind the scenes would make a cell for you and make a getter that reads from the cell and have a setter that writes itself. And I just find like personally, I sometimes like, like as you can see, I made a class here, it's not like you can't do it, but you end up having to do a little long end here and there's a, you get a nice set of behaviors if you can write decorators and I plan to do that. So it's not because I don't have an opinion, like I don't wanna put my thumb on the scale about which is better, I think I like what we did with this design. Like I like the fact that you, like this is pretty good. Unlike React it gives you the stable values blah, blah, blah but I like it, but I also like being able to use classes more ergonomically and that's coming.
Okay, I think I've covered everything. I don't know who MD is, but do you have any questions before I go? I don't know, do I have to, I might have to unmute you or I don't even know how that works. Do not follow that one. That. Okay. I see, you said. So StarBeam is just an API that fetches JSON data. That is not quite it. It's a StarBeam is an API that lets you create APIs that fetch data. But like, I think the important part is like, if you were going to write your own fetch logic, right. You write fetch logic and then you put it somewhere. And I started from the very beginning of like showing you, okay, you could put in a cell, you could build up abstractions from there. So that's the answer for what to do with it. I think it would be cool if people built like ORMs and stuff around it. There's some stuff in the repo, like there's something called StarBeam store that is just a tiny little store that has filtering and stuff like that. Yeah, I think that's what it is. I think in terms of Visual Studio, there's nothing to stop. It's like I need a release the packages. So there's packages that are already on MPM, but they aren't the API I just showed you completely. There's some changes. Once I released the package, it's just an MPM package. And we just like, what's happening? If you look at the code, it's like you are doing this. Assuming that Visual Studio has some of the same IntelliSense and TypeScript support that VS Code has, I think it will just work. Ah, okay, you don't use React. Okay, so I didn't cover that because that was not what I said in the tutorial. But the way StarBeam works is that this code, so this code we call universal code, not this code. So this code and this code, all the code that doesn't say anything about React, we call universal code. And universal code is just reactive code that describes everything. It has resources, it has lifetimes and everything, but it doesn't refer to any specific framework. And the way that you glue it into a framework is something called the renderer. So I spent a bunch of time showing you the React renderer. There already is a Preact renderer, and the Preact renderer works the same way, but doesn't make you type, use Reactive all the time, basically. There's also a view render in the repo, view.js, and there is a, there's a spell renderer that we built a long time ago we need to refresh, coming pretty soon also. But the basic idea is that you, like, the right way to use Starbeam is you, like, learn how to build this kind of code really well, you just think about everything, mostly in terms, like, you can build a whole data library without ever thinking about React, React, view, spell, whatever. And then when you're ready to use it, then you just say, like, use, blah, blah, blah. Like, you'll just go, like, like, here you're going to say, use Reactive or use resource.