Fast Functional Reactive Programming with Datastar Creator Delaney Gillilan

**Delaney Gillilan** (0:00)
Your job as a web developer, most of the time is to get strings to the browser as fast as possible. And that's because the browser is going to parse that faster because if you basically have a special class, which is like anything that the browser does with DOM parser or with like built-in functions, it's like regex, the JSON parser, all that, it's orders of magnitude faster than what you get in the JS world. So your job is to get as much into their hands as fast as possible. And if you have something that's local, you have to like minimize the amount of JavaScript you're doing. So things like reactive signals and all that stuff. So basically what Datastar is all about is making these plugins that anybody can use, but we ship with plugins that do the fastest version of morphing, by like 10x faster than what's currently in HGVAC. We have the fastest signal library in the world right now too. So like just do the things to get things in the place correctly. But the thing is they want to be in the language of your choice. The problem is the language you have is just a bunch of declarative strings. Like that's what the actual interface is, is the browser has an interface and it is just a pile of strings. That's the reality.
Welcome to Software Unscripted. I'm your host Richard Feldman. Today I'm talking with Delaney Gilroy, creator of the Datastar library for doing high performance hypermedia focused web development. We talk a lot about performance both inside the browser and outside it, as well as functional programming, JavaScript library culture, and how both technical and non-technical constraints end up influencing seemingly unrelated technical decisions. I want to give a massive thank you to everyone who's, thank you to Mailtrap for sponsoring this episode of Software Unscripted. If you don't know Mailtrap or you only know them for email testing, they are a modern email delivery system for developers. They support things like straightforward integration in your code with native SDKs, or they have a security compliant API and also SMTP access. In their freeze here, you get 4,000 emails monthly, so it's pretty easy to try out. And they also have 24-7 support where you would talk to real humans, not AI chatbots. If that's the type of thing you're interested in, as you do email delivering at your business, check out mailsrap.io to learn more.
All right, Delaney, thanks for joining me. Yeah, thank you. Okay, so you made this framework that somehow I had not heard about until very recently called Datastar. And the thing that stood out to me as cool about this is that it seems like, correct me if I'm wrong, it seems like your design principle behind creating this was to work backwards from what is the fastest way you can get stuff done in the browser to, like can I put an API on top of that, as opposed to starting with what are the API ergonomics I want, and then backing your way into, well, maybe we can make it fast, which seems like the more normal way that people do JavaScript frameworks. Do I have it? The irony is that a lot of the stuff came from this book from this author that I never reading called like Elm in Action. And then I found out that I gave my copy to somebody, and I never got it back. So I'm ready to buy another copy as long as you've signed it, because it actually helped inspire a lot of the things that became Datastar in the long run. So the irony is that I actually am ready to buy another copy. I just don't, I demand that it is signed now. Somebody, I know the author, so. Damn, do you? Yeah, to make a signature happen, for sure. Yeah. Okay, that's even more interesting. So how did Elm in Action lead to Datastar? So I have kind of a weird background. I started as a 3D artist, and in the tech space, I was a 3D artist, and I was building tools, and the irony is because I was doing game stuff at the beginning, I basically started learning C and Python. Those were really my starting thing that I really got deep into the leads with for doing technical art stuff, right? I started doing stuff in Python, I got really deep into Blender, and the Python right there is basically C.
There's not a lot of things between you and the C, so then you start learning C and then you start going down the whole of GLSL and all that stuff. So I kind of have a weird thing of like, I try to look at the artistic side or like the user interface and on the back, like I want to know both sides. To me, it's just one problem. The problem is the problem, as Mike Acton would say. It's that kind of thing of like, you just want to solve the problem. So I remember when I was reading the, because I've been doing web stuff off and on since the .com times. And my thing is that it's, everyone had these really good ideas. Like the Clojure guys have good ideas, Functional guys have good ideas, the Low Level guys have good ideas, but no one seems to be, it's kind of like they're in their different worlds. And I think the thing that I got out of the Elm book was like, if you come to WebDev with these constraints, you can have a beautiful experience. The thing is that they were not constraints based off of performance. So it's like, can I get the ideas of something like Elm and say, I know how to make this work at a low level. Like there's a combination of these two things that I want. So I basically, in a lot of ways, working into the leads of this is that basically, I thought the ideas of FRP are brilliant, the actual implementations tend to be garbage. And if you can solve the in between, you could actually get all the value of FRP in any language and be incredibly fast and also simple it. So it's kind of a weird blend of like the Elm in Action, but like I don't think Elm is the right answer, but it got us to the right answer in a lot of ways, in my opinion. Interesting. So certainly I would say that there are different things that are, there's a lot of different variables. So in Elm, when I think about Elm, like what are the things I love about Elm the most, it's mostly at the language level and it's really not necessarily to do with the problem space of building UIs in the browser. For example, you have the Elm architecture, which people have ported to other things. What I like about the Elm architecture is that it allows me to use this language that I love in a way that makes sense for building UIs. But if I were building a UI in JavaScript or in Rust or something like that, I wouldn't necessarily say, oh, I got to have the Elm architecture for this because I'm not using Elm anymore, so it's not going to fit it as well. At that point, do I necessarily care? Yeah, I would say that based on the way Evan's talked about it and stuff, I don't want to speak for him, but Elm was developed to solve problems of correctness and maintainability and stuff like that first, and then Evan was pleasantly surprised when David Nolen in the ClojureScript world figured out that you could take React and put immutable data structures under it and then get really fast diffing.