Ben von Polheim is a Freelance Front-end Developer. He also built two Elixir libraries: live_motion and ex_cva. He joins Allen and Sascha to talk about his article, "Remote Development in Elixir with Gitpod". He explains how he came up with the idea for the project and the process of setting it up. 

Hey everybody and welcome to another episode of Elixir Mix. This week on the panel we have Alan Weimar.

 

Hello.

 

And me, Sasha Wolff. And as usual, we have a special guest. And this week it's Ben Pohlheim. And I'm at a home field advantage because I know exactly how to pronounce that name because it's German, yes. So,

 

Hahaha, great.

 

Ben, why don't you tell the listeners why you're here and what we're going to talk about today?

 

Hi, so first thanks for having me on the show today. Yes, as you already said, my name is Ben. It's actually von Pohlheim. Well, it's

 

Damn it!

 

like the

 

I

 

von,

 

fucked up.

 

but that's something I'm used to, so that's fine. So Pohlheim is also fine. I think it's quite unique already. So yeah, what about me? I'm based in Wuppertal, which is in Germany, which is on the western part of Germany. As a normally I'm based right now, I'm currently traveling through Europe together with my wife and my little two year old son. Um, and right now recording this from, um, Florence in Italy. Um,

 

Nice.

 

yeah. So, so I haven't, hasn't, I haven't had the time yet to, uh, to actually visit the city, but this is something for the next day. So, um, yeah, I'm professionally, I'm a front end developer. I'm working as a freelancer since six years now, but I am into software development. Like, well, like I can think of like, like when I finished school, which is now almost, I think 15 years ago or something. So pretty long time already. I'm professional working. So doing my freelancing work, using React and TypeScript, which is a little off topic. If you consider that this is

 

That's

 

an Elixir

 

fine.

 

podcast, but. Yeah, I came across Elixir, I think, around 2017. I saw it in a forum post where a lot of Rubyists were hanging out. And I always used Ruby for my side projects when I did something. And I saw the syntax, looked a little weird to me, and looked into that, and found it interesting somehow doing the real-time things and stuff like that. And yeah, I just started to learn it at the time. And... Well, basically, I did all my side projects, which what I did and then starting afterwards. Yeah, I have a little blog, but like it's a two blog post, a thing where I occasionally write something right now. I'm more into like, I wrote like two different kind of libraries for Elixir, which is the LiveMotion library and Elixir, the CBA library, and built like a few side projects, as I already mentioned in Elixir itself. Yeah, that's it for me so far.

 

Yes, we kind of invited you for one of our blog posts, but I mean, you also did a few other things in Elixir. So let's just see where the conversation brings us, right? And what we call this episode afterwards.

 

Let's see.

 

Yeah. But I actually, I would like to start one step back because you've basically said you're more of a front-end developer,

 

Yeah.

 

but you also work with Elixir. So Is this just like a side, was this just a side project thing or was this also for like your freelance work where you started to then look also into Elixir? Like what is the story here? I'm curious actually.

 

So I never had the opportunity yet to do any professional work in Elixir, which is

 

Mm-hmm.

 

too bad. I really prefer to do it at some point. But well, I'm fully booked doing like freelancing stuff and wrecking types because I always somehow was always on the front end side and this became popular. And so I did stick with it until now because just my projects are also going on and on. Anyway, yeah, I did. mainly all the things just for fun, like part-time outside of it, just because I really, really was interested in it and it seemed really interesting to me. I like the architecture behind it and the ideas behind it. So yeah, that's it why I got into that.

 

Cool. I mean, it's also the libraries you've written, they kind of show your front end background. But. Yeah.

 

Yeah, exactly. That's very true. I mainly try to move the knowledge which I have from the front end world and just to apply it so that you can combine it because I think there's a lot of potential in combining stuff like on the live view side and combining stuff from the front end.

 

Yeah, yeah. I think we can, we can get to that back later. Maybe for everyone who wants to already Google while we're, while we're talking, it's the libraries are called XC underscore CVA and life underscore motion. And they're both both related to components and live view in front of work. So yeah, somebody wants to already Google, I think we're going to revisit that back later. But yeah, something why, it kind of what prompted all of us, you we invite we inviting you. was a blog post you wrote on, like one of the two blog posts, I guess, on your website about

 

Yeah,

 

remote development with Elixir.

 

exactly.

 

And maybe you can give just our listeners a super short definition of what that actually means.

 

Yeah, of course. So I mean the basic idea of remote development or cloud development environments or whatever, how you want to call it exactly. But it is like that you take your source code, which lives in your repository, and that you basically remove, basically move this into the cloud. So put this on a different machine inside of the cloud, run it inside the cloud on a different machine, and connect to this code via your own IDE. So this, for example, the main supported one is always Visual Studio Code, which you can either run in the browser so that you can directly run Visual Code in the browser or run it locally and connect to your code, which is executed on a different machine. So I think the main thing to say what cloud development is actually not is that it's not like something Like you could imagine like a remote desktop or Citrix style environment. So this is not what the cloud development is about. So you do not get like a full remote desktop where you have your mouse and every keystroke basically mirrored onto a different machine. You would just connect via SSH, via your local code editor, via SSH to a remote machine, meaning that you can run your code. wherever you want actually, and on whatever device you want, even if it's like a low power device or something.

 

And so to summarize, you could probably say it's kind of like a Docker container. You connect to do development work. Would that be like

 

It is

 

a,

 

exactly

 

yeah.

 

like the popular providers work. It's always a Docker container you connect to.

 

I think it also makes a lot of sense to be honest. We already have this tool for having reproducible environments, so why not use it for this particular use case?

 

Exactly. So it's basically using the CI part and bringing it to the development side of it, and not only to the building side.

 

Mm-hmm.

 

So that's it.

 

Yeah, I've, like my only experience in that particular font has been like dev containers for like Visual Studio Code, which never quite worked for me because I have an M1 MacBook and then it was always a hassle of getting this thing around. So

 

Thank you.

 

maybe it's better now. Like I haven't tried in a while. I'm still very much in the camp of I have my system set up in a certain way. Like I enjoy it. I have my.files backed up to a place and that is how I prefer it. How, like, is it, I know, let me phrase it differently. So is this like now your new development modus operandi? Like, is this how you tend to now build software like with this remote development, maybe also for React and TypeScript and now also for Elixir? Or is it still something you've only played with because there are things.

 

So not 100%. I found it interesting and I wanted to get into the idea of how it works and if it could be beneficial, especially when I'm traveling right now and just have a little MacBook Air. I

 

Mm-hmm.

 

think the M1 is quite capable of running everything locally. But still battery life could be an issue

 

Mm-hmm.

 

and I just wanted to give it a try. So you mentioned dev containers, right? So I think the dev containers config file is what GitHub Codespaces uses for it. There are different kind of cloud providers out there. So I basically went always with Gitpod. I never tried GitHub Codespaces yet because I think previously it wasn't free. And I wanted just wanted to invest too much money into it to just look just looking how it works. I mean, they have, I think right now they have already. Also a free tier which is more or less the same like the Gitpod one. But anyway, I just tried out Gitpod and I was very skeptical at first. Especially what you mentioned that you said, okay, you have your.files local, you have all your environment, you have all your setup which you're used to on your machine. And

 

Mm-hmm.

 

it's quite hard to say goodbye to that, right? Because you know how everything works and you put so much work into it. And this is, I would say it's only half. the case if that you have to give up your local development environment because you actually use quite a lot of it. Um, also when developing remotely, as I said, you are basically SS aging into, into, um, a Docker container and have your registry code still running locally. So you still can have all your extensions set up, have all, um, basically all your dot files, even you can even include your dot files and you can. point, I think on git, but you can point it to a repository where.files are hosted and they will be automatically mounted inside the Docker container so you can

 

Ah, interesting.

 

make even use of that. So if you all have your own scripts and things, this is also what I do there when developing on it. So as I said, I was really skeptical about it. I wanted to give it a try. Looked into how you could get things up and running using Elixir. They have... some kind of base images, which provides like a ton of different languages to get you up and running basically very quick. They also have like a specific Elixir image, but it comes with a drawback that it's just installing Elixir from the APT sources and this is always like a quite dated version. I don't know exactly what it is, but some three or four versions back then what the get it set up, I decided to give it a try and play around a little bit. And it took quite a while to get used to it and how to get it up and running. But after I did set up it properly, I think it's a viable choice to do development work on this. And so I do not, like in the work, I do not use it. for my everyday work, so for my everyday tasks, but I use it for all the open source work I do. So this is, I think, one of the main benefits of the cloud environment. It makes things easy when you have an open source product. You could just put, let's say, you could just put a button on your repository. You click the button and then you have a full working development environment just set up in the browser. If somebody else wants to contribute to your project, this makes it very easy for them to contribute because they do not have to go over a huge readme file and store an enormous amount of dependencies, for example, but just can get them running very quickly and do their contributions.

 

Yeah, that makes a lot of sense, especially when... Doubly so, I would assume, if you look for something like GitHub Codespaces, which probably integrates just very nicely with GitHub repositories, just by the nature

 

Yeah.

 

of them being built by the same company. I'm not doing any promotion here, just I would expect that to be very seamless. I got to say though, the Gitpod website looks very cozy. I really like it.

 

Hahaha

 

I just had... All right. Is there anything why you felt when you kind of tried it out, which gave you more of an impression of, okay, this is not working as nicely as I thought it would be, or vice versa, right? Where you maybe expected, oh, this is going to suck, and then it didn't. I mean, for me, like I just said, I have all my.file settings, that's all and so forth, so those already can be mounted that I think, in and of itself, already brings a lot of value. They're super messy, I would have to clean that up.

 

Hahaha.

 

in general, what was your expectation and what was not so great and what was maybe surprisingly smooth sailing.

 

So my expectation was that to get it up and running that it would be a little easier, especially regarding the Docker container, get the Docker image up and running. But this, I don't have to, I cannot blame Gitport for this or Docker itself. It's just, I would say a lack of my knowledge on Docker because I'm never used to

 

Mm-hmm.

 

that much. I know, I mean, how to run the commands and a few commands of that to get the environment up and running. So basically installing. like Elixir installing ASDF for the version version manager. But first challenge was actually like installing a Postgres database into it because I'm running on Mac and I'm using just using the Postgres app for this. And so I had to look

 

Mm-hmm.

 

up all the commands to actually install it and get it up and running. The nice thing here was that that Gitpod itself has a Docker file for the for the Postgres image, but this was also like, I think it was Postgres 10 or something. And so, but I just was able to basically copy and paste and adapt this code so that it would work. So this was a little more work to do, but. Right up from then, the container came up quite quickly and it was working already. So you could then also, for example, on Gitpod, you have a configuration file where you can define all the tasks for the app to build. So let's say, part of the automation process or getting things up and running here is that you say, okay, you want to get your mixed dependencies installed, then you would say, please when starting up the container, run the command mix-debs get and mix-debs compile. So then you run the Phoenix server, for example. And this is then done directly when starting up the container. So you have everything up and running. So you do not have to enter any command manually afterwards. This was quite nice experience. And then you can also say, okay, for this specific project, which is quite nice, I want to have these. extensions available. So imagine you have a project which you are building with a team and you know for this specific project there are a handful of Visual Studio Code extensions which are quite valuable for this specific project and then you can define it and it would automatically install them when starting up the container and merge this one with your local configuration extensions you want to have in any project. So this is something which is really nice on this one.

 

Yeah, that sounds really useful. Oh, sorry. Did you want to say something? Okay.

 

Everything's fine.

 

Um, I, I, I, from what you've laid out, I'm wondering like, if this may be also the kind of the next natural step from some other things, because I've been personally a big fan of like a version, version manager, like ASDF, you know, which is kind of achieving something similar, I guess, to a certain degree while also being very local. I still have like in a repository potentially a file which specifies, okay, for this particular project, I want to use this and that version, blah, blah, blah, blah, blah. And there's all like the configuration approaches to the configure your editor slightly different for each different repository. So this, this feels like a, like a, like the next, next step evolution, say like in, in

 

Um.

 

reproducible development environments.

 

Yes, maybe. So I wouldn't say it's this or that. So because in the container, I'm actually using ASDF as the version manager itself. It's because as I said, the normal image, if you try to install it except from via APT, you would get an older version. And I'm installing ASDF inside the Docker container, for example, in my image. And then you could just set an environment variable. on the image or you could also say use the tool versions file of ASDF so that it automatically installs the Thumbacrap version of it for FedEx earning and for example Node.js if you want.

 

That makes sense, that makes sense, okay. Since you're more of like a front end and it's React and TypeScript person yourself, would you say that like the develop, I would expect that the experience for like something like remote containers is just a little bit better for like more popular technologies like TypeScript.

 

It definitely has a better support because it has

 

I'm not

 

more

 

surprised.

 

people requesting it. But still, if you know Docker and how to create a Docker image and install basically all the things you need to get Erlang and Elixir, then it's only just a couple of lines of code to get it up and running. But definitely, I mean, the out of the box support could be better. There's one thing, I mean, this is a very specific thing to mention. I don't know if anybody of you ran into this, but I'm happy user also of the Elixir LS extension of Visual Studio Code, like for auto completion. And it always has an issue. And there's an open GitHub issue. I don't know if this is going to be solved anytime or if this seems solvable, but basically whenever, so the Elixir LS extension is compiled using a specific version of Erlang. and Elixir. And when you run it locally in your project, you probably have a different version than the one the language server has been compiled with. And this results in the issue that if you, for example, if you have a module using the use macro, then take a live view, you just put at the top, you put the use statement with use live view, and then you try to call the function assign or assign new. something. This wouldn't result in any auto-completion most of the time. And this is something where the Gitpod environment or the cloud development environment in general comes in pretty handy because I do compile the Elixir LS extension directly with the version installed in the Docker container itself. So you always will get the proper auto-completion even if you... run different versions of Lix on different projects.

 

Ah, that makes sense, okay.

 

So locally for my development, I even have locally like a script in my dot file. So whenever I switch between two different Elixir projects, which use different versions, I just quickly run a bash script, which will then recompile the Elixir language server to be compliant with the current conversion.

 

Mm-hmm. That's kind of neat, but also a bit hacky. Ha ha ha!

 

It is, but still there's no work around yet for it. So at least

 

See you

 

I'm

 

later.

 

not, I am aware of it. If anybody knows an easier way, please tell me.

 

Yeah, I gotta say, I think the work of Elixir and his team, it's amazing that people are working on this.

 

I do.

 

For me personally, there's always been a bit of a finicky experience, like sometimes unexpectedly it doesn't work and you don't really know why. You never really dig deep into that. So, curious to hear a bit more about

 

Yeah.

 

some of the issues I would expect a lot of people are experiencing, where they come from and what the root causes. But I'm actually curious, Alan, have you done any remote development yet as Ben laid out?

 

Not like this. No, usually it's I have a slack call or Google meet call and they're sharing a screen and I'm screaming at them. No, no, no, not like that. Do like this. Sadly, I'm not though. That's something I wanted to take a to take a look at. But I don't know, I just I'm have skepticism, right? I think that's, I like the fact that you can have like a reproducible environment, you can share it with people. They can get everything going. It's basically like Docker container, but then they don't run on their on their on the computer. I actually was doing some freelance work on one of these CDEs, these cloud editors. I forgot the name of it quite a few years ago. It's all written in Java or something like that. I forgot what the heck it was. It's one of the free open ones at the head. I mean, I like the idea, but I don't know. I think I need to try it before I can say it. It's just too weird for me. I like just doing everything on the machine like Sasha was saying. ASDF just works and it's just... just an old school kind of person like that, I guess.

 

Yeah, I get it. So I think it's probably that you have actually to try to actually experience if it's something

 

Probably,

 

for you,

 

yeah.

 

if it's good. And I think the most benefit, so the biggest benefit or largest benefit out of it, definitely get teams working on. So like where teams,

 

Hmm.

 

where you have a team, multiple persons working on a single project, and where constantly like people are onboarding or offboarding, we have this one. This is a huge time saver, I'd say.

 

But I can't be left to wonder, I get what you're saying there, and especially in more volatile environments, I can definitely see the appeal. And also, as we mentioned earlier, open source development, having just something ready-made where contributors can jump in easily, I definitely can see the appeal there. But I'm left wondering if there is... Maybe I'm getting old and grumpy, but

 

Hahaha.

 

I can't shake the feeling that this is like taking it a step too far, you know, where I mean, is to then still have to go over the internet so like if I have a bad internet connection, you haven't screwed me, I guess. Right. And I do feel like there is a compromise where you can say, okay, we have reproducible development environments and they're easy to set up, built on some kind of standard, for example, Docker or something like that, right? And it's still a matter of, okay, I have to set up Docker on your machine. Okay. But I mean, at this point, um, that is, that is a given, I feel, especially in backend engineering, that you set up Docker and then you maybe have some kind of, of, of, of specification, which kind of goes for the same, the same idea and makes it easy to, to, to start out things. But yeah, yet again, I mean, we have dev containers here at my current employer and some of our old services just don't work for me because my

 

Thank

 

M1

 

you.

 

MacBook is like, nah, nah. So I guess you never can quite eliminate that particular area of friction. Yeah.

 

But that is something which you mentioned, what actually these cloud development environments try to solve, the thing that something doesn't work on your machine.

 

Yeah, I get it. So like I said, maybe I'm getting old and cranky. Ha ha ha.

 

Yeah, I mean, if you have a proper container set up and like, then this is definitely to say it is the end of the statement works on my machine. Because if it works

 

Yeah, true.

 

on one thing, one nice thing, for example, which Gitpod also has a thing called, called pre-builds, which basically you can you could think of this. Sorry. You could think of this, for example, you build a feature and then you create a pull request void.

 

Mm-hmm.

 

And then you create the pull request and then automatically there's a bot inside of it, which then picks up the pull request and automatically creates a dev environment for that so that you can afterwards, that you afterwards have a button there, open up this pull request and then you just get the full pull request up and running in your browser. You can test it out. You can see everything what's going on, test if there's anything, any issue here or not. Because, I mean, especially for myself, when I'm doing pull request previews, also my freelance work, I most, almost all the time, I check out the pull request, I have to call, I mean, on the TypeScript thing, I have to call you on install, wait for the packages to be fetched, and then check everything, if everything is working. And this is basically... cut off if you are using a cloud development environment. You do not even have to wait for the build to finish, because the build already has finished before when the pull request has been created. So you just jump directly into it.

 

Yeah, okay. I can definitely see that. I guess at the end of the day, it always depends on your particular circumstances. And just because there are cloud development environments doesn't mean that everybody now starts to replace their local development environments with them. Right. I mean, they can't, they can't definitely, I can't, I can't see what you just laid out as like a, like a helpful thing to still have, even if you still prefer your local development environment. So,

 

Exactly.

 

yeah.

 

So you could even decide, okay, today, this is also something I do. So today I'm working locally in my machine because I had it open or it's just set up right for me right now. And on another day, I would just open up the same repository in a cloud development environment.

 

Mm-hmm. Mm-hmm.

 

So you do not have to opt in fully because in essence it's just one or two configuration files added to your repository and nothing more, so you can still run it locally.

 

Yeah, that makes sense. OK. So you said earlier that basically all of your open source development now happens through these kind of cloud development environments. So what kind of open source development do you make?

 

So

 

That was a smooth segue, wasn't it?

 

yeah, it was great. Yeah, so I did some, all my open source development actually is around Elixir because I'm doing this out of work, so not during my work hours and I want to do something which I really enjoy and I also want to learn. So I always want to learn new stuff and that's happening mostly by doing things, especially especially by writing libraries and stuff like that. So I've wrote a few things. I mean, when I got started with Elixir, the first one which really, really bugged me, which was nice to have a nice thing which you have when running TypeScript projects is that whenever you open up your dependency file like the package JSON, it would automatically recommend you the latest version of the package which is available. So... I thought, OK, I could bring this into Elixir or in the Mix.exe file. So I built in a little extension for Visual Studio Code, which is called hex.pm IntelliSense, which automatically gives you the latest version when you hit the autocomplete within the Mix.exe file. So that you do not have to do to call a Mixinfo in your terminal or go to... the hex web page to see what the latest version of the package is. So this is one which I created a few years ago which was my first one and well lately I was playing around with mainly like animations which I think it is a thing which is a bit lacking on Phoenix live views on the animation side. I mean got better with the js commands and supporting the transition classes. for example, from Tailwind. So this got easier to do transitions and animations, but not for complex animations or even spring animations or something like that. This is something which is quite popular in the TypeScript world, in the React world, and there are a few libraries which I certainly got inspired from. And this is called live underscore motion, which is an animation library for. for live view. It is kind of experimental. So it's not running 100% smooth yet. I invested some of my time into it when I just wanted to work on this. So it is a bit experimental, but the API is quite nice if you look at it for the first time.

 

It's also an example, as a deployed example, and it's actually quite fun to play around with it. I'm just

 

Yeah.

 

doing it while I'm speaking, because you can change the numbers and it goes, whee!

 

Exactly. Yeah, so this is something I looked into. But so this is also where my front end like front experience comes through. So I try to, or where I see some potential, you can definitely bring things from the front end world also to this live view thing and bridge this gap for the fully, for the things which should fully run on the, on the browser, on the server, which are actually animations. So, but there is right now no way to declare. could declaratively define them on the server. So this is what I was trying to solve. Yeah.

 

I think that's really cool. It's also, I'm not sure when that was, a while ago we had someone on the show who also had more of a front-end background and back then we already said that the Elixir community, especially now with live view, getting as much traction and as much attention and as much spotlight as it does, that there are probably a lot of things we can learn from the front-end community because they both... They've had to work with some of those things for quite a while. So why

 

Yeah.

 

not benefit from from from very gained knowledge there? And this is like, this is exactly the kind of things I was thinking of back then when we were talking about that. So it's really, really cool to see that.

 

kind of also reminds me of when we had man, why am I losing me? It's too late over here. But our last guest last week, he said, remember, why am I blanking over here? Remember, they're they made this very, very fast and efficient Erlang

 

Yeah, yeah,

 

web

 

yeah.

 

server, right? And they

 

Jaws,

 

learned from elixir.

 

I think jaws, right?

 

Yaw is or something. Yeah.

 

Yeah.

 

So that was also very interesting. It's like everybody

 

and

 

has to learn from other, we're all learning from other communities, right? I think without Ruby, we wouldn't have a lot of the features of mix, et cetera, and everything else. Even like rust, right? Since Sasha missed me talking about rust. You know that the team that built Bundler also built cargo for rust.

 

No, not aware.

 

No.

 

Yeah, that's pretty crazy. Right. I mean, and cargo for us is pretty decent. Like bundler is not bad. But I think it's better. And that's usually what happens when you get to rebuild something. And another thing is that you can make it better than what you know, it was the last time, right?

 

I'm actually curious though, this is maybe a bit of a controversial question then, but there are people, and I've heard people say that basically also about LiveView, it's like the selling point, there's no JavaScript, you don't have to do JavaScript. So what is your perspective on that as somebody who basically just typescripts a JavaScript for a living, right?

 

I mean, I can get the point why it's a good selling point actually, because I mean, if I imagine myself just going into development right now, going into web development

 

Mm-hmm.

 

and I have to, I mean, like every, absolutely every tutorial on the web just recommends your use JavaScript, you get straight thrown into JavaScript and then I think you're getting pretty fast, you're getting exhausted. just have so many moving things going on there. You have like a ton of different bundlers, or let's say package

 

Oh boy

 

managers

 

yes.

 

you have. And there are so many things. I mean, there are libraries for like 10 libraries for every problem and every problem, they are solving basically the same problem in a slightly different way. I mean, it is kind of. So it's a double edged sword, I'd say it's, there's something which is actually good by it because libraries learn from each other. They get better, but still you have to pick something of them. If you're a developer and trying to get things done, if you're presented with like, like 10 different choices, at least I'm speaking for me. It is always hard. I want to pick the best one. I want to pick the one which resonates the best with me or which have a nice, a nice API. And I'm pretty fast exhausted if I have to look up. 10 different repositories just to solve a single problem, right? And you end up researching for like one or two hours instead of just picking one and solve the problem, right? Um, so, uh, in regards to this, I can get the point that you do not need to write any JavaScript that this is a good selling point, but still I think. The main value here from the main selling point is that everything lives actually on the server so that you only have a single code base which

 

Mm-hmm.

 

you need to manage and that reduces like a lot of mental overhead you would have for the classic. I mean most of the time it's recommended to have like a backend so you have a separate backend or use some... some serverless cloud functions or something for it. They can use something like Firebase or SuperBase and then have a single page application for it. But most of the time, I mean, if you think or look at most of the web applications itself, most of them, they are just mainly crud things. And

 

Yes, yes.

 

they do not really have to be a single page application just for the sake of being a single page application. And this is what makes LiveView and... So, so attractive and so good because you only have a single, like a single source of truth of your code and have way less mental overhead. And if you need to, to get some more interactivity, which needs to really run on the client, then you still can go for any JavaScript thing you like and can add it. So I think it is actually absolutely the best of two worlds because as a reactive, a part, so let's take a rich text editor for example. You can easily add a rich text editor using one of the popular react-based libraries for it or JavaScript-based libraries, but still have the full, the main part of the state living on the server and have like this server-rendered application and just sprinkle the JS where I really need it. Makes you also think about it more, where you really need that interactivity.

 

Yeah, that actually fits quite well into my perspective on those things. And I'm gonna now just share what I've been thinking because I'm also not quite in the area of yeah, no more JavaScript anywhere. Hooray. Because I mean, JavaScript is there for a reason, but I'm also of the opinion that JavaScript in the past few years it tends to be overused, like on some things, because as you just said, like most applications boil down to crud. And do I really need a full-fledged single-page application for a crop thing? Like, it's just a lot of complexity for something which you could make the argument is maybe not necessary. Not every time. Sometimes it is. I mean, I wouldn't want to build something like Google Docs just in a server-rendered scenario. It sounds like a bad idea. But I don't know, like my pizza ordering website, do I really

 

Yeah.

 

need a full-blown single-page application for that? So. I feel like LiveView is bridging the gap there from what we had and if like a kind of static HTML, then the next step will be something like jQuery with Ajax, so on and so forth, like what we had there. And then at the other end of the spectrum, we have like full-blown single page applications, but in between, there is now this thing which makes certain types of tasks just simpler. less complexity, less things, less moving parts you need to understand. Because if you actually need some kind of backend work, some kind of database, which probably you need for most useful business applications, then you can't get around of having a backend and having only one code base is in terms of complexity, often, often not always preferable. So yeah.

 

Yeah. Absolutely. I totally agree. And you even see like, like the trend that there's an ongoing trend also in the, in the front end or the REC community to, to go back to the server. So render more on the server, get more things done already on the server. So you do not, so that you have to make less web requests.

 

Mm-hmm. Mm-hmm.

 

So there is definitely a trend going back to that.

 

Yeah,

 

Um, yeah.

 

yeah. I've been observing that as well. And I mean, I think a lot of frustration that is personally for me has come from, as you said earlier, how fast the JavaScript ecosystem is moving. Because when I actually did have scenarios where I came back to an old Elixir app, maybe that hasn't been updated in a year, but it's running along fine. And now I want to do some changes. So I tried to get it running locally and then this It's always, always it was JavaScript, and like with package updates, which were giving me hassle. It's like always.

 

Thank

 

Like when

 

you.

 

it links it apart, maybe, oh, okay, this increased a few versions. Yeah, I can update it. Okay, maybe I need to do a few small changes. Yeah, no big hassle. Okay, let's maybe also update the packages for the JavaScript part. And it wasn't

 

Absolutely.

 

an issue every time, but if there was an issue, it was often there. So I think that is like where a lot of frustration has been brought. Okay, yeah, anything else you would like to pitch, you would like to mention then, you would like to let our listeners know?

 

Maybe, yeah. A library I was working lately on, it's another one which also has a large inspiration from the JavaScript ecosystem. This is ex-underscore-cva. And it's mainly just a port of a library in the JavaScript world, which is just called CVA. it really resonated from the idea with my thinking and it was it's basically around. I mean, in essence, it is just a function which concatenates classes based on some some conditions on some props in a red component, for example, as you would give it. Let's for example, take a button and you have a button and you have like a primary variant of it and you have a secondary variant of it. So primary has a primary color. the other one has a different color. And then you also have a simple variant, for example, which is called medium, like the size. So medium size, large size, small size. And this is actually a function to it, which automatically adds proper types to your REC components. Then So and concatenates the classes accordingly, depending on the variance you pass into it. So say you have a primary button on the size small, you will get a color button in a small size of it. So yeah, the correct class supply. And this one, I used it a lot in my front end projects and I really liked it. I thought about that this could be easily ported also to Elixir. Yes. I mean, if you look at the code base, it's just, I think it's around 100 lines of code or something. It's pretty small. And then I thought this could be easily ported to an Excel as well. I tried it initially by using, just using a function of it and then really got into more of it and thought, okay, there's the atom macro, like the attribute macro from when defining live view components. And I thought, okay, I could dig into meta programming a bit. try to

 

Mm-hmm.

 

create

 

Mm-hmm.

 

my own macro for variance so that you can define variance more declaratively. And this is what I did in this library. I'm using it on my projects. I really like it so far. And yeah, check it out if you're interested on that one.

 

I think that's really interesting. It goes exactly with the same kind of fashion I mentioned earlier, like getting inspired by other ecosystems and the things that are happening out there. It's really cool. I still have to admit that I haven't really digged into the whole component movement in Phoenix. So me, I just didn't really have an opportunity

 

Yeah.

 

yet. It's really, really cool to see what people are coming up there. And I think like even the latest Phoenix version is now view less. So.

 

Yes, they removed it. So

 

Yeah.

 

if you generate a new one, you won't get any view folder anymore. So it's just components everywhere, basically.

 

It's really

 

So it's really good.

 

cool to see why we are moving there. And I mean, you can't deny that a lot of those developments have been strongly inspired by things from the mobile, from the front end, sorry, front end

 

Absolutely.

 

community.

 

So yeah, I think Chris McCord recently, it's a couple of weeks now, posted a blog post on I think on the Fly.io blog. He posted a love letter to React. So where he clearly

 

Ah,

 

states

 

okay. I haven't

 

that

 

seen

 

he

 

that yet.

 

got inspired by the React ecosystem on designing the components things. It's a nice read, definitely.

 

It also feels like a natural evolution considering what we are doing in live view, like the components and live view that seems like a match made in heaven. Yeah, really cool. Alan, do you have anything you would like to add, like to ask?

 

No, actually, I mean, now that you're traveling, right? Do you find that if you're using that kind of remote environment that makes things easier because you can kind of spin it down, spin it back up, you don't need to carry some like beefy laptop with you. I mean, you can basically take maybe a Chromebook or something even lighter. I mean, nowadays, Mac books are really light anyways, right? I'm just thinking, like, do you think it actually helps with your traveling around the world?

 

So it definitely helps to use like a thinner book. So as I said, I'm just using a MacBook. And previously I used to use like a 15 inch MacBook, which is quite a lot heavier. I mean, nowadays that you have these new M1 or now M2 MacBooks, if you think of this one, that these are so powerful by being so battery efficient. Well, I honestly think for most of the development work you do, you can get away with some of these small laptops. Um, so on this, this is not anymore the full selling point I'd say, but definitely battery life, battery life has definitely increased if you, for example, I, or another example, if you, if you have like multiple projects running simultaneously, then this is also, um, a huge save on, on battery life first. and on the performance side, because each of your environments gets its full processor, its own RAM, its own disk space, basically everything is isolated between them, so you can run like 10 different projects without affecting your machine RAM.

 

Okay, yeah, I was just thinking about, you know, because I got to probably do some traveling soon. So it's always kind of wondering like what gear should I bring? Now I got my Steam Deck. So now I got Steam Deck, iPad, laptop.

 

Yeah.

 

Alan doesn't stop talking about a Steam Deck, it's too.

 

Yeah, I was just playing it before the show, you know, I barely have a chance to play it these days anymore.

 

Yeah, I even tried, like while traveling, I tried first, the first time I tried game streaming. So sometimes I got a little bored and I tried, okay, give GeForce now a try. I tried streaming games and it works pretty well. I was pretty impressed by it. So I thought, I always thought, okay, that this is never going to work properly.

 

Yeah, Logitech has a similar thing, but yeah, they run the GeForce, I think, on it. And I heard that Android games are not very good at it, but somehow GeForce is really good. I guess it's because really it's like they run everything on the cloud, right? So

 

Yeah.

 

it just runs easier.

 

Okay, unless there's anything we would like to be adding, how can people reach you if they have follow-up questions, Ben?

 

So yeah, I'm mainly active on Twitter. The Twitter handle is benvp underscore. So underscore at the last. And of course also via email, this is hi at benvp.co. So this is something where you could reach me if you have a question. I just want to say hello.

 

Nice. Then let's get to the more random part of a podcast. Pics. Alan, do you have any pics for us this week?

 

Yeah, maybe I'm a little bit late to the party, but I just started playing Doom 2016 and been super addicted to that. I saw Sasha, you also have this game.

 

I never finished it because...

 

Yeah, I'm trying to finish it. Almost done.

 

It's very intense and what it tries to do is it does very well with action-heavy shooter, but it has no pacing at all. Like it's just action, action, action, action, action,

 

Ha ha ha!

 

and then it's exhausting

 

Oh, really?

 

after a while.

 

Oh, really?

 

Yes.

 

For me, I just get it. The one thing that annoys me is you have to think a lot. And the maps are not linear. So that takes me a while. I gave up and started looking at walkthroughs to try to figure out how to move the next part. So that was the part that annoys me. Otherwise, yeah. And also, some of the room challenges are really difficult. But other than that, I'm loving it. And yeah, OK, I die sometimes. But. I'm also playing on the easiest level. So maybe you play on the hard level. I don't know. But yeah, it's great. For somebody who is a big fan of FPS games, I quite like it a lot. So I'm looking forward to playing Eternal after this.

 

Nice. Anything else?

 

For my picks? I can't just pick one, I gotta pick more? Come

 

Yes.

 

on, I got 161 games coming in.

 

Okay.

 

It's 161 podcast recordings right there.

 

Okay, fair enough, fair enough. I have two picks for this week. One is very straightforward. And it's Gleam. I just want to pick Gleam. I want to do a Gleam shoutout again. Because they actually now have Elixir Compilation. Like you can basically have a Gleam project with Elixir code in there. Yeah, it will install like the mix toolchain. It's kind of akin to what Elixir does with Erlang. Like how you can have Erlang in the Elixir project and can manage that or like all the dependencies. It's kind of the same with Gleam now, it can manage Elixir files and Elixir dependencies. And I'm not sure where I exactly read that or if that popped into my own head, but I saw the sentence which was like, Gleam is getting dangerously usable now. So we are at work now really considering to put it in production for some parts of our modulithic Elixir app and where we actually say, okay, we can really... benefit from like a more statically typed language here. So I would just, I mean, we had Louis on the show a few times, but I just have to do it again, like say maybe check out Gleam. It's really getting, getting to a point where you can't even be put in the production without, before being concerned about this. So that's my, that's my pick. Just want to do this shout out again. And my other pick is I'm going to do like one weird indie pick. which is a game called Domekeeper. And it's actually been built by a German couple. Like it's just the guy and his wife, I think, they're married. And they built this little game where you have like this little dome and it has this cycle, but like you go into underground and dig, like dig out resources and so forth. And then every... X seconds there's like a wave of enemies so you kind of have to go back up but of course grabbing all these resources makes you slow so you kind of have to manage time really well and it's like this this rogue-like scenario where like you start one run again and then you can do maybe little modifications about like getting different starting gear for your dome and so on and it's i don't know like it's it's one of these games like come on come on just just one more run Right, like one more round. And then it's 1 AM and you're like, damn,

 

Just

 

I have

 

a

 

to

 

quick

 

work tomorrow.

 

one.

 

So Domekeeper, maybe check that out. It's also not very expensive. I don't know from the top of my head, but it's under 20 bucks. And there was another video game pick. Ah, right, another video game pick I'm doing is not indie. It's very mainstream. But I've just recently got the new Mario Strikers football game. And I've played this thing to death on the GameCube back then. Like, I loved it. And I loved every second of it. And the new game is actually surprisingly deep. Like, I was surprised by the level of little interactions you can be doing. Like how timing plays a role in the different actions. For example, if you pass and then shoot just at the right time, like it gets a stronger shot and like all of those little, little details you can actually put into action, which the old GameCube game didn't have, which I'm not saying is bad, but like... I was surprised by the level of potential skill you can kinda, people can kinda get in this game. So I just played a few times now, but I'm already loving it quite a bit. And if you're looking for like, arcadey football action, arcadey soccer action, then this game is potentially worth a look. So Mario Strikers, the new battle football. Those are my picks for this week. Ben, do you have picks for us?

 

Yes, I also brought actually brought three picks. First up, real quick to the topic of cloud development environments. I created a Gitpod starter template. I'm basically in relation to the blog post. You can check it out. It's free to use it. So basically everything I talked about, you can you can see on this this template. So that's The first pick for me, second pick, is actually one of the books which I really, really learned a lot of in regards to meta-programming. That's the Meta-Programming Elixir book by Chris McCourt. It is, even if it's a few years old now, it's really, really concise and the examples are very good if you look to go into meta-programming itself. So I would even argue it's also fine if you do not, if you just want to... learn some meta programming, even if you're not using elixir or something. So it's really understandable and the examples are very good. So definitely give this a read if you want to learn something about meta programming. And the last

 

Just

 

one.

 

plus one on that. I've also picked it a few times in the past and it's also a surprisingly short read, which I think is

 

Yeah.

 

really nice.

 

Absolutely. Last one also, we all brought games, so I also brought a game here.

 

Nice.

 

So my game which I bring is Tunic. This is something I discovered I think when just browsing or when I subscribed to the Xbox Game Pass I think. So Tunic is a game which looks quite cute. It's like you have it is based on the isometric perspective. So you look from the top onto your character. It's a little 3D kind of thing. It looks a little bit like Zelda, so it has definitely been inspired by Zelda. And you control a cute little fox, which looks cute, but it is pretty hard, actually, the game. So it's a souls-like game. And it has a lot of little, well... secrets inside of it. So there are actually so many secrets inside of the game that there are even full communities outside of the game. They're trying to solve like the final puzzle which is that. So it is a really really interesting game and it's it's also nice if you just have like a few minutes left to play a little. So yeah, definitely recommend this one.

 

Nice, thank you. It was a pleasure having you, Ben.

 

Thank you. It was a pleasure being here.

 

And I hope you all also enjoyed listening to our rambling. I guess we're going to call this episode something like remote development and front end inspirations in Elixir.

 

Hahaha

 

So something like that. Okay, so I hope you all enjoyed listening to this and tune in next time when we have another episode of Eleximix. Bye!