Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#60 4th Anniversary Episode - Return of David Nolen (aka @swannodette)
69 Plays5 years ago
David is back for our anniversary episode to chat about plenty of Clojure Script and projects - especially about https://github.com/vouch-opensource/krell
Checkout https://github.com/swannodette and https://github.com/mfikes to sponsor David or Mike!
Recommended
Transcript
Forgetting Anniversaries and Podcast Introduction
00:00:15
Speaker
So this is Deaf in episode number 16. And next week, hopefully by the time you hear this one, I think we're celebrating our anniversary. When was it? 2016, May something. We started our first episode. I don't know. To be honest, I've recently forgot my wife's and my wedding anniversary. So remembering Deaf in his anniversary is definitely going to get me in trouble.
00:00:38
Speaker
So the good thing was, the good thing was that she forgot the anniversary as well. So you got lucky. She remembered first, though, which is annoying. It was the day after, though. It was the day after. So, yeah. Oh, man. That's a sign of us getting old, maybe.
00:01:02
Speaker
How many years, Ray? I think we've been married for 26 years now, actually, 26. Oh, wow. It wasn't as important as the last one, you know, 25. Yeah. Some arbitrary number that is way more important than the other number.
00:01:17
Speaker
was divided by five so obviously it's more religiously significant and you know just generally better so shut up okay i don't know what your religious beliefs are but okay anyway coming back to uh belief in random number generation you know exactly
00:01:35
Speaker
So welcome to Deaf and anniversary edition. I think we are, I think when we were talking about this, I think Wouter was commenting, are we aging like dogs in terms of podcasts? And so probably we are 21 or something now. Anyway, but I think the nicest part is that we have an amazing guest coming back again from our
00:01:57
Speaker
What was it? I think 24th episode and then now it is 60th one. I don't care. Okay. Welcome to the episode, David. It's good to have you back again. Hi, it's good to be back again. Yes.
David's Quarantine Experience and ClosureScript Sponsorship
00:02:10
Speaker
So what is cooking in the closure script land or how are you doing? How are you doing? How are you doing first? Maybe it's because we're living in some strange times here, you know?
00:02:23
Speaker
I'm doing okay. I'm trying, just like everybody else, trying to stay safe, quarantining, trying to follow the guidelines and in spite of all the craziness at the higher levels of the American government, as we're all aware. It's been good. I've been, as with some other people, been lucky. I still have work and I'm still able to
00:02:54
Speaker
Actually, because of the quarantining, I actually have the past couple of months have had a lot more time actually to sort of free time to direct towards ClosureScript. So that's good. So I think there is some new happenings around the ClosureScript land, right? First of all, I think, you know, Cognitec started sponsoring. So I think a big shout out to them. I think that's the latest news from Cognitec and from ClosureScript land.
00:03:23
Speaker
Yeah, that was cool. I mean, you know, as a closure scripts, not, it's not young anymore. You know, like closure script is three years younger than closure,
ClosureScript's Growth and Open-Source Challenges
00:03:33
Speaker
right? So closure appeared in 2000 and maybe four actually. Yeah. Four. Cause I think closure appeared in 2007 closure script appeared in 2011.
00:03:47
Speaker
So yeah, Closure's been around for 13 years, right? Is that right? 13 years. And Closure's script in May or so, July, I guess it'll be nine years. You know, so it was really just...
00:04:03
Speaker
You know, Mike Fikes and I have sort of become the de facto maintainers and we spend a lot of time just managing tickets and going through issues, releases, website stuff. It's like any open source project. It's not our main gig. It's just something we do. But after nine years, I was chatting with Mike and saying, you know, I think we should
00:04:26
Speaker
approach Cognitec actually, just write them an email saying, you know, we'd be interested in being as other open source projects are, sort of taking on sponsorship. And Cognitec was like, not only is that a great idea, and that makes perfect sense, but we're more than happy to be the first people to sort of announce support for that. So that was really actually, to be honest, unexpected.
00:04:47
Speaker
Um, and, uh, that's really nice on their part and generous. So that's, it's a good start to, you know, just making sure that, you know, Mike and I, like Mike's been working on it for six years. I've been working on it for nine, just, you know, it's just, um, a certain level of support to contribute to sustainability, which is a good thing. How is the support being, uh, paid for that? Is it via the GitHub stuff?
00:05:13
Speaker
to the GitHub sponsors is exactly right. So people just send either Mike or myself some amount of money. We have like, we basically, Rich Hickey did this sponsorship thing, I don't know, like last year or something, late last year. And we just modeled it after him, which is that, you know, the basic idea is if you're a hobbyist or a contributor, pay whatever you want, $1, $5, it really doesn't matter. That's just a personal thing.
00:05:40
Speaker
It's really more about companies. Companies who have budgets are already spending X amount of money on infrastructure and this and that. And if ClosureScript is a core part of their product, then send us 50 bucks a month or 25 bucks a month, whatever makes sense for the size of your company.
Evolution and Integration of ClosureScript with JavaScript
00:06:01
Speaker
Yeah. So it's almost, I think, I mean, we can say decade, right? Almost, almost like a decade of existence of ClosureScript. So when you look back at the beginning of the projects and then now, so how do you see that?
00:06:15
Speaker
I mean, a lot of the changes, it has nothing really to do in some sense. It has everything to do with ClosureScript in the end because everybody's for people that are using it, but a lot of the changes are just around the fact that JavaScript changed, right?
00:06:33
Speaker
I mean, Node.js was only two years old, right? Maybe S3, but I think it was only two. And you couldn't really use Node for web development yet. I mean, there was weird things, but it wasn't that common. A lot of people were using this thing called Bower, which was libraries that are packaged to be used from NPM, but you couldn't just use things from
00:06:57
Speaker
Anyways, it's just a different world. At this point, I would say, what's going to be installed on a machine that's up in the cloud? It's going to be Java or Node. All the cloud stuff is either Node or JVM stuff. At this point, I think Node is essential technology. It's essential technology and people really expect to build client
00:07:23
Speaker
oriented applications directly from NPM. We tried many things in this past release, I think a week ago now, maybe two weeks. Sorry, I can't really exactly remember because I've been working on it for a bit, addresses that world, that reality, the reality that people need to be able to use stuff from NPM and it needs to be easy. It hasn't really been easy.
00:07:52
Speaker
It's been possible, of course, there are many ways to do it, but it's never been straightforward. With the last release, we have this new thing called the bundle target that finally is like, anybody can make this work. The response has been very positive and people seem generally excited about it, so it's good.
00:08:18
Speaker
How do you contrast that with things like shadow CLJS and other efforts around ClosureScript?
00:08:24
Speaker
Shadow is a great project. It's mostly led by Thomas Heller. He's the maintainer of that project. He's been at that project for a long time now. It's basically a custom build tool. It simply takes the core parts of the compiler and it has its own build system. For a long time now, it's supported
00:08:49
Speaker
building things from node modules. But the thing is that in order to do it, you have to use shadow. So without ClosureScript supporting it in a fundamental way, it meant that, okay, you can accomplish that goal with shadow by itself, but you could never, for example, build a ClosureScript project
00:09:10
Speaker
that depends on a node module that can be used from any ClosureScript build tool. Think about Closure. With Closure, I can say my Closure library has a dependency on these Java libraries, and nobody that writes Closure cares about this problem. You don't care that this library depends on five Java libs, you know it's going to work. Basically, for a very long time, that's not been true for ClosureScript.
00:09:40
Speaker
Really, shadow couldn't really address that problem because if it's not addressed at the bottom, it's not really addressed at all. You can build applications, but you can't really distribute libraries unless everybody's building with shadow. So doing the bundle target, you can build with anything. You can build with line CLJS build, you can build with fig wheel, you can build with shadow, you can build with ClosureScript by itself.
00:10:07
Speaker
Any ClosureScript tool can handle the bundle target because it's at the bottom. It's more pushing it to the code level rather than just having another layer.
Node and React Native's Influence on ClosureScript
00:10:21
Speaker
Yeah. And again, there's benefits. I mean, as Ray knows, full disclosure, I work with Ray. I'm Ray's coworker, right? So we work together about... I think my sympathies, but yeah. Coming out to vouch was like... Keep it professional, Vijay. Yeah.
00:10:44
Speaker
What the fuck? I mean just because we just crossed four years, we're supposed to be four years old now. Never tell him you work with me, David. Jesus. Go ahead. So at Vouch, they were leaning heavily on Node, and they were doing a lot of React Native stuff.
00:11:04
Speaker
Actually, I was at Cognitech for four years and the Cognitech work was very interesting, it was really great. But actually, I never had the opportunity to work on things that were not purely browser stuff.
00:11:18
Speaker
And that's only unfortunate, not for cognitive tech, but it's unfortunate as the maintainer of ClosureScript that it was hard for me to see the pain around node or the pain around React Native or node modules. And working at Vouch for the past year has been like, oh man.
00:11:36
Speaker
This stuff needs fixing fast. I really know in the time I've been at Vouch, a large number of fixes around using Node as a target, and of course now using Node modules. These are directly correlated to me seeing the pain points from the point of view of somebody who has to use this stuff every day for that particular use case.
00:12:02
Speaker
So do you think now Closure Script is more or less becoming like a competitor to Closure in terms of the whole stack development? Because Closure, you can't do front-end anyway, right? So Closure Script started as mostly as the front-end thing and then slowly seeping into the quote-unquote back-end, which is node-driven stuff. So Closure Script can become like whole stack language or
00:12:28
Speaker
I mean, it could, but the thing is, my theory has always been, I feel like this is what happens. People who are doing JavaScript stuff, they dabble in ClojureScript.
00:12:43
Speaker
And they're like, man, this is cool. And then they start down with a closure. It's like, oh, it's just like closure script, but I have real threads, real concurrency constructs. And to be honest, I actually think
00:13:02
Speaker
Node and node tooling has surpassed Java and complexity. It's not like I love, I mean, let's be completely honest, it's not that I love Java, but you cannot claim with a straight face that node is simpler than Java. I find a lot of the tooling and the documentation to be just as up to us as anything from Java and in many cases worse.
00:13:32
Speaker
So my feeling is that ClosureScript ideally is a way for people to do full stack Closure ClosureScript. I mean, you can do full stack ClosureScript if you want, but I just think you eventually will say, why not just use Closure and then use it? It's like, I get to do all these things I can't do in a single threaded runtime.
00:13:52
Speaker
And of course, you can still do, this is the thing about Java people. Java people realize it's not async versus threads. That was always like a kind of a false argument. In Java, especially modern Java, you can combine multi-threading and asynchronous programming. It's not an either or thing. And at Vouch, I think we use Node when it makes sense, where the Java just isn't going to work for us.
00:14:20
Speaker
JVM is what I mean. But most of our backend services are with the JVM, and I think we're okay with that. Yeah, and I think also the ecosystem on Node is like, it used to be quite simple, but now Node itself is getting fragmented and complicated, like you have NPM and you have yarn and you have other things that make it sort of, it makes the whole thing complicated.
ClosureScript in Web Development
00:14:50
Speaker
Um, and I think also to be honest, I don't think the closure script story on the, the node backend is very good at the moment. You know, there's not a lot of libraries actually integrate directly with, you know, express or something like that. I think there's, what is it called? Macchiato. Yeah, there's, there's Macchiato. And that seems to test framework. No, no, no. It's a good library. No, no. Macchiato I thought was a wrapper. It's like a lightweight web server thing.
00:15:18
Speaker
Yeah, that's what I mean. Yeah. Yeah, that's what I mean. So there's, there's not many, there's not much, there aren't many games in town on the server side for Node.js with Closure Script is what I mean. Yeah. That ecosystem isn't, you know, very big. It's not very big. And again, it's my, it's again, this is back to my impression that, I mean, there are other reasons for this too, right? Serverless is getting bigger, right? I feel like if you're doing a lightweight thing,
00:15:49
Speaker
You're probably going serverless anyway. There's a lot of services to directly deploy these node applications. You can build a serverless node thing, and it's becoming trivial. So I think there are many reasons why you're not seeing a lot of the affordances or things that we're used to in the Clojure and JVM world. But again, it's really my opinion that
00:16:16
Speaker
that it just hasn't remained a very big thing. And the survey really reflects this. The survey, it's still like 80% of users are using ClosureScript for web stuff. So that's front-end web stuff.
00:16:31
Speaker
One of the things that interest me doing something that we've looked at at work as well but not to get too detailed into work but is the is the clj see stuff. That's something which is you know i see that coming more and more in a lot of libraries and a lot of the ecosystem where. Like to your point bj you know where the closure and closure script stuff if you see how to see it's becoming a little bit easier to kind of.
00:16:59
Speaker
cross the boundary a little bit. I don't know how you feel about that, David. No, I think it's great. I mean, the CLJC, it's a massive time saver, right? There's many cases. You're building business logic. You need to do something with buffers. There's just so many cases where you need the same logic on both the client and the server. And the fact that people are
00:17:22
Speaker
taking the time to build CLJC libraries really proves that A, everybody needs this, everybody has this problem, and that library designers are doing the right thing and providing these libraries in one file is two formats. I think it's great. I think that was what we expected would happen.
00:17:43
Speaker
It's really nice to see especially the more mature libraries do CLJC and then it's really paint. It's not much effort for the user to use something that works in both places. I think it's just a net win. Do you think the closing script stuff that you've changed recently helps that as well?
00:18:05
Speaker
No, not really, because the bundle stuff is really just about, I just want to be able to use, let's actually state one more thing, because we sort of glossed over something about the bundle target, which is that
00:18:21
Speaker
What the bundle target really lets you do, it lets you take any JavaScript-based tool that will build for the web. It doesn't really matter if it's Webpack. There are many competing tools that do this. They all work the same way. They resolve the require as a statement in Node that lets you import a library. They all take the require statements and then produce a single concatenated JavaScript file. That's effectively what they do.
00:18:48
Speaker
So every time you have a require, instead of that being a dynamic require in the node runtime, it's going to be a static require in a bundled thing that gets loaded on a web page. Now, that's how it works. But what's happened is that what are users actually doing?
00:19:07
Speaker
Users are making libraries that are written in ES6. They're written with advanced features which may or may not be in the browser. They may be importing style sheets. They may be importing images. There's all these statements in the JavaScript files that you're importing that we can't possibly process. We can't process this stuff. It's like we're not going to take
00:19:32
Speaker
You know, five years of our time trying to understand every possible pattern that exists in a JavaScript library. But the bundle target just gets rid of that problem. What we say is there are too many practices in place, too many idioms that we can't possibly handle. So what we do is we say we're in our simple immutable functional world.
00:19:53
Speaker
The thing that we produce can then be fed into the bundler, and the bundler can handle all this other stuff that we never want to see that stuff. We never want to have to think about it. It's very much this closure strategy of, let's have our simple core, which is our code that we generated, we compiled a JavaScript, let something else deal with all this other stuff. We're not going to do anything.
00:20:20
Speaker
Again, it's because it's become impractical. Webpack and these other build tools, they just have to handle too many cases. We don't have the time, simply we don't have the time and the people power to make that work. It's just logical to pass the buck on to the tools that can handle it.
00:20:48
Speaker
Yeah, especially the native dependencies where you're like compiling into libuv and stuff like this. This is crazy. Yeah. How would you deal with that?
00:20:57
Speaker
can't deal with that stuff. And again, I mean, you know, something that's never been, I haven't had time to talk about it, but a lot of the reasons we ended up here was because, again, because of work I was doing at Vouche, we were using Renee Tall.
Introduction to Krell for React Native
00:21:12
Speaker
And Renee Tall is a really great tool. It's been out for, I mean, four or five, it's almost, I feel like shortly after React Native appeared, maybe it was six, eight months. So it's been out for a while. I think four years.
00:21:25
Speaker
And we use it to build our mobile app. And reading it all is a great tool. It solves the problem. But there are many things about it that were, like, unidiomatic for a Closure Script user. I mean, A, the tool itself is written in CoffeeScript, which is a bit strange for contribution because most Closure or Closure Script people
00:21:46
Speaker
They may be, some of them are not even JavaScript experts, right? They're mostly closure experts. They know enough JavaScript to get the job done. But then, I mean, an even smaller population in those copy scripts. So it was a bit, the code base is a bit unidiomatic.
00:22:01
Speaker
And also, it was built on as a line plugin, which makes it hard now that, at least at Vouch, we moved to Deps Eden. And then finally, the API was definitely not very closure-y, right? Because it was a sort of stateful API. You had to issue stateful commands. It was easy to be like, am I working on Android, or am I working with Fig Wheel? There were all these things you had to do.
00:22:25
Speaker
Uh, I, you know, talked to the team at batch and said, you know, I think in like basically a four or five weeks time, I can make a thing that does what Renee tall does and it will fit much better with our workflow. Um, but before we talk about that, which we can talk about in a second. When I started doing that, I was like, wait a second. I'm solving this other problem, which is the web pack bundler problem.
00:22:50
Speaker
And I actually hit the brakes. I hit the brakes. It actually solved all the parts. And I spent a couple of days to port the essential critical components over to ClosureScript so that everybody could use it.
00:23:04
Speaker
And in fact, the tool that I built, which is called Krell, basically uses the bundle target. So this is the other reason why it's big. It shows you that it's not about Webpack. It's not about Metro, which is the React Native thing. It's literally about the entire universe of bundlers that can handle node modules.
00:23:24
Speaker
any sort of node style bundler can use our output. And that's really looking into the future because we don't really know if it's going to be webpack or foo-pack, right? Who knows? Who knows? JavaScript is every day, it's something different.
00:23:42
Speaker
So we're just getting ourselves out of that game being like, we know node's not going to go anywhere anytime soon. So whatever flavor of bundler cool. Our thing is not, it's not about Webpack. It's not about Metro. It can, it's just prepared to allow you to apply any bundler that you want. So tell us more about the tool that you're talking about.
00:24:04
Speaker
Yeah, so, so Krell, Krell is, it's, it's, it's, yeah, it's Krell. As you should, uh, enunciate it. Yeah, probably. That's K-R-E-L-L, like Krell. It's the, uh, it's the, it's the alien. It's like the, uh, long lost alien race from the movie, The Forbidden Planet. Um,
00:24:25
Speaker
Okay. You know, it's a play on words because react native, it's kind of like, you know, react native is like this native thing. I was like, yeah, we're going to make this alien list things and stick it inside of your native thing. And you know, it's also like, you know, um,
00:24:42
Speaker
If you follow LISP, there used to be this really great LISP, LISP is alien technology logo. So it's kind of a nod towards, these are older sort of LISP alien stuff. Have you ever looked at Conrad Barsky's books, Land of LISP? Oh yeah, LISP aliens. Exactly. So it's definitely playing into that. If you're a synthesis, modular synthesis nerd, there's also a famous modular synthesis patch called the Crow patch.
00:25:10
Speaker
But that patch is actually based off the Forbidden Planet. I can't remember their names. It's so sad. I should have memorized their names. The people that worked on the soundtrack, they would make these electronic circuits. And the soundtrack was composed of multitracking these little circuits.
00:25:29
Speaker
that would make these sounds and they would eventually burn out. So they were like life forms. This little circuit would play this weird space alien sound and it would keep evolving and they would just run the tape and record as much of it as they could. And then the circuit would die. It would just burn out and then you have to go melt or whatever. And then you'd go make a new circuit and the new circuit would make a weird crazy sound.
00:25:53
Speaker
And they edited the entire soundtrack from all these weird circuits that had this very limited lifespan, but produces beautiful, unpredictable patches. Unpredictable sound. I think this is the best pitch for a tool or a library in a programming language. Nothing about what the tool does, but the entire history is so important.
00:26:20
Speaker
And then people are like, damn it, I have to use this one right now. Why? Because it's from the forbidden alien, you know, auto destroying thing that David said. I think maybe it's going to burn out all the circuits on people's computers. Is that your idea?
00:26:36
Speaker
Oh, sorry, you can be rebelted, you know. What you will want, you know. You have this end user licensing agreement for Krell. Anyway, let's back onto the actual pitch. Yes.
00:26:53
Speaker
Yeah, so it really is. So the main idea is that I wanted it to be depth-eaten friendly. And by depth-eaten friendly, I mean, really, it means it's friendly. You can use it with line again. You can use it with boot. You can use it with anything. I mean, if you're depth-friendly, you're really friendly with any tool.
00:27:11
Speaker
And the other thing is that I wanted it to be zero configuration, meaning that I didn't want to have to talk about Android versus iOS. There's a lot of stateful stuff around that. I also just wanted to make a thing that had almost no dependencies. Krell, I think, only has two. We use a open source directory watcher, which is fast on all platforms, including OS 10.
00:27:36
Speaker
which is harder to find. So I wanted something that could build quickly on all platforms, the Watcher anyway. And then it just relies on ClosureScript. It has no dependencies. It doesn't use WebSockets. It doesn't use a TCP server. So a lot of times with a lot of these tools, if they don't bundle in their own WebSocket implementation, then there's a conflict with Java stuff. Anyways, as you know, it becomes a hassle. So Corel just uses a TCP socket to your device.
00:28:07
Speaker
And that's it. And, um, and it, and it, and it, and it basically re implements what Renee tall did Renee tall used fig wheel. Um, but fig world, fig world actually is a largest library because it does a lot of things. Um, and I felt like actually a TCP socket based repl is all you need for, for developing react native. You don't need all this web feature stuff.
00:28:31
Speaker
That's really how it works. It means that there's not much code to read, there's not much to see. In total, I think half the code is JavaScript to Bootstrap and the other half is Closure and ClosureScript. I think it's 600 lines of Closure and ClosureScript. There's 600 lines of ClosureScript and Closure. It's quite tiny and it means that it's pretty easy to review.
00:28:57
Speaker
you know, I'm of the opinion, I'm also the opinion that you make a thing and basically you want the goal as an open source maintainers. How can I make a thing that's done? How can I make something that's just that you that you know, you work on it for a year or maybe, maybe a year total. And then you're like, after that, it's just maintenance, like, ideally, actually for Krell, in the next month or two,
00:29:21
Speaker
There won't be any updates except for updates for React Native. That would be the goal. That corral is effectively done because what is it? What is it? What is it? It's just a REPL.
00:29:33
Speaker
Like, and I think, I think, um, tools like rebel, like rebel, and there's been some other cool, uh, rebel based experiments. I think there's the beautiful idea. If you really make a great rebel, adding meta features, adding auto completion, all this other stuff can be done as a second step. It doesn't need to be done in the core. Uh, and that's what I'm really trying to do. I want a very simple.
00:30:01
Speaker
zero configuration tool that gives us a REPL to React Native. And after that, it's done. And I want it to be so simple that if you want to build a rebel thing, or you want to build an inspector or you want to build, you want to add rebel read line,
00:30:17
Speaker
that adding stuff to Corel should require a person to spend maybe a long afternoon reading the code base. That's the maximum amount of time you should spend understanding how Corel works. And that completely depends on Corel remaining small and doing very little. One of the things that was a problem, if I remember rightly, David, was these updates of React Native.
00:30:44
Speaker
Yeah, so, but that's because with Renee Tall, Renee Tall was pinned. Renee Tall, you couldn't, you had, you couldn't just, because Renee Tall did a lot of CodeGen for you, the CodeGen would produce the templates and set the versions and it did a lot of things.
00:31:01
Speaker
Which Krell just says, no, because what happens is that Renee tall became stuck because you need you need the maintainer. If not the maintainer, somebody to step up as a maintainer to update Renee tall to allow people to migrate. And that that requires a lot of, you know, just a lot of work. And so with Krell, I basically said I didn't want us to take on that burden. So Krell,
00:31:27
Speaker
says does not know anything about the React Native version. You just have to maintain the React Native version yourself, which is actually a good thing. It's a good thing because now the problem is not in the tool. Every user is free to upgrade React Native and Corel may need minor changes, but because it doesn't depend too much on the React Native version, that should be fairly straightforward.
00:31:54
Speaker
I will say though, as a word of caution to people that are interested in Corel, you really do need to update to the latest React Native. Corel assumes that you're at least on the 0.60 version of React Native because that's when React Native solved the auto-linking problem.
00:32:13
Speaker
which is using native libraries with Android and iOS prior to auto-linking was terrible. You had to modify all your build files, you had to modify your source code, you had to modify linking Xcode. It was a complete and total nightmare to use third-party libraries that needed native support. It was just unusable. That's the only way to describe it, unusable.
00:32:41
Speaker
React Native now does this thing called auto linking and people are doing this amazing thing right there being like
00:32:48
Speaker
I'm going to make a zero-conf library that uses Java zero-conf and iOS zero-conf, NDNS, whatever. That's a React native library that automatically links in the native components that are needed for the JVM or for iOS. So that means the native integration story is way, way, way, way, way, way, way simpler. I just think that
00:33:17
Speaker
Really, you should upgrade anyway because, again, I think the way that it was done before was extremely hard to maintain. The native stuff, I'm not sure if you saw or followed Flutter from Google. I do. I do follow Flutter. Yeah, yeah.
00:33:38
Speaker
Oh, cool. So then I'm really curious about your impression of it because I recently got back, quote unquote, got back into iOS development. I think I did something like 10 years ago, I built a couple of apps
Comparing React Native and Flutter
00:33:50
Speaker
in Objective-C and now I'm now learning Swift because I was never a fan of using these frameworks that is going to produce for both things and I've never used React Native.
00:34:02
Speaker
How do you compare React Native with Flutter? Of course, there is a language difference, but other than that, how do you see the comparison there? I would say Flutter is a direct competitor. To be honest, I think Flutter is probably in many... It needs to be assessed, but to be honest, my initial impression, it's probably
00:34:24
Speaker
a better solution in the long run. Something that happened with Flutter, which is actually pretty exciting, is that they started doing desktop support. Flutter is now, now it's not only a way to do native stuff on the device, on Android, and on iOS.
00:34:44
Speaker
And also, I wouldn't be surprised if performance is better, especially on Android, right? That's always a concern, is how do you get really good mobile performance on Android? But my impression is that it's quite good. All the things you expect from React Native exist, for example, hot code reloading works, even if you're untethered and all this stuff.
00:35:07
Speaker
There are many pluses for Flutter and now that they're slowly getting serious about desktop development, I do see a lot of potential there.
00:35:19
Speaker
And it does need to be followed pretty closely. If it ends up becoming very exciting in terms of if we start seeing a lot of market adoption, then this is a longer thing. It's not any time in the near future. But I've often mentioned to the community that it would be great to see a new
00:35:41
Speaker
emitter for ClosureScript that emits Dart. Dart lets you hot code reload. Dart lets you, in the same way that the JVM lets you reload bytecode, Dart actually does it. There's no exposed bytecode.
00:35:56
Speaker
But Dart lets you reload Dart files, and it will do the correct thing. It will reload. Instead of changing the state, it just reloads the classes and the methods, which is exactly the type of reloading that you want to get a list-like experience.
00:36:15
Speaker
So it's definitely something to follow. And, you know, if it turns out that it's a runaway hit, you know, I can imagine in four or five years that there is a ClojureScript Dart and that's an extremely popular option. You know, I mean, I don't know. My opinion is this is that, you know,
00:36:39
Speaker
You know, it's truly sad, right? JVM was supposed to be this thing. Like if you really think about it, JVM was supposed to be this thing where you could write this thing anywhere. It's just not true. It's just not true. I mean, JVM is great for server stuff. It stinks when you want to do lightweight stuff. It stinks when you want to do clients. And if Flutter ends up being a really great universal UI, lightweight
00:37:05
Speaker
thing. That would be cool. That would be cool. And also, Flutter, I mean, nothing against the JavaScript ecosystem. But something I've never liked about JavaScript, it's just my opinion. It's like there's no taste, right? It's just like a ubiquitous lack of taste. Yes, JavaScript is useful.
00:37:25
Speaker
it works but you know it's really as overall my opinion is that it's like complexity gone amok it's a necessary evil that's what that's what javascript is to me javascript npm node it's a necessary evil you incur a lot of complexity by adopting it but maybe it's the only solution for you.
00:37:44
Speaker
Something like Dart, honestly, at this point seems simpler. It seems more straightforward. The community is smaller. It seems more tightly controlled. And there are downsides, of course, maybe for contribution and, you know, the sort of like, you know, the bizarre, maybe there's problems with that, like that philosophy. But the benefit I see is that you have a simpler ecosystem and possibly a more coherent ecosystem. So that's another thing.
00:38:15
Speaker
Go ahead. Go ahead. I was just going to say, how do you compare it to TypeScript, for example? TypeScript is TypeScript. TypeScript did the thing that we did, which was we. We're okay with dealing with all the bad stuff. TypeScript doesn't do anything about the bad stuff. It throws up its hand and says, we're going to add types. That'll solve all your problems and it doesn't solve all your problems. You still have all the other problems you had before.
00:38:45
Speaker
Um, so, uh, you know, um, you know, again, like the fact that, you know, that really, really the other reason why I think Dart is pretty cool is because in the end, um, I think Lars Bach, the,
00:38:58
Speaker
the lead architect of that project, the language designer. He worked on the JBM and he was a small talker. His heritage is in small talk. By association, effectively, that's a list-like viewpoint. That types are great, they can be useful, but you should never give up dynamism.
00:39:20
Speaker
Dart VM is clearly a language design, a VM that's targeted around the idea of dynamism. Why else would they have hot code reloading? The only point of having hot code reloading is to have a system that's dynamic. It's a lie. That's why they did it that way. And I think that Dart has its head
00:39:43
Speaker
you know, in the right place. And I think that Lars, I mean, there are things that I don't like about Dart, like, but it doesn't matter, right? That's the that's the beautiful thing about closure. If it's a good platform, we don't really care that much about linguistic choices, because that's not what we're going to be using. Anyway, if the tooling is simple, if the runtime is simple,
00:40:05
Speaker
then maybe it's a good target. I'm not saying it is yet because again, I haven't spent a lot of time with Dart. I can't really say that with any confidence yet. But there are lots of things that I like about it. And again, to Vijay's point is that like, wow, the Flutter thing is actually pretty compelling. It's pretty compelling because I mean, Flutter gives you this React Native style development. It gives you that style of functional style components.
00:40:33
Speaker
And it appears to give you a much simpler build system. So definitely something to look at. Yeah, I think. Because I was thinking to build something, and then I thought, OK, obviously, iOS being 20%, 30% of the market, and then 80% of the market is Android.
00:40:53
Speaker
And I dabbled with Flutter when they released, I think, the first version at some point. I was thinking, okay, maybe I should lean towards Flutter because the whole experience, as you said, is really good. I mean, just download the IDE and then the reloading and the emulators and everything is much more coherent, you know, compared to React Native stuff. Or I think back in the day, the Apache project, forgot the name, something.
00:41:18
Speaker
to do the cross-platform thing. But for me, I think there is also the risk of, especially iOS being, you know, they control, the walled garden of iOS is controlled by Swift and everything. And for me, I always have this fear of, oh, if I invest a lot in Flutter, then if the ship breaks on iOS, for some reason, Apple, you know, pulling the carpet under your feet. They would never do that, come on.
00:41:44
Speaker
Yeah, sure. I'm skeptical, but again, I think that's why even if we did do a thing with Dart, it would always be an option anyway, because JavaScript is not going to go anywhere. And I definitely think that the effort to run on Dart
00:42:03
Speaker
probably wouldn't, you know, that sounds like a couple of months of work. That's what I'm saying. Like, you really, it's just, instead of generating JavaScript, you're going to generate Dart. And there's, you know, it's going to, there's a lot of stuff to remove, because we definitely have a lot of things around JavaScript. But, but if you really, but really to, to, to ClosureScript's credit,
00:42:27
Speaker
I mean, ClosureScript has a very large integration with Google Closure. But for example, if you look at something like Shadow, Shadow doesn't use, Shadow uses only the analyzer and the compiler. It uses none of our build stuff.
00:42:43
Speaker
and that's actually shows that it's not ClosureScript as code base is not perfect, but there is, I believe, enough separation in ClosureScript itself already to decouple these things so that targeting Dart should be reasonably feasible without too much pain. Actually, and if somebody started on that,
00:43:08
Speaker
It would also be good because it would allow us to make that a bit more clean so that the next person that wants to come along and do it has a much easier time. So there's other benefits as well. So I think that would be super fun as well because using Closure, of course React Native has, as you said, a lot of Closure, Closure Script compatibility or you can just write
00:43:34
Speaker
I remember I think Kevin was one of the first persons who was building ClosureScript mobile applications. Now the story is much more, I think, easier to build ClosureScript-driven mobile apps and as you guys are building already. And I think if we can target to other platforms like Dart, I think then using Flutter plus ClosureScript would be an amazing experience, right?
00:43:57
Speaker
Yeah. I'm again, it's, it's, it's, it's definitely a cool idea. Uh, my, my hope is that somebody else works on it. Trying to tell people that, Hey, you know, try it out. It's awesome. No, try it out. Yeah. Go on. Go ahead. No, go right. Go ahead. No, no, go on, please. No, I'm just going to say it's okay. Okay. Now we're on a deadlock. Please, please, please.
00:44:28
Speaker
All I was going to say was that I'd be happy to see that be an open source effort, and I'd be happy to make changes to make sure that ClodrScript is well-separated enough for that to work. Go ahead, Ray. Yeah, I was just going to say that because all these other targets are definitely very tempting these days because the other one that's coming up that we've talked about before is WebAssembly.
Exploring New Targets for ClosureScript
00:44:56
Speaker
That could be an interesting target as well, given the fact that it's relatively small in terms of scope. It's not ready yet by the looks of things, but it's getting cooked. It's coming in the browsers and the GC is getting there and other bits and pieces. What do you think about that potential as a target for ClosureScript? To be honest, I think the thing about that is that
00:45:23
Speaker
I mean, I think the first step would be, A, what I would like to see actually, and if I was going to do it, my opinion is that what we want is a dialect of ClojureScript that's specifically for WebAssembly. It's not actually like ClojureScript. It's actually a dialect for writing WebAssembly directly.
00:45:46
Speaker
If you think about it, that's actually kind of what you would want to write because you want to write some high-performance code and you would like to write in something that basically is a DSL for Wasm.
00:46:02
Speaker
You have the basic semantics. It's not low level like Wasm. Wasm is super low level, but it's a higher level dialect of Wasm that looks almost like ClosureScript. So you can write high performance modules in ClosureScript. That I think would be pretty interesting.
00:46:23
Speaker
Otherwise, besides that, I don't see much else that we would want to do until the performance is better on a wider variety of targets. People have always said, compile the Wasm, but there's just a lot of trade-offs there, and that would really be for a very specific audience. Yeah.
00:46:49
Speaker
So the one last one that I know that I think you're friends with Ramsey and Cole who are doing the games. The Arcadia. Yeah, Tim's. Arcadia, yeah. And they're friends of the show. With Tim's and stuff like that. Over the four years, we have built so many relationships with everyone.
00:47:15
Speaker
Anyway, yeah, so I think they're looking at like, they're generating the C sharp stuff. And, you know, that seems like an interesting space as well. Oh, yeah, I mean, I think, I mean, I think Arcadia stuff has been really cool. I mean, I feel like they've, they've gone a lot farther with the C sharp stuff than anybody else. And that's also another possibility. I mean, you know, we'll see. I definitely think that
00:47:41
Speaker
It's something that since C sharp is now cross platform and there's an officially cross platform, that's also something to consider. I mean, in the end, it's like I say, there are lots of fun projects to hack on. Right, yes. There are a lot of fun projects to hack on, but I think a lot of what I would like to see really is
00:48:05
Speaker
going back, because the Dart is a really concrete example, is just that, is there a demand from the existing user base, right? What's the demand? The only time we would take something on, to be honest, is that if in four years or five years from now we're like, we just think,
00:48:26
Speaker
Dart is superior. It's superior. And you just mean we're making a bet. It's like when Rich Hickey said, JVM is a better target for what we want to do and how we want to do it. And it may be in four or five years, we're just like, actually, we're just tired. We're just collectively tired of there only being JavaScript. And we believe that we could do everything we're doing currently. And it could be way simpler.
00:48:54
Speaker
We're going to officially support Dart because, and I'm not saying we're going to do that, but I'm saying those are the reasons why we would do it. Those are the reasons why we do it because we as a community believe or I believe as the maintainer that there's a huge opportunity to show the world there's a better way to do the same stuff that you've been doing. I guess you have a very big platform as well. You'd have to feel like it was really justifiable.
00:49:19
Speaker
And that's why there's no rush. That's why there's no rush with Dart, because it really has to feel like that people are, in fact, there's an opportunity. If you see people abandoning JavaScript, because they're tired of it, then you know it's time. The moment that people begin assessing other technologies, because they're no longer willing to put up with the complexity, which is already happening. Sorry, it's already happening.
00:49:49
Speaker
But you want to see more movement. You definitely want to see more movement than there is right at this moment.
00:49:55
Speaker
But it is still surprising how much pain, I mean, as a community, we can tolerate, given the amount of JavaScript libraries and trying to patch these holes around this whole, I think that whole developer experience, as you said, it's not, there is no taste for all the stuff that is proliferation of every problem being solved in million ways.
00:50:24
Speaker
So maybe it will change.
ClosureScript's Impact on Web Development
00:50:26
Speaker
I don't know. I'm not doing much of the front-end development because most of the stuff I do is in ClojureScript, so I don't touch much of the JavaScript at all. So I was just curious with the with the iOS stuff and then Flutter and these kind of things. So we talked a lot about all the mobile stuff and everything, but ClojureScript, at least, you know, looking back,
00:50:50
Speaker
Shot into fame or we got our our big push because of the react stuff right on the web so so Where do you think the web stuff is going? Or what do you see for the web related technologies? I mean I to be honest I I mean actually for the web stuff. I think react native react native is like a
00:51:14
Speaker
What is this, what do they call it? It's like a local optimum, right? It's like, you know, it's like, actually, you know, there's so many different things and that, and it's really, I find them largely uninteresting, right? I feel like, you know, when you, when you have something like React, React out there, unless something's truly doing something that's game changing, which I haven't seen anything yet to be honest. Yeah.
00:51:41
Speaker
There's not much reason for me to look elsewhere because, again, React lets us write functional code, functional UIs. That's like the holy grail. We were given the holy grail with respect to doing UI programming. We can do functional UI programming. This is something that people have been wanting to do for
00:52:04
Speaker
years and it was a research problem. It was a research problem and that's not true anymore. Every ClojureScript programmer out there is writing functional UIs like it's completely normal. I think that I can imagine incremental improvements, but it's hard for me to see
00:52:26
Speaker
It's hard for me to see it right at the moment doing much better than what we've done. Also, Flutter, Swift, everybody has adopted this pattern. So clearly, that was the step evolution. If you really think about it, if you really think about it,
00:52:45
Speaker
there was nothing for 30 years. Not since Xerox PARC. Since Xerox PARC, you had Model View Controller. You had Model View Controller since 1979, 2015, 35 years later, you had functional views. So it took 35 years to make one step.
00:53:06
Speaker
I'm not holding my breath. I'm going to, I'm going to, I'm going to go on a limb and say, I don't think you're going to see anything interesting for quite some time. Yeah. So I think I will retire with this, uh, with this paradigm. Before we go on, but don't you think like, cause we act themselves have been maybe is it again more local maximum stuff, but they've been changing.
00:53:33
Speaker
some of their framework quite heavily with hooks and stuff like this. Do you think that's just kind of like syntax sugar or do you think it's deeper?
00:53:45
Speaker
I mean, that stuff, the hooks, honestly, the hooks thing was something that we asked for when React first came out. I was like, oh, man, we have to do all this object-oriented bridging. I mean, it's trivial for the library, the Clojure script binding to hide the details of that. But all hooks let you do, hooks let you write without writing objects, right? In some sense, it was how we wanted to interact with React.
00:54:12
Speaker
Now it's officially supported. So it was really something that we wanted, but now we have it. So I only see it as a plus. It simply simplifies integration. There's actually a few, I think, open source libraries that are now even thinner wrappers around React that simply let you write ClojureScript with hooks. So it's all good. I mean, that stuff's great. But again, it's...
00:54:41
Speaker
You know, because it's simply removing one layer that we had to do, it's not a dramatic change. It's just like a incremental improvement. I think maybe that's the other thing that you're doing with these tools, is having a very largely unopinionated view on the higher level concepts. Yeah, for sure. Like you're talking about Krell and stuff.
00:55:08
Speaker
Yeah, yeah, yeah. Yeah, yeah. Just, you know, I think now after like, yeah, it's been five years, five years of React. Five, five years? Well, maybe longer. Six years? Yeah, six.
00:55:23
Speaker
No, six and a half. Yeah, okay. Something like that. But anyways, yeah, I feel like, you know, I feel like I observed what was going on and then taking the stance that we should do less. I mean, this goes back to bundle, right? Bundle says, we don't know what people are going to do. Let's generate something that works for everybody. Krell says, I don't know what you're going to want to do with React Native.
00:55:48
Speaker
We're going to make various small number of decisions and make it easy to make downstream decisions. So yeah, making as few choices as possible. And let the upstream kind of innovate without really getting the kind of infrastructure tooling sort of knotted up in it. Exactly. So in terms of the paradigm or the design
00:56:16
Speaker
I'm not sure if we want to call it design pattern because it has a lot of connotation around it. So the way we design web applications in the functional UI. So other than that, I think the rest of the stuff is just how the language evolution, right? For example, if you take ReasonML, so how do you see that compared to Dart or compared to ClosureScript?
00:56:40
Speaker
I mean, ReasonML doesn't seem like it does anything important other than the type stuff. I mean, if you're into types, then it does the type stuff. I mean, that's also why I find, you know, it's like this thing. It's like the most important innovations for actually making the software. It's not the types anyway, right? React-React is an untyped thing, right? I mean, you don't need types to invent a UI paradigm.
00:57:08
Speaker
You know, it's great. If you like types, it's great. You want the checking and all that stuff to happen. But in the end, I mean, in my opinion, real innovation, it does not matter if it's typed or untyped. React could have been created by, could have been made in a typed language. And you would have instantly said, wow, that's amazing.
00:57:30
Speaker
You can make that work in any language. Sure, you have types, but the critical part of the thing, it does not matter because the types don't matter with that part.
00:57:40
Speaker
Right. But ReasonML, I'm not saying anything bad about ReasonML. I just think that ReasonML is really cool, but if you like OCaml, if you want an updated, cool looking OCaml, great. I don't see it contributing anything meaningful other than being like an updated OCaml. Meaningful in that if that's your cup of tea, cool.
00:58:04
Speaker
I think that, as you said, it makes sense that the idea is now implemented in different flavors, in different languages. So whatever the language that you use, you're still following the same, the new evolutionary idea that you use this functional UI, whether you Swift, whether you start, whether you use ClosureScript or ReasonML. Exactly. I think, yeah, yeah. So coming back to one of the, you know,
00:58:32
Speaker
because project that you're working on. So ClosureScript, you were saying that the open source maintainer stream or open source creator's dream is that you want to move to a done, quote unquote, done level and then keep maintaining it.
00:58:46
Speaker
So what do you see for ClosureScript? I mean, where are we at? And then are there any plans that you have a bit of a vision? Well, I mean, I think, A, I mean, you know, when I say done, I mean, libraries, tools that are clearly finite.
Maintaining and Improving ClosureScript
00:59:03
Speaker
I mean, language projects really have, you know, they have, they have the raw end of the deal with respect to maintaining maintenance, because I mean, there's always going to be like, you know, there may be,
00:59:16
Speaker
ecosystem things we need to address or closure adds a new feature and we need to add it or, you know, Oh man, there's so many, there's always tons of bugs, right? I mean, you know, it's like, fortunately there's not so many major bugs, but I think we have hundreds, we have hundreds of minor bugs, like in foreclosure scripting, hundreds of minor bugs, which I just don't have time to look at. Um, so there's always going to be stuff to do. I mean, if I was only fixing minor bugs, I'd be busy for probably two years. Right. Um,
00:59:46
Speaker
So I don't think, I think it's hard to achieve the done state with a language project. Um, but I'm, I'm feeling, to be honest, I'm feeling pretty good about bundle. I think bundle answers. One of the biggest questions that I had, you know, I mean, I've had that problem and that question floating on my mind for at least four or five years. Um, there's another thing that we want to work on, um, which is smaller, but I think we'll also help.
01:00:15
Speaker
around how we require libraries because right now it's a bit annoying with third party stuff specifically with like stuff from node modules or global libraries importing that stuff into ClosureScript. You can't really do it. So I want to solve that problem. But otherwise I don't see much
01:00:39
Speaker
other than fixing bugs, performance, cleaning up the APIs. There's boring stuff. There is a part of ClosureScript that's crufty, meaning for downstream users, for the typical user, they wouldn't care. But Shadow did this cool thing, which is the Shadow has a very functional build pipeline. You can take any compilation unit,
01:01:07
Speaker
And it has a true data-oriented pipeline. Each step of the compiler produces data, which can be passed on to the next step in the pipeline. For various reasons, all of them historical, ClosureScript, it's not very disciplined. The build pipeline is not disciplined. There are many different points where you write to disk. And what it means is that the
01:01:33
Speaker
The build stuff in ClosureScript is so unfunctional, you can't use it as a library. It's almost impossible to use as a library, meaning it's very difficult for somebody who is a ClosureScript expert that wants to do things in a slightly different way at the build step of their project to do anything custom.
01:01:56
Speaker
because you have to know too much about what happens when. And that's not just a problem for would-be tooling developers. It's a problem for me because I forget how the thing works. I can never remember how it works. It's impossible. So that's not really like, again, that's not so much user-facing as tooling developer-facing.
01:02:19
Speaker
and simplifying our internal maintenance, I would like to redo the build pipeline to adopt the shadow functional build pipeline. So we wouldn't just copy what they have, but we would say that's a solid idea. Closure scripts should only have data, and writing to disk should only be a final side effect. But that's a big project, actually. That's a big project. That requires changing a lot of code.
01:02:49
Speaker
Yeah, totally. And it's also a trade-off, right? I mean, how much benefit that it is going to give and the impact of it. Because if most of the people who are using ClosureScrape don't need to plug into this thing or understand this stuff, then...
01:03:03
Speaker
But if it helps him though, Vijay, it's quite a good idea. That's true. So that's really, in some sense, that's the problem with this project. That's why it's been delayed for so long, even though I've been thinking about it for, again, four or five years. It has no immediate impact. But as Ray says eventually,
01:03:23
Speaker
the burden of maintenance, it's like, yeah, it's, it's preventing me from working on the thing. So, um, it has to be addressed at some point. In fact, it's probably that if anything was going to get worked on, that was major. That would probably be the biggest project within the next year or two, uh, because that would, again, that would ease our own maintenance burden. If I say that, um, most of the closure script work is around tooling or
01:03:51
Speaker
the compiler level work because given the nature that it is a LISP, so there won't be much of the language level changes, right? Because that needs to closely follow closure. Is that a correct assumption? Again, there's one thing that we're going to do, but that's around, again, around the NS form. And I can explain that really quick.
01:04:12
Speaker
Sure. No, just take your time. No, no, no. It's really quick. It's a quick explanation. In Java, because you have packages, the language, even at the VM level, there's a sort of disciplined notion of importing because that's enforced at the notion of Java packages in the class path.
01:04:32
Speaker
But that's not how JavaScript works. That's just not how JavaScript works. JavaScript node.js stuff, it's all relative paths. And then even more, in a more troublesome way, there is no specific way to describe the structure of your library.
01:04:51
Speaker
There really isn't. There are many things inside of a library, in a JavaScript library, that may in fact be a nested library. There's no way to know, is that a JavaScript object or is it a nested library? There's no way to know that.
01:05:12
Speaker
In fact, it's quite common that I want to use something from a JavaScript library, but that library is actually a nested library, a nested series of namespaces, but I can't get at the inner namespace and use that as my library that's under consideration. I can't require the nested thing.
01:05:33
Speaker
So I had a big conversation around the last release saying, I want to fix this. And we got an amazing feedback. Thomas Heller gave some really good feedback. A lot of the Closure Script users gave a lot of good feedback.
01:05:46
Speaker
So we're going to have a syntax for reaching into any library and saying, I want to use this part of the object that's the library. I want to use a sub-object as the library. And that's actually really cool because now it does not matter how nested the thing I'm importing is. I can always treat some sub-property of the nested object as the library that I care about.
01:06:14
Speaker
Because previously, there was no way to do this. You could use property access, but now you no longer can use NSName stuff. You can't use refer, you can't use rename, you can't use... There's all these things you can't use if you can't use the NSForm. You have to bring them into Devs, and it's very ugly, right? Because what's the point of doing that? The whole point of having the NSForm is to have
01:06:37
Speaker
structure around the usage of the library. So this feature would allow you to add structure to things we couldn't add structure to before. The other thing that's related is that you can now require global libraries.
01:06:52
Speaker
So currently when you have a global, you have to say JS slash and your, your, your code is littered with JS slash this JS slash that is ugly, right? So ugly. So now we would be able to say there is a property, a global property, and you want to treat that as a lid and you can use refer, rename, all that stuff as well. So, so we, so we would be able to lift almost every, almost every pattern.
01:07:20
Speaker
that people are using either intermediate definitions or they're using globals, those can all be moved into the NS form. So that's, it's actually not going to be a lot of work. And it's a huge, to be honest, I think it's a huge feature. It's been something we should be like, now that I'm like, now that I see the light, I'm like, oh man, we should have had that like five years ago. But that's an easy one. That's coming, that's coming.
01:07:48
Speaker
But syntactically, it's not going to deviate from closure and as well. It's going to be pretty much the same except that it's going to be the same syntactically is going to be the same, but, um, we'll have, it's basically requires a little bit of special handling, which closure doesn't have, but it won't look any different. It won't look any different. Okay. No, that's the window. Isn't it? That is the huge win is that you can align everything more closely. Yeah. For me, it's been like this thing. It's been a sore thumb. The fact that we don't have.
01:08:18
Speaker
a way to avoid these strange, these unidematic things because it's ClosureScript. So with this change, a lot more code can look just like Closure, a lot more code. Yeah, yeah. That's nice. So any other long-term plans for ClosureScript?
01:08:38
Speaker
No, no, I really can't. I really can't think of anything. I mean, I'm glad you brought the Dart stuff because I actually was funny. That's like totally like it must be in the air because I really was looking that at the other day. I was like, oh, man, Dart looks pretty cool. It looks. Yeah, it is because I've been doing all this React Native stuff, but but but it's not time. I don't think it's time yet.
01:08:57
Speaker
But other than that, to be honest, I'm really excited about ClosureScript. At Vouche, it's really rewarding to be able to use ClosureScript every day for all these problems. We're literally using ClosureScript for so many things. It's astounding how many things we use it for.
01:09:21
Speaker
And, um, I mean, it's a good thing, right? Because now, now your own, you know, as they say, you know, you're drinking your own wine or use the dog food metaphor. I was like, shitty, shitty metaphor or eating your own dog food. Yeah.
01:09:35
Speaker
Yeah, I mean, those are shitty metaphors. I was thinking, okay, you know, you're brewing your own beer and then drinking it. So that's much, much better. So I think it's good that you're going through quote unquote pain. So you're fixing that for the wider community. So that's a good thing, I think. It's a service we bring as vouch.
01:09:57
Speaker
We're all vouching for it. Probably the only other thing is performance. Every now and then we do performance spikes. It's nicer when... Actually, there is another thing which is better caching. Right now, caching could be a lot better, like builds. Builds could be faster in that if you've built something once, we should never recompile it.
01:10:20
Speaker
Currently, if your build gets corrupted, everybody blows away the target directory, and then we do everything from scratch. But that's actually silly. Why should we recompile things just because you erased the target directory? There's another project, which is an easy project too, which will be the local cache. There'll be a project local cache, which is not the target directory. When you blow away target, we're like,
01:10:49
Speaker
Who cares? We're not going to recompile that stuff. We're just going to move it over from the cache. I have a feeling that the performance work that you and Mike especially have been doing is actually something which Clojure can benefit from, the class path stuff and the caching stuff. It seems to me like I know there's definitely innovation coming from Clojure, but it seems like there's quite a lot of innovation going on in ClojureScript as well.
01:11:17
Speaker
It's true. I mean, some, I mean, another to your point, though, I think another thing that would be interesting would be, I mean, a cool way to try that is to be honest, is that somebody should experiment with a tool that just integrates with depth or as a new command that just, it's just a wraparound depth that says, what we're going to do is we're going to compile your dependencies for you behind the scenes and cache them. You know, I agree. I mean, a lot of the complaints about startup time,
01:11:44
Speaker
are just recompiling. I mean, a lot of people don't know like ClosureScript is distributed as an AOT artifact, which is slightly annoying sometimes because of transit, because transit's in there, but it normally doesn't matter because everybody keeps transit up to date, so it's not a big deal.
ClosureScript's Compilation and Efficiency
01:12:01
Speaker
But the reason I did this is because at least on my old iMac, which was a 3.4 gigahertz iMac, compiling ClosureScript every time took eight seconds.
01:12:13
Speaker
That's right. Every command that triggered the ClosureScript compiler would lose eight seconds just compiling ClosureScript. AOT ClosureScript loads in one second. So it's eight times faster to load ClosureScript AOT.
01:12:30
Speaker
Right, eight times faster. So that really means that for large closure projects, you're really getting burned if you're recompiling all your dependencies. It's really a massive waste of time. Yeah, it would be great to see people
01:12:48
Speaker
adopt ClosureScript strategy of compiling that stuff, caching it, and just loading that stuff. Incremental, yeah. Incremental, yeah. I think it's a fairly interesting way to do it. I mean, you do have to be smart with the cache. We use version numbers and all this stuff that we do to make sure that you're going to get the right thing. But I agree. I agree that that's a right area for people's
01:13:16
Speaker
experience, day-to-day experience, to be more responsive. Yeah, because it seems like the lesson of immutable data structures is this lesson that actually
01:13:30
Speaker
having things change looks like it should cost a lot, but in the end doesn't cost a lot. And it feels like there are some lessons to be learned, you know, like dog fooding, like you were saying, BJ, you know, in the kind of two-way space. You're drinking your own wine. Yeah. Yeah. Yeah. I'm sorry. Yeah. Whining. Yeah. You were whining? No.
01:13:51
Speaker
But I really like the stuff that like, uh, the people like Michael Borkent is doing in the growl VM, you know, cause that that's showing a lot of, um, a lot of potential there for super fast startup time. You know, Oh yeah. Oh yeah. I definitely, I definitely think there's, I mean, that's, that's in some sense, that ball is in the, in the, in the closure side of the court, you know, um, I definitely know that Alex is aware. I think he knows this, this is like,
01:14:20
Speaker
This is what, I think this comes up in the surveys. I mean, I think it's one of the biggest complaints is, you know, that's not like error messages, right? It's like, we would like our process to start up faster, you know? And I think that, I suspect that this will get worked on. Alex is very aware.
01:14:40
Speaker
But at the same time, to your point, as you know, I constantly try to convince people to solve their own problem. It's just like, man, you could just build a tool. You could just build a wrapper around CLJ, a vet that does this thing. And you can at least vet. What are the problems one would encounter? And how does it really feel better day to day? Are there other problems we need to solve?
01:15:06
Speaker
Yeah, well, I think that's what Michael Bockend has done with this small closure interpreter. Yeah, definitely. Yeah, it's really amazing. But what I was going to say was actually the other thing was this, because I mentioned it, I kind of came up to my head, which was the Graal VM. Because that's obviously got a JavaScript engine as well. Yeah, yeah, the Graal JS. Yeah.
01:15:28
Speaker
Yeah. And it's kind of like, in theory, you know, this notion of going back to like the painful times of dynamic reloading. What was this technology called? Durable. No, well, there was a sort of standard around it that... Yeah.
01:15:48
Speaker
Yeah. Oh my God. In Java? It was a good Java thing. Yeah. JVM thing. There was a JVM thing and it was a bunch of like, like ISO standards. It's for internet of things actually, where you could have reloadable code. Oh man, it's like O-D-M-I or something. I come up with the name of the damn thing now. Oh yeah, maybe. Maybe.
01:16:09
Speaker
So that was the Serone acronym, but it's something along those lines where you could just... No, you could just... OSGI, OSGI, OSGI, OSGI. Equinox and Eclipse and then OSGI. You worked it out. You got two characters right. Not bad, not bad. You're halfway there. A bit fuzzy logic with some smart people. We got it there. You only lost half of the characters. Not bad, yeah.
01:16:40
Speaker
So, OK, so because that's an interesting technology, you know, where you can just drop a new version of something in and bam, it picks it up because, you know, it got way too complicated. But oh, yeah, it did. Yeah, I mean, ridiculous. But the grass looks looks looks like that's got some legs as well. No, I do. And they've accomplished something that
01:17:00
Speaker
To be honest, many efforts have never achieved Rhino. Rhino couldn't do it. Nasshorn really couldn't do it. But Grohl has shown that much better than Nasshorn, that they were able to really narrow the gap between their implementation and node. Definitely for peak for performance. And I know that they're constantly working on the startup time problem. So we'll see where that goes. But yeah, no, I think it's very, it's very cool. It's very interesting.
01:17:27
Speaker
Okay. So, um, I think, wow, one and a half hour almost where we are reaching another recording. You said you could talk for an hour, David, and you've broken your own record there. By the way, how is this? I know, we know, David, you, I think last time you were on the podcast, I mean, it seems like ages ago. And, and, uh, at that time you were also doing some music with, with your band, right? It is still.
01:17:55
Speaker
Continuing or are you doing something? Well, I'm not I'm not I'm not in New York right now. It's like there's not that much going on at the moment because Yeah doing stuff online. It's you know, it's like your internet connection has to be good and all this other stuff. Yeah. Yeah, yeah, but I Mean I I'm still doing stuff and my collaborators still doing stuff, but we're not there's not much Collaboration happening at the moment
01:18:20
Speaker
But no, but in terms of being active, yeah, we're active. We, I don't know, like six months ago, we got a studio and stuff and we moved all our gear in there. And so yeah, there's stuff that's happening. Hopefully, you know, it's gonna be, I think for musicians, it's gonna be a pretty slow year, right? The next 12 months, it's gonna be slow. I just don't see venues and all this, all the other things that you need for live music coming back for some time.
01:18:50
Speaker
You know, it means that, you know, get in the studio, do a lot of recording, you know, do some live streams. I mean, that's probably what we'll end up doing. We'll record a lot. We'll do some live streams. But it's good. It's a chance to hunker down and write. Just, you know, you got to make do with what you got.
01:19:07
Speaker
Cool. So, I think we can take a, I think we can close on that musical note for now. It's really, really nice to have you back on the show, David. I mean, it's always a pleasure. And, you know, it's good that you're staying safe and everybody is doing good. Good to know that as well.
01:19:31
Speaker
And thanks a lot for sharing your ideas and also all the contribution that you're doing. So the GitHub-sponsored thing, is it just going to your user account on GitHub, right? And then click the sponsor button. It just goes to my GitHub account. And also, to be clear, the other person you should contribute to is Mike Fikes. So what I do is I generally do, yes, this patch, no, not this patch. Somebody wants to talk about it. We'll talk about it.
01:20:00
Speaker
I've also, for people that are listening to this podcast, if you're a user of ClosureScript and you have a question or you have a bug, use askclosure.org. I believe it's askclosure.org. That's the new Stack Overflow style official website that's maintained
01:20:19
Speaker
by Alex Miller from Cognitec. So bugs and feature requests, suggestions, all that stuff should go there. I have my RSS feeder reader hooked up to that. Every question that comes in now, I'm looking at that. So I do that stuff. I try to basically, I'm constantly doing community wrangling and
01:20:42
Speaker
working on new features and looking at the survey, figuring out where work needs to go, managing releases and all that stuff. But Mike Fikes does a lot. So the thing is that what I just described is a massive demand on my time. So that means I don't have that much time to look at Jira, make sure the patch passed all the tests, that CI is working, that we have a matrix of open source projects that reruns every time we push to GitHub. There's all this other stuff that needs to be done.
01:21:13
Speaker
testing tickets. There's, you know, Mike does a lot of that stuff. There's all this secondary stuff that I just don't have time for that Mike does. So it's really both of us that really keep the lights on around the ClosureScript project. And that's not, that's of course, not to say, you know, to downplay patches that come in patches do come in for contributors. But in the end, they have funnel through Mike.
01:21:38
Speaker
And then they get to me, and then we have to manage that process once the patch gets there. The long tail of work that has to happen for each small contribution that comes in. So if you're gonna contribute, I would say contribute something to me that you believe is reasonable for whatever thing, whatever you represent, a company, an individual, and do the same thing for Mike. It's really both of us that keep the project alive,
01:22:07
Speaker
again, as the sort of the process side of things.
01:22:11
Speaker
I'd also like to, you know, I'm not sure when, but of course, as things go, move along, you know, it'd be nice to investigate some way. To give back to individual contributors would be another one thing for us to look at. Like maybe there's a pool, we make a thing just around closure script and that pool is only for people who are contributing patches. My concern about that is that, you know, that's probably what's given the amount of contribution that happens, which is not small. Maybe that'll end up being like,
01:22:40
Speaker
not that much to go around. The other thing that I'd really like to see is I'd really like to see the ClosureScript community in general. Hopefully, ClosureScript can be a model, right? One way is to like, yeah, we're making millions of dollars with ClosureScript. We'll give David and Mike
01:22:59
Speaker
$200 each. Okay, that's cool. But actually, I think a smarter way for all open source communities. Think about it.
Sustainable Funding for ClosureScript
01:23:07
Speaker
It would be better for me if I was getting $5 from 1000 users of ClosureScript, right? It's better. I'm getting $5 from everybody that uses ClosureScript or every company that uses ClosureScript gives me $5.
01:23:20
Speaker
Every company that uses ClosureScript gives Mike Fikes five bucks. Every company gives Bruce Hammond five bucks, right? Like to me, the only sustainable model isn't like every huge company giving a couple people a large lump sum. It's saying these are the tools we use. We're using Fig Wheel, we're using Shadow, we're using ClosureScript, we're using HTTP Kit.
01:23:46
Speaker
Well, send freaking five bucks to those developers. Come on. That's like literally a coffee a month. But if everybody does it, wow. Wow. That's like great. So in some sense, I think that the individual sponsor or maintainer model is great if
01:24:10
Speaker
companies and individuals distribute a small amount and everybody collectively does it, then sending large lump sums to particular people.
01:24:22
Speaker
Yeah, I think that makes sense. So go and check out David's GitHub account and also Mike Fikes and the way you can contribute or sponsor. And it's not only to show how grateful we are, the amount of work that you guys are putting in, but also it's a
01:24:43
Speaker
As David, you said, it's much more sustainable when there is a large group of people are contributing. Obviously, ClosureScript has crossed that critical number a long time ago in terms of users. Go ahead and do that if you have not done it yet. But again, I want to reiterate, if you're a Closure School, ClosureScript or Closure Tool Maintainer, make a sponsorship account.
01:25:12
Speaker
Really, I think as a community, we could be a model. I think there are many ways that Closure and Closure Script is a model. I think the complexity thing, we're a model for people who are looking to reduce complexity. I also think given that we're still a reasonable size of community, it would be great to see Closure and Closure Script community show that there's a better way to do open source and it's a version of open source that really
01:25:42
Speaker
Everybody gives a little bit and then we all get something, you know? Yeah, I mean, it's more sustainable instead of, you know, people losing the interest or projects dying because of various reasons. I mean, people don't just do things, people don't do things for the money, but it certainly helps, you know? Oh, yeah, of course, of course. You know, especially if it's like taking time away from your family and stuff like that, you know, to give a day a week or two days a week or a lot more. You know, this is not
01:26:12
Speaker
This is not nothing. I think it's not. It's not. Not only is it not nothing, I just want to say, I mean, I follow closures together. And closures together is really great. Daniel Compton does it.
01:26:24
Speaker
Yeah, they only they only do like three or four people, three projects, not people, projects, they do three or four projects. I mean, people apply. But I looked and there's like 30 or 40 projects that apply that don't get it. So my my honest impression is that there are many, there are many projects in the ClosureScript community that need support. And
Closing Remarks and Audience Engagement
01:26:43
Speaker
yeah,
01:26:44
Speaker
that it's really not just about sending money to ClosureScript. I'd say if there's any tool, I know that there are other maintainers that have been working on things for years, just like we have, that could use your support just as much as we can. Good call. Yeah, totally.
01:27:00
Speaker
Okay. So, uh, I think, I think everything that, that needs to be said, I think David, uh, I just second, I think what you said. Uh, so sorry, 15 minutes longer. Hey, we, we, we don't mind. We, we, we are listeners. Oh man. David.
01:27:29
Speaker
I mean, they're happy that you're here. Otherwise, they would have to listen to Ray trying to remember stuff and me trying to figure out what to say. Oh, SGI, mate. Come on, we got there.
01:27:44
Speaker
Anyway, so thanks a lot David again and hopefully we'll do one more episode with you. Not with this amount of gap, like two years or something, but pretty soon again. So stay safe and that's it from us for this episode. Thank you.
01:28:02
Speaker
Thank you for listening to this episode of DeafN and the awesome vegetarian music on the track is Melon Hamburger by Pizzeri and the show's audio is mixed by Wouter Dullert. I'm pretty sure I butchered his name. Um, maybe you should insert your own name here, Dullert.
01:28:21
Speaker
If you'd like to support us, please do check out our Patreon page and you can show your appreciation to all the hard work or the lack of hard work that we're doing. And you can also catch up with either Ray with me for some unexplainable reason you want to interact with us, then do check us out on Slack, Closureion Slack or Closureverse or on Zulep or just at us at Deafened Podcast on Twitter.
01:28:48
Speaker
Enjoy your day and see you in the next episode.
01:29:15
Speaker
Mmm