Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#46 - Roman Liutikov
45 Plays7 years ago
#46 - Roman Liutikov by defn
Recommended
Transcript
Introduction and Guest Background
00:00:15
Speaker
Welcome to Deaf in episode number 46 with me, Vijay. That's narcissistic. I think I should start with the guest first.
00:00:24
Speaker
With Roman Lyutikov. Yeah, that is the right one. So I got a little bit, but yeah, that was pretty good. Very good. I would say Dobro Otro? Or Dobro? Yeah. Dobro Waitcher. Waitcher, maybe. Yeah. So welcome to the episode. Hello, Ray. Yeah, hi. Here as well from Windy, Belgium. It's very windy here.
00:00:52
Speaker
Where are you, Roman? Which country? Kiev. Ukraine. It's finally warm here. I think there's some elections or something going on, right? I just saw something on BBC, some discussions about Ukrainian leadership or elections or something.
Ukrainian Elections and Local Insights
00:01:11
Speaker
Yeah, I guess it should be in March.
00:01:13
Speaker
Yeah, yeah. Cool. So we have a very, very strong campaign going on everywhere. Well, you've had a complicated couple of years, haven't you? Yeah.
00:01:26
Speaker
You don't want to get too into that, though, because yeah, a big welcome to Ukrainian politics podcast, what is it one one of the things that one of the things I did see in the news over the weekend, though, was I don't know if it's I think it's Russia, one of the Ukraine, actually, was this there's a river or a lake or whatever between two straits that becomes frozen and cars drive over it cars drive over the ice.
00:01:54
Speaker
And I was absolutely astonished, you know, that these these cars were the people, you know, the local people, the local supervisory administrative people make sure it's all good. I guess.
00:02:08
Speaker
So it is it
Role and Tech Stack at Pitch
00:02:09
Speaker
is part of the highway or something, not highway, but it's part of the regular road. No, no, no, no, it's just it's just it's just a strip between the two parts of Russia open for freeze sometimes. Really, it gets very, it's very thick. So they can actually drive a car over it. And these fuckers do it, you know. So you've got balls to do that, don't you? You know?
00:02:32
Speaker
But I was in Budapest a couple of weeks ago and the history was pretty much similar because in winter the river Danube freezes over so you can actually walk on that one because they don't have any bridges to cross the thing. So in summer it's like they really have to go really far to cross the bridges.
00:02:53
Speaker
Yeah. Oh, okay. That's our other talk. Wasn't there a famous maths problem about the Danube bridges? Was it Danube bridges? The six bridges or seven bridges? No, it wasn't them. Okay. Probably something else. Okay. Sorry. So I think we finished politics. We finished weather. Now you can get to the real topics. So Roman, welcome to the podcast. Can you give us some introduction about yourself?
00:03:20
Speaker
Yeah. So, I'm Roman. Hello, Roman. Nice to meet you all. Yeah. So, I'm a front-end developer. I'm working with Closure maybe five last four years or three years or something commercially. Yeah. Yeah. Right now I'm working for Pitch and doing front-end there.
00:03:47
Speaker
What is pitch? So pitch is a burden-based startup. They are coming from Wunderlist, the Todo app. So the pitch is a new product of Wunderlist team. And we are doing presentation software for web and desktop. And it's based in Closure and Closure Scripts web stack.
00:04:14
Speaker
So even the even the desktop one is also enclosure into a script. Yeah, yeah, it's electron. Oh, okay. Interesting. So it's like a company to prezi or something or a bit. I don't know if you need a keynote probably. Yeah, yeah, I would say. Okay. We still try to innovate somewhere. So we can be everything. Yeah, it's still work in progress. Are you are you the master of CSS transitions?
00:04:43
Speaker
Now we have, I think, Marvin in the master of the CSS transition, the other guy. That strikes me as the beauty of the web presentation type stuff, those animations that can drive the hardware on the web browser, the CSS stuff.
00:05:02
Speaker
Ah, yeah, you mean that? Yeah, sure. It's actually very nice to be able to use web stuff in presentations because you have already everything built by other people. You can just use it. Right, right, right. You don't need to implement everything, just everything is already done for you.
00:05:19
Speaker
Yeah.
Journey into Closure and Career Path
00:05:20
Speaker
So what is the stack we use? Of course, it's Closure and ClosureScript, but any specific libraries or something? I think it's pretty basic. So it's on the front end, it's a reagent, reframe, spec. I don't know much about Becken because I didn't work with it, but I don't think we have anything special there as well. Yeah. But before coming to Closure, how did you end up writing Closure stuff?
00:05:47
Speaker
I honestly don't remember. Okay, moving on then.
00:05:56
Speaker
Is it is it like you've had a memory wipe, you know, everything else before that it was obviously total bullshit. So I just remember the good stuff. Everything else is like reset immediately. You've already got durable persistent data structures as of closure. But I didn't have enough memory to keep doing that.
00:06:20
Speaker
Or maybe you switch to like, you know, like a core sync channel. So there is a buffer of only like two languages and only one language. So that's it. Rest of the shit is like dropped and who cares in a dropping buffer. Yeah, exactly. Yeah. I remember at the time I was working at a company and we were doing the front end in React and it was before the Redux came out.
00:06:45
Speaker
So the whole thing about like global immutable state was, let's say unknown in the frontend community. And somehow I've seen a couple of talks and closer script probably on the internet.
00:06:57
Speaker
And in the same time, I found a blog post from some other guy. I think he's completely unknown in the community that, but it was, he was talking about the global state, like pure transformations and all of that stuff. And I understood that as kind of much as the closure script. And then I started reading a lot about it. Just tried it.
00:07:23
Speaker
and i've been trying for i don't know maybe a couple of years and because like coming from javascript it's super foreign in everything like from all the sides yeah but at some point i decided to maybe find a job
00:07:39
Speaker
And luckily, I found a job even here in Ukraine on site, because usually when you want to do closure, it's most likely somewhere not in your country. How is that possible? Every person we talk to, they say it's not in our country. I mean, there must be somewhere like some people living in the same country.
00:08:03
Speaker
It's always on the other side. Yeah. The interesting thing was is that I didn't know about it, but when you go to when you want to work with Clojure, no one is actually asking you to be super professional about it. You just want to be passionate.
00:08:21
Speaker
I mean, you obviously need to be like a good engineer, right? Yeah. But given the size of the community, like no one expects you to be super good at Clojure, just want to learn it.
00:08:34
Speaker
Yeah, I think this is the this is it's a good thing, right? I think it's probably a long time ago. I think Paul Graham wrote this blood or blood paradox like the people who are drawn to this kind of languages are actually more interested in learning stuff and doing things. So that means, you know, you're you're learning a non-mainstream language.
00:08:57
Speaker
That means you're actually interested in programming, not just for, oh, let me get a job at a huge corporation writing Java. I'm done.
00:09:07
Speaker
I guess that's probably the like a litmus test or something. So my Python become pretty big these days. I think he was giving Python as an example back in the day. But it looks like Clojure will never become like Java. So you always have this nice advantage. Yeah, it's like people who are actually interested in this thing. Yeah.
00:09:28
Speaker
Okay.
Transition to ClosureScript and UI Development
00:09:29
Speaker
So how do you compare your experience doing front-end stuff before React and after React and before Closure Script and after Closure Script?
00:09:42
Speaker
Well, before React, I wasn't doing much, let's say, or as you say, complex applications, right? I was doing a little bit of Angular, but mostly it was pure JavaScript or some jQuery shit or something like that. There was jQuery mobile where people started doing web applications. I wouldn't say it was a pain given the size of the projects that I've been working on, but obviously,
00:10:13
Speaker
more abstract UI stuff like React, the component system, the state model, it's much better. It's less granular, let's say.
00:10:30
Speaker
So right now you're working with a front-end heavy application essentially, right? Yeah. It's extremely because it's more or less trying to perform like a native application. Yeah, and especially like presentation software, it's basically the complexities on a client because it's highly interactive. Yeah. So what are the challenges that you have building this kind of stuff in ClosureScript and Electron?
00:10:59
Speaker
I would say performance, but it's not related to electron itself.
00:11:08
Speaker
but the characteristics of the closure script, like persistent data structures, interpretation of the hiccup at runtime. Sometimes it's not expensive, but when you build a lot of stuff, it just adds up at some point. You see that there is kind of obvious ways to optimize it, but sometimes it's just the baseline and you cannot do anything about it, but yeah.
00:11:37
Speaker
So you might pick up as hiccups. What? Hiccup has hiccups every
Performance Challenges in Electron
00:11:43
Speaker
now and then.
00:11:48
Speaker
Yeah, sorry. Yeah, but in general, it's very nice to work with it, because previously, when I switched to Closure Script, I started with O, but I get busted very fast, because it was a little bit, I don't know, it's just too much code to write, and it seems like Closure should be a little bit simpler than that. So I switched to Realm, Nikita Prokopo project.
00:12:14
Speaker
Yeah, and ROM was nice, especially because it compiles Hiccup with macros. So you end up with just basically JavaScript code without any interpretation. Yeah, but then I tried re-agent and it's really nice to have this ability to compose Hiccup at runtime even though you pay the cost for interpretation. But sometimes it helps a lot to be able to do that.
00:12:44
Speaker
And also, you use functions. I mean, you don't really need this composability of components in React. I mean, if you use macros, you cannot compose that, right? But even in reagent, because it's functions, some things are much nicer to do. What is it? So if you go back to this performance issue, Ron,
00:13:11
Speaker
How do you measure this performance? Do you have some browser tools or the Google DevTools? What do you do? There is a performance panel in Chrome DevTools. Chrome DevTools is basically the best debugger that we have. I don't know. Firefox is more or less good.
00:13:33
Speaker
They are trying to push other things that are not present in Chrome, but Chrome is very good at profiling JavaScript these days. So they are this performance panel, so you can have flame graphs.
00:13:45
Speaker
And also, React DevTools has their own flame graph, which works specifically on component render types. So instead of showing every function separately, they show you how the components, how much time it takes to render them. And it's really helpful because you can see it.
00:14:05
Speaker
all the interactions that you had on a page and what was the consequence of this interaction when it's rendering the component, interacting with DOM, and also React itself in development mode uses the Chrome DevTools API to basically mark the flame graphs with some additional metadata so you can see not only the functions that are being called but
00:14:34
Speaker
different stages of the life of the React component. It's really a good deep dive into performance.
00:14:43
Speaker
re, you know, react in general, and maybe the things on top of it is that, in theory, you should set your you should set your screen. And then the only usually render the differences. So the performance in general should be better for or at least more predictable for react based apps than for like standard JavaScript apps. Would you say that plays out in reality in your applications?
00:15:10
Speaker
Yeah, sure, sure. Especially with stuff like reframe where you can subscribe only the parts of the UI to the parts of the state. Yeah, it's true. It's a subscription stuff and reframe is very good, especially that you can compose it in very different ways. It's very nice. But do you use reframe as well or is it just a reagent? No, it's a reagent with reframe.
00:15:38
Speaker
OK, so the application architecture is driven by reframe, essentially. Yeah, yeah. OK. So you are also playing with porting REPL onto Android, right? Can we just stay on the reframe for a second, mate? Sure. We've got a bit more time. Come on. Yeah. I need to take a bit deeper here. Yes. We'll come to the interesting stuff later.
00:16:05
Speaker
Yeah, let's let's do the morning stuff first. No, no. Well, I like reframe a lot. So I think it's quite interesting. I was wondering whether, for instance, whether you've got any mileage out of this reframe 10x project, because that reframe, I've used it myself fairly recently. And some bits were quite nice, but some bits I didn't really understand what was going on. So I was wondering if you've used it very much yourself.
00:16:29
Speaker
Not much. We actually used it in pitch, but I don't remember what was the reason, but we switched to our own, kind of.
00:16:39
Speaker
clone of Reframe10x with reduced functionality. I don't remember what was the reason, and maybe it even was swapped before I joined. But I was wondering if it's possible to watch subscriptions, all the Reframe subscriptions in the Reframe10x, if it's possible to do that. Yes, it is possible to. Oh, that's very nice, because sometimes I need it a lot.
00:17:04
Speaker
Just to be able to list all the values, all the current values in subscriptions. Yeah. And you can filter it as well. And so you can watch certain subscriptions or certain, and you can watch like across time. So it has this epoch time model. So yeah, well, with dredging out again, maybe it could be good for you in terms of understanding what's going on.
00:17:32
Speaker
Is it possible to use web workers or something like that? Because I'm still wondering, how can you squeeze the maximum performance out of an electron amp? Because I did some iOS development. So that's basically in object to see. So there it's a bit different, right? It's just like the performance graphs and everything that you see and how much time it is taking to re-render. But is it still possible to get like native level speeds using reframe inside electron, inside
00:18:02
Speaker
something? I don't know. I don't think so because of all the legacy stuff that lives in the browser. There is some baseline that you cannot go past. But maybe when you're running on a desktop, maybe you can configure the instance, somehow give it more memory, more CPU. I don't know. Force it to use the hardware instead of
00:18:25
Speaker
like software renderer. Yeah. Well, I mean, that's, that's the nice thing about CSS rendering, isn't it? It does use the hardware. And, you know, so, I mean, you know, that's, that's pretty much as fast as native, but yeah, I mean, you're right. I mean, you know, if depends
00:18:40
Speaker
depends on what you're doing. I mean, a lot of the React native stuff or the React stuff in general should render just as fast because it's doing a lot of intelligent... The algorithm is quite clever in terms of how it only changes the small amount. And also, because you're using these subscriptions, you're only capturing changes from each event. So the code is very light for managing that kind of stuff.
00:19:10
Speaker
But if you're thinking in terms of the most native stuff is games, and I don't think it's going to compete on that sort of stuff, really. That's why we're talking to Tim's gardener, wasn't it, about native stuff for consoles and PCs? I mean, it's a different ballgame. Yeah, yeah. I think there it's the performances. I mean, there's a different benchmark performance there, probably. 60 seconds, that kind of stuff. You're not going to get that. Exactly.
00:19:38
Speaker
You don't need it for most reframe apps. It's not a measure that you need. In general, I think it's more geared towards normal applications, like normal ones, which are online booking things or whatever, that kind of UI heavy, but still you don't need a lot of transitions. One thing that, Roman, I'm curious about pitch is because
00:20:01
Speaker
You need a lot of these things as well, right? I mean, it's not a traditional, okay, I have a form and then I'm going to fill in some stuff and it's not like that. So how is the, compared to your other application that you're building? Because pitch needs to be probably, or the application that you're working on requires a lot of these optimizations.
00:20:24
Speaker
So is there anything that comes to your mind that you try differently in ClosureScript to help with the performance? I don't know. I would say the performance are good so far. Probably the main bottlenecks are somewhere where you need, I don't know, like measure stuff.
00:20:44
Speaker
measure the DOM, talk to DOM frequently. This is usually going to slow down the rendering, the updates. But in general, I would say it's really good, even though we already have a lot of stuff going on on the screen. Yeah. And how do you do the UI testing for this, by the way? Sorry, what? Sorry, go on. You said.
00:21:08
Speaker
Yeah, I wanted to say that usually stuff is getting slower when you're just rendering more UI. Instead of testing on the one item, you have 100 of them.
UI Testing and Error Handling
00:21:21
Speaker
And then you start seeing how small, slow things are just adding up. And as a whole thing, it's much slower.
00:21:29
Speaker
Yeah. And how do you do the UI testing? Is there some sort of an automated thing or any library that you use? No, we use a spectrum. It's a kind of...
00:21:40
Speaker
I don't know. What is the traditional UI, like headless browser? PhantomJS, Selenium. Yeah. Yeah, like Selenium. Headless Chrome, I think, as well. Yeah, yeah, yeah. Yeah, yeah. So I think Spectrum is something like JavaScript, Node.js, wrapper for Headless Chrome. So it's funny. We don't do fancy stuff like...
00:22:03
Speaker
running, I don't know, reframe handlers on JVM because it's just pure closure or something like that. So we don't spend too much time on testing everything because at the end of the day, if user flow works, like if clicking buttons is doing what you intended to do, so that's fine. If there is some error in the console and it doesn't cause anything on the UI or in the logic, that's okay.
00:22:32
Speaker
You have to test across browsers, though, because that's the bane of every web developer, isn't it? It's like, Internet Explorer! Ah! So, you know, what's the story there? They're also moving to Chrome Engine, right? Internet Explorer is also moving to Chrome. Well, yeah, the Edge browser is, but there's still a lot of shit out there.
00:22:52
Speaker
Yeah. But I think for you, probably it's not a problem, right, Roman? No, I wouldn't be targeting the web as well. But I wouldn't say it as much. Like it's Firefox, Chrome.
00:23:04
Speaker
Yeah, we have a couple of bugs for Edge, but it's just too early to start working on that. OK. You know how it backlog fills with those tickets? Yeah. Yeah. And how is the delivery?
Web Application Development Practices
00:23:20
Speaker
Is it like you have a build and you generate platform-specific binaries or something, right? Yeah. Just files for every platform. So you have to have Windows, CI. Yeah.
00:23:32
Speaker
And the communication with the back end, because there must be some compression or something, or because there is a bit of a heavy data, at least in the application state. So how do you handle that one? For now, it's just very simple. It's just how do you call it event pooling?
00:23:52
Speaker
So you don't use web sockets or transit over web sockets kind of thing. We would need to use it, but like send in HTTP, separate HTTP requests is much easier.
00:24:08
Speaker
But isn't that OK, maybe I don't know about the product fully. I think you're still in a stealth mode, or at least for the product is not released yet. But do you plan to have something like multiple people collaborating as well? Because that is something that Ray is also working on, or I think there are a lot of people who are trying these things.
00:24:31
Speaker
Maybe, I don't know. Well, I mean, Apple do that for Keynote, don't they? Yes, they do. Even on the web, by the way, even on the web, they do the same sort of thing. Because I remember a long time ago, I think in 2009,
00:24:51
Speaker
or eight or something, there was a company called 260 North or 280 North. They built the online presentation software in JavaScript. But for that one, they built something called Objective J, which is basically port of Objective C and then that compiles to JavaScript. That was a fun thing to try out.
00:25:13
Speaker
Is it like GWT for Objective-C? No, it's more like ClosureScript, actually. So you have Objective, not even ClosureScript, more like TypeScript, essentially. At that time, we had this multiple coffee script and all that stuff back in the day.
00:25:30
Speaker
CoffeeScript is, by the way, such a nice language, except of some things in the syntax, but it's very nice. So CoffeeScript was Ruby for JavaScript, right? Something like that. And then we have the objective J was basically Objective-C for JavaScript, and they used that one to build the online presentation software.
00:25:51
Speaker
was replicating entire Cocoa API in that one. Because I remember I was contributing to that one for NSString functions or something a long time ago. I think there was this wave of porting all the desktop software into web at some level. Didn't Apple buy one of those companies in the end?
00:26:12
Speaker
Yes, they did and that's the reason why you see iCloud is built using Sprout Core. Sprout Core was the library or the framework to build this.
00:26:29
Speaker
I mean, isn't Sprout Core turned into Ember.js? Yes, exactly. Because one of the Sprout Core developers started Ember and I don't know where Ember is. I think LinkedIn uses Ember heavily these days. Or at least I see them sponsoring the Ember conferences. I think Ember is like
00:26:52
Speaker
closure in the world, but like closure in JavaScript community. It's there, it's good, but a little people know about it, but those who use it are really fond of it.
00:27:08
Speaker
Can I come back to another like web question, which is like, which is always the kind of thing that people complain about with, well, not always, but okay, fuck it. I'll just say some people complain. Some people complain that like security, you know,
00:27:27
Speaker
Yeah, so people complain about web security. So I was wondering what you do with like cross-site scripting, CSRF, all this kind of stuff that people talk about when you get into sort of website web security. What do you do with that? Do you have like a package for it? Or do you just make up your own stuff against the NIST guidelines? Or you just ignore it because, hey, we're a startup. Exactly.
00:27:57
Speaker
I think it's pretty basic. The things that's obvious to have, we do that as well. So there is nothing like super interesting, I would say. I think that security by not telling anybody what kind of security we have. Yeah, exactly. Don't mention on a podcast. What have you done?
00:28:27
Speaker
Is it something like one of your lawyers is listening to this one? Yeah. What if there is anything special? All right. So there are very clear guidelines on what to say. Yeah. Okay. So I think we have one standard question that we ask everybody. I don't think we discussed it on Twitter as well. So EMACs or some other shit.
00:28:49
Speaker
Some other shit. No. No, I have emacs. It's right in the center of my desk. So you ask, maybe once a month. This is literally shelf work.
00:29:08
Speaker
I open it once and once and I'm like, yeah, okay, that's nice. Moving on. How I do learn all of these key bindings. Let's get back to real work, open Karsim and start writing software. You have to go to the process manager to kill Emacs then.
00:29:29
Speaker
No, I already got past it at this point. Oh yeah, okay, okay. No, Emux is pretty much next. You're pretty much next, but at that point then. You're in the 1%. I tried to write a little bit of Common Lisp in Emux, but then I was too lazy to set it up, so I just downloaded like pre...
00:29:52
Speaker
pre-configured Emacs, which is called portacle or something. So it basically has anything for common Lisp already installed, like slime, REPL, all the environment. It's really nice to work in. Okay. But in general, use IntelliJ or Curcivor. Yeah.
00:30:13
Speaker
Okay, nice. It would be great to have an ability to script the IntelliJ, the course view, like you do in Emacs, like you can configure it with custom scripts. So it would be nice to have this in cursive.
00:30:30
Speaker
Yeah, I think there is some meta programming system or something in intelligent core. It's called MPS. But that is more for the, I think, IDE developers or something. So I don't think you can have your own scriptable language or macro system or something that you can use.
00:30:47
Speaker
I'm not sure. Because I remember Visual Studio has something like that. You could record the UI actions and then repeat them. That was a long time ago. You can do that kind of thing in IntelliJ. You can definitely do Visual.
Debugging Tools and Techniques
00:31:00
Speaker
You can record it. That's no problem. Oh, I don't know. There's no problem. So you can record your actions and then replay them. Yeah, of course. OK.
00:31:12
Speaker
Yeah, because I know Visual Studio 5 had this already. So that's one of the super advanced thing. Maybe MPS, I don't know. But it has cursive is written in Kotlin, probably. So maybe you can't plug into cursive, maybe. But these days, Java has its own REPL, right? So maybe eventually you can get something. What do you do, actually? Interesting, because I do a lot of web stuff as well with IntelliJ.
00:31:42
Speaker
I think the problem I've got in general is that if you're debugging stuff, you have to go to the Chrome tools to do that. It's not too bad about source mapping and that kind of stuff. Is that where you set a lot of the time as well in the DevTools debugger? Not much. Not much, no.
00:32:04
Speaker
Mostly just looking at the console where it says... And then you can work it out from there. Printing stuff always works. You don't have to use the debugger. It works.
00:32:18
Speaker
But Chrome also has the source code editor, right? You can point to some files and try to edit some shit in that one. But probably it's not useful for closure, maybe. But they have the source maps because you have to recompile it. No, no, not source maps. What you can do is in Chrome, you can actually open the HTML file in Chrome and edit it. Oh, yeah. Yeah. Like there is a source. I can link to a folder and then say, OK, link to this one. And then I can see the structure. And there is some sort of.
00:32:44
Speaker
Projectively. In Clojure scripts, it's all generated, isn't it? Exactly. The interesting thing is that when you have JavaScript code loaded, you can open it, as you said, in DevTools. But then you can edit it, hit Save, and it will just reevaluate. So it's basically like hope to reload in built-in to Chrome. That's really cool. So you also use Fig Wheel probably. Yeah, yeah.
00:33:12
Speaker
to the hot reloading or whatever. One of the questions for you as well, which I think is kind of fascinating with this reframe stuff, because I've struggled with it recently, so I'm just wondering if you've done the thing similar. Do you use any like native, like stateful JS components with the reframe stuff?
00:33:34
Speaker
Yeah. Yeah. So how, cause then you have to use like a different component model for reframe. How's that working out for you? I'm not sure if we use any like stateful. Well, I mean, thinking like Google maps or, or if you have some, some things that are, you know, where it just, with a, with normal kind of react,
00:34:00
Speaker
The rendering is kind of direct because, you know, everything is stateless. But if you've got a stateful JS component, then you have to manage it more carefully yourself. Maybe you don't have any. And if you don't have any, you're lucky because you're a pen, yes, you know. Yeah. I think I usually just to make a wrapper component for it, which uses reframe subscriptions. Yeah.
00:34:23
Speaker
So the important part is that this JavaScript component would provide you the API to consume and provide values, right? Yes. If it doesn't have this, it doesn't matter if it keeps the state inside, but the important thing is that it has the API. Yeah. So you can route around it. Yeah. Yeah. Yeah.
00:34:46
Speaker
So that's usually how it is, but sometimes there is those components that you cannot do anything about. Have you ever thought of, you know, this is becoming, have you ever thought of thinking that, okay, I should do this in JavaScript?
00:35:03
Speaker
Not yet, but sometimes I'm thinking that, yeah, maybe it would be nice. And it's actually very nice that you can just go, let's say, lower level, right? Yeah. So you can just include, OK, this part I'm just going to write in JavaScript, because maybe one of these things is like this component that is more JavaScript friendly rather than close script friendly or you're model friendly. And then you drop down to JavaScript level and then just introduce that part there. It's like the foreign function interface or something.
00:35:33
Speaker
Yes, I'm actually thinking about it. It's interesting that probably it's not very common to do in a closer script world, right? We tend to write everything in our language. But you consume a lot of JavaScript libraries, don't you? Typically. So whether you write them or you take them from third parties, you know. I mean, like while working on a code,
00:35:59
Speaker
you think perhaps something is slow or just interrupt is not nice. So maybe it would be, it would be nice to keep in mind that you can actually go and write a JavaScript model and just include it. That's interesting. Talking of like those kind of things, do you use like the, like the NPM, like the, what's it called, the shadow, the CLJS shadow stuff, or do you use the,
00:36:27
Speaker
the line plug-ins or use the fig wheel or fig wheel main now or the depth? What are your kind of build tools like these? We use depth and fig wheel main. And I didn't know it, but it turns out that fig wheel main can also compile stuff for production and has additional stuff that is already in shadow CLGS as well, so including NPM is a little bit easier now. It's very nice.
00:36:53
Speaker
Excellent. Yeah, I must admit, from my perspective, I think the Dev Store Eden stuff on ClosureScript is really, you know, raising the bar a lot. I hear some people complaining about it, maybe it's they're all on the Closure side, but certainly from ClosureScript side, the Dev Store Eden makes everything very, very nice to work with. Pretty simple. Personally, for me, it's more like for someone who's coming from JavaScript, for me, Dev Store Eden is more closer to JavaScript world,
00:37:22
Speaker
something like Packet JSON stuff with config.js. So it's just not that huge project.clg with apps and everything in one file. Yeah. And then you have to use CLJS build, which seems like a weird tool as well, you know. Yeah. But do you use Lightning Inn or Boot, or which one do you use for your project? No, no. It's just Fig will main with steps.
00:37:52
Speaker
Okay. Yeah, it's all the rage now, BJ, you know? With the kids, you know? I'm not into the front-end world. Maybe I will get into it eventually, but I fucking gave up on this shit long time ago. It's too fucking hard. Yes, I think I built a pretty complex one using Backbone. That was the first thing, and also EXTJS and Dojo and other shit as well. I think Backbone was fun, but with CoffeeScript, especially.
00:38:21
Speaker
Because the same guy who was building Backbone with CoffeeScript was pretty nice. But I didn't get too much into Curvescript because mostly I'm working with big data. Okay, big. Big is relative term, but mostly
Trends in Front-End Frameworks
00:38:35
Speaker
working with data. So I think it's the JVM and backend stuff that is much more interesting for me.
00:38:41
Speaker
I think I'll wait until all the thing settles down in probably in 40 years. We don't have like 70 different frameworks and some other shit in JavaScript constantly. It does seem like that now. I mean, don't you think like the React Net, if it's basically one?
00:38:58
Speaker
I'm not really convinced with React Native, though. No, I mean React. Yeah, I think it's converging. But the thing is that it's a similar wave that happened with Angular. And everybody wanted to do Angular applications. And then I saw, what the fuck? This is basically Spring in JavaScript. Interesting, I guess. And then React came in. I think React is a pretty nice thing. I think it's converging towards React. Everybody wants to build just React applications.
00:39:27
Speaker
That's pretty cool. But for the front end, I think I'm still kind of old school because I'm convinced that if I'm going to build something on the desktop, I would go for the native language for some reason. I'm not sure why. I feel I should do it in Swift. I think the problem is that it's OK if you're making a hobby project, but if you're trying to make something for the phones and for the desktop and for the web,
00:39:56
Speaker
then having all those languages, you've really got to work out that there is a big payback for actually dropping down into each of those languages rather than using a framework like ClosureScript to get the benefit across all of them because the investment you're gonna make is pretty huge to maintain all of those projects in a kind of nice visual, sort of a common visual experience and all that kind of stuff, cross-platform. It's gonna be hellish.
00:40:24
Speaker
Really? So you have to have a really good argument for it, but I guess it's your point, Roman, your company's point. That's why they're using the Closure and ClosureScript stack, because they can get the benefit across all of the devices. Yeah, exactly. Time to market is immediate. You reach to every platform, including that. So that's very good.
00:40:48
Speaker
Yeah, I mean, that's what we see in Slack or in all the new chat applications essentially using this platform. And then taking, I don't know, the fucking 800 gigabytes of memory and just run the shit. Yeah. And just mental. Yeah, that's the bad part of it, for sure.
00:41:07
Speaker
Yeah, because I saw some open source, not open source, but there is a project. There is a person who is building cross-platform chat applications, but in C or C++. Sorry, not in C or C++, but a language called V. So he's building his own language. And then he's building a chat applications very native. So it's like super tiny binary. And it doesn't take this much memory. And it talks to Slack. It talks to IRC and all that stuff.
00:41:33
Speaker
So maybe we need a different runtime. I think it's, as you were pointing out Roman, I mean, there is this, the baseline of electron application is the 20 years of fucking browser shit that it needs to render. I'd say that one day we are going to have a switch in a browser where you can just switch off all the legacy stuff. I don't know.
00:41:55
Speaker
So maybe there is some sort of a build tool that can do the tree shaking or something from the cord and remove all this crap and then you build like tiny Chrome. There is actually a couple of projects I've seen that are like the port of the WebKit for embedded devices and it's super tiny. I think even PS4 is using WebKit, like the small version of the UI is rendered in WebGL.
00:42:21
Speaker
Yeah, yeah, that'd be super cool. I think, to be honest, I don't see there. I don't think there should be a particular problem with that, especially for electron apps. I mean, that looks like, because, you know, you're shipping the code, you're shipping, I mean, standard web browsers are a bit different because they're expected to support code from everywhere. So fair enough, you know? But you control the environment. I think with electron apps, you can do that.
00:42:46
Speaker
Yeah, I agree. So talking about native stuff, maybe before we go to native things. So what is the application that you're building for Android, replete or rappel on Android?
Personal Projects and Inspirations
00:43:00
Speaker
Yeah. So it's, um, the Mike Fikes built the original application for iOS. I believe in 2015 or something. Yeah. So it's a basically iOS application with embedded JavaScript core engine, which is in Safari browser and it runs the self hosted, uh, closer script.
00:43:20
Speaker
I was using it a lot until I broke my phone and switched to Android. I was interested in what it would take to build such an application for Android and also practice a little bit mobile stuff. It turned out to be a very nice experience.
00:43:45
Speaker
especially for when the web developer, uh, who is like spoiled with dynamic languages called hot code reloading and everything. It's, uh, it's still really good. You can have sort of a hot reloading for, uh, Android because they, if you change only view logic, it auto reloads the view instead of recompiling the whole application. So it's nice and also Kotlin and feels good.
00:44:10
Speaker
Yeah, but is this available on the Play Store now? Yeah, it's already in beta. You can go to Play Store, search, replete and join the beta program and start it and try. So instead of JavaScript core on Android, it runs V8 just because of...
00:44:27
Speaker
It was much easier that there is already a library with Java bindings, and you can use it directly from Kotlin. The interop between Kotlin and Java is super seamless. You don't have to do anything. It's very nice. I understand that JavaScript code does run on Android, though. Yeah, you can do that. But, I mean, I didn't want to spend time on writing bindings. No, no, sure, sure, sure. But it's what React Native uses, isn't it?
00:44:57
Speaker
Yeah, they also use JavaScript Core because apparently it's much faster. And I believe in the performance test of ClosureScript to show that JavaScript Core is much better at executing compiled ClosureScript than V8. Which is weird to me, yeah.
00:45:14
Speaker
Did you know that in our latest chips on mobile, Apple included JavaScript-tailored instructions for working with floating-point numbers? I didn't know that. So they reserved semantics of the floating-point number on the CPU.
00:45:30
Speaker
there is a set of new instructions. And that's why new iPhones are like four times faster than iMac Pro. Wow. I didn't know that. That's interesting. Yeah. So they've actually put the JavaScript on the metal. Wow. I guess when you can design your own chips, you have that option. Yeah.
00:45:54
Speaker
That probably means a lot for React Native as well. Yeah, yeah. But how do you handle all the NPM bullshit? Like all the bazillion libraries and all these things? I don't know. I don't use that much. That is one way of using it.
00:46:14
Speaker
Makes sense, I think. In those four of something years that I used Closure Script, nothing has changed. Reagent is the same. Everything is the same. At the same time, when PM ecosystem grows, and especially reactive ecosystem grows, and you get more and more very nice UI primitives that you can start using without rebuilding everything yourself. So it's just consuming the modules.
00:46:41
Speaker
Yeah. That's a nice segue into, I think, the UI. What do you mean by UI primitives? Like web components or something like that? No, I mean some, let's say, more or less stateless components that, for example, like tables, buttons, I don't know, sliders. Like if you want to build a custom select on a web today, it's madness. If you want to handle all of the focus, keyboard stuff, no, I don't
00:47:12
Speaker
Yeah, yeah. So it's very nice to be able to use that. But you're also experimenting with building something for a native like that, right? The UI components. Or did I understand? Yeah, so I was wondering, because I was working with React Native a couple of years ago. And I really liked the model that you basically provide bindings for native UI controls into JavaScript environment. And I was wondering why is no one doing this for a desktop?
00:47:40
Speaker
Electron right now is basically what phone gap was before React Native. It's just a web view wrapped into full screen container, right? And no one seems to be interested in that for the desktop. I don't know, maybe it's not much demand on the market for that.
00:47:58
Speaker
I don't know. So can you give us a bit of background like what exactly the problem that you think that needs to be solved for this one? I mean there are a lot of different toolkits already for an 8-year-old like the most popular probably is GTK right? Yeah yeah or Qt or GTK yeah yeah it would be very nice to have a dynamic environment where you can
00:48:24
Speaker
execute JavaScript or whatever dynamic language and have the native hardware graphics spin. So it would be very cool. So you're talking about this notion of being able to use, like with the iPhone or the Android, where you've got the native web, the native toolkits.
00:48:47
Speaker
So they already got all of the bits and pieces, or you can write all the bits and pieces in like your native language like Swift or Java or Kotlin or whatever. And you're saying you'd like to be able to do that for like some Electron app. So if you could have like a GTK control or something like that, which was super fast, like a super smooth scroll or something like that, or
00:49:12
Speaker
window resize, or I don't know what's kind of slow on Electron really, probably everything, but you know. But if there's one specific thing with the scrolling or with the scaling or whatever, you'd like to be able to just get a native version of that and integrate it, but it's hard at the moment. Is that the problem? Yeah, sure. No, it would be nice. I didn't think about it, but it would be nice if you could, like on Electron, if you could provide native controls. But I was thinking more,
00:49:40
Speaker
a way that is Flutter, Google's Flutter is doing it. So they provide you basically a canvas where you can draw anything.
00:49:51
Speaker
So instead of using native controls, which look different on every platform, it would be nice to have this dynamic environment, which provides you bindings to OpenGL, and you can just draw anything that you want. Of course, it would require to re-implement the events model, the scrolling, everything, basically. That's the essential problem, isn't it, with the canvas and that whole thing. It's just the reinvention of the web.
00:50:20
Speaker
No, that's true. But it will go fast, though. That's for sure. Yeah. But isn't it something because there should be something using SVG on the web for this kind of things, right? Yeah. Like you can use SVG to build these components, so to speak. But there is a behavior that you need to attach to those things. I mean, rendering is done by SVG. There could be something like that, I think.
00:50:48
Speaker
But on native, I have no idea. So if you're using OpenGL or something to draw, you need a surface to draw on some graphics context probably. So you're working on bringing JavaScript into this, or where is the dynamic thing coming from?
00:51:07
Speaker
Yeah, it's more like experiments. I was thinking about it a lot, and then I saw this project in OCaml in Reason. So they basically do the same, but they compile to native binary and compile to WebAssembly for web. But it's really good that they do it as a native binary for OCaml.
00:51:31
Speaker
for desktop, but compiling everything to WebAssembly for browser means that they run UI on a WebGL, then you don't have, I don't know, like accessibility basic stuff.
00:51:42
Speaker
And for desktop as well, you have to use accessibility frameworks on every OS if you want to make your interface accessible. If you draw it in OpenGL, it's just a canvas with all the visual stuff. So I was thinking it would be really nice that you can actually use React ecosystem. So React has this ability to write your own custom reconciler.
00:52:08
Speaker
they extracted in recent versions, they extracted into separate package. It's called just React Reconciler. And the Reconciler is basically a function that emits a set of command for two different UI trees. So when it did diff, it converts it into like five or six commands, like create, delete, node, create, change, attribute, delete attribute.
00:52:33
Speaker
And you can apply it to any target that you want. You can reconcile, like the UI and OpenGL, or just maybe even talk to server. I don't know. That is where it has instruction for everything. Do you have like what state you are in when you're still experimenting with it, right? I mean, is there something that you already? No, I'm mostly experimenting. So I was thinking about, like,
00:53:03
Speaker
run node.js instance, write a little bit of interrupt code as a native add-on for node.js, like provide bindings for window controls, for scrolling for events, and OpenGL. And then I think is that, for example, OpenGL maps one-to-one with WebGL, because basically WebGL is OpenGL for the web. So it was very easy to
00:53:32
Speaker
Uh, to bind OpenGL to have jail and then you can run every like JavaScript library for 3d, like three JS and yeah, have 3d stuff very fast. Yeah.
00:53:46
Speaker
Sounds pretty interesting. So I think we'll keep following you. I think once you have the demo or something. I don't think I will get anywhere with this because we're working alone. No pressure. We'll make it awesome. I think in a couple of weeks, if we can get the demo, that would be super nice.
00:54:11
Speaker
So I think we are almost one hour. Nice. So I was just talking to you before we started recording. You're there at Closure D, right?
Closure D Conference Highlights
00:54:23
Speaker
I mean, any impressions from Closure D? I was there too, but I think it's better to hear from you.
00:54:31
Speaker
Yeah, it was nice conference. Yeah. A lot of nice talks. I think the favorite talk for me was the German guy about Lisp history. Yeah. Yeah. Yeah.
00:54:47
Speaker
Yeah, it was very nice to... I like that he was talking about the local stuff that was going on in Germany, not the entire world. So you learn a little bit of Lisp history in Germany. Yeah, that was really interesting talk. I think of the West Germany and then East Germany and there is a Lisp movement everywhere and that was super fun.
00:55:10
Speaker
I think one of the best things was the whole compilation was essentially taking your punch cards and going by S-Bahn and then actually going to the machine and putting the punch cards in. That was super fun to hear, you know, like how much we have changed in just 20-30 years. It's crazy. Yeah.
00:55:29
Speaker
And I really like the talk by Paul. Paulus Esterhazy. I don't know how to pronounce his name. He's also from Pitch. The philosophy of combining things, composition, and that one was pretty nice. Yeah. It was very abstract talk.
00:55:48
Speaker
Yeah, very philosophical. But it was a very nice conference. I think because it's a two-track thing, there is this missing out on some other tags, missing out on some other talks in another one. It was fun.
00:56:04
Speaker
But it was pretty nice of Ingo and the organizers to invite us on the stage as well. So I was able to talk about DCD for five minutes. And I met a lot of people from Heart of Closure as well, RNA running out of Heart of Closure. So I think we're getting, there are dozens of us, you know?
00:56:26
Speaker
Yeah, it's very nice to be in a room with a lot of people who are interested in the same stuff that you do. Yeah, exactly. What I like about Closure Conference is that they are not feeling like a festival, like a thousand people super expensive conference or something where you don't know anyone and know what to give the fuck about you.
00:56:48
Speaker
Yeah, I think if you go to Java world or something, one of those things, they're just probably like a village or something. Not a Russian village, but probably an Indian village. Huge amount of people. And you're just one of those persons and a lot of exhibitors, et cetera. But it's still really cozy and a nice environment. So any other topics that we want to cover?
00:57:18
Speaker
I don't know. OK, so we'll wait for your native toolkit in a couple of weeks.
Upcoming Closure Events and Community Engagement
00:57:27
Speaker
So I think maybe first April or so. No pressure again.
00:57:34
Speaker
Just to give a quick update on, because we're talking about conferences, and so Dutch closure day is going to happen on 6th of April. We just published most of the talks. I think there is still one talk that we need to pick. It's been a big challenge for the program committee to pick the seven talks out of 42.
00:57:56
Speaker
I mean, they're so amazing. All the proposals are so awesome. We were actually thinking, shit, next year we really want to have a two-day conference. Because we really want to have all these talks and it was so difficult to pick what we want to have.
00:58:15
Speaker
But I think we have a very nice combination of talks, both beginner and tooling and real world and a bit of things. So it's going to be fun. We are planning a couple of fun activities as well. I think more, once we send an email out for all attendees, it'll be, I think, more out in the public.
00:58:37
Speaker
But we are looking forward to the conference. And of course, there is a big shout out. I want to give a big shout out to Heart of Closure that is going to happen in August. I think the CFP is still open. I think they closed it, actually. No. No, I think they extended it. Oh, they extended it, actually. Yeah, yeah, a bit. I need to look it up. And also Closure Tray as well, and enclosure. So all these people on the stage on Closure D.
00:59:04
Speaker
So we are essentially trying to work together to make sure that we give different flavors of conference for catering it to everybody in Closure Community. So I hope I'll see some of you at Dutch Closure Day, or probably Heart of Closure maybe, in Belgium. And Closure Tray is in Helsinki, somewhere in September, I guess. We'll put the links on the thing.
00:59:34
Speaker
So that's it from us. Ray, do you have any list of people that you want to give a shout out to? I'm not very well organized today, I'm afraid. So we thank everybody. Yeah, yeah. Of course. I think Roman is buying his way onto the show, in fact.
00:59:53
Speaker
So if any of the patreons do want to shout up and join us on the show. Yeah, exactly. You just give us one dollar, we'll put you on the show. You know, that's that's super easy. Yeah. Yeah. Bribers, please. That's the one I remember. I don't remember, but I do remember that he's on the list. I was a good new shout out before, but we can give you a special one today as well. So thank you for your money and thank you for your ideas. You know, it's both a welcome.
01:00:22
Speaker
I think we are the first podcast ever that the listeners are the people who are the guests, you know, like basically one to one. And they're also the people who pay to be on the podcast or help us out to run the cost or something. That's a healthy ecosystem.
01:00:39
Speaker
But anyway, thanks a lot for your support. I think we will put the money to good use, and it's helping us in covering the costs as well. And that's it from us today.
01:00:54
Speaker
Yeah, thank you very much really good fun and You know, I think everyone should check out the the beta version of replete on Android Because you know it's in good work there Keeping up keeping get getting the reach of closure and closer script across more platforms is solid work. So Really well done. Thank you very much Yeah
01:01:18
Speaker
Yeah, thanks a lot for being on the show. And for all the lovely money. Yes. Okay, that's it. Goodbye and we'll see you in a week.
01:01:58
Speaker
you