Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#72 Chris Badahdah from Phoenix!
15 Plays3 years ago
Chris takes us into his Clojure Portal and other Clojure adventures :)
Check his awesome tool: https://djblue.github.io/portal/
Recommended
Transcript
Introduction with Special Guest Chris
00:00:15
Speaker
Welcome to Defend, episode number 72. This is Vijay from Holland, still in Holland. Raymond from Belgium.
00:00:23
Speaker
And we have a special guest today as well. Yeah, please go ahead. Introduce yourself. I'm Chris from Phoenix. Chris from Phoenix. The US Arizona. I don't know. Fucking names. I didn't use my full name in fairness. Neither did you. Okay, come on, Chris. Because you're the new unknown one, you got to give your full name. Okay, Chris Palata.
00:00:49
Speaker
Yeah. Welcome. I think DJ Blue. Yes. Yes. You're wearing blue as well. Yeah, exactly. Yeah. Blue is my favorite color. So you can, you can guess as to why that's the name. Are you a DJ? No, I wish I was musically gifted. I'm not.
00:01:07
Speaker
So just see if you need something else. You don't need to be musically gifted to become DJ, no? Oh! Oh! Yeah, just bullshitting anyway, you know. Is the DJ thing that you keep rotating the disc and then you make weird cat noises?
00:01:21
Speaker
Yeah, like that. Oh, you have a DJ in the house. It's a name I came up with when I was younger, when I was like playing a game and it was like, you have to come up with a username. I'm like, then there's like the initials of the game and then my favorite color. I'm like, this is good. And it's just stuck with me for just years and years and years and years. So it's one of those things.
00:01:41
Speaker
I like how you introduce yourself, as if you're the only Chris from Phoenix. I'm Chris from Phoenix. You just go to Phoenix and then ask, where is Chris? They point to you. It doesn't matter where they are. I know you're very popular there. Exactly, exactly. Guaranteed no collisions. If you look up that in this area, just no other ones.
00:02:04
Speaker
So let's try to narrow it down a little bit, a little bit more.
Chris's Journey to ClojureScript
00:02:08
Speaker
So what are you up to in the closure world, or maybe in programming world? So a little bit of a bio, you know?
00:02:17
Speaker
Well, I can talk about my like journey to closure. I think that's yes. Yeah. So actually, the my question is better than we do, Chris. Exactly. Listen to a few episodes. Yeah, I mean, this video beating around the bush a little bit.
00:02:35
Speaker
But okay, yeah, Chris, answer the correct question that you found out. I'm glad you have the checklist, you know, you're just going to go through it yourself. So we don't need to do anything here. It's the point of us now. We're just a random things and then you pick out the question that you want to answer. Okay, Chris.
00:02:54
Speaker
Well, you guys don't get to monopolize random things, okay? I get to say random things too. But yeah, I came to closure by way of scheme, S-I-C-P. I found those MIT videos.
00:03:10
Speaker
And I love them and I was like, oh, this is so good because I mean, before that I had done it like a ton of JavaScript and I was like, JavaScript is nice. I liked a lot of the things you could do with it is very expressive and have like object literals, which I think that is the killer feature in JavaScript is you can just write the data down. And then I was like, scheme is really cool.
00:03:30
Speaker
And I implemented like an interpreter and all that stuff, but I was like, okay, now how do I build web apps with this? Cause I need to, you know, I need to actually build stuff that people can use. And I was like, I was looking for a, you know, a version of scheme that could run the browser and I was like, oh, there's closure script. Okay. And then I went down that rabbit hole and here I am full closure. This is a bit, uh, this is a bit.
00:03:53
Speaker
Well, I won't say unusual, but this is probably the new age closure entry point, I would say, right? Because back in the day, I think 10, 15 years ago. When you say new age, do you mean like, you know, the kind of hippie? Because I think, or do you mean like, because he's young?
00:04:08
Speaker
Okay. It doesn't look like a hippie to me. Are you self describing yourself as a hippie, Chris? I mean, I don't know. I don't know what that means or what you mean by that. Well, usually it's all flower power, love, peace, smoking the door or tripping on acid, you know, kind of stuff. I don't subscribe to all those things, but I subscribe to some of those things.
00:04:31
Speaker
No, I meant new age would make younger hip, not hip. So without the P, only hip. Back to my... Like the latter drinking coffee kind of people.
00:04:47
Speaker
Exactly. You know, like the big beard and then, you know, like that hipster, I guess. I'm not cool enough to be hipster. After this episode, you know, once we publish this, you know, you'll be there.
ClojureScript vs JavaScript
00:05:01
Speaker
But anyway, what I meant is that I think most of the people, or some of the people initially, the entry point of closure was where Java and then, you know, so for you, it's a bit of a, you're coming from the front end. Yeah.
00:05:17
Speaker
Yeah, I came from like JavaScript on the client and the server like I did node and I really liked node and I was like, you know, you know, found closure script got really into it. And then actually, I used to hate Java in the JVM. I still hate Java. But I love the JVM. Like it's, it's so nice, especially paired with closure. It's such a nice runtime to work in.
00:05:42
Speaker
And I think the tooling for it is probably the best. Of all the closure dialects, the JVM one has got the most support. So it's really nice. And because the journey is via JavaScript, did you try... I saw that you worked on what was the backbone some time ago or that you ported from backbone to something else, right?
00:06:05
Speaker
Yeah, yeah. So at my last job, we were like going from Backbone.js, marionette to React. And that was another thing too that I really liked about Closure Script is that interop with React was just seamless. Like I watched all the David Nolan talks about how Closure, React is better in Closure Script than it really is. It's so nice to just be able to be like, hey take, especially paired with like something like Hiccup. It's just like data maps in, vectors out.
00:06:36
Speaker
And you don't have to worry about how to get that change into the DOM. And I think that was always the hard part, especially because you don't know what state you're in. You have to figure out how to get from where you are to where you want to be. And there's so many edges. If you think about a graph and nodes, there's way more edges than there are nodes a lot of times. So it's like in React line, you just focus on the nodes.
00:06:57
Speaker
you forget about the edges because react does all the edges for you and it's like an order of magnitude less work something like react but did you try some other flavors of javascript like because i remember when i was writing javascript when backbone was a big deal um i think it was coffee script because backbone was written in coffee script so
00:07:20
Speaker
I never got into CoffeeScript. It looked interesting. But no, yeah, I started with just like Vanilla, JavaScript, and I went to something like jQuery in terms of UI frameworks. But in terms of languages, it was pretty much just JavaScript all the way. And even then, I kind of liked ES5. Even when people were getting into ES6, I'm just like, oh, there's more stuff now. So yeah, but the style of JavaScript I tended to write was just functions.
00:07:48
Speaker
that took in maps and returned maps. Honestly, that's what I ended up doing even after I learned ClosureScript and I still had to work in JavaScript is I was like, I'm going to bring all the good parts from ClosureScript into JavaScript, okay, immutable.js, okay, Redux with that being our atom and it was just like, keep it functions and data, please. Yes. You're writing ClosureScript in JavaScript before even coming into your script anyway.
00:08:17
Speaker
Yeah, exactly. But how complex are your applications? Because usually Clue to Script, you know, it's used for not just like websites or sprinkling here and there, you know, like animations and DHTML shit, you know.
00:08:32
Speaker
So how big is the code base? So what kind of applications are you building with it? So it depends. My personal projects are a couple hundred lines. But it worked a couple thousand lines, like 2030. So that's not a good proxy for the complexity. But yeah, there's a lot of interactivity in a lot of these. They're like Google-ish style things with result viewers and things like that. Those are the types of apps.
00:09:00
Speaker
that I was working on, at least with JavaScript. What is your preferred stack enclosure script?
ClojureScript Stack and Tools
00:09:10
Speaker
I don't know if I have a preferred stack, like anything, I'll work in whatever as long as it's like primarily just data driven. Cause I've used Reagent. That's a really nice, like feels very closurey. There's another library that I use at work called Helix, which is kind of a, it's less of a wrapper or well, actually no, it's exposing React directly. I would say that's how I describe Helix, but yeah.
00:09:39
Speaker
But yeah, as long as you keep your application, I think you guys talked about this in the last episode, like data oriented, that's where I want to be. I don't really care what the underlying technology is. As long as you keep it data oriented, I'll be happy, right? You can use any HTTP server. It's all the same stuff. It's all maps. You can use any serialization. You can use transit or Eden or whatever, but please just stay in data. Do you use like a client side router? Something like, you know, like, like Reddit or, you know,
00:10:09
Speaker
I think at work we just use React Router just because it's like Helix gives you like a really easy path to using all the JavaScript libraries. But yeah, for like my personal projects they tend to be like single pages like without a bunch of different places to go to so I tend not to bring in routing and just like here's the page and then there's state on the page.
00:10:36
Speaker
So you don't need deep linking or stuff like that in your application usually. So in terms of, because you came from JavaScript, you were building fairly complex stuff in JavaScript already, right?
Async-await in ClojureScript
00:10:50
Speaker
And so what do you miss from JavaScript? I mean, it's kind of probably nothing, but it's still, is there something when you're writing ClosureScript applications, oh, this shit has been much easier in JavaScript.
00:11:03
Speaker
So I think the thing that was easier, and this was towards the end of my JavaScript stuff, was the introduction of async await. With ClosureScript, I think there's people who have implemented compiler extensions that introduce it. Or you can bring in core async, but that's like you can't interop with other people. And there are promise extensions to core async now, but it's not as
00:11:30
Speaker
well-supported, I guess, I don't know. But yeah, async-await, just direct async-await support. What about something like Promise Air? There is a Promiser library which integrates with async-await. No, yeah, but I mean just as part of the language itself. You're right, though. There's plenty of ways to fix this in the user space. I'm just, you know, I would like to have less dependency sometimes. Oh, yeah. What is async-await for people like me who are JavaScript illiterates?
00:12:01
Speaker
OK, I can walk you through it. So it's like, in JavaScript, you only have one thread. So when you need to do things that take a long, well, not even take a long time, but that are semantically blocking, like IO, that they take on the order of hundreds of milliseconds? I don't know. You don't want to be consuming the entire thread for that. So you say, OK, pause here.
00:12:25
Speaker
And then when you're done with that, resume. And so normally in JavaScript, people do that via callbacks, right? And then people got sick of writing, is it callback hell? Is that what they called it? And then there was promises. And then on top of promises, people added syntax to JavaScript called async await. So is it something like bringing Node.js type of
00:12:49
Speaker
programming style to the language itself. Yeah, C-sharp, isn't it? Yeah, it originally did come from C-sharp, this async-await concept. But it's just like syntactic sugar around promises that are in JavaScript proper, like the languages at ES. I don't know which version of ES brought it in, but... Okay.
00:13:11
Speaker
But yeah, and you kind of don't get a choice. You have to use it because you only have one thread. And that's the thing I like about the JVM is like sometimes I just want to block and I don't care. I don't need to be high performance. You know, I just want to block. Just let me block.
00:13:28
Speaker
Okay. So this is, this is, so I think a way it is one of the things that, that you missed or that you something that you think it's a, it's not there. It's not as easy. I think, I think it's available in a variety of forms. What are you going to say? Right? No, I was just going to say after you finished that, it's okay.
00:13:46
Speaker
Oh yeah, it's definitely there. There's a bunch of ways to solve it. It's just not as easy as doing async-await. There's like, you can bring in core async and deal with promises via channels and stuff, or you could do like the library you were saying, premisesia, I think.
00:14:01
Speaker
Well, you know, we have to have a show of its own to find out its true pronunciation, the canonical pronunciation. Promisee. Promisee. Promisee. It's a Jeff. Who knows? And then the thing I think to think it makes kind of challenging sometimes is if you want to do like IO and CLJC files. And I know this is like supposed to be a platform problem, but it's like, it's still,
00:14:29
Speaker
I want to pretend that everything is the same in CLJC and it's kind of hard with one platform is like all promise based and the other one is like, you can actually block them. So I don't know. I'm just.
00:14:42
Speaker
But the other thing I was going to say to you, we were talking about it a bit earlier, was the interoperability aspects of things. Because there was a time when, in my mind, before I started talking to you, there was still the time that you couldn't interoperate with all of the React functionality, the React libraries, the React bits and pieces that have been brought into the React ecosystem.
00:15:10
Speaker
But you were telling us that that's not the case anymore. Yeah. I think it's relatively new in the beginning of this year, Reagent 1.0 introduced support for a functional compiler, which is a mode of reagent where all of your components are functional components, which maps really well to, I think, ClosureScript. And then you can leverage straight up React hooks and effects state.
00:15:38
Speaker
use reducer, all the things that are new in React you can use. And they're really nice sometimes, instead of the class-based APIs that you had to deal with, you can just say, use this thing. And a lot of the JavaScript ecosystem exposes hooks, so you can just pull them in. And with a tool like
00:15:58
Speaker
Shadow CLJS, it's really easy to just pull an NPM dependencies and say, okay, I'm using it now. And there's no wrappers around them that need to be maintained. I think that's one of the issues with wrappers is that they're a maintenance burden. So are you using any of those things yourself? I'm using all those things. I use Shadow CLJS all the time. I'm using any of the libraries from React that maybe you wouldn't have had access to before the one zero.
00:16:28
Speaker
Um, I don't think so. Um, I definitely just, I just leverage the hooks directly for the things I need. Um, it worked though. We use like, like I was saying, react router directly because it's really easy to just use it directly. Um, so. And what is the, what is the backend of the application that you're building? It's also completely closure JVM stuff.
Emacs and Workflow Integration
00:16:50
Speaker
Yes, it works. It's all a JVM backend, which is nice. Just full stack closures is ideal, especially with something like transit in between, because then you don't have to worry about serialization. Use Emacs or some other shit.
00:17:07
Speaker
Ooh, here's the question. I've been waiting for this question. The reason to ask this now is whether we can end the episode right now or not. Saving time. It's being optimal. Is it still worth talking after you do it with Emacs? That's the next question. Are we going to start the Emacs podcast that we often have on this podcast? What do you think this podcast is about?
00:17:36
Speaker
It's it's it's an emacs podcast masquerading as a closure but actually it's begin to feel like that yeah anyway yes please go ahead. I've had a journey i've used a lot of different editors i've used i've used cursive a little bit i've used them and i use them for a long time with like them fireplace and then i used conjure with me open.
00:18:00
Speaker
But earlier this year, I don't like where this is going. I don't like where this is going. I really don't like where this is going. Oh, what do you think? No, no, I need you to guess now. Where do you think I ended up? Please, please.
00:18:14
Speaker
Please, VS Code? No, I tried VS Code and I think Call was a great extension, but Nora, I switched. I'm in, I'm in evac now. Man of culture. Oh my God. Now we can enjoy the podcast much better. Now we can talk about this stuff.
00:18:34
Speaker
Yeah, like a real programmer. And now we enter the Emacs podcast. No, no, but it's evil Emacs though. So it's okay, right? Fair enough. Fair enough, of course. It's funny though. If somehow I disable evil mode, I get completely lost and I don't know how to use my computer anymore.
00:18:52
Speaker
You're just looking in the activity monitor just to kill the session at that point. Yeah. Just be like, oh, no, hard restart. I don't know. Let's just pull the flag. Take the battery off, you know? I could learn about Emacs or I could keep pretending that it's VIM, you know? Yeah. Well, I think VJ's activity monitor is running inside of Emacs, so it would be impossible to kill anything. Yeah, that is a process monitor.
00:19:16
Speaker
You know, I recently started using, quote-unquote, using Pinephone. This is like the Linux phone. So the first thing that I did, it's based on like Manjaro Linux or something. So the first thing I did, okay, let me install Emacs. I couldn't get out of Emacs. Literally, on the phone, I couldn't. It's supposed to show that thingy when you swipe from the bottom. Because the cords can't work on the phone or something.
00:19:39
Speaker
No, no, it's EMAX is up. EMAX is running. I can type shit and everything is working. So no problem at all. But I can't quit EMAX. Like, it's impossible on the phone. It's full screen. And I cannot switch to the app switcher or whatever. So I had to do that.
00:19:54
Speaker
You sure? It was the proper Emacs thing. I was like, wow, this is amazing. I'm just stuck in Emacs now. I can't do anything. Well, it knows what your preference is. Exactly. Everything else should come to Emacs. That's the message, isn't it? I've got Emacs up right now. What's going to come in here? Give me a phone. Where's the phone? Where's the phone board?
00:20:23
Speaker
It's all text call somebody, you know? Yeah, yeah, exactly. Anyway, yeah.
00:20:29
Speaker
But I like that your journey ended at the logical conclusion of the best editor of all time. Hey man, I could switch again. I don't know. I don't have allegiances to any editor. Do it, do it. Look, it doesn't matter. It matters what you are using right now until this episode. That's true. It just cares about the scores. It doesn't care about the match. It just cares about the results.
00:20:55
Speaker
So if you still want to come for another episode, you know what to do. Keep using your mind. Or just switch right, switch just in time, you know, to be like, Oh, no. Like the lost sheep, you know, the prodigal son returning home.
00:21:12
Speaker
Like half an hour ago, I just switched to Emacs again. So anyway, so I was talking about the backend stuff as well. So you're doing closure in the backend, closure script in the frontend. And the kind of, you know, you're talking about the interoperability, right? You know, that's the thing that you really, I mean, do you think it's,
00:21:40
Speaker
way more easier compared to JavaScript and Rails backend, whatever people use.
00:21:46
Speaker
So I do think in terms of accessibility to ecosystem, it used to be much harder in JavaScript, especially like NPM, but I think that's a solved problem now, both in external tools like Shadow because of the closure with the S, I think, compiler extensions that are in that. But also, I think in proper ClosureScript, you could just export something that can be consumed directly by something like Webpack. So I think this used to be a bigger problem, but it's pretty much not an issue anymore, I think.
00:22:16
Speaker
Yeah. What I would do in terms of like,
Tips for ClojureScript Development
00:22:20
Speaker
oh, sorry. I was just going to say that I do think that a lot of the runtime reification of like developer things is nicer in the JBM closure, like namespaces and vars, whereas like in, in JavaScript, you're just trying to compile the JavaScript. You're not trying to in the runtime provide a, you know, extensive development environment. Yeah.
00:22:42
Speaker
It's like you need the JVM to have a nice JavaScript development or a ClosureScript development experience. Talking about the ClosureScript development experience, you're using ShadowCLGS, so I guess you use it's live reloading facilities.
00:23:00
Speaker
Yeah, I'll go back and forth between using the REPL and just saving a file to read. If it's render-based, I'll save the file and look at what my browser rendered. But if I'm working on logic, I'll just grab a snapshot of my state via an atom or something and run it through some code and look at the results, maybe pipe it to Portal.
00:23:22
Speaker
Nice. Hold steady. Hold steady. Yeah, so so yeah, okay. So any other sort of tips and tricks for people out there with using like doing closure script development?
00:23:36
Speaker
Yeah, for me, one of the things I really resisted early on was the JVM. I was like, I want to do JavaScript, but I don't want to take on the JVM. And in retrospect, I think that's just like, yeah, who cares if it works, it works. And you do get a really nice experience of use, something like Shadow, where there's, you know, and FigWell, I think actually as well has like good end REPL support and you just, you know, connect and start evaluating forms. So, hmm.
00:24:03
Speaker
And don't resist the JVM if it's new to you. Yeah, yeah. But I think it's how did your closure script.
00:24:14
Speaker
Let me start from JavaScript to ClosureScript. I'm assuming you learned ClosureScript first compared to Closure, although they're pretty much similar languages. Do you feel any friction in writing Closure on JVM versus ClosureScript?
00:24:34
Speaker
I think I knew Java enough and I was comfortable enough with Java to explore the ecosystem. So like if I needed a IO stuff with buffered input stream, right? You know, all the like Java isms I was comfortable with. I actually didn't know all that much about class paths. And then I was like, Oh, okay. I feel like I did learn more about the JVM through closure than I did through Java.
00:24:56
Speaker
I don't know how, but yeah, I'm much more comfortable with the JVM now. One more question about the front end is what do you do for like, because when I'm like, the front end is always much, much more complicated to me than the back end, because you have like at least three languages always, you know, you've got JavaScript or ClosureScript and you've got CSS and you've got HTML.
00:25:24
Speaker
What do you do to reduce the amount of complexity or friction between all these things? Do you just pick some CSS and just stick with it? How do you work like that? Is it sort of a design that makes a CSS and you all just use it or is it more fluid? Are you involved in that aspect of things?
00:25:45
Speaker
So there's like two modes, like there's like what I do on my projects, and then there's what I do at work. At work, we're just using Tailwind, I think. It's a pretty popular solution for CSS these days, and then we just use, you know, Helix for the React components, right? So it is technically, I mean, it's all in ClosureScript, and we write very little CSS because we're just leveraging
00:26:06
Speaker
tailwind for the CSS. But on my personal projects, I have to keep everything as like just closure script data, or sorry, I guess closure data.
CSS Management in ClojureScript
00:26:15
Speaker
And like, you know, pickup is the HTML, and then maps are the CSS. You still have to understand the semantics of what the data means, which I think is still a hard problem. Like, we always say in the closure community, everything's just data. Yeah, but what does it mean? That's still a problem. We have to be able to communicate what data means.
00:26:33
Speaker
I mean, it's a map. What do you mean? It's a map, yes. Moving on. What do these keys mean? It's a map. But that's the sort of matrix type question, isn't it? Now your data is in a map, but what does it mean? Yeah. Yeah. And it's a map. But at least if it's data, you can at least start building a UI to inspect it. And then you get leverage across all these different data formats. And I don't know.
00:27:03
Speaker
Yeah, exactly. But yeah, in my personal projects, I just like to keep everything in ClosureScript. Even my CSS, I like to, you know, like the CSS and JS thing, I like to do that except in ClosureScript. The problem is that there's a lot of features in CSS that are only exposed via like class names and pseudo selectors, and like you have to be in a CSS file. So what I tend to do is I write, I think you can use something like Garden,
00:27:31
Speaker
to generate your CSS, but I think that's too far away. So what I like to do is just generate the CSS at runtime in my browser and then just link them together. Because turning a map into CSS is really easy. You just like put some colons in there, some semicolons and
00:27:47
Speaker
You just say, here browser, here's a new class name. And you can generate that class name and then put it on the actual DOM nodes, which I think is what something like styled does in JavaScript plan. So that's how I like to work on my projects, is just to put everything in ClosureScript. And then the other benefit to doing something like that is that you get free linting with something like CLT condo because it's Closure.
00:28:12
Speaker
And if you have programmability, you have if statements, you have when statements merge, all of your data manipulation is all checked by your static analyzer, like CLJ Condo, and your formatting, I don't need a new formatter. It's all just closure. I have a formatter for closure. I have a static analyzer. I have all these things for closure. I can move it to the JVM if I wanted to leverage it, because it's all just closure data. But isn't it going too far? I'm just playing.
00:28:40
Speaker
being an ass, but as usual. But isn't it like utilizing the same language for everything? Isn't it like
00:28:57
Speaker
I would agree if we were trying to use something like an HTML-ish hiccup language for CSS or the other way around. But I think if you can have a one-to-one correspondence between your data structures and your target domain, it's like, who cares?
00:29:13
Speaker
It's a direct mapping. The documentation is identical because it's like... And actually, I think that CSS maps better in ClosureScript than it does in JavaScript, right? Because in ClosureScript, we have like kebab case with the dashes, so I can copy code that's exactly CSS pasted, switch the colons, and I'm good to go. And then I think CSS is more or less just data anywhere, right? So it's just interpreted by the browser.
00:29:42
Speaker
Exactly, exactly. The impedance mismatch is less in that case anyway. I do think that CSS is still fundamentally hard no matter how you do it because it's a constraint language and you have to think in terms of constraints and layout. That's not a problem that goes away independently of the technology you use. You still have to know all the quirks, all of the CSSes.
00:30:06
Speaker
Do you, which one do you go with? Do you go with like flexbox or you go? Yeah, I'm a big fan of flexbox. I've been using grid sometimes. I like grid, like you can have gaps in your grid, which is kind of harder to do and like other things. So I'll use grid sometimes for that. But yeah, anything that's available in CSS that I can use to solve this problem I'll use. I used to use like the floats. I hate that. So flexbox is way better than floats.
00:30:31
Speaker
Yeah. But isn't the world moving towards, you know, everything is going to be Canvas these days? I read Google is trying to convert all the shit to Canvas now. The Google Docs, right? The Google Docs. Yeah. Yeah. Yeah. Yeah. I think they're solving a very niche problem though, right? They're like, they want a high performance text editor in the browser. It turns out the browser isn't a high performance text editor. So I think that's fine.
00:30:55
Speaker
But I don't think everyone's going to do that. I mean, not everyone has the same budget and capacity that Google does.
00:31:03
Speaker
But isn't it the case that, isn't it the case that eventually they're like, if you think about what they've done, I mean, I, I hope what they'll do is they'll, they'll release a whole bunch of open source stuff to make it easier to write canvas apps. And for me, that would be excellent because, you know, I think, uh, it's a underused resource because, because HTML and everything is not made. I mean, the whole dome is a piece of shit. Basically, if you could just replace, if you could just replace the dome and throw it all away and just use a canvas.
00:31:33
Speaker
To some extent, that would be a bit easier. Aren't you arguing for Java applets or something? A flash? Well, no. Well, kind of. I mean, Tonski has done this thing recently, hasn't he, with SVG. SVG is still, I think, in my opinion, is still kind of an open
00:31:55
Speaker
language sort of thing, right? It is still XML. So it is reasonable with SVG, but I'm wondering if we switch to Canvas, then it's basically becoming like another flash object that nobody knows what the fuck is happening. Yeah, you still need to solve all the same problems with layout and like people are like, we need responsive websites because we only want to write it once.
00:32:14
Speaker
So it doesn't matter how you get the pixels on the screen. What matters is how you deal with interaction and state. And all those problems, if you go to Canvas, you still need to solve them. Whereas right now in JavaScript with the DOM, it's kind of solved not super well, but it is solved. Yeah, but I think that's the question. That's me. I don't like the answer because I think that it's like all the complexity is brushed under the carpet.
00:32:37
Speaker
If you throw away the DOM, because what you're doing with HTML and all this stuff is you're abusing it to some extent. The whole idea of an application in the web is not what it's meant for. It's meant for documents. It's called a document object model. Everyone says that it's, oh yeah, but whatever. No, fuck off. It's not whatever. That's what it's meant for.
00:33:03
Speaker
All this other stuff, all the JavaScript things were meant for showing little enhancements, not for running first-class applications. Well, I mean, that's debatable, but still, it seems like the fact is, once it's out there, it can be made to work in a certain way. I think it's potentially the same thing for Canvas.
00:33:28
Speaker
I think the thing that I would want changed about the web and like HTML and CSS is just less, can we have less things? Because I feel like right now, because of the need to keep accurate compatibility, you run across articles on how to do the thing and then, oh, how to do the thing and this new thing and how to do, and it's like, what's the right way to do it? And you don't know. So my argument or what I would like is just less options because then it's like, it's easier to choose what to do. And I love that about closure is that you don't have a lot of options. It's like you have data and you have functions.
00:33:58
Speaker
You don't like the idea of a fast array of tick boxes at the bottom of every single page about which version of the browser and which browser. It's like this big block of stuff at the bottom of every page of MDM. Every time I want to use a feature, I'm like, can I use this? Is this still a relevant feature? Is there a new way to do this?
00:34:25
Speaker
I mean, there is an easy way out, right? I mean, like in the 90s, you can just put a nice GIF at the bottom that says, this website is optimized for Internet Explorer for 1080 by 960 or 720. That's it. Fuck off. You know, if you don't have the Internet Explorer 4.5 running at 480 by 320, whatever, then you can't use my app. So it's fine.
00:34:45
Speaker
It's like this thing that we're running now is Zancaster. It's optimized for Chrome, and it tells you to fuck off if you're not using Chrome. Oh, really? OK. Yeah. I mean, you can use Firefox as well. No, I tried for Firefox, and you can't use it. It doesn't work? No. Oh, OK. It's weird. It's all Chrome stuff. They didn't use it for Firefox. It's all Brave or I use Chromium, but you know. But these days, I think everything is kind of all roads are leading to Chrome anyway. Wow. No. All roads leading to Chrome? Leading to Chrome? OK. No, I hope not. I hope not. That would be horrible.
00:35:16
Speaker
Well, IE has a Chrome engine now, I think, or WebKit, whatever, not WebKit. The Chrome ship now, IE, the Edge, whatever. Yep, Edge is Chromium based, yeah. Yeah, Edge is Chromium brave. Yeah, all the shit is now.
00:35:29
Speaker
We're going into the monoculture, but I think the openness of the web is what created this ecosystem of weird shit. That's nice. If we say there is only one way to do shit, and if we go back to saying, hey, document object model is only for documents,
00:35:47
Speaker
No, no, what I meant to some extent is that I would argue that Canvas is a bit like WebSockets versus HTTP in the sense that it's a kind of more open protocol. So you can have more creativity around that in some ways. But of course, you've got this problem of standardization, but you have a problem with standardization on the web anyway, see above.
00:36:16
Speaker
Anyway, so yeah, I think we'll all move to Canvas then. Bring back Flash. I would not like to implement the apps that I've implemented in Canvas because without like a lot of substantial infrastructure, like layout events.
00:36:33
Speaker
events. That's what I mean. I'm guessing that Google, with all of their stuff, with all their budget and all that kind of stuff, because if you can think about reactors, why do all these big companies open source shit? It's because they want programmers from the outside world to be able to come to them, and they want to be able to maintain it and all this kind of stuff. There's some beneficence as well, but there's a large degree of enlightened self-interest.
00:37:00
Speaker
So my guess is if they did make a thing with Google Docs, they will use it on other Google pieces of the Google estate, as they say. They'll want to use that technology elsewhere in Google. And then in a year after that, once it's all settled down and they've got a competitive advantage, they'll think, okay, well, let's open source it. And they'll have all this infrastructure for events and for this kind of that and the other.
00:37:23
Speaker
Yeah, I think that that's something that they kind of kick-started, right? The first Gmail version was mind-blowing to see this in the browser. And Google Maps. Yeah, exactly. Google Maps, and they're pushing the envelope on them that is triggering this whole cartridge industry. You know, it's like a huge industry of sparse, you know, the single page application. So maybe they'll do that. So that would be nice, though.
00:37:47
Speaker
Yeah, and if it had an API like React, I probably would just be like, OK, if the pros outweigh the cons, like it's faster or there's less quirks. As long as I get my reactive API, and that's the nice thing about something like React is it kind of abstracts a lot of the issues with the browser. I don't have to worry about setting up handlers and then unsetting them up and worrying about memory leaks and all that stuff. I can just, hey, make this the page. OK, cool. I'll be back later.
00:38:15
Speaker
Yeah, my guess is that would be even easier with Canvas though. But yeah, yeah, I mean, yeah, we'll see. I'm pretty sure Google is going to release AWT for Canvas, you know, like, yes, yes. That's what we need. CwT. Point one. Yeah, the Canvas Web Toolkit. Yeah, like I said, a GWT, didn't I? Yeah, yeah, exactly. Something like that. Oh, my God.
00:38:38
Speaker
Anyway, OK, so let's get back to Closure World, you know, in the cozy Closure World.
Exploring Data with Portal
00:38:44
Speaker
So the data exploration part. So you're talking about, you know, you explore the data, you check what is in there. So you're saying something about Portal. So let's get into it. What is it? What is it about? So Portal is an open source project I work on for, like, exploring data. Not big data, not small data. Kind of like me. There's a lot of medium sized data that we have to deal with. It's like the Goldilocks data.
00:39:07
Speaker
Yeah. Well, it's like a map with more than like 20 keys. You print that out and it might look weird and you're trying to, you pretty print it and you're trying to figure out. And it's just kind of sometimes hard to work with. So, and like pretty print only goes so far, I think. So, I think the next evolution, there's something like Rebel, right? That's the first thing that came out and data find nav where you take objects that aren't data and you turn them into data and then you can
00:39:32
Speaker
navigate them and that was like in the closure ecosystem I think when a lot of this but before that there was an inspector and there still is an inspector enclosure. I never saw it used a lot though.
00:39:43
Speaker
But yeah, Rebel kind of took off, and then Shadow has a prod of an internal inspector. Reveal has a thing, and I'm like, okay, well, I want to make one that works on all the platforms. So I think the strength of Portal is that it works in the web. On the web, it works in Node, it works in Babashka, it works in the JVM. And I'm working on a one for Erlang right now, because Closure was pretty cool, actually.
00:40:11
Speaker
So it's like, hey, you implement a little bit of code for your runtime, which expose. And I think I talked to this a little bit on app pose. You have this API that your host process implements, and then you can just shovel data back and forth. And then you should be able to re-leverage all the UI that you have.
00:40:30
Speaker
That's where I've been experimenting with different ways to visualize information. The normal thing is to put things in tables, but there's a lot of other ways you can visualize information. One thing this last week, I was working with my coworker and we had dates, and we kept trying to figure out, okay, but how long ago was this? Okay, let's have a viewer that tells us how long ago. Do you know the thing that Moment JS has, which is like 10 minutes ago? 10 minutes ago. Turn that into a viewer.
00:40:59
Speaker
And now anytime I have an instant, I can just say, oh, how long ago was that 10 minutes ago? Oh, and then I want to look at it as it formatted like as a normal date or something. And then maybe I don't know what format this is in, because maybe I live in a different place in the world and I can hover over and it can say, oh, this is the month. This is the day or the date because that's it's flipped in different places. Right. So it's like all these little things that just would make life easier. That's only a US problem. Yeah. No, I know. I was like.
00:41:27
Speaker
The US is like needlessly different sometimes, like why aren't we metric? Why are we still doing miles?
00:41:36
Speaker
Oh, God. It's a huge amount of demographic that you want to serve with Portal anyway, so it makes sense. You want to be inclusive of any kind of day format. Yeah. As long as you tell people what it means, then I think people are open to it. People are very good at picking up on. It should also lead to something like my mother saying, back in my day, what does that mean? There is a translator for back in my day from your mother.
00:42:06
Speaker
from your grandfather. That'll be a nice format. Anyway, so is this a... So what is this built with on by... Is it a web publication? Is it something that runs on Emacs? No, it doesn't run on Emacs. Although... Thanks a lot, man. It was nice talking to you.
00:42:33
Speaker
No, no, but one of the cool things I like about Emacs is I have a bunch of shortcuts set up that call portal API functions. In my editor, I can do Control-L and it'll clear my portal session, or I can open it up. I have Command-Option or Command-Shift-O will open up a portal session. I can still leverage shortcuts in my runtime from my Emacs.
00:42:59
Speaker
So what is the architecture like? So how does it communicate with your process and what is it built on? So yeah, it's doing HTTP. It's doing WebSockets. And it used to speak transit. I moved away from transit a little bit because I wanted more flexibility with how I serialized information for the UI. So I have a protocol-based
00:43:22
Speaker
I did the same thing transit did. I don't do anything novel. I did what transit did and I have this concept of take the thing, turn it into JSON, then use a JSON serializer to turn it into a string JSON, ship it over JSON.parse, and then rerun the code in the inverse to get the data structures back.
00:43:41
Speaker
That's like the data exchange and then, yeah, it's just using on the client reagent mostly. Just a lot of reagent components. So it's like a web app that runs in your browser that connects to your current project where you can send the data to in this state.
00:43:59
Speaker
Exactly, exactly. And there's a bunch of different components that you can use. There's like a table viewer. I don't know if I can share my screen or not. On the podcast, yeah. But to you guys, because you guys could be like, oh. But yeah, there's like a table viewer. We can do like a running commentary on what is happening in there. Oh, it looks really good, guys. Yes.
00:44:29
Speaker
It does. It has themes. There aren't that many themes, but there's a few themes. There's a blue theme, isn't there? Oh, yeah. Of course. That's the default. What are you talking about? There's like a Solarize theme, which by the way, the funny thing about the Solarize theme is I think in Apropos, I was trying to show Eric the dark Solarize theme because I knew he used it. And when I said that, he wasn't there. He was gone.
00:44:58
Speaker
What's going on? Just maybe we should clear up that this Aproport thing is a YouTube channel I do as well with some other people. So if anyone hasn't heard of it, you can look up Aproport on YouTube. And we've got an episode with Chris doing the kind of more visual demonstration of this stuff. So if you want to get a more visual feel for this discussion, then go over there. And it's really good. It was a really good session with Chris here.
00:45:28
Speaker
Thank you. Nice. Yeah, I have made a bunch of improvements since then, though, so it should be even nicer now. It's outdated, do you mean? Yeah. That's the problem with documentation, honestly, though, is that it's so, which is, I feel like for me, the
00:45:47
Speaker
the ideal way to do documentation is that you have data structures which you use to drive your system and to drive your documentation because then that way the system is the documentation and the documentation is the system. I don't know. It's kind of similar to the literate programming stuff, right? If you write the whole
00:46:08
Speaker
program as a novel with literate stuff with argbabel and you know like sprinkle code in between i would say it's it's similar but the the the problem with that is that you're still like writing here's what i mean to say and then here's me saying it well what i think the the slight difference here is that the actual code is driven like it's driven by the data so it work uh we have like this flow-based system and so we have a bunch of data structures that represent like a flow graph
00:46:38
Speaker
And those data structures actually are leveraged in the code, but they're data, so we can render them as flow graphs. So we have this symmetry where there's canonical data, and it's leveraged in two ways as a way to visualize it. And that's our documentation, right? People can look at the flow graphs, and they can be like, oh, OK, we go here. We do this. We go here. We do this. Without even running the application, they can run it in their mind. And I don't know how we make that easier for people to kind of,
00:47:07
Speaker
like understand the system at a high level. But the problem, right, with traditional documentation is you write it and then it gets stale and no one maintains it sometimes. Yeah, I think that's why we just don't write documentation because, you know, it's unfortunate because it's better.
Documentation Challenges
00:47:23
Speaker
It's better not to give you wrong ideas than giving you wrong ideas. Yeah, because honestly, running the code is so much, especially in something like Closure. I tend not to read a bunch of documentation. I just run a code sample. And I'll read it to get an initial feel for how a library works or for some high-level context. But then there's a lot of experimentation, I think, in Closure, which is what I like about it, actually, is because the code can't lie to me when I run it.
00:47:50
Speaker
Yeah, that's a fair point. But this is a big, big issue in every ecosystem, right? I mean, the documentation and then how to communicate. Because I think the difficulty there is that with code, you have only one audience or one goal to explain. But with documentation, you're casting a really wide net. So there are beginners, there are advanced people. So it's extremely difficult to create something that is going to cater to everybody.
00:48:18
Speaker
Yeah, so I think that is the biggest challenge in my opinion. Yeah, which is I think then which this again isn't I think like still something I'm like struggling with working on is like, I think the more you can model your domain as data,
00:48:33
Speaker
that normal people would understand, the easier it is for you to take that information and just generate tables, generate diagrams, generate whatever, and then literally hand an analyst a table. Here's the columns with all the names, the words we use. Here's a description. Here's all the things that you would care about. It'd be great if the UI was Excel. Honestly, everybody wants Excel.
00:49:00
Speaker
Every company I think I worked on, or maybe not the last one, but every company is just like, hey, can we have this as Excel though? Oh, okay. For sure. We'll just rebuild Excel real quick.
00:49:12
Speaker
Yeah, yeah. Aren't the things like spec and Mali and things like this, they're a schematic scheme, etc. They're kind of designed to give you that documentation as well, to sort of provide you with the information about stuff. So that's good. That's definitely a sort of mechanical way to integrate it.
00:49:34
Speaker
But I often feel that one of the problems is that it misses what you were talking about, Chris, which is the overall intent of the system. Because yeah, you can say this particular data structure is made up of these things, but why? What does it mean?
00:49:49
Speaker
Yeah, yeah, I do think that actually those systems are like like Molly and like spec are really interesting because it lets you start to write down some of these things that are important to you. But I think the the hard part about that is the accessibility. Like one of the things we do is we have like a spec for our flows, but then you run the spec and we do like explain data and it's like this big
00:50:09
Speaker
Medium, it's not this big. It's medium-sized data, which is kind of hard to deal with. And so it would be great if there was a spec viewer that kind of let you drill into and kind of explain, because the structure of the explained data is well known, right? It's really easy to build a UI for the output of specs. And that makes it more accessible.
00:50:28
Speaker
And then also leverageable, like it'd be really cool if a user who doesn't do closure at all can look at like a spec error. Cause at the end of the day, it's going to be like, Hey, this is not that, or I expected this year. It's not that. There are tools for that, aren't there? Like Marley has this human readable stuff and there are these expound and things like that, you know?
00:50:46
Speaker
No, no, no. I think those are great. The thing that I kind of like, they're all, and I could be wrong, because I haven't leveraged them, is that they all spit out strings at the end of the day. I want to spit out a UI, right? I want to be like, hey, here's a UI. Because when you take your information and you put it in a UI, you let the user drive. Whereas if you take your data and you spit it out as a string, the user just gets to navigate that manually.
00:51:13
Speaker
Um, so I think that's probably where I'm the saddest about the state of like programming right now. It's just like, we don't really have enough interfaces for ourselves and for explaining to other people, our systems there's Excel. Like that's, that's everyone puts like,
00:51:30
Speaker
If something gets sufficiently complicated in terms of modeling and traffic to other people, they just put it in a table and say, okay, we're going to share this spreadsheet. I think at my last job, there was a project where I was getting chaotic and we were like, okay, let's put everything in Excel here. We didn't even use Jira. Jira was too much of an impediment. We put these tickets of work that we need to do in Excel and it works.
00:51:49
Speaker
That's the thing, because it's so powerful, I think that's the gold standard for everyone in terms of the flexibility you want to offer users in your UI as Excel.
Portal vs Other Data Tools
00:51:58
Speaker
I think it has yet to be dethroned.
00:52:01
Speaker
Yeah, I don't think it will ever be, but in back in, I don't know, 99 or something, I used to work at a company where our, our project management software or the shared Excel sheet, you know, like somebody just having an Excel sheet with a list of stuff. And then somebody will fucking, you know, lock it. And then we are fucked. Nobody can edit it.
00:52:20
Speaker
Yeah, it's fun fun. But yeah, I think that is the thing. Excel is so malleable, flexible plastic, you know, that you cannot dethrone it because to dethrone it, you have to build every possible tool that can be done with Excel separately and excel at it. That is the shit, you know, it's impossible.
00:52:43
Speaker
I think my biggest gripe with Excel is just that the data structure is bad. There's only one and it's a grid. I like closure data structures, I like maps, I like sets, I like vectors. I want Excel but with better data structures.
00:53:02
Speaker
Right? Like proper data structures. Maybe even a database stored up there. You can potentially do that, but that's going to make it extremely difficult to maintain. You can have variable names and shit and whatnot, and it's mental. I think it's a really hard, especially because
00:53:22
Speaker
I think, and I don't know, I feel like the data structure literacy is like something that you spend forever trying to get comfortable with and understanding and learning how to use. It's not something you get for free. Whereas like a grid is kind of familiar for people because in school there's like, you know, grids everywhere. Yeah. But I think maybe coming back to, I think we should roll back to the portal. So what can portal do that Excel can't do?
00:53:47
Speaker
Oh, it can do things with proper data. If you give it a list of maps, it'll render it as a table. It has tables. It doesn't have edit because I think that's a hard problem because the secession of state over time and what it means and where to put it is still like, it's hard to guess.
00:54:12
Speaker
So I haven't tried to solve that problem yet. But in terms of rendering read-only data, that's okay. You gave me a map, render it as a table. You give me a map of maps. I render it like something else. I don't know.
00:54:25
Speaker
I think that should be, that's my ideal, is you spend a lot of time modeling your domain as data, and for that, you get a bunch of UIs that you can leverage. And I think, of course, you can do that currently, but the investment is high. You have to learn React or some UI framework. You have to learn ClosureScript. You have to learn all the web quirks. You have to learn HTTP to shovel the data. You have to pick a serialization. So the barrier to entry is kind of high, so people don't do it.
00:54:54
Speaker
They're just like, this is too much work. And I agree, it's too much work. So solve the problem once, hopefully. It's all about for enough platforms. Because that's the thing is every project I've worked on, there's always been a back end and a front end. So if the tool only works on the back end or only works on the front end, it's kind of incomplete in my mind.
00:55:10
Speaker
Yeah. So did you take any, because as you know, we spoke to Vlad and a few other folks working on similar kind of things. So how do you compare with them? Obviously, working on both ends is obviously the biggest challenge, I think. But did you get any inspiration from them or how do you contrast experience with those tools versus Portal? Yeah, I've used them. I think Portal is
00:55:39
Speaker
I don't have either. The biggest difference between portal and reveal is reveal is the JVM only. There is a version of it that lets you run PRAPL, I think, where you can pipe data to it, which works, but it doesn't feel like an integrated experience with that runtime. That's one of the differences.
00:56:00
Speaker
In the Shadow Inspector, it's pretty much the same except for I think there's not, like in terms of runtime support, like the JVM and the JavaScript runtimes are equally supported for the Shadow Inspector, but I think there's not a bunch of different viewers, right? There's like two viewers, like inspect and inspect latest, and then it's all datafied now, and you just keep digging through your data. Whereas like Portal is trying to like
00:56:26
Speaker
take your data and let you see it in different ways. Does that make sense? It's trying to be trying to give you a variety of different cross-sections that you can loop your data through. And it's doing that by guessing, oh, you're a list of numbers. Maybe this is a plot or something. There's predicates. One of the predicates I have is, this is an exception datification. Oh, OK. Well, let me render it as an exception.
00:56:56
Speaker
Okay. So you're inspecting the data for semantics and then picking the right resolution or something. Yeah. Yeah. And I give you multiple options. Like, oh, you can view it this way or that way or that way or that way or whatever way, whatever way makes sense. Okay. So what changed between your demo on Apropo and now and what is in the future for Portal?
00:57:19
Speaker
Oh, so one of the nice little changes is you can click and select things. So you can hold this sub piece of data in your hand and choose a viewer for that, as opposed to saying, this entire piece of data from the root means this. Now you can be like, this sub piece of the data I want to look at as a table. This sub piece of the data I want to look at as a tree. So you can actually click it without nabbing into it and kind of play with it. You can copy it by itself. You can choose a different viewer. You can run a function on just that.
00:57:49
Speaker
So there's like little things like that. In the future, I don't know. I think one of the things I really want is extensibility because I don't want to solve everyone's problems. I want to give people tools to solve their problems. I think that's a hard problem with multiple runtimes, right? Because it's like now, if you write an extension, what are the semantics? Does it run in your runtime? Does it run in the portal web runtime?
00:58:12
Speaker
What language is it in? Do I have to compile it? It's just like, I have avoided that problem. What about this kind of stuff like with, um, with closure LSP, um, stuff like that. Doesn't that, could not potentially help you in terms of runtime? Um, I think that that's more on the side of like helping you navigate your code. Right. Sure. I want to, I want to help you navigate your data. Yeah. Okay.
00:58:40
Speaker
I think that, yeah, I think that's, uh, unless you want to show your entire code as data into portal. Yeah. So I'm not, I'm not trying to solve that problem because I think there's, uh, there's, there's a bunch of really good editors out there. There's a bunch of really good tooling around editing code, like static analysis, all that stuff. I'm just going to stay focused on data. I'm going to stay in that lane. I'm not competing against editors. Yeah. Do you, do you integrate with tap?
00:59:08
Speaker
Yeah, yeah, yeah. That is one of the nice things that Closure added recently in 110, I think, is that now you can, instead of print, you can do tap, and that'll send that object somewhere else. I put up my hand and I intercept, and I'm like, cool, thanks for passing me that. And then I do a bunch of stuff with it. I store it off in a list in an atom, and then I can send it to the UI and serialize it. I can do a bunch of fun stuff with it directly.
00:59:34
Speaker
So how else do you get the data other than tap? How else do you, you, you kind of like inspect these things? Um, if you wanted, if you, if you didn't have tap, you could call the API function directly. There's like a, in my portal API namespace, there's like a submit function, which will submit a value to a portal, or you could have like a bunch of, there's a bunch of ways to push data around. So it's just the, the, yeah. I was just going to say, so with the REPL, you, you, you integrate like the results.
01:00:06
Speaker
Um, no, no, you have to, right now you have to explicitly send, I think there's an N REPL middle world that I have, but I never use, so I don't know if it works still. So don't worry about it. But yeah, for the most part, I'm expecting people to use it like console log, right? They have tap. Right. Right. Right. Okay. Yeah. Yeah. And I'm just saying, because something like the preple summit, the P REPL gives you back data. See? Yeah. That's a nice thing.
01:00:34
Speaker
Yeah, I was kind of, when P REPL first came out, I was excited about that, maybe taking over N REPL, but N REPL has so much momentum that I think it'd be really hard. Plus, it's solving a
01:00:47
Speaker
a harder problem, I think, of, like, a programmatic API into a closure REPL that's, like, there's a bunch of things you can do with, like, end REPL, like, killing execution, right? Whereas the P REPL API is, like, synchronous. You send me a thing, I give you a return. I mean, I think you can do a bunch of standard outs and then a final return.
01:01:08
Speaker
I don't know if you can kill something with a P REPL API directly. Does that make sense? If I have a thing that's taken too long, I might want to kill it. With the API directly not, but you can do it out of band because it's just a thread running on the back end. Yeah, so you would still need to implement that as a side channel. But I do like how simple something like P REPL is, where it's just like you give me the code and I'll give you a bunch of result data format, so I think it's simpler that way.
01:01:37
Speaker
I mean, it's more tool friendly. That's the point, isn't it? Yeah. Cause I think like, and rep was really cool, but like, there's one of the projects I worked on that I was trying to get working. And this is when I was again, I didn't want to take on the JVM. I was like, I want N REPL, but in node. And I was like, Oh, this is actually a bit harder than I thought to implement. So like the encoding is this thing called Ben code, which I had to learn and like do. And then, Oh, these are the different data formats and the semantics. And it wasn't, uh, and like N REPL is cool. I'm not being disparaging.
01:02:07
Speaker
But I think they're changing. I think they're giving an Eden, there is an Eden format either coming or it's out there recently. Yeah, I think it was zero seven, they introduced Eden or transit or a bunch of them. Yeah. So there's other ways to do it. You're right.
01:02:25
Speaker
Nice. So how do I use Portal? I was just browsing through the thing, and I see that there is a section called Emacs, so I'm sold.
Trying Portal and Closing Remarks
01:02:35
Speaker
Yeah.
01:02:38
Speaker
So all I need to do is just portal.el and then I'm done. If you just want to try it in the browser, there's a link at the top that you can click on. So that link takes you to a website that's like a progressive web app. So you can use it, you can install it locally. So you have a nice little icon in your dock or whatever OS equivalent.
01:02:57
Speaker
And you can use it to, it used to just be for a demo, but I was like, nah, you can just put a file in it and it'll try to parse like a markdown file or a JSON file, it'll parse it. Or you can load the demo data. I don't know if you did that. You can see all the example data I have. Yeah, yeah, yeah, I can see that. I think it's super cool, actually. I think that this is the kind of seamless experience we want to have with them, especially when you're dealing with the developer tools.
01:03:23
Speaker
I don't want to install some shit and then it requires like 200 dependencies. I don't have time for typing all these commands. If it doesn't have all text portal, I'm done. No, I think in the last Defend podcast, Daniel was talking about easy versus simple. I do think that simple is essential, but I think easy is essential for more adoption because people tend to give up if something is too hard.
01:03:51
Speaker
So at the top of the read me, you'll see like four examples for all the different runtimes. Here's like a minimal paces in your terminal and you have a portal running, you can start tapping stuff to it and just trying things out. And I think that's the thing I really appreciate about Closure is that it's really easy to just try things out, to make mistakes and to learn. And that's what I want out of my tools. Let me make mistakes.
01:04:14
Speaker
Yeah, yeah. Because that's just a human thing. That's how I've learned a lot of things is by trying, trying, trying. Yeah, yeah. I don't think Portal is a mistake though, so I think it's amazing. It looks pretty amazing. Oh, you should try the different teams.
01:04:32
Speaker
Yes, that is that is the that is the fucking act shaving that I do constantly I have like teams on a max and I keep calm like every every two seconds But like it's funny though because it's not just a developer thing like every project I've worked on The inevitably they want theming and branding it's and it's like the thing that you have to do later after you wrote all your CSS
01:05:02
Speaker
Yeah, where is the dark mode, you know, there is a first step. Oh, yeah, exactly. But I recently read some, there was some proper research done for the dark mode. I think they said that it doesn't increase any of the, you know, people using night mode, not dark mode on your phones. You know, it doesn't actually help you to sleep.
01:05:23
Speaker
So apparently there is some research now that says, no, that's not true. I just do it because I like it. Yeah, that's a perfectly valid reason. But people telling you that if you use night mode, then you can sleep better. That's apparently now researched. And at least there is one research that says that's bullshit. Anyway.
01:05:46
Speaker
But yeah, themes. Yeah, yeah, themes, always. Ooh, and then there's like a color. If you go to the very bottom, you can see all of them and you can put it in a table and view all the colors side by side. That's like, I don't know. I like to like demo data because you can kind of play with things, but yeah. Do you have rainbow operands? That's the biggest question.
01:06:02
Speaker
Yes, only for the tree viewer though, because that's where it made the most sense. If you switch to the tree viewer, you can see like the rainbow parens. It's pretty fancy. All right. Cool. Yeah. It's super cool. Yeah. I think, well, I mean, as we said, this is a podcast, so you can't see anything, but trust us.
01:06:23
Speaker
You can't prove otherwise right now. Exactly. Guys, you have people who are listening to this stuff, guys and girls, you're missing out on me clicking shit around and then admiring all the CSS shown in different colors now. It's crazy. On that bombshell. Yes.
01:06:45
Speaker
So yeah, I think this is a super cool tool. I think I would definitely encourage people to give that a try. And as I said, the demo is just click away. So you can just click on the icon and then another icon for the screenshot and see the demo. So yeah, thanks a lot for sharing this, Chris. Lovely. I think we need more of these kind of things that are much more integrated into
01:07:12
Speaker
developer ecosystem. Hopefully, you're going to dethrone at least some use cases of Excel with this. At least for the view side for now. Yeah, fair enough. I think integrating Excel into the REPL is still a little way off.
01:07:33
Speaker
Yeah. No, it needs to be better than Excel, right? That's like the thing that if you want to bring users over, it has to be like 10 times better, right? Yeah. So it has to be 10 times better. Yeah. I think, you know, I kind of gave up fighting Excel. I don't even complain about it anymore. I just don't even talk about Excel. Then it goes away.
01:07:58
Speaker
Yeah, I think the thing is the programmability is what I think is the thing that's appealing to me about Excel is like without having to write a bunch of code. Yeah, I mean, it's it's crazy what what you can do. I mean, especially because are we leaving Excel?
01:08:15
Speaker
Because I know it's got an E in an L in it. So, you know, we're excited about it. It starts with an E in an L. Well, in E-Max, you have actually spreadsheet mode, so you don't need to use Excel. I still haven't gotten too familiar with org mode. I know it can do all these things, but I haven't gone down that rabbit hole yet. We're back in the fucking E-Max.
01:08:40
Speaker
You gotta use Org Mode, man. I mean, the people who don't even use Emacs, they use Org Mode for Emacs, so that says something about it, which is super cool. Anyway, so awesome. But one thing, though, actually, tomorrow, we are celebrating five years of DeafN. Ooh, five years. Yeah, yeah.
01:09:09
Speaker
feels like we've been doing this forever. But yeah, I think May 17th or five years ago, we released our stupid show, or at least the stupid episode, the first one. And we've been, you know, going
01:09:25
Speaker
on and off with some random frequency, you know, making noises and then pushing them into the world. So yeah, so happy anniversary to Defend and to all the people who've been listening for over five years for our constant chatter.
01:09:42
Speaker
So so this is a momentous occasion Chris, so you know I'm sure you're you're privileged to be part of this amazing episode Although I think episode 69 was probably
01:09:58
Speaker
I was just saying. Well, we were thinking of just sticking to 69. Just keep saying every episode is 69. 69.1. Yeah, exactly. 69.96. On a repeat.
01:10:16
Speaker
Yeah, so we've been doing this for five years, which is awesome. And especially to all our guests, of course, like you, coming here and then sharing awesome stuff that you guys are working on. I don't think we'd have got five years if it was just you and me talking. Thank God we gave up on that pretty quickly. Exactly. We ran out of the shit in one episode, so that's a good thing. And already on the second one, we were like, hmm, what should we talk about? We have no clue.
01:10:45
Speaker
But yeah, here is to another another five years, I guess of different. So a big, big thank you to all our Patreon people who are supporting us to cover the costs and all the guests that appeared and then we're going to continue doing the good job or whatever the job that we're doing, you know, not necessarily good. I think it's a good job. I enjoy the podcast. Thanks. Yeah. Thank you. Thank you. Yeah.
01:11:10
Speaker
Well, this has been a pretty good episode in my opinion. One of the good ones.
01:11:17
Speaker
Sometimes the nice thing about it is that it's always a problem when you've got a very visual tool. So it's nice to have a bit of a rapport about the other bits and pieces that are making you excited as the author and what's driving you. And I think that's one of the values of the shows as well, is to find out a bit about the people and what motivates them and what's brought them here and what's keeping them here. And that's really good. Thanks very much, Chris.
01:11:44
Speaker
Yeah, thanks a lot. Thanks a lot. And yeah, keep using Emacs. So maybe there is a chance we'll invite you again if it's still using Emacs. I mean, it's really nice how you can integrate like little functions that call into the Java, to the JVM. We're back into it again. And now to the Emacs podcast. I can't take my five fucking years of this, that's for sure. cursive is cool too. Okay, right? cursive is cool. I like cursive. They have cool colors.
01:12:15
Speaker
I'll try to get back on in the future. Anyway, that's, um, I think that's, that's a wrap, I guess. So, uh, yeah, thanks again. Thanks again, Chris, for joining and, um, you know, thanks a lot to all our, um, Patreons. And we are thinking of doing something with, uh, with people who are on Patreon soon because they did this Twitter spaces now. So we're thinking maybe we'll, we'll arrange something on, on Twitter spaces so we can all get all of you at least 10 people talking together. That's going to be fun.
01:12:45
Speaker
As you know, everybody, everybody talking at the same time on Twitter, but we'll, we'll announce something soon on, on, on Defen, uh, on, on the usual channels. So that's it from us. This is episode number 72, five years of Defen and Chris, you know, taking us into portal.
01:13:07
Speaker
Thank you for listening to this episode of DeafN and the awesome vegetarian music on the track is Melon Hamburger by Pizzeri and the show's audio is mixed by Wouter Dullert. I'm pretty sure I butchered his name. Maybe you should insert your own name here, Dullert.
01:13:24
Speaker
If you'd like to support us, please do check out our Patreon page and you can show your appreciation to all the hard work or the lack of hard work that we're doing. And you can also catch up with either Ray with me for some unexplainable reason you want to interact with us, then do check us out on Slack, Closureion Slack or Closureverse or on Zulep or just at us at Deafened Podcast on Twitter.
01:13:53
Speaker
Enjoy your day and see you in the next episode.
01:14:30
Speaker
Anyway, so let's do the intro then. Blah, blah, blah. What is this? Okay. Yeah, definitely.