And so do you think closure script is maybe the next iteration of

that process? That's I mean, that is certainly a possibility. I'm not going to predict that. So Java's closure script compiles to JavaScript. And so that lets it run on the browser or a node or, you know, any of the smaller JavaScript runtimes.

And I think more importantly, let's say, have access to that ecosystem really easily. That's

right. That's right. And when it came out, there wasn't much of an ecosystem in JavaScript. You know, this was 2011. The most common way to write your front end application was with jQuery. Right. And so NPM wasn't that big. It was just getting started. Webpack wasn't around. You know, all these things that we we take for granted today weren't there. But it was a good bet. You know, JavaScript exploded. There's millions of libraries now that closure script can take advantage of and more places than ever that JavaScript runs. So yeah, I think it was a good bet. I don't know if I would bet whether closure script becomes like the main focus and closure becomes like an old thing that nobody uses anymore.

Gotcha. Okay. Well, so I guess lastly for UI, how do you build your user interfaces now your websites and whatnot? Do you are you using closure script or I think earlier you mentioned that you are using JavaScript to a degree? So.

Yeah, I am. I do use closure script. That is my preferred way. So, you know, I'm using closure script with. React wrappers. So react works really well with closure script. Like I was talking about before the immutable data makes it really nice. The fact that we define most of our components is just functions. You know, we don't make classes. It's interesting because I see a lot of, I guess I'd call it churn and like features new features of react and stuff like that. Like we've basically been using react mostly the same way with, you know, minor tweaks since like 2013. And we like, you know, poke our head up to see what the JavaScript people are doing and we're like, Oh my God, another thing like what how many names do you have to learn like just to use, you know, names of libraries and frameworks and stuff just to use this thing we've been using the same one for, you know, since 2013 and it's been working fine. That said, it probably is showing its age now, but it still works really well. Still very comfortable. You know, we have a thing called fig wheel that gives you a live coding experience in the browser. So I know I have used fig wheel just a little bit. And

first time that I used it. I think I followed through with like the little flappy bird clone. Oh, cool. From some article or something. And oh man, when like the first time I recompile the function and it just started like working immediately in the browser. With like very, very little round trip time there. I just my eyes were just kind of glowing. I felt really good about it. Yeah.

Yeah. And it's, it's amazing because, you know, if you ask JavaScript programmers, like this has been my experience. Nothing against JavaScript programmers. Right. But in my experience, I've asked people like do you have live reloading? Like if I if you type something into your file and you save it, you see that change in your browser right away, right? And they're like, Oh, yeah, we've had that. Yeah, we have that. And then you ask them. Yeah. But if you if you if you type something like you change, like let's say the class of a an HTML element. And you hit save like it just immediately you see the difference in your HTML like output. And they're like, well, not really. Because when you hit save, then it recompiles and then it reloads. And if you're not on that few, like because you had to like open in accordion or something, you know, and there's like all these. Then you have to click around and get back to where you were. And now you're now you can see the change. Like, ah, I see that's not that's not live. You know, what's funny is that

this has like an inverse Morse law to it almost. It's getting worse somehow. Nowadays, there's a lot of like movement back towards like, I don't know how to phrase it, but I've been saying the client is now full stack. So like you'll still have your your web services be separate. Like you would expect in sort of a full stack thing in modern days, but your your front end is now like full stack again in the JavaScript world in a lot of ways. You

have like a state. Yeah. And you have a state you have a router and you have everything that you have on the back end.

Yeah. And then you like you change a server route or something like, oh, you add a console log to debug something on the server and it refreshes your entire front end and like you have to you have to like fully implement state and sessions for users in your application before you can even like reload onto the same page. Yeah. Whenever, you know, it's just it's getting worse and worse. And nowadays, like I've been using this thing called sapper for my own personal like side project stuff. And I swear on my really awesome beefy desktop. The reload time for like a console log or something like a log statement is probably

11 seconds.

Oh, man. It's crazy. Sorry. I didn't mean to tang it so hard.

But somehow it's getting worse. I mean, I don't doubt it. It reminds me that back in back when closure script first came out, you know, new and people were using like the only compile to JS language that people were really using was coffee script. And that was super fast to compile. And so people, you know, when something is fast to compile, you kind of don't mind. Let's say it takes 200 milliseconds 300 milliseconds less than half a second. You don't mind hitting the refresh button on your browser. You're on your dev machine. That's going to take less than less than 100 milliseconds. And so the feedback loop really feels fast. Right. But as you add features and you add transpilation steps and things start getting slower because you want to do like type analysis and you're doing, you know, you're doing more and more stuff. That loop gets slower and slower. So people were complaining in about closure script that it takes so long to compile. But it only it takes a long time to compile the first time. And so people are used to like, I'm going to compile from source every time because it doesn't take long. Well, if it takes a long time, you don't want to do that. And so we don't do that in the closure script world. We compile it once it takes, you know, it can take a long time, 60 seconds. But then once it's compiled, you only have to compile individual files. And so that's really fast. And plus the JVM is loaded and hot. So you don't have that wait time anymore. And you have a watcher on your file system. You're hitting save. And then you've just got a web socket between your browser and the JVM server. And so it's sending up the code really quickly. You can't really beat that. You know, like there's something architecturally that that liveness has that even in the code. And so it has that even if the steps get longer and longer, we can just compile less and less. You know, we can we can play with that a lot more, I think. And I don't know. I feel like I'm going off the rails here. But there's like a. Between the live coding and the like compile or the edit compile run loop that most languages have. This was done in like the 50s. Right. This, this is that same. Difference between like a mainframe where you sent your punch cards to and you had to wait a week for the result to come back versus the time sharing where you had a terminal into the computer. And you would type something and using using threads, right? It would it would give you some time, like a little slice of time and run it and then give you the answer right back. Right. It goes way back to then and LISP was on that time sharing side and the edit compile run loop was on the other side, the kind of mainframe side. And and the edit compile run loop like looked like it was losing except. Then with the personal computer revolution. Everyone now has a full mainframe on their desk. Right. And so it's fast. You don't have to share it. You don't have to get in line. But you still have that same idea of I'm going to compile a program into an executable. I'm going to run that executable and I'm going to check the output. Whereas the the live system, the time sharing system always had this idea of your program is running. You send it a line of code. It will run that line of code and show you the output. And that's that architectural difference. Let's you do so much. It makes up for so much like the lack of tooling because you can write your own tool right there. Or you can write just the tool that you need. Like you don't have to, you know, write a console log, rerun your program and and see what it outputs. You can save that value instead of logging it, save it to a variable. And at any time, just check the value of the variable. Right. You can have it printed every five seconds as it's changing. You know, so there's there's all sorts of benefits to having this live system that. I don't know. This isn't about functional programming anymore. This is about, you know, live coding, but it's the kind of thing that I think has to be experienced to really appreciate.