Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#5 - Hoplon Special with Micha Niskin
58 Plays9 years ago
*Follow up*
We retain our status as the top vegetarian Clojure podcast. Phew.
Maria Geller’s video - in which she did a great job of explaining how the CLJS compiler works and provides some interface to the contribution process:
https://www.youtube.com/watch?v=Elg17s_nwDg
*News*
Euro Clojure - Bratislava tickets are on sale. Defn will be there
*Main discussion - ClojureScript UI - Hoplon Special*
http://hoplon.io
Welcome to Micha Niskin - co-author of the awesome Hoplon library collection
Potted history of Micha and the main goals of Hoplon
Hoplon - LISP based DOM manipulation
Javelin - Spreadsheet data flow model
Castra - CQRS, RPC
Comparison to React / Rum / Reagent
*Credits*
Special Guest: Micha Niskin. Thanks Micha and please look after those nukes.
Music: Thanks to the very talented ptzery for the permitting us to use his music on the opening and closing of the podcast. This track is Melon Hamburger. You can give his work some ❤️ and hear more on his SoundCloud.
Recommended
Transcript
Brexit and Euro 2016 Humor
00:00:38
Speaker
Right. Hi, okay, Deaf on episode five. Hi, how are you? Right, I'm very well. Yeah, very good. It's a good Sunday and I'm actually, I don't know about you, but I'm missing the football, the European Cup final to do this podcast and
00:01:02
Speaker
dedicate our time towards closure rather than watching the the French and Italians beat it out for Euro 2016. Okay I'm from India I don't I don't care about football if it's not cricket then we don't care so it doesn't matter. Well Wales got knocked out so the Brits don't care anymore either.
Podcast Ranking and Challenges
00:01:20
Speaker
There was a Brexit there was a big heavy Brexit in the Euros that's for sure. Yeah yeah.
00:01:25
Speaker
Anyway, yeah, so just a quickie follow-up. Apparently, we're still number one on the Vegetarian Closure podcast rankings. In fairness, there's only one in that ranking, but that's where it's the top of that. So this is the challenge to the vegetarians of the world who are into closure, so you can still beat us up. So let's see if somebody does it. But we're still the number one, so that's pretty good to know.
00:01:52
Speaker
We're throwing it down.
Engaging with Listeners: Slack Channel
00:01:53
Speaker
We're throwing it down. And we've been getting pretty good feedback, I think. Also, we have a new channel on Slack as well. So if you want to complain or let us know, just find us on Closureie and Slack and chat with us. And if you have any ideas for the show, we'd love to hear it. That'll be great.
Guest Recommendations and Praise
00:02:13
Speaker
So speaking of which, we had some follow-up from Alex, right?
00:02:19
Speaker
Yeah, from Alex Miller. After the last podcast, we were talking about potentially being a bit more open and transparent about the process. And Alex said, actually Alex offered to come on the show and talk a bit more about it as well. So I think we'll definitely queue that up.
00:02:37
Speaker
So that's a great offer and I definitely will follow that up, I'm sure of it. He also recommended having a look at Maria Geller's video from the last Closure Conge talking about a look behind the curtain of the Closure Script from Piler. I've got to say I hadn't watched it until he mentioned it but I watched it this week and
00:02:58
Speaker
she did a great job i've got to say i'm very impressed i mean number one i think she said she'd only been doing closure for a few months maybe six months or something even four months before she started doing this work on a compiler which is freaking amazing in my opinion so she's obviously smart but she's a great presenter as well she really makes it very easy to watch
00:03:21
Speaker
She explains things very well and then she ends up talking a bit about how the contribution process works as well, which is good to know. I still think there's more detail to be had from that. I still think that we can go into more detail with Alex about that kind of stuff, but I'll put the link to Maria's video in the show notes because I think she did an awesome job there.
Euroclosure Event and Humor
00:03:46
Speaker
So the news, we are going to Euroclosure and the Euroclosure this year is going to happen in Bratislava in Slovakia and the tickets are on sale. Did you buy your ticket actually? I don't think so because me and I'll be traveling with my wife as well so we both of us will be there for a week in Slovakia and of course the Deafen will be there right? I think you got the Ellyberg one right?
00:04:13
Speaker
I got an early bird one, yeah. Absolutely. I think I could single figure. You know what? I'm a vegetarian, so I don't really eat worms. So, you know, early bird gets the worm and I'm okay. So that's why I'm being a late bird. I'm happy with the fruits and stuff.
00:04:29
Speaker
But yeah, so I think it's going to be a blast, I suppose. So we'll be there and hopefully we'll catch us. Maybe we'll do a special episode there if we can drag our equipment there, the whole microphone. So we'll see. Well, I'm going to bring my son along, actually. I'm going to bring my 16-year-old son. He just finished school recently. And I'm going to get him to be my multimedia lackey. He doesn't know that yet.
00:04:57
Speaker
At least I'm hoping. He's definitely agreeing to travel with us. He thinks it's just going to be a holiday. I'll let him know a bit later that he's actually going to have to work for it. So far he just thinks it's a great end of school trip. Hopefully you won't listen to this podcast and find out there's a nasty surprise waiting for him.
00:05:17
Speaker
Right, anyway, yeah. So we'll definitely be back. Let's get
Introducing Hoplon and Ray's Presentation
00:05:20
Speaker
on to the show. So I know we promised we're going to look into asynchronous programming and stream thing. But as you know, we are very flexible and agile. And we are one of the most awesome podcasts ever. So we decided we're going to make it even better. So what we did this time is we're going to discuss Hoplon.
00:05:39
Speaker
And I have very, not very, I mean, very less knowledge of Hoplon. So I thought it would be better to, of course, I know Ray has given a presentation in Belgium meetup and I heard that it's a roaring success with half a dozen people showing up.
00:06:01
Speaker
Carefully selected crew, I think you're talking about here. Highly curated. Yeah. It's like the elite of closure in Belgium. Actually, to be honest, it was one of those things where I didn't know enough about it. So we're going to do a little trick now.
Mischa Niskian on Hoplon's Origins
00:06:18
Speaker
Yeah. So we decided because instead of two less
00:06:24
Speaker
intelligent people speaking about Hoplon, we decided we're going to bring in the experts. So on that note, I'd like to welcome Mr. Mishia Niskian. Hello. Hello. Hello, Mishia. Hello world. How's it going? Pretty good. That's going great. Happy to be here.
00:06:47
Speaker
Yeah, so. All right, good, good, good. We need to tell you that we are the world's best or the, yeah, obviously world's best podcast of vegetarian closureians. So welcome to the world's best vegetarian closureian podcast. So are you into vegetarian food? You told me Misha that your favorite food is a vegetarian food. Is that right?
00:07:09
Speaker
Yeah, yeah, I would I would never want to like participate in some cut rate vegetarian closure situation. Only the best is good to know exactly this is the best one. So you're on the right right podcast for that. Yeah, you can make the tarnish your reputation with substandard vegetarian
00:07:29
Speaker
Podcasts. Podcasts, yeah. That's true. Yeah, you wouldn't want to know about those guys, yeah. Thankfully, we haven't got a splitting of that particular group yet. Maybe I'll just edit this out, actually, because we couldn't fucking know where.
00:07:45
Speaker
Anyway, no, leave it in, leave it in, leave it in. All right, good. Mischa, come on, let's talk about Hoplon. Mischa, tell us, just before we go there, Mischa, I know this whole Hoplon story started a bit before your current work. So can you tell us a little bit about you and a bit about kind of like the Hoplon story, where it all came from? What was the origin story of this technology? Sure. Alan Deypert and I have been friends for a long time. We met in the army and
00:08:16
Speaker
Yeah, we served together, and later, and we both were like, we were not doing a computer-type job. So we were the only kind of computer people there. So we became friends, and later we were working together in like 2011, 2012 at this place, The Fresh Diet, where we made food and sent it to people. It was like a 250,000 lines of PHP type of situation.
00:08:42
Speaker
So some of the things that they needed to do, we just couldn't do it. And we decided to make our own solution. And yeah, we did.
00:08:56
Speaker
Did you have experience of closure before that? Or was that something where you decided to where you first learned it? Yeah, Alan actually demanded that I try closure. Like I was I was doing like some stuff with skiing at the time. And I remember he was like, Scala, you should look at it. It has reduced. It's awesome. And so I like got the book and like on a page 120, they were still introducing new syntax.
00:09:20
Speaker
And I was like, don't ever talk to me again about any of this nonsense. And the next thing was closure. And I was like, oh, look at all that syntax. I don't know, dude, but it turned out to be the best thing ever. So. So, yeah, I've been doing closure. It hasn't got that much syntax, is it? No, but I mean, compared to just just just just a moment here, you know, it's just a competitive scheme. Yeah. But it depends on which version of scheme you're talking about, because that's still got. Yeah. OK.
00:09:46
Speaker
Yeah, that's true. I mean, I'm not complaining. Closure is great. And, uh, you know, it's improved the quality of my life. Like the, my actual day to day living is actually way better because closure exists because most of my time is spent programming and closure is way better. Yeah. Yeah. You've got a lot more, you've got a lot more options, haven't you,
Why Not Angular or Knockout?
00:10:07
Speaker
with, uh, closure than you have with scheme in terms of libraries and all those kinds of things.
00:10:12
Speaker
Yeah, and just the engineering is like, we were talking, Alan and I were talking about, you know, like reference types, comparing to ML and stuff, and just like the engineering of how reference types work, that, you know, you have this, whatever, you have a defined semantic for updating a mutable thing, and that you could watch it if it's a mutable thing. It's amazing engineering, like stuff like that is all throughout Closure, and like, I learned a ton just looking at closure.core, like about computing.
00:10:39
Speaker
You know, right. Right. Yeah. Yeah. Yeah. Like the whole STM thing is just phenomenal, isn't it? Okay. Let's, um,
00:10:48
Speaker
Yeah, let's get into the topic of the hand. I know that you guys are working really hard with different kinds of libraries that you're releasing. I know you're busy with boot and a lot of amazing things that you guys are building. But for this podcast, we'd like to discuss something more about the Hoplon framework and the whole libraries behind it.
00:11:09
Speaker
So, you know, you know, there's this trio of trilogy, not only trilogy, but the three holy trinity of Hoplon, I would say, like Hoplon and Castra. Yeah, the pillars. So let's talk about Hoplon. So where did Hoplon come from? And what is the what is the fundamental
00:11:33
Speaker
aspect behind it. So I know that there are lots of web frameworks out there, starting from jQuery and history, you know, you did a lot of DOM related things. So can you give us some some quick overview of Hoplon, what it does.
00:11:45
Speaker
Sure, yeah. Maybe like a tiny little intro to our state of mind. Alan and I both, throughout my whole career up until I discovered Closure, I would make these applications and every time it would get to a certain point, usually I would release the thing, the first iteration of it to the stakeholders and whatnot, and they would look at it and
00:12:08
Speaker
make changes, and as soon as their changes started coming in, things would start unraveling architecture-wise, like you add magical arguments to your functions, like special case one, true or false, you know, that kind of stuff. And pretty soon, like you're at paralysis mode, which is where we were at with this PHP application, where making any change is like this death-defying thing. But with Clojure, and with Lisp in general, like I think
00:12:34
Speaker
I feel like we're actually solving problems like Javelin, we haven't updated it in years now. We haven't needed to add any features to it. We just solved the problem and that's all we need and that's it. I'd never experienced that before. When we discovered this, we were like, man, it makes sense to invest in making frameworks and things because we could just do it once and then we use it for the rest of our careers to do stuff, to get other jobs done.
00:13:00
Speaker
And so one thing we noticed at the Fresh Diet was that in an ordinary amount of our time, developer time was spent dicking around with the UI.
00:13:08
Speaker
you know, getting the UI to work on something that's trivial, you know, like when you click this button, that other thing should disappear, but then this other form should show itself, or whatever. And it was so hard to do it, and it took so much time, we were like, it makes sense for us to make some kind of framework, because we believe that it can actually be a solution that will not be like, you know, so.
00:13:31
Speaker
Yeah, so. But PHP is on the server side, so on the client side, you have jQuery, so why would you want, I mean, okay, forget, this is pre-react, isn't it? This is pre-Angular. Angular was around. So why wouldn't, oh, is it around? Okay, so why would you reject?
00:13:51
Speaker
it's maybe it's harsh to say why would you reject them but why did you say okay well angular or jQuery or Ember or Backbone or all those little frameworks around what was the what was your thinking to say well those guys don't fulfill what we need
00:14:08
Speaker
Yeah, the main things that we investigated first were Angular, Knockout.js was another thing at the time. Oh, yeah, Knockout. And then we made weird hybrids of them, and one of them involved making Jekyll, generating static sites and then adding Knockout to it after they'd loaded, all kinds of crazy things.
00:14:27
Speaker
And, but the problem with all of those was that we decided that we needed a program that ran in the client, which is something that's obvious to us today. Like I think everybody kind of agrees on that, that like maintaining state in sessions and.
00:14:42
Speaker
redirects with URLs and stuff like that is just not, you can't form abstractions there. Like that makes all your abstractions leak by necessity. So you need it to have the things that make abstractions work are first class representations of things, meaning like that anything you have you can make an anonymous version of it. So those are things that you can't do when you're storing stuff in sessions, you know what I mean? Like when you have to hydrate and deserialize and so on.
00:15:07
Speaker
in order to build up the state for every request. So we decided that we needed something that ran purely in the client. And we decided on a list. And we initially had our own crazy. Hlist was actually its own list, because ClosureScript didn't really exist. It was pretty crazy and not great. So thank God for being rich in ClosureScript.
00:15:33
Speaker
So you actually had it even before closure script, in fact. Yeah, yeah.
00:15:39
Speaker
Wow, I didn't know that. It was pretty not great. But we had F expressions and stuff. Basically, we just spent all our time playing around in 1950s Lisp technology. Right, OK. So you're writing on evaluators at the same time. Yeah, yeah. It's pretty sweet. You want to read this? OK. Got paid to do it, kind of. But yeah. They didn't know, but you got paid for it. It's a nice thought experiment. Right.
00:16:08
Speaker
Yeah, I mean, it was an actual experiment too, unfortunately, but... Yeah, yeah, yeah, that's true. Yeah. So I think you should have left it at... Do you think you should have left it at the thought level instead of implementing it or what were the insights that you got from doing this one apart from, hey, let's not do that again? From making the Lisp? Yeah, it was...
00:16:30
Speaker
I mean, I think we just learned a lot, I learned a lot about how Lisp works, you know, making it and then optimizing it and stuff, and you know, and also what we needed from Hoplon, because it was basically implementing a lot of the Hoplon stuff in kind of... Behind the scenes, Hoplon uses jQuery, right? Or does it? Well, anything that works on the web today needs to use some kind of DOM standardization interface.
00:16:59
Speaker
And we picked jQuery just because it has like 70% of all the websites
DOM Standardization with jQuery
00:17:06
Speaker
in the world have jQuery running on them versus for the Google Closure library, it's like 0.0005%. And so we started running into bugs there. And I just had zero inclination or bandwidth for fixing cross-browser bugs. And jQuery is 34k.
00:17:29
Speaker
And so that. Well, so I guess you know that most people have already got jQuery as well on their PC or their phone or whatever, because if you see the end, everyone's got it from their other website visits. Yeah, I mean, also like another thing that's important, I guess, to note is that like our interest is in making business applications. You know, so we want to make like what I want to be able to do is concentrate on the functionality of the back end and have the front end be as straightforward and simple as possible.
00:17:59
Speaker
And I just want to make business out like interfaces for applications that people are making money with. So a lot of the things that you would get from like, like we're not implementing, you know, Instagram, you know, or things like that, or like Twitter, like show somebody some some tweets, like we're implementing workflows and things like that.
00:18:19
Speaker
which is like an important consideration because stuff like load time, loading an extra 34K of stuff is not a problem for these people because like Gmail, you keep it open for a long time.
00:18:30
Speaker
So I remember before the show, you were discussing about web components. And you mentioned that one of the things that you played with before was the WebFUE thing, right? So can you give us some idea about what your opinion on the web components and how it fits into Hoplon and the WebFUE, of course?
00:18:50
Speaker
I mean, WebFooey is a kind of different thing. It's sort of like the pre-react-react. It wasn't so much about... It didn't have such a... Well, maybe I just didn't know, but I didn't see a very pervasive component story. He was more interested in the React, the virtual DOM experimentation.
00:19:12
Speaker
Which was super cool, I remember seeing it at the conge and thinking, good job dude, very nice. But like the main thing with Hoplon, the thing that we really wanted to accomplish is to have a very, very strong component story so that you can make building blocks. So like the way I see a user interface for a business application especially is you have a, you know, you make a toolkit of components and then you assemble those into an application.
00:19:42
Speaker
where the application itself is just an assembly, kind of like what we did with boot. When you make a boot script, you're just assembling tasks that are decoupled from each other. You assemble them into a thing.
00:19:55
Speaker
Yeah, but this has been done multiple times, right? I mean, people have been trying to achieve this holy grail of getting web components right.
Building Strong, Reusable Components
00:20:04
Speaker
I mean, back in the days with flash rear things and then, of course, Java saying, yes, you can build the whole applet stuff and then you don't need to worry about the DOM at all.
00:20:13
Speaker
And the DOM became like a very least common denominator. So it's very difficult to get components that people can share easily with each other. So what do you think about that?
00:20:27
Speaker
Yeah, so the reason why we arrived at Hoplon is because we determined, in our opinion, that the issue with all those attempts were that they make a fake DOM. So you're not actually operating on DOM elements themselves. And so there's this impotence that causes your abstractions to start to leak. You have to start making all kinds of special case arguments and stuff. And so what we wanted to do was
00:20:57
Speaker
So we looked at HTML, and HTML is a programming language already. It's just a very poor one. It doesn't have any means of abstraction. But it does get parsed, and it gets parsed into an abstract syntax tree, which then gets evaluated, which becomes a document object model, where things become objects.
00:21:20
Speaker
We realized that with closure, all we needed to do was add an invocable, add ifn implementation to make DOM elements themselves invocable, and we could achieve the goals of web components in a lot of ways.
00:21:36
Speaker
Well, everyone says, don't they, that like XML is a kind of poor man's lisp. And so HTML is a form of XML. So yeah, you're right. When you squint, it makes sense that you can take each of the DOM elements and essentially treat them as an S expression. I think I would say it's more like a sadomasochistic version of lisp. I mean, it's not actually a poor man's lisp. The sharp brackets actually, they pierce into your eyes.
00:22:06
Speaker
You know, on the other hand. At this other startup I was working at recently. That's bracketist. You do know that, don't you? Yeah, I was working at this other startup where we had to parse like tons of crazy XML soap stuff from like, you know, the travel, the OTA. There's like this travel thing. It's like enormously enterprising and everything. And so like I was working on this library that I called XML SVU.
00:22:32
Speaker
Which was, yeah, making it invocable. It wasn't a complete success because I kind of ran out of steam. Okay, so Hoplon is essentially the UI level thing that used to build the front end.
Designer-Friendly to Developer Utility
00:22:48
Speaker
And there is this always a discussion about every time when people make a web framework, they keep comparing that, hey, we want to make it friendly to the designers so they can write HTML.
00:22:58
Speaker
So if you see most of the newer applications, they try as much as possible to make the front-end very HTML-like. So what is the story in Hoplon for that? So designers can write HTML or
00:23:15
Speaker
Yeah, we started out with that because that was basically where we were at business-wise. In other words, the fresh diet, they needed a thing that they could put designers on, and it needed to work well with them. So that was something that just fell out of the design of it, like we could evaluate HTML. In other words, HTML can be transformed into S expressions. So we did that, but now we've kind of moved away from that to a more, like an even more utilitarian view, which is that
00:23:44
Speaker
we don't need to have, like at the fresh diet, the marketing department had like a huge say in how things worked. And, but like at Adzerk say, we're dealing with, you know, it's like business to business. We're dealing with professionals. So utilitarian is the most important thing. So we're not really that interested in, you know, making everything ultimately pretty, although Hopland can still do it, you know, but like, that's not like where we're kind of focusing ourselves.
00:24:14
Speaker
So you imagine that developers are mostly users or developers rather than designers in other words. And so you're thinking like bootstrap-tastic and enable the developers to make the most straightforward UIs to get the data in and get it out and get it represented rather than the kind of
00:24:37
Speaker
beautifully pixel perfect finessed UIs that maybe these iOS apps might dream of. Right, I mean like at Adzerk for our application, we have an excellent designer who made us, he based it on Bootstrap but he could have done anything like, but he made us like a UI kit and we just used that. And so he gave it to us as HTML and we transformed it into components.
00:25:04
Speaker
OK. So before we move on to the next topic, I'd just like to ask you one question. So how independent is this? So can I use just Hoplon UI with any of the frameworks that I can play with, or is it very tight to the two other pillars, like Javelin and Kastra? No, they're all just libraries. So yeah, you can just, from any ClosureScript application, you can just pull in the Hoplon dependency, require the namespace, and use it.
00:25:34
Speaker
Oh, okay, that's weak. Okay, let's talk about javelin then. Just before we move on to that, just one quick final question. Final question is, how well does it play with the Bootstrap closure script stuff? Is it just all drops in or is there anything special? You mean like closure script and closure script?
00:25:55
Speaker
Yeah, that's something I'm not. I'm definitely want to look into it because I'd really like to have eval for like the spreadsheet aspect would be really nice. I just haven't had time to figure out like how macros exactly work in that environment, but.
00:26:10
Speaker
Yeah, I'm also curious, I don't know if you guys know, but I'm curious about, could you compile ClosureScript and ClosureScript and then run it through the Google Closure Compiler? Like instead of using the Closure... Yeah, yeah, yeah, yeah. I think the Clips thing is basically that, right? You write ClosureScript and then it's gonna compile using ClosureScript, but I'm not sure whether it is using the Google Closure Compiler there. I don't know, maybe we need to look it up.
00:26:40
Speaker
But I'm sure, I'm sure plenty of audiences will be happy to let us know. Hey, you're wrong. Wants to follow up on that one. Wants to follow up. Yeah, that's definitely something I've been experimenting with. So, cause I really do want to have like in, in client access to eval too. Yeah. Yeah.
00:27:00
Speaker
Yeah, to make it more dynamic and so you can embed Hoplon in other kind of environments. Yeah. Okay. Good. Okay. Cool. I didn't know if it was going to be anything special required there to make that happen, but I guess not, but it will just be more about exploiting the capabilities of that environment office. Yeah. We'd have to rewrite some macros to be cross platform, you know?
00:27:24
Speaker
Right, okay. So how difficult is it to get into Hoplon's code? So what do you think? I mean, if people want to contribute or people want to, what are the open-ended things that we can get into? Do you think is that contributing more components or what is the entry point?
00:27:42
Speaker
Well, so there's a few projects going on. One of them that's really interesting is Skye Jumbler on Slack. He's making a really interesting UI component library on top of Hoplon, which is really like what we want. That was our goal, is to end up with these kinds of things. So that's had like a bunch of activity. So there's a number of contributors and commits every day. It's still kind of like alpha,
00:28:11
Speaker
Um, but that's like, yeah, that's totally what we want to achieve. So all kinds of things like that hop on itself is really, really simple. Yeah. So, you know, we haven't, I mean, we're adding, we're making some changes now, getting ready for a new, a new major version. So we're deprecating some things and, but there's not really that much to it. So there's no real roadmap for it. You know what I mean? Like, yeah, there are some problems that need to be solved.
00:28:40
Speaker
As you said, you know, you just made something that is going to last forever. So that is going to make you more productive over the period. So I think it's pretty stable right now. Yeah. Yeah, I guess the other thing I was just going to ask you about, Michelle, just quickly is all these other functions, like we mentioned, jQuery and stuff like that. How does it play with like CSS frameworks or other JavaScript frameworks?
00:29:04
Speaker
Hoplon only uses jQuery for a very, very small number of things, like specifically dealing with attributes, which we found was buggy in Google Closure Library, things like that. Because attributes, as we know, are not always properties of the element. They need to be special case for different user agents and so on. So that's the one place that Hoplon Core uses it.
00:29:30
Speaker
And then Hoplon has a concept of custom attributes, which are like attributes that you can define how they behave as a multi-method. So every element, so you could have like a fade-in attribute, right? That when you turn it to true, the element fades in to visibility. Or if you set it to false, it fades out, right? And that can be, that attribute can be applied to any element. And so a lot of the default implementations, the default attributes that come with Hoplon are implemented using jQuery.
00:30:00
Speaker
But we're planning to separate that out into a separate namespace, so it'll be like the jQuery dependency will be optional. Right, okay. So you could potentially use other little frameworks like Zippo or something like that.
00:30:17
Speaker
But okay, so that's like in your core. But what about if I want to use, I don't know, some other like, like, let's say I want to use a CSS library, like less or something like that, or if I know there are like CSS modules now that you can, you can bring in a JavaScript modules. How would we, how would we do that in Hoplon?
00:30:40
Speaker
There's no, Hoplon doesn't have anything to do with that. You can just use them. And most of the time you can just use jQuery plugins directly because you're dealing directly with the DOM. There's no complication of making it compatible with the DOM.
00:30:55
Speaker
Now what I mean is, let's say you've got a table called foo, but the name of that table is foo inside of a Hoplon page. Is that still called foo as far as the CSS is concerned? The selectors can still use the name foo. If you set the class, sure. Or the IDE or whatever. Yeah, OK. Yeah, I mean they're just regular DOM elements.
00:31:18
Speaker
Hoplon doesn't. Okay, so it's not name mangling or anything like that. There's no special ceremony to introduce all of these things on top of Hoplon. It's just all plain vanilla stuff. You don't do any mangling or name changing underneath the covers. Nope, not at all, yeah. All right, okay. Yeah, that's one of the things, that's the thing that Hoplon does is it allows you to program with the actual DOM. So there's no magic or funny business going on at all.
00:31:48
Speaker
Right, right, right, okay, so when you look at it on the browser tools and all these kind of things, it's just looking like straightforward DOM elements. Except for IE8, IE8 has like a weird, you'll see some weird things in IE8, but yeah, but it does actually work, we have tests and everything. You said business applications, so you know, IE8 is like the standard thing for probably, I don't know. We have moved on, so we have moved on from IE8, luckily, at least in the work that I'm doing.
00:32:19
Speaker
I think most business applications have moved on from IE8 as well. If in a business applications, we're all using more modern environments. It's actually, it's worse for consumer environments where the consumers out there are 20% of them are something or 15. It's always diminishing year by year, but there's still probably 20%. If you want to reach 100% of all users, you have to include IE8. Well, 97% plus. Luckily, Adzerk doesn't care about IE8.
00:32:52
Speaker
Do you have a shim or something or do you have some special code to deal with IE8? No, we wrote it. We special case some things. Our thinking is that if you're making something that works in IE8 and works in a modern browser, you're going to have your own special cases too. True. I mean jQuery helps you as well I guess.
00:33:16
Speaker
Yeah, yeah. All right, cool. Right. So anything else you want to talk about with Hoplon before we move on to the next pillar? Nope.
00:33:28
Speaker
No, okay, awesome.
Javelin's Spreadsheet-Like Approach
00:33:30
Speaker
All right, it's good. So the next one we wanted to talk about was still really kind of like the, let's say the jazzy stuff in the Hoplon ecosystem is this Javelin spreadsheet, functional reactive programming model that you have, because everyone's crazy for FRP on the client side now. No one knows what the fuck it means, but everyone wants it, you know? And especially since
00:33:57
Speaker
And again, I don't think people know that React says it. It's one pure function of rendering, whatever that means. But I think people feel somehow that FRP is the hotness. Obviously, Elm has helped to make that the hotness in San Francisco. But where are you coming from in terms of FRP and spreadsheet models for Javelins? I know that's something that you're excited about in this framework.
00:34:22
Speaker
Yeah, we were, we've been like kind of fascinated with spreadsheets for a long time. And, you know, we made applications with Angular and with Knockout. So we had some experience with like some observable type situations. And then we just like
00:34:39
Speaker
went in and, oh, we found this paper for this library called Flapjax. I think it was a Microsoft research project. Yeah, I think that was very long time ago. It's a Lisp thingy. I remember subscribing to their mailing list. That was pretty amazing, by the way. Yeah, they were like schemers and they wrote their JavaScript in a really weird, schemy way, which is pretty awesome. That's true. All their curly braces end up on the same line or something. Exactly.
00:35:09
Speaker
So they were really kind of working on this principle that JavaScript is a form of skinny. I think so, yeah. But it didn't have enough support, by the way. I think it was a long time ago, somewhere in the 10, 15 years ago, maybe. Anyway, that's interesting. I mean, the crucial thing that we got from that was the dependency graph and how that
00:35:32
Speaker
The concept of glitch elimination, they call it glitches. And so we had this thing that we were already working on called declarified.js or something like that, which allowed you to make a spreadsheet, basically, but using attributes declaratively, whatever. It's kind of confused. But what it did was it did dirty checking. So in FRP, there's these two competing things. And one of them is dirty checking. And the other one is dependency graphs. And with dirty checking, that's very similar to what React does, is you evaluate everything.
00:36:02
Speaker
And you detect what changes when it's time to make side effects. Right. And so like with a spreadsheet, what you might do is you might just evaluate every cell, every formula, you know, from left to right, top to bottom. And you keep doing it iteratively, like the way closure expands macros until it stops changing. And then you know you're there.
00:36:21
Speaker
And, uh, but this doesn't work very well. Like when you're making an application, because like you might get the right values in the formulas, but a lot of times you need, you need those values to schedule side effects, which are the thing that really matters like launching the nukes. You need to do that. Right. Yeah. And so what we would end up with is, uh, we came up with like this test called the, I don't think there is a right way to launch the nukes. I mean, well, doing it only once is smart, right? Yeah. Oh my God. Yeah.
00:36:50
Speaker
But speaking of the whole spreadsheet model, so what is behind it? So Javelin is basically a ClosureScript library, right? So what do you use in behind? I mean, do you have an atom with watchers? How does it actually work?
00:37:08
Speaker
Yes, so the Atom with Watchers, you end up with glitches, which is when things happen out of order and they, for a certain amount of time, have the wrong value, you know? So the way we eliminated that was by making a new reference type. So in Javelin, cells are first-class objects, meaning you don't need any macros to work with them. So we have a bunch of macros, but that's just, you know, syntax.
00:37:31
Speaker
The macros just expand to function calls. And so we made a new reference type. And in Clojure, a reference type is a thing that has some semantic for updating it. It contains a mutable thing, but it itself is immutable. And you can watch it.
00:37:45
Speaker
And so we implemented that. And the unique property that javelin cells have are that they respect the dependency graph. So if a formula depends on cells, it will never update until all the cells that it knows about have already updated.
00:38:02
Speaker
So in effect, it's like storing all your stuff in one big atom. In other words, you get the same atomic view of the world because any given part, the view of its world, is that it's the last one to update.
00:38:17
Speaker
OK. And so how about the local state? So I know that there is, when Aum came in, we wanted to keep the entire application state in one atom. And there has been some discussion around how to keep the local state, like the form validations and these kind of things. Because then you're essentially putting everything onto the global application state, where you want to have a temporary state. And that made the whole tree very unwieldy, especially if you have multiple forms.
00:38:46
Speaker
So how does this work in Javelin then? Or in Hoplon? So with Hoplon you have a real reference type. So you can make anonymous cells, you can, you know, all these things are possible, so you just use regular Lisp. So you use the scope mechanisms that are
00:39:04
Speaker
that are the foundation of Lisp. So you could use lexical, global, dynamic scope, whatever you want. And that's how we organize it, rather than needing to make cursors and things like that. And the problem with cursors is that essentially you've, like when you have the big atom approach, you've essentially recreated the concept of namespaces, but like in a poor man's way, when we have real namespaces.
00:39:28
Speaker
And where you would run into problems there is with things that need to be anonymous, because how do you make an anonymous thing in a map? You have to gensim something, maybe, I don't know. So just to clarify a little bit on that then, so what you're saying is your one big atom is mostly for this dependency network, but it's not for everything in the application. Well, I think all the things, it forms, it emerges.
00:39:57
Speaker
the units of atomicness or whatever are emergent meaning like you set that up so you can have as many input cells as you want and these are basically the places that you can call swap on.
00:40:10
Speaker
And then there's formulas that are dependent on those, you know, derived state. And so like an input, you know, a number of input cells plus all the things that depend on them, that forms like one atomic unit that's sort of like a big atom, but that you don't need to have a map and address things via keys in the map. You can just use vars and address things as by evaluating their symbol.
00:40:33
Speaker
Okay, so you're always referring to the thing that is being updated, like the value that you see in front of you rather than some side thing. Yeah, and you're not looking things up in a database, you're operating on first class objects rather than proxying that object into this giant database.
00:40:48
Speaker
Yeah, so how does so remember when I remember when almost announced and one of the biggest things that David Nolan pointed out is that you can actually do undo and redo sort of thing. So you can actually go back in the in the state. So does it translate similar on hop on as well or
00:41:08
Speaker
Well, OK, so I have two things. First of all, yeah, you can do that in Hoplon. We have a tic-tac-toe game that implements undo in one line, because you just have a vector of states. So every time the state changes, it puts it there, and you can pop it and push it. And there's a cell. So the state is a formula cell, which is just the first item in this stack.
00:41:29
Speaker
But however i should say though that like in my actual work all this stuff is useless because you know i'm making business applications that have workflows you know and people's money is actually you know we are actually launching nukes all the time you know those nukes being people's money and so like
00:41:48
Speaker
you launch a nuke and then you press undo and the UI rewinds to the state before you launch the nuke, Moscow is still getting torched. It's not helping you. And the fundamental problem, I think, is that the state of the user's brain and understanding does not rewind when you press a button. So I think at the end of the day, you're always going to need a situation that's more like Git, where you make a reverting commit.
00:42:12
Speaker
And you always need like, like when you change your password, right? A thing comes up saying your password was changed successfully. What happens when you undo that? Yeah. Yeah. And I think that one of the, one of the things when I saw the undo things, I completely agree with you. I mean, undo is basically like the user level things. I mean, okay. I typed something I just want to undo and it's, it's not, it's not useful for applications where as you say, everything is backed up by a business process.
00:42:41
Speaker
But it's useful for if I'm doing a document editing or something like Photoshop, you know, you have this undo history where you can actually go back to the things. But there I think it's also I remember when Photoshop first came in and the initial versions, they also have the limit like you have like seven or ten things and then you could only undo for five or ten and then
00:43:02
Speaker
Every time I had to remember that, oh, shit, I need to reset the number somehow. And then they introduced another thing called snapshots. So every time you can have a snapshot, because it can become very unwieldy because you keep adding the state again and again and again. And you obviously don't want to go back to the original. So that kind of stupid.
00:43:20
Speaker
Yeah, but that was a bit weird though, wasn't it? Because in those environments, you had to put so much on the stack, it was probably hellish, you know? Whereas obviously it's a much lighter weight enclosure. The only thing that's like, the problem I guess is that there's two parts. I mean, obviously the example people give is like the drawing applications, like you say, and that's where the demo that people, that David Nolan gives for instance, is the drawing app where you can undo things. And that's not a business app, I get that.
00:43:50
Speaker
But the other thing is that on a form, say if we're undoing form entry, which is another interesting example is, let's say you have a form that has 10 fields, you've really got a choice of either undo per, okay, if you're typing something in a field, like a text field, the browser supports undo in that environment.
00:44:14
Speaker
But if you've put something in one field, then put something in the next field, then put something in the next field, the only way the browser will support undo across all of those fields is by pressing the cancel button. So I guess there are small use cases where you might want to undo one or more of those inputs. But I don't know. It's definitely an edge case. It's an edge case. And it's doable. It's trivial to implement in Hoplon, just as it is in any ClosureScript application that
00:44:42
Speaker
Because you're basically just saying, look, I just want to maintain the state of this thing somewhere. So just pop it onto a vector and off we go. Yeah, that's what we do in like the tic-tac-toe game, you know? Yeah. Okay. So in the spreadsheet model, there are formulas for each cells and then a cell can update the other cell or a formula in a cell can update the other cell. And so how do you handle the dependency between them? If I have a cell A,
00:45:08
Speaker
A1, for example, to speak in Excel parlance. So you have A1, and then you have B1, and then the formula in B1 actually updates A1. So it's basically a circular dependency. So how do you avoid that one? Yeah, that never really comes up. I mean, you can't do that in spreadsheets, in most spreadsheets either.
00:45:28
Speaker
But usually you don't want to program that way. So that's one of the big things. Javelin isn't really FRP. When we first released it, we wrote FRP because that was the word. And we had done all this research, and we had read all these papers, and all of them were FRP. But then we didn't use all this FRP stuff. Most of the time, these FRP papers would end up like, how do you do Fibonacci in FRP? But we don't want to do any of that.
00:45:53
Speaker
So javelin is the layer for piping information piping flowing state around. So it's like a data flow is what we call it now. And so the idea is that all of your actual work happens in functions or whatever and you can separate those out. You know and just it's just the flow of state.
00:46:13
Speaker
One small example I think that I saw in the early days from the FRP crowd, because I think the FRP crowd are also interesting, all the signals and events and merging, all those kind of things. So there's a bit of a, like there's two parts to it. One part is like the spreadsheet bit which says, if I change the value in
00:46:34
Speaker
a1 you can tell that vj is doing an nba now because it's such an excel guru you have to take the cell in a1 so that means that the value in a1 is changed so the formula in b1
00:46:49
Speaker
which is like a calculation, 10 times that value, that gets updated automatically. And that's all great. So that works in Javelin. The classic FRP example, I think, is where you're looking for a username in the database. So you start typing out the username and then letter by letter, you start to look back on the server and see which names are available.
00:47:15
Speaker
So do you have that kind of feature as well where you can treat all the inputs as signals, or is that the bits that you're not really implementing? Well, the terminology that we're most familiar with is behaviors and event streams.
00:47:32
Speaker
So I can never remember which one is the signal and which one isn't, but anyway. Behaviors are things that always have a value, and you could look at them at any time. And event streams are things that have instantaneous values. And we decided that we didn't want event streams at all. We had no use for them. They weren't helpful in the conceptual model in any way.
00:47:54
Speaker
Because if something doesn't have a value at all times, that means that you have to have a callback to catch the thing, and that now the order that those things happen in is important. Whereas with behaviors, the dependency determines the order. So it's not even something that's under your control. And the fact that it always has a value means that you can use all the things that reference types are good for.
00:48:22
Speaker
to relate to, so you could dereference it at any time, things like that. And if you need something that acts like an event stream, all you need to do is make a vector that contains one unique object, like a UUID, along with the payload. So for example, because one of the properties of Javelin is that it will only reevaluate formulas when their inputs, like when their dependent cells, the cells they depend on, they change their values.
00:48:49
Speaker
So that was a thing that didn't exist in any of the other FRP things that were out there, like flapjacks or whatever, because they all used JavaScript and there's no equality story for JavaScript. And that polluted the entire thing from top to bottom.
00:49:05
Speaker
It's a super inefficient way. You have to check everything from top to bottom. Yeah. And also it's crucial though, like this once only semantic is extremely important in order to be able to build robust programs. Like even if, you know, it's not even about efficiency, it's about where you attach the side effects. Correctness. Yeah. Yeah. Yeah. Cause this will ensure that like the nukes early launch ones. Yeah.
00:49:29
Speaker
So before, maybe you should just leave the nukes out this far. American. That's all we have. I know you're American, but you know, you're frightening us now, Michelle, you know. So before we move, why can't we launch koala bears? We're nice, peaceful Europeans. Yeah, launch koala bears. Eh? Yeah, our kittens and.
00:49:48
Speaker
Okay, we're launching the koala bags. That's the kittens. Yeah, kill the kittens or whatever. I don't know. I don't know if there are any cat aficionados in the audience. Please don't scream right now. Look, we're a vegetarian podcast. Exactly. We just launched the vegetables. We may kill cats, but we don't eat them. That's the idea.
00:50:05
Speaker
We don't kill them either, OK? Let's not live together in harmony. No kittens were killed to produce this podcast. Let's just be clear about that. So before we move on to the next topic, so do you see any reason to use or pour javelin into Closure World? I mean, on JVM level things?
00:50:24
Speaker
You know, it's interesting. I haven't found any, so there was recently a request to add to Javelin like a lazy evaluation semantic, meaning that, you know, the formulas wouldn't update unless there was a watch on it or something like that.
00:50:42
Speaker
So to me, that's the world that you have on the server, because you don't want to have a million things out there updating all the time. You can't afford that on a server that's heavily loaded. And what you end up with is if you don't dereference it, it doesn't compute it, right?
00:50:57
Speaker
But that's just calling a function. I mean, if you need to, if you're referencing the thing produces the value, you have just effectively called a function. And that's where I always end up back at like we do have a javelin port for closure. And I think the only place that it would be useful for me would be if I was making like a Java UI. Yeah, because in the UI, you really do have like persistent things that need to reactively update. But on a server, you can't afford that.
00:51:22
Speaker
Yeah, I mean, my question was related to whether we can build desktop applications. Well, not with Electron and all the crap. And I know everybody wants to write Electron these days and then bring JavaScript onto the desktop. But I was thinking, can we use Java as a back end or the model layer for swing applications or Java effects or something like that?
00:51:44
Speaker
But yeah, I mean, it makes sense. I mean, as you're pointing out, it's basically a function because you just want to call it and then get it updated. But for UIs, it totally makes sense. Yeah, yeah. Not on the server, though. But maybe part of the server story is where you want to do some rendering on the server side just to render out the UI at least. But I guess that's less javelini and more hoploni.
00:52:12
Speaker
Yeah, and it's also of like- If that makes sense. It's of limited utility, because we do have a, you can pre-render Hoplon, and it loads your thing in a, you know, PhantomJS or whatever. Yeah. So that's good for SEO, for example. So you can do like the Google, you know, crawler thing. Yeah. And it's good for like when the page first loads. So like how to splash screen or something. But in general,
00:52:39
Speaker
like you really want to be working like you're making a program and it's not like you know like imagine a desktop like a normal program you know you don't want to have like this pre-computed stuff that needs to be torn down and you know you want to like do your computing as directly as possible because
00:52:57
Speaker
Okay, so we... Okay, just one final thing on the Javelin thing we didn't discuss actually, and then we're reading a little bit there, but who cares? It's all great stuff. It's the ability to use these lenses so you can have like
00:53:14
Speaker
much more because i think like the concept of having like a function it's some sort of formula cell where you say this function is equal to that function you also have these lenses can you talk about that a little bit just to kind of show that you have let's say more arbitrarily complex features in in javelin then then we might think just from a pure simple spreadsheet model sure yeah and lenses you know the term you know maybe is not entirely correct but uh
00:53:45
Speaker
The huskles are going to get upset. I don't know which flavor of monoid it is. So in javelin, in a normal spreadsheet you have input cells and formula cells. And the contract there is that an input cell can have any value you want and at any time of the day or night you can put a new value in there and you can get the value out whenever you want.
00:54:06
Speaker
And the contract with the formula cell is that there is a constraint on the value of this that will be in the cell and that constraint is expressed in terms of other cells and constants or whatever values you want. But the idea is that this is a rigid constraint and you can guarantee that at no time will you be able to observe this guy in a state that is not consistent with this constraint.
00:54:31
Speaker
So it's like an acid-style thing almost. So if A is 1 and B is 2 and C is the formula A plus B, that thing will definitely have 3 in it. You'll never find it in some other state. So that means that calling swap or reset on the formula cell makes no sense whatsoever and should cause an error, which it does. But what we implemented is a very general form of lenses.
00:54:59
Speaker
And the idea is that you can give a request to the formula to update. Say, I would like you to make your value this. And maybe that formula has some implementation that you've given to it that can update the relevant input cells to make it so.
00:55:16
Speaker
So that's the javelin form of a lens. So you can create a lens from a formula expression plus a callback. So the formula expression is what the value will always be. That's like a solid constraint. The callback is something that attempts to update things in the world such that it will achieve the result that you want. But it might not actually work that way.
00:55:43
Speaker
Do you have a kind of concrete example of that? Yeah, so one place where we use lenses all the time is suppose I have a component that is going to say accept like a form component, right? That has maybe your name and your email address or something. And maybe if the person already exists in the database, you want to pre-populate it with the current values.
00:56:06
Speaker
And you want to have constraints on what those values might be. So you don't let them type in something bad and you want that to come from outside of the component. So you don't want the component to need to know about how that works. So it would be great if you could pass them a cell that will only that has a constraint on which values it can ever contain.
00:56:24
Speaker
and might have a default thing, but that you could also call swap on it to try and set the value, right? So that's like a use case. So you pass it, you construct this formula, which is saying the formula would be like look in the database, you know, would be like the default value.
00:56:43
Speaker
And this callback would be able to do validation and stuff like that, and then it would set, it would go into the mutable thing, the input cell, and update that such that the name and the form input would actually update. Super useful.
00:56:57
Speaker
Oh, okay. Actually, that's really cool because someone asked me about that at this closure meetup and I'd forgotten how it worked. So, so now you've given me a great answer. So, so yes. Yeah. And I think it was called yet. Yeah. That's one of the things that I'm kind of like, I don't know. One of the things that I enjoy that came out of it was like how simple the, the lens implementation and like how, how general it ended up being. Hmm.
00:57:25
Speaker
It really kind of makes me happy. Yeah, because actually it's quite interesting that that part of it is definitely something which you don't see anywhere else. That aspect of that, you know, do something to me, do something outside of the scope. You said it better. But we get it. I mean, we can do something to you. That's what you mean.
00:57:50
Speaker
Yeah, it's like here's a request to do something, and then your internal implementation might make it happen or might not, does the best it can. Okay. Yeah, so you've got a loop, basically, that's optional. It might or might not result in a change. Okay.
00:58:05
Speaker
Yeah, that's really cool. Yeah, we looked at the UI, which is hop on and the javelin that you use on the client side to store the state and make sure that that reflects the thing. And of course, the other piece of the puzzle is talking to the back end, right? I mean, how do you how do you send this data over to the server? Because obviously, you need you need something in the back end that's interacting with the database or
00:58:27
Speaker
managing all these things. So we have the Castra library for it, right? Can you give us a quick overview of what Castra is and how does it fit into the three pillar thing? Yeah, so Castra is, I don't know, the buzzwords would be like RPC, CQRS, those types of things. And the idea of it is that in the client you can call a function that gets evaluated on the server.
00:58:54
Speaker
And this function is for side effects only. And so when you call the function, it doesn't return data. It doesn't return a result. The result ends up in a javelin cell.
00:59:10
Speaker
And how it factors into, how it relates to CQRS is with CQRS you have like a separation between command and query. So I send a command to the backend to, you know, change my password, say.
00:59:28
Speaker
And actually, that's a bad example, but to change my birthday, you know? And then the query is, what is my birthday, or what is my user information that might contain my birthday? And decoupling the two things gives a lot of benefits in how you can organize the front end, because take, for example, a login form, right? Basically, any interaction with the back end, you normally have two concerns that are at odds with each other.
00:59:58
Speaker
When you log in, when you fill in the login form and it talks to the backend and you've successfully given your password, that login form doesn't know anything about what the application needs to do once you're logged in, nor should it. It should only know about how to get you logged in and that's it, right? So you have that concern. But also, suppose your password isn't correct. It needs to show you an error message or something. So it needs to know about how to deal with errors locally
01:00:25
Speaker
But it needs to know, but it shouldn't know anything about how to deal with like successful state changes because those changes are at a totally different level of your application. And so what we do is when you call one of these RPC stubs on the client, it returns a promise.
01:00:42
Speaker
which will, when the promise is fulfilled, it contains information about the status of the request, meaning like if there were errors, it returns them, validation errors, connection or whatever. But additionally, when the Ajax request actually completes, rather than returning the result to the caller, meaning like this query, it gets put into a cell.
01:01:17
Speaker
If I have a big form, basically I'm thinking about a business application. I'm filling in data to book a flight or something. It doesn't matter. Something like that. I'm adding all this information and I'm clicking on, okay, send this data back to the server. I have another view where it shows a number of flight reservations. That needs to be updated when the server gets the successful reservation, for example.
01:01:42
Speaker
So what is the sequence of events there? Is it an optimistic update that locally changes or is it actually going back to the server and then only the cell gets updated if the backend is successful? And how does the error handling work in that case?
01:01:57
Speaker
Usually it's a combination of those two approaches, depending on how your application is organized. Because I could see there being two stem cells, we call it. One of them showing all the flights that you care about, maybe. And it's probably going to be paginated. So maybe the current page.
01:02:21
Speaker
So there's that, and there's also, you know, like the purchasing workflow. So maybe you have information about, you know, the current, like your current place in the workflow. And so there might be like a bunch of different steps in this workflow to book a flight. And so those will be a bunch of RPC calls probably that all are related to the same query.
Castra: RPC and CQRS Solution
01:02:43
Speaker
Meaning this query is, what's my current workflow state? And so every time you make an RPC call, that does some stuff in the back end for side effects only, and then the same query function is run, and that value gets put into the cell, right?
01:02:59
Speaker
Okay, so the RPC has got two parts then it's got like this essentially this part where normally with an RPC one expects the the RPC to Take a call and then return a result But what you're saying is this one takes a command and then you tell it where the result is going to end up in some cell somewhere And then you can evaluate that cell how you wish yeah, and it's not even I don't really think of it as a result because
01:03:29
Speaker
So you might have like, let's say you have five RPC functions that implement this workflow. There will be one single query function that is returned for every single one of those. Meaning the client, when that Ajax call completes, it gets the result of evaluating the query expression, not the RPC expression. Okay. So how are the two things linked together then?
01:03:57
Speaker
Well, decoupling them is huge because you have, so like for this workflow thing, there's a query on your database that will return all the information about the state of that workflow.
01:04:06
Speaker
Right? And that's completely decoupled from the things that are performing side effects mutating the database, which is very powerful. So in Castor, when you define your RPC functions on the backend, they're like, you know how in Closure you can make pre-conditions and post-conditions? Yeah, yeah. So we extended that so you can make a query condition, which specifies the expression, the query expression, to return to the client.
01:04:33
Speaker
And you can also have preconditions which are performed kind of like closure preconditions, but only when it's an HTTP endpoint. Meaning that like if one RPC function on the backend calls another, it doesn't evaluate those. So you don't need to mock any state or anything.
01:04:55
Speaker
Ah, okay. I didn't get that either, but okay. I'd written one of those, and someone asked me what the difference between the normal pre and the Castro pre was, and I couldn't for the life of me remember.
01:05:12
Speaker
Okay, that's that's good to know. Yeah, so it's only when the HTTP endpoint is called. Well, it also has like a crucial other purpose. Separating that out is that you could, if you send validation metadata saying like, operate in validation mode, it only performs the preconditions but never the body. And this
01:05:31
Speaker
Right. Yeah. So like what we do at Adzerk. A bit like a fancy head. Exactly. Yeah. And like at Adzerk what we do a lot, like for pretty much every form is we have, you know, once you submit the form, you're like, while you type, it's validating everything. And we validate on the backend mostly. Like we have very little front end validation because it's like so, it's so solid to do it this way that it just like, we get like, yeah, it's really effective for simplifying how your code works.
01:06:00
Speaker
So what is it piggybacking on? So Castro uses a ring or what is the backend based on?
01:06:11
Speaker
Yeah, it's implemented as a ring middleware. OK. So we just need to just add the library and then start writing RPC functions, and then we can call them from this one. OK. So another question that I was interested in is the whole server push thing. So can you do that? Or do you think it's a good idea or not?
01:06:36
Speaker
Yeah, you can do it. My needs for the type of business applications I write, we have very little
Session Management Strategies
01:06:44
Speaker
use for that. Most of the applications we write doesn't have a lot of interaction between users. So in that situation, polling makes a lot more sense. But it should be possible to do it, of course.
01:06:58
Speaker
So do you think what is what is the best use cases? I mean, of course, I mean, every every framework can be used or abused to fit into every kind of application that you can build. But do you think Hoplon is something that you want to pick up if you want to build, for example, something like Slack, you know, lots of users, lots of clients and
01:07:17
Speaker
I mean, I think Slack would be a good, I mean, because that's like basically any application that you open and you use and you have workflows, you know? If you expect someone, if you expect that all your customers are going to be there for less than 30 seconds and you expect to make your living that way, don't pick Hoplon, you know?
01:07:36
Speaker
Yeah, yeah. So better applications and then heavy, not heavy, but rich applications. And before we close on Kastra, I just want to ask one more thing. Like, so how does the, especially when you're building this rich internet applications, you know, using, using our rich rears or whatever, our sparse or single page applications. One of the questions that keeps coming back is about the sessions and
01:08:01
Speaker
you know, maintaining the session on the server and logging out and these kind of things. So how does that work in Hoplon?
01:08:09
Speaker
So usually the way we organize the applications for deployment is we'll deploy the front end, the hop on part, all to a CDN because you just end up with HTML file and some JavaScript and whatever. So we put that on a CDN and then we use CORS to talk to the Castro back end, which is just a HTTP endpoint.
01:08:32
Speaker
So cores makes things a little bit difficult sometimes like cookies and whatnot. So we have another implementation that like I just needed to ship a thing and I had so many problems with cores in different browsers that I made a local storage based implementation.
01:08:50
Speaker
But but the general approach is you just have an identifier that you don't need to store a lot of information in the session. You just need to store, you know, basically the identity of the user. That's the only thing needs to persist. We encrypt it, send it over to the client, stored on the client. They send it back with every request.
01:09:08
Speaker
along with the CSRF tokens and whatnot that are automatically generated by Castra, it just sends an additional thing. Because Castra is based on ring, I can use all sorts of ring middleware on it. Any kind of middleware that I want to put in, or do you think there is anything that you should be aware of or careful about?
01:09:31
Speaker
No, not at all. And in fact, Castro doesn't care about URIs at all. It'll accept any post. It just cares about the body because it's an RPC call. So you can mount it anywhere.
01:09:44
Speaker
What we do with that kind of thing, by the way, is we often use, we use a CDN, but we sub-domain the CDN onto our own domain. So it looks like from a course perspective that you're on the same domain. So if you use, if you, you know, with CloudFront, that kind of thing, you can put, make your bucket as a sub-domain of your domain rather than having all this course crap, because course seems like hell based. Well, it's not, it doesn't seem like a hell. It is a total hell.
01:10:14
Speaker
You know, it's like, it's just ridiculous. Especially for, it's fine for when you really have to trust something, but mostly it's just an impediment to good deployment practices as far as I can tell. Rant over. Okay, bam. Right, so the other thing that's what we were talking about was the actual, I think this is something which comes up a lot with the modern applications is this,
01:10:41
Speaker
how do you transfer like payloads because is your payload like a rest payload and you have to go to 10 different servers to get this payload or does the RPC give you a nice closure or closure script payload that you can rehydrate easily on both sides? Yeah that's the key one of the most key aspects of Castra is that when you call the function in the client it's as if you were calling
01:11:07
Speaker
a closure function. There's no, you know, you give it closure data and what ends up in the cell is closure data and you can do the same thing in the REPL enclosure when you're working and testing and all of that. So it's essentially just like a function call.
01:11:26
Speaker
Okay, so you can get back any kind of collection or data structure or whatever you want. And you can, you know, it uses transit in the middle. So if you want to extend that, you can send record types over, you know, whatever you want. Right, right. We've discussed that in the reader program, which I'm sure you've listened to many times in the show by now. So just refer back to the reader episode, everyone.
01:11:52
Speaker
Okay, that's a great explanation, I think. And as Vijay says, each of these things can be taken independently or obviously multiply or affect if you use them all together. Yeah. Okay, so...
01:12:07
Speaker
Let's move on to the final topic. Now, we want to discuss about what's your opinion about other frameworks? So what do you think about React and React-based ClojureScript libraries? And what lessons that we can take from each other? Yeah, I'm interested. I mean, I've been studying it lately a lot more than I had been for a while. And so I've been making some applications with RUM.
01:12:36
Speaker
the past few weeks, and with Reagent, exploring things. The thing that I'm most interested in, like the overarching goal, is the component story. Yeah, especially with Reframe. When we were discussing the web components thing, I think Reframe, our Reagent-based thing, they also want to build something similar, like different components. It seems like a common kind of goal.
01:13:06
Speaker
Yeah, and like the specific kind of things that we want to support is like, for example, in Hoplon, there's this macro def lm plus, which allows you to make a component where you declare attributes and you can accept children. It acts like a function. You could call it like a function. Specify attributes, which are like keyword
01:13:29
Speaker
value pairs and, you know, children or like if you nest things inside. But the idea of it is that this component is a first class DOM element thing. So suppose I have a component that is some kind of list component.
01:13:46
Speaker
where it has its own internal structure, and deep inside of it, it has a container area where children are gonna go, and when you add a child, it's gonna be wrapped in all this stuff to make it a proper child of this custom element, right? So what we want to have is a real first-class implementation would provide
01:14:12
Speaker
where I have a function over here that constructs one of these things, I pass it to another function which can add children, add attributes, whatever, and normally what happens is if this thing is like 20 divs or whatever and the container is deep inside, you end up just adding the children to the outermost div, it's useless.
01:14:32
Speaker
it's a leaky abstraction so that's the kind of thing that's like our overarching goal because what we want to achieve at the end of the day is a system where you can
01:14:43
Speaker
construct your more complex things from simpler things, full fidelity, and then combine those with, you know, like the state machines and javelin cells, you know, to assemble applications with zero architecting is like our own.
Rendering Efficiency without Virtual DOM
01:15:04
Speaker
So what's your opinion on virtual DOM? Because I know the top one is using jQuery, so it's not doing any virtual DOM optimization, as well as I know. Am I wrong, or do you have any plans for...
01:15:17
Speaker
There's no virtual DOM as such. I mean, it does have some aspects of the virtual DOM. But like, for example, Hopline does allocation a little bit differently. So with Hopline, you leverage static allocation as much as possible. It's very declarative. But sometimes you don't know at compile time how many elements a certain thing will have, like a table, say. So that depends on what comes back from the database.
01:15:45
Speaker
And the way Hoplon handles this is kind of like, I don't know, we saw this thing in common lists called a fill vector.
01:15:54
Speaker
I don't know if it's exactly that, but it's similar. Basically, you have a pool which represents the high watermark of how many things there were, and you never destroy them. You have this pool, but the properties of each of these elements in the pool are formulas on the nth element in this vector of
01:16:16
Speaker
Okay. Meaning like, you know, if you have your flights like you were saying before, you know, those are coming from a database. And so you might have n flights in view. And so there's n little objects. And each one of them is constructed by a constructor that exposes a formula for the nth item in this cell.
01:16:36
Speaker
Okay. And so like that cell can grow and shrink, you know, the items in there. So maybe there's 40 of them now, and maybe there's only 10 of them, you know, t plus one. So the 11th item now has no in itself.
01:16:52
Speaker
Right? And so what Hoplon provides is like it provides some things for managing this. And so the TPL macros, we call them, it removes those guys from the DOM, but doesn't destroy them. It just puts them into a pool. So there's only 10 items in the table. But the other ones are still alive. They're still wired up and everything. They're just in this pool. And so when your thing grows again, they go back into the DOM, and now the thing isn't nil anymore. Now it's the 11. It has the volume. Yeah.
01:17:22
Speaker
Right and so you don't need to explicitly handle a life cycle there because everything just automatically works because you've simplified it because you don't deallocate anything. So you don't need to like rebuild state. So like those are the kinds of things that I think virtual DOMs interfere with because you're not dealing with a direct reference to the thing. You're dealing with like an intermediary.
01:17:49
Speaker
Yeah, there is a different abstraction. How do you stop it getting out of control or in terms of memory and stuff like that? We've made some really large applications now. The Adzerk one is pretty huge in terms of functionality, the number of screens and so on. And it's totally not a problem at all because humans can't handle more than a certain number of things at any given time.
01:18:15
Speaker
And so allocating some divs, allocating 100 divs, a lot of times because of the way it works, you can reuse those divs. So a lot of times we can reuse the same table for different purposes. If it has the same structure, it's just a matter of changing what's in this vector of data, right? And all the things update. So in practice, you never run into that kind of problem.
01:18:44
Speaker
Okay, so it's like a mini, it's like a, not a virtual DOM, it's like a virtual, like a mini DOM, like a virtual set of elements. Yeah. Or a pool of elements, yeah. Like you said, DOM, DOM element pooling, basically. Yeah, and you can make it lazy a lot of times. I mean, there are constructs that allow you to delay initialization of these things until the vector becomes non-nil.
01:19:11
Speaker
which allows you to like, sometimes it's good, sometimes it's not good, but it allows you to not have to load everything at once. Okay. And what is the, what is the story about native hoplon? Um, like nowadays it's, it's, everybody wants to write closer script or, or just writing JavaScript and run it everywhere. I think it's like, um, Java of the nineties, I think, you know, write once and run somewhere, you know, right?
01:19:37
Speaker
So JavaScript is now everywhere, all the way from the server to the mobile applications that people are building in JavaScript. And do you think Hoplon can be used for the native applications, native mobile applications, for example?
01:19:52
Speaker
Yeah, I've personally made a number of applications that are, you know, in the app store or whatever with Trigger.io in the past and Cordova and stuff. And I haven't done anything in that area for, like, the past couple years. But, like, my view is that, like, I bet you HTML containers are just going to get better and better.
01:20:14
Speaker
So I think the benefit, I've been reading a bunch of stuff from game engines and stuff about native engines versus HTML5.
01:20:24
Speaker
And I don't know, it seems like it might be that the future is not with native shims, but might be with just HTML. I don't know. Yeah, it could be, because I know that with every iteration, I know they remove more and more restrictions from the WebKit, for example, on iOS. So the WebView becomes way more powerful than the previous one.
01:20:48
Speaker
because previous versions they had a lot of problems because the touch events had a specific delay when you use it on the app and that made all the wrapper applications behave like shit.
01:21:02
Speaker
Yeah, the 300 millisecond thing. Exactly. Once it is gone, things have started getting, certainly started getting better, so. But that's... Yeah, also, I guess the WebGL is also the other big thing, isn't it? Because now they have WebGL on there, so you can actually program on the web as well as on the native graphics stuff. I don't know if, I mean, I guess Hopline has not really got a good WebGL story, or is that, am I wrong there?
01:21:28
Speaker
I haven't done any WebGL stuff, but I've done SVG stuff, and that works fine. Works awesome. Canvas done some of that too. Works fine. So it is pretty much a big couple from whatever kind of UI you want to use.
01:21:48
Speaker
Yeah, I mean, SVG was especially well suited, I think.
Creating Games with SVG and JavaScript
01:21:54
Speaker
Alan and I made some games. And it was an interesting process because we offloaded all the stuff that you would normally need a super quick render loop for. The stuff that React usually says, oh, look at all this perf. You could do 60 frames per second.
01:22:10
Speaker
Generally, what we did was we found we used SVG animations, transforms, things like that. And there's tons of highly optimized JavaScript libraries that you offload that stuff onto. And you actually only need to update your state and some trajectories and stuff. Did you make a game to launch the nukes? Yeah, it was actually Missile Command. Oh my god.
01:22:37
Speaker
okay okay we got the theme that's for sure okay well that's brilliant i think that's really fantastic i don't know if you've got uh anything else uh that we want to we want to talk about misha or anything else that that you guys are uh sorry vj i have one one yeah well one last point the basic question is
01:22:56
Speaker
So how do we, how do people hop on to Hoplon bus?
Connecting with the Hoplon Community
01:23:01
Speaker
Well, I like it. I like it. Yeah. Yeah. Just hoplon.io. That's it. Okay. Of course, you guys are on IRC and Slack and yeah, there is a Slack channel. And of course, your code is everywhere on GitHub and people can follow you on Twitter, I suppose. So
01:23:21
Speaker
Yeah, I don't tweet very much, but I do have a Twitter, so. But yeah, Slack Shadow is the best place. There's a lot of really friendly people in there from all over the world, so pretty much 24-7 support.
01:23:35
Speaker
Oh, that's sweet. Yeah, I think it's actually, I've been in that Slack channel as well. I think it's always, it's like the warm pool of the Slack team, you know? It's like everybody's sitting in a jacuzzi. I know. It's a spa, yeah. It's quite literally. It doesn't matter, okay.
Hoplon Demos and Adoption Encouragement
01:23:53
Speaker
Yeah, but it's really nice and also the other thing that I've done as well in the past is looked at the examples that you've got for Hoplon and Javelin and Castro and using those examples to get started is a very good way of bootstrapping yourself and into the technology, I think. Yeah, we have like 30 demo applications or something, a lot.
01:24:17
Speaker
Okay. Yeah. So that was, I mean, it was very nice talking to Amisha. I mean, especially, you know, we are very grateful for you, for you too. You've been very kind and spent a lot of time with us. I know pre-show discussion also extended quite long. This is the longest show in our history, by the way, by a mile. So you've done something right there, Amisha. Thanks for inviting me. I'm having a great time.
01:24:39
Speaker
And of course, our thanks goes to Alan as well. Both of you guys have been making amazing stuff. So we hope you guys are going to continue with these things. And more and more people will, I'm going to use the pun again, hop on to hop on. And we're going to have much more fun.
01:24:57
Speaker
so thanks a lot and maybe if you've got a new slogan there hop on to hop on yeah please go ahead please use it and every time you every for every we've got a trade bar for every impression you can send me two euros okay that's that's you guys are in ad business right you know you know how this works
01:25:15
Speaker
Yeah, yeah, we'll work out a deal. We'll work something out. But I mean, unfortunately, I couldn't do much with Hoplon. But after this discussion, I'm really curious because I built most of the web applications that are used in very closed environment, so to speak, like business applications. And I've been trying a bit with Reagent and Reframe. And of course, I would love to try it out. And I'll, again, hop on to Hoplon and onto your channel.
01:25:45
Speaker
Yeah, I it seems to be very very interesting by the way, so thanks a lot and Any any last words for us? Oh, by the way, emacs are some other crap Yeah, I'm a bye guy Yeah, okay. That's not bad. Not bad. Actually. I think it has been tradition in for for one episode to ask man I I spent like a year and a half with emacs and
01:26:12
Speaker
and Space Max. And I'm like, I tried to like it so bad, but I couldn't, man. Yeah. Well, I'm on Space Max. So how friendly is Hoplon development with Emacs now? Is it OK? Can I just plug in? Because I am assuming I just use boot and then just hook into it. OK. But that's probably a different thing.
01:26:34
Speaker
Yeah, our workflow is a lot more kind of like fig wheel style than repel style, like my own personal one. Okay. Just because of the way like cells and spreadsheets work, you don't need to do the same kind of debugging as like I normally would in a closure program where you're calling functions a lot. Okay. Okay. But we'll certainly do another episode about build tools and everything and boot and we'd be very happy to have you or Alan.
01:26:59
Speaker
on the show again. So we have lots of things to discuss because you keep producing amazing libraries and we need to talk about this stuff. That's fantastic. OK. Thanks a lot, Misha and Ray. And of course, we promise we're going to discuss about concurrency and async. But we will certainly pick it up in the next episode. We'll discuss.
01:27:23
Speaker
That's the nice thing about AsyncC, it's a promise that is durable in the future. We don't say when. We just say it's in the future. So it will be next time. We did put the request into the channel. So as soon as the other side is going to pick it up, we know we're going to publish it. So that's it. It's in the buffer at the moment. So that's it, I think. That's it for today. Any quick updates, Ray?
01:27:49
Speaker
Just to set the end, we will post all the show notes and all the links to Hoplon. It's fairly easy, I think, hoplon.io. We'll post it onto deafened.audio on the Soundcloud, all this kind of stuff. But I think now, just like you, Vijay, thanks very much again to Misha. It was totally fantastic, great conversation. I hope everyone who listens to the show has as much fun listening to it as we are talking about it, and it's really good.
01:28:18
Speaker
It's a great technology, I'm a massive enthusiast for it, so I think let's, you know, come on guys, get on board the Hoplon story. Hoplon, yes. Hoplon to Hoplon. Hoplon to Hoplon. I'm gonna use it now. So that's one thing, just one final quick credit again to Pizzeria for the intro and outro music. Melon Hamburg, go and support him on SoundCloud, he's doing a great job. P-T-Z-E-R-Y.
01:28:45
Speaker
Okay, thanks very much. Bye bye BJ. Bye bye Ray. Bye bye Misha.
01:29:12
Speaker
you