Rooftop Ruby Podcast
Two Ruby programmers (Collin Donnell and Joel Drapper) discuss Ruby, web and native software development, technology, and more.
Rooftop Ruby Podcast
13: Open Source and More With Marco Roth
Joel is recording from his car, Collin is recording from a sauna, and Marco Roth is here to talk about Stimulus Reflex, Hotwire, and more.
Follow us on Mastodon:
Show art created by JD Davis.
So you're sitting in your car, you've completely lined it with pillows and blankets and everything.
Joel:Yes,
Collin:The dedication. It's, let me check what the weather is here
Joel:For, for the audio quality. Um, lemme just make sure my levels are good.
Collin:I mean, it sounds, sounds great to me.
Joel:Yeah. I'm thinking may, maybe I should do this more often. I'm also, I'm also hand holding the microphone, which I don't
Collin:That's
Joel:do.
Collin:That's wild. um,
Joel:I think it's okay. Like I'm just gonna not move my hand and hopefully
Collin:yeah, I just don't move a lot or tap it or anything. I think you should be okay.
Joel:Yeah.
Collin:Yeah. Um, well I just turned off all my air conditioners and it's 88 degrees Fahrenheit, which in Celsius is um, 31.11 as as
Joel:Oh wow.
Collin:so it's, it's pretty warm out. And I turned off all the air conditioning because, um, I knew that the, the, the rooftop, ruby listeners would not, uh, would not stand, you know, a degradation, audio quality. And I
Joel:Right, exactly.
Collin:Yeah. Um, I don't, I don't, I don't wanna revolt. But anyway, uh, Joel, we, we have a friend here. It's Marco Roth.
Marco:Yeah. Hi Cole. Hey Joel. Thanks for having me.
Collin:Um, how, how, how's your day going, Marco?
Marco:Good. I have been having a lot of fun lately and be excited to be on a podcast for the first time.
Collin:This is, this is the first time you've been on a podcast.
Marco:That's right.
Collin:I, I feel much like at, um, at Rails Comp where, uh, you know, people didn't realize that they were talking to the Marco Roth. Um, not the magazine editor, but the other, the Marco Roth. Uh, you know, that I, I am surprised it's the first time you've been on a podcast, but even have a nice microphone so that, that really worked out.
Marco:Yep. Sounds just about right to get on our first time on a podcast. Yeah.
Collin:I mean, I'm banging things together over here, so you're definitely beating me. Um, but anyway, uh, well, Marco, why don't you introduce yourself to the audience so they, you know, know who you are if they don't already.
Marco:Right. So I am Marco Roth. I've been programming for about 10 years now. I've been doing an apprenticeship, which we have in Switzerland, which is kind of like a, a way to get into your first job. And you are like in a four year program with a company and you work with actual teams, so you already get your first like four years of experience while working and studying at the same time. And I've been doing that and I've like got to. Used rails in the top and that's why I got so excited for Ruby and Rails. And, uh, the whole thing about program in general that I also added a bachelor's degree after that and doing so was also, um, working part-time in a company And yeah. Being done with my bachelor's degree, I had already ideas of experience working in the industry with actual teams and software develop development. So I feel like it's super fun to have this different, I guess take, which is not typical, I guess, in the whole world, and being so young in the community and having the possibility to work on so many open, uh, like awesome projects and, um, ideas out there. Yeah.
Collin:I mean, I have two thoughts on that one. I definitely should have been born European. I think, I think this is a big mistake. I don't think the uk I, I, I always imagine, Joel, you can correct me. I always think like Switzerland and like, um, some of those other places in the continent are, you know, sort of s tier, right? If you're ranking them, they're like the top, the top and then, And then the United States is, you know, a couple tiers lower in like services and things, and the UK is sort of in the middle. It's kind of crappier than some other places, but still a lot better than the United States. Does that seem about right to you?
Joel:I, I wouldn't say in the middle. I think it, it, it does come between the two, but I don't think it's anywhere near the United States.
Collin:Yeah, it's
Joel:In terms of services and like, I don't know, you could like the, I don't know. Our public health service is not terrible, but at least it's free and at least it exists, so.
Collin:Yeah, I mean, having no public health service versus having a public health service is a pretty big difference. You know, going from nothing to something is pretty dramatic. But anyway, Marco, uh, my mistakes of being born where I am is not, uh, we are here to discuss. Um, so we met at Rails Comp. Was this your first Rails comp?
Marco:It was my second, but like 15th in General Royals or Ruby related conference. So yeah, I've done a few.
Collin:15th in general that you've been to?
Marco:I think so, yeah, about that.
Collin:Wow, it's a lot. I, uh, I think this was my third Ruby thing, but I've been to a bunch of like iOS conferences, but I don't, you might have me beat 15 is a lot. Um, that, that's impressive. Uh, but this one was the best cuz you got to hang out with me. Right.
Marco:Exactly. No, I feel like it's, it's, it's so much different. Um, all the other conference I've been to, it was more single tracker, two tracks, and it wasn't that big of a conference where you have like a thousand plus. Rubius joining the whole thing, and usually it's like 200 people with a single track and in some small city or in a small city somewhere in Europe. And that's usually how I experienced confidences in the past and getting to experience like rails, conference meeting, all those people that you, I guess look up to and. See them speak and talk and even get to hang out with them is super awesome experience. I'm not saying you don't get it if the smaller conference, but it's just less likely to happen in this, in the way it happens at RailsConf,
Joel:Mm-hmm.
Collin:Yeah, absolutely. I think there were like 800 people this year, which to me is like, it's kind of a weird size, right? Cuz it's bigger than a regional conference of, like you said, might be like 200, 300, but it's certainly not as big as like a W W D C or something. It's like in the thousands, kind of in between. Um, I think it's a good size. It's like big, but you can still meet a lot of people very easily.
Marco:Yeah, that sounds about right. I feel like it's almost too big in a way because you don't get to get a chance to meet all the people, and I feel like with the smaller regional conference you might be able to talk or see at least all the people once at least it feels a lot close to that happening.
Collin:So the reason, uh, well, the reason I asked you on is because you're, you're, you're, uh, Is because you're so nice and, uh, nice to talk to. But the other reason was that you've done all this open source stuff and I thought it'd be interesting to talk about. I have actually, this is gonna involve both of you been using both of your open source things a lot this week because you made something called Phlexing.fun, which is a converter to take your e r b templates and turn them into Phlex components. Uh, and so I've actually been just, I, you, you guys are like the water. I've been swimming in this week, I guess, if you think about it that way. But, um, but how did you get, how'd you get involved in open source?
Marco:Yeah, so I guess the first time was actually a heto Fest in probably 2018, and I've been doing some stuff and was looking for project to contribute to, and I found this similar library to actually what Phlex does today, which was called MA Stack. And I was kind of interested in doing some open source related work, cuz I found it's fun. You learn, get to learn so many things. You get to know a lot of people doing it. And most importantly, yeah, it's fun just to work on hack and things and try to yourself in open source or in software basically. So yeah, that's basically was my first project like in 2018. Then, But I wasn't kind of satisfied with the project itself. The project itself was fine. It was fun to work on, but I felt like some stuff was missing to make what I was looking for to make actual reactive applications in rails or to make it a lot easy to build the application and doing reactive stuff without having to write a lot of JavaScript, which was why I was looking to contribute to those projects. And that's when I got started with that project. But then I found this other cool project called Stimulus, rePhlex and Cab already, which I started using like in 2019. And that's where my whole, I guess, trained for the open source. Um, my open source journey started in like in the big way. I was using it, found some issues and found some missing features. I upstreamed and then it just controlling from that point.
Collin:So for people who aren't familiar, uh, what is, uh, stimulus, rePhlex and cable ready?
Marco:Right. I guess I start with seamless rePhlex. So it's, it's aim is to provide a system for users to build reactive applications. That means whenever you click something on a website, some stuff is going to happen, and usually in the past, this. Means that the page is gonna refresh or you navigate to some other page and it'll reflect the changes after you clicked. But what we want today, nowadays with modern JavaScript applications or JavaScript framework, we want don't want to have a full page reload and having the interruption that this creates. So Steams RePhlex provides a way to basically build applications by having the state on the server side, but. Without having to write a lot of JavaScript while still, um, using irregular rubian rails tools you already do today. So it uses web sockets under the hood and it's updating those, those, um, changes or those, this data in real time.
Collin:Cool. Yeah, I was looking, I have not used this personally, but obviously I've like heard about it a lot. Joel, have you, uh, used stimulus rePhlex at all?
Joel:Um, I've not really used it directly or like I've, I've experimented with it a little bit. Um, I think that I didn't really know about it until after Hot Wire, and so for most of the things that I've been working on, um, I think it made more sense to use Hot Wire. But, um, yeah, I've definitely very much aware of the project. Um,
Marco:So, yeah, that's kind of the big issue with Siemens RePhlex, I would say. Because this project was created in 20, I think 18, when hot wild wasn't a thing, and basically we had to come up with something to make this kind of application work within Rails. We had TUR lengths at the time, but there wasn't much modern that it wouldn't handle form submissions and all that stuff, which we kind of use a lot in rails. So it wasn't really a good fit for the solution to make that work, and that's why this whole project was born in the first place.
Joel:Mm-hmm.
Collin:Yeah, I, I'm not gonna lie, the naming definitely has confused me a little bit since I haven't really used it, uh, personally. So like, so there's stimulus, there's hot wire. Stimulus is a part of hot wire. There's also stimulus rePhlex. Um, what is the relationship there with stimulus and stimulus rePhlex? Are those connected? I'm very confused by the whole thing.
Marco:Yeah, that's like one of the most, I guess, um, common issues that people have. They don't understand which part is which and what belongs to what. Um, so stimulus RePhlex is using stimulus, stimulus being just a JavaScript library. Under hoods to create this experience for creating these, those real-time applications. Stimulus rePhlex in itself is actually a stimulus controller, which has a bunch of stuff in it for handling all this lifecycle and events that it hap it, it's, it's using to make the whole thing work. So it's using stimulus, refu is using stimulus under hoods to make the whole application lifecycle work.
Collin:That makes sense. I've said that's what I thought the deal was here, but it's a little bit confusing because it has stimulus in the name and also stimulus is like a part of Hotwire, but this isn't Hotwire, right? This is its own thing. So is it kind of solving some of the same problems that Hotwire is solving? It's just that. Hot wire did not exist when this started, so now there's kind of two independent approaches.
Marco:Right. Yeah. It has some overlap. I wouldn't say it's completely like, Replacing the other thing, but that's kind of where we are heading or trying to head right now. We want to bring as much of the experience into native hot wire or into native turbo in that sense that you don't have to rely on those library as much as you would have like five, four years ago. At least that's my goal or my idea of how the vision or how to future of those frameworks looks like. That you have hot wire and you stick to that because that's what chips be frails. And you can do a bunch with it already. And if you would have today a case where you think like, it's not enough, I need something more, that's when you would reach for Sims rePhlex. At least that's my take, how I would approach the problem today.
Joel:Yeah, that make, that makes sense. What's the, um, so, The team that are working on SIM's rePhlex, you're also working on a new set of like open source products or framework, I dunno what you call it, uh, called I, I'll probably get this wrong, but I think it's, it's, um, let me see if I can remember. turbo Boost, turbo Element, and Turbo. Oh, what's the final one?
Marco:Streams.
Joel:Streams. Yep. That's it. So what's the story with that? I, I guess, um, is this like stimulus rePhlex two,
Marco:I guess you could look at it that way, but what we just try to do is try to come up with a approach, which would. Use all the hot wire parts, but trying to mimic the The behavior we hand with stimulus rePhlex. But I wouldn't say that it's ready to use as of today. It's probably more like an experiment that we can see and figure out how it feels and how it would look like if we would go the drought.
Joel:Mm-hmm.
Marco:Just that you don't have to choose between the two, but it's more like you want to build directive applications. That's what you're going to use. You're gonna use Turbo and then there are some plugins or be behavior that you can plug in, but doesn't make just the whole thing work.
Joel:Yeah, that makes sense.
Collin:Yeah, that makes sense. So, so you said you got started contributing to these because you were just basically using them and then you were like, some stuff is missing or there's some bugs or whatever, and you just jumped in.
Marco:Right. I was using Chase, S D R B files. A few years ago, which basically you were writing JavaScript templates, but you were injecting HTML and texts into actual JavaScript templates to update the site. After you'd done a request, you could write Shakespeare in the, you could write regular native Java strips, but you basically were interpolating into JavaScript, which felt. Like a heck to me. And that's why I was looking for a more elegant solution, how you could approach this problem space. And that's why I found students rePhlex back then.
Joel:How, how do you approach, um, when you find a library like that and you are thinking about contributing? Um, So, so from my experience, I haven't done a lot of that kind of open source work where I've started contributing to someone else's library that I've been using. A lot of my stuff has just been, uh, this is something that I want to exist, so I'm gonna create it from scratch and then share it with others. So I'm really interested in your process in terms of how you choose, like what projects interest you and like, How you choose what you're gonna spend your time on, like whether you, like, do you reach out to them first or, um, yeah. How, how did that kind of come, come to be that, that, cuz you're now like working, you're now like on the core, the core stimulus rePhlex team, um, several years later. Right. Um, so I'm kind of interested how that all came about in the beginning.
Marco:I guess the really secret to that is that you need to be curious. You want to use those app like just projects and all those, um, gems and libraries and if you use them by yourself and try to solve a problem with them. You figure out what is missing, what's wrong, what feels wrong or what could be improved. And just by doing that, you have so many opportunities to, um, I guess, improve things, help implement things, or even try to create new features for those existing libraries or that are out there.
Joel:Mm-hmm.
Marco:And you need to be, I guess, curious also to look into the codes and try to understand how it works Under the hoods. I like, I like to take, um, a look into the source code just because I want to know how it works and how other people solve problems that are complex and abstract by just looking at the code. You learn so much by doing so, and it might be imitating at first, but once you get the hang of it, it's. Really inspiring to see how other people solve problems.
Joel:Mm-hmm.
Marco:And yeah, if you do that over and over again, you kind of get into the habit of just improving things. If you see something which is off in a library and or a framework or even a website, if it's just as simple as a docs update in a library.
Joel:Yeah, I, that's so interesting. So, You've just become so good at like, looking like you'll use a, a library or something and then just feel like, oh, I, I feel like it would be great if it could do this, or whatever. And you just dig into the code and figure out how that works. Um,
Marco:Right, and sometimes that just means I open the code base, I start hacking on things, but might not make it upstream. Might just be me experimenting with stuff or trying to figure out how it feels. And then maybe I figure out, okay, that's not how it's supposed to work or how it's not gonna look like. Then I just scrap that idea. But after some time, I feel like you get into the habit of just trying to see if people would be interested in you open upstream exchanges to their library and they might accept it, or may, maybe they're not, but it's in the end up to them if they want to have those changes in their library.
Joel:I guess there's like a, you get a sense I think when you, when you use a library, even just like looking at a library reading the Read me, uh, you do, I think. You can quickly get a sense for at least the vision that the author's going with and if that fits what you feel you are trying to accomplish as well, then I guess it, it's easier to approach them and be like, I think this is like, I'm on the same exact wavelength. I think this is brilliant and it could do these things as well. Um, so I guess, I guess that's probably how. How that works. I'm, I'm really interested in how, uh, how you came to, to join the, the core team. I guess was, was that like a process of, you know, you've been committing for so long and you're invited to start working with them? I'm guessing it was, um, I know Nate Hopkins works on that, but I'm, I'm not sure. I'm not sure where, like, what the origins of the project were.
Marco:Yeah, so. Hopkins started the project I think in 26 18, I think, and I was using it in early 2019 when it was really early, still in the project's lifetime. And just by using it, I was figuring out stuff which I was missing. One of the first things I was like missing was like debugging features or like logging features that you could see what's actually going on. And I was like, yeah, let's just tackle it and try to. See how it could look like, how it could work. I upstreamed the changes and they were like, that's awesome. Um, let's merge this. And it's really motivating if people see that they are, can you, uh, uh, if people are using your stuff and to see that they are delighted by using it, and then you kind of start doing it over and over again. And that was Upstreaming features I was missing for some time. And then they were like, yeah, do you want to join the core team? And I was like, yeah, I would love to. And uh, I was helping, basically just driving the whole framework forward since then. Yeah.
Collin:I think an interesting part of it, you talking about like, you know, you uh, you start using a library or whatever. And that it seems like a lot of how you get into it is it's just practice that you've done it a few times and so you're in like the right mindset now to be able to, you know, uh, approach it in a way to where maybe you can start contributing.
Marco:Yeah, I would say so. And. I think it also helps if you try to look into newer projects, which I was, was doing what reflects, um, Joel Opensource, I think last year in August, and I was seeing him tweeting about it and I saw some stuff and I was like, yeah, I guess let's just use and see how it feels and how it could work or how we, I could help improve it in some ways. And that's, uh, also why I was like, yeah, I'm struggling to convert Eer B to Phlex and maybe I can just hack out a tool to convert that for me. And that was a retail project. I was just like, let's do it. Let's try see how it goes. And, um, turned out to be great.
Collin:Yeah, the, the, um, the Phlex conversion tool you made it, it worked, it works really well. I did find a bug in it today, so I'm gonna fix it and submit a, uh, it. It's, it got confused and thought that it needed to, um, it added the render method as one of the like, Hey, you may need to implement this. So then I'm like, why is my whole component coming up blank? Because I had overridden render. Um, and, uh, so I'll maybe, maybe I'll submit a, a, uh, a bug fix for that. But that's all re that's all really interesting. tell us about Hotwire and like how you've been contributing to that and getting into it since it seems like there is some overlap that's kind of interesting. Right.
Marco:Yeah. Um, I started using stimulus also a few years ago, and I was working also on a project called Stimulus use. Which is basically a, you could stay almost like a standard library for stimulus controllers. You get to, you get some behaviors you can include in your controllers and then create your own F functions out of it or like your own controllers out of it. And I was using that and um, then at some point David reached dh, reached out to ask if I want to help upstream or help maintain stimulus. And I was like, yeah, I'm using it for stimulus rePhlex, I'm using it in all my projects and I want this project to live on because I feel like it's super awesome technology and I feel like it helped me understand the whole thing so much more. The hardware approach that is, um, by creating those small, reusable controls that you can write, the tower kept in and that's where I was introduced into the. I guess you can say umbrella term, and I also started maintaining that and also upstream some features I was missing or I was having a need for. And as of late, I have been trying to also help improve Turbo as much as I can to also help with that vision that I have that you probably don't need CS rePhlex anymore, but all of that could just live within. Turbo or some of that stuff could leave alongside Turbo as a plugin or as a external dependency or whatever it is, but that is more streamlined for Rails is shipping out per default today.
Collin:Yeah. So what are some of those ideas that you're thinking of? Like what would you like to see be folded back into like turbo?
Marco:Right. There's some stuff about form handling on the client set, which I feel like is missing. There is this concept of Optim, um, optimistic updates, which we also have some features in Turbo already, but it's more like this data Disabled Swift, when you click on a button that it shows a text, um, like submitting, do dots. But you could do this with like, so much more than just form buttons. You could say. You could swap out a whole page and just showing a pulsing. Box that waits for the submission to, um, finish or whatever. Um, there's also some stuff around dev tooling, which I feel like could be helpful that you see frames more obvious in a, um, in, in your page that you see some error locks. If some, um, frames have the same, share, the same id, even though it should just have one with the same id, then there is a lot of. Features I feel like is missing in turbo streams. Um, the default are seven actions, but there's so much more you can do with those stream actions if you do them right. And I feel like either it would make sense if there would be more than seven actions or if there are more that you can just plug in. But then there's also like elder tooling, which I feel like is missing. I, I was really inspired by the um, workshop if I was doing for Rub LSP and Rails lsp. And actually I have been working on a stimulus LSP two years ago and I was also kind of motivated again to pick that up and finish it that you can see when you write the stimulus controllers, all the available. Values, the targets, the um, attributes for auto complete and all that when you write your html, because that's what a lot of people get wrong most of the time when they write data, dash control, name dash targets, then have to write the actual target name. There's so much that could go wrong in that process of figuring out how the attribute looks like, but if your editor just brings you up all the available attributes, It's just easy to get it right the first time and without spending a lot of time figuring out what was wrong.
Collin:That'd be amazing cuz I have experienced exactly what you were just talking about and then was staring at a blank page and didn't, I'm like, I don't know. I was going to make a joke before when you're like, there should be more than seven. I was gonna be like, well there were seven apostles. But then I looked it up and there were actually 12 apostles. Uh, so. The American Education Systems failed me again. Um, anyway, I don't
Joel:Isn't the seven sub things from Breath of the Wild?
Collin:There are the seven something from Breath of the Wild. Uh,
Joel:Yeah. What was
Collin:I'll think about that. I don't know what it is. The seven Divine Bees.
Marco:It's four.
Collin:think there are only four divine
Joel:four. That's four.
Collin:This is really important. Um,
Joel:There were seven Somethings.
Collin:you know, here's the thing. So Zelda's, my favorite game, my dog's name link. And every Zelda game, I think mostly follows the thing of you have to get the N number of magical McGuffin.
Joel:Yeah.
Collin:And then about halfway through the game you find out that actually those McGuffin were not the thing you needed at all. And then you have to go find these other four or whatever number of them. And then that's the real thing.
Joel:Mm-hmm.
Collin:and so I think you're probably right that that was the, before you find the Divine Beast, there were probably seven of something else you had to get, or I'm just misremembering. Have you guys been playing the new one? Do you, Marco, do you play Zelda? Do you play Nintendo Switch?
Marco:Yes, I've been playing tears of the kingdom a few hours, and I have to say it's super awesome.
Collin:It's, it's remarkable. So, Joel, have you, have you looked at this at all? Cheers. The kingdom.
Joel:played Breath of the World. I haven't actually got a switch, so I haven't played tears of the Kingdom yet.
Collin:All right. We'll go get a switch and then we'll talk about this. But the thing I wanna say is they have a crafting system in here, and I see basically I, I put a, I put a rock on the end of a stick. And that's like the, that's how good I am at the crafting. And then I go online and I'm like so proud of myself for my Rock on a stick, and I see other people are creating like, uh, you know, stealth bombers and, uh, nuking balans from orbit or whatever. Anyway, so Marco, what are you? Uh, so, so what are you excited about, uh, in the world of programming and Ruby and everything, uh, currently, what, what's, what are you, what's exciting for you in the next year or two?
Marco:Right. Um, I feel like. There's a lot of opportunity we can do in rails for tooling for, um, more JavaScript enabled apps. Again, um, I'm not, I'm, I wasn't a big fan of JavaScript a few years ago, and I agree that most Ruby developers or rest developers don't want to use JavaScript as much, but. In today's age, you probably have to use JavaScript in some way or form anyway, because otherwise your website is not gonna work. And I feel like there has been missing focus on the JavaScript, I guess, tooling frameworks and I guess ideas, how you can write JavaScript in. Rails. There was this whole Webpack drama. A lot of people were complaining about that. They was so confusing and so annoying. But now we have, again, four different news stories in Rail seven, how you can bundle your transcript or not bundle it at all. And I feel to, has a lot of opportunity to clean up and, um, polish some things that it makes fun to write Java script in your rails up, even if you don't write a full. Fully server. Oh, client site JavaScript application.
Collin:That makes sense. I do like that the default option, if you don't, if just like import maps or whatever Right. Is they're moving more towards like simplicity and using like, The more standard things. That seems good. That seems like a good move. Maybe it'll sort of figure itself out in the next couple of versions.
Marco:Yeah. Um, I like the idea, but I have an issue with it because, um, if you, I have say more than five dependencies. You get the, like, op, like the um, You get to version resolve your own dependencies because if two packages share the same dependency on a version, you have to figure that out and include the right version inside of your input map conflict.
Joel:Mm-hmm.
Marco:Um, there has been some other kind of weird issues when you have syntax errors in your codes that it won't show any error at all. At least that's what I saw
Collin:Mm-hmm.
Marco:and some kind of weird things around it. But I like the trend and the idea of where this is heading.
Collin:Yeah, I would like to see in all of these things, cuz I'm just thinking about it as you're talking. Uh, better error handling in general as like a thing. I do feel like there are a lot of places where things kind of fail silently in like, and I have to go digging for like where the error actually is. Uh, that is definitely a focus I would like to see, uh, spent a lot of energy on.
Marco:I feel like Rails is doing a good job with that already. Um, compared to other frameworks, but whenever JavaScript is involved in rails, I feel like it's super tricky to figure out what's actually going on.
Collin:Yeah, it's interesting. Um, have I ever told you my theory about why I kind of think like Visual Studio Code isn't that great for Ruby is because you have to write the plugins in JavaScript and Ruby developers suck at JavaScript, so all the plugins suck. Because none of us wanna write it. Um, but anyway, uh, I don't know. I think this is all really interesting. I think we should have you back, uh, another time and, but for the time being, are there any final thoughts or anything else we want to cover from either you guys?
Marco:Yeah, I, I have, I have something, some stuff lined up in, in my pipeline, which I want to, um, get out sooner or later. And I have been working or trying to work on a Turbo ui, that's what I call it right now, plugin of library, which is kind of aiming what's, um, headless s or Headless React is doing from the Tailwind guys, which is just trying to, um, Provides react reactive, um, components that you can plug into your application, which are on styles, but, um, but, uh, I can't talk.
Collin:of a component library that you could, uh, that uses sort of hot wire.
Marco:Yeah, so it's kind of a like powered by hot value and it's just a behavior, but without having the styles for it in, in place. So you could think of a, a dropdown, which you could type in and would search on a endpoint, whatever it's looking for. You're typing, but you just plug in the components or the. The thing that it works, you have to style it, you have to plug it into something, but it's doing all the, um, behavior and the reactive, all the syncing between the client server for you. So it's more like a Yeah, a headless, reactive library that it can plug into your existing application for pulling all those um, behaviors.
Collin:Yeah. That's really interesting. That sounds cool. That'd be really fun to talk about when you've like, got that worked out more.
Marco:Yep.
Joel:I was just gonna say on the whole like asset pipeline thing, There's gotta be a solution. Like it just feels so much like the worst bit of rails, and I'm glad that, you know, it's not just me that feels like that and they, that people like you are thinking about this and trying to figure out how, how it can be improved. Because I, I actually remember, um, it was a lot better before. It's definitely a regression. I remember when I was building apps using Rails five or six and Coffee Script.
Marco:Mm-hmm.
Joel:You know, the experience was just amazing. Like, we didn't have Hot Wire, but we had uh, I think early stimulus, right? And the experience like working with JavaScript, with Coffee Script and whatever the default was back then, like everything just worked and there was like one. Like you didn't make any decisions about how you would do things. It just worked. And I hope we can get back to that again, like having four different ways to do, to do asset management plus like, probably extras, right? So there's, there are other tools that, that can be thrown in the mix as well. Like vi
Marco:Mm-hmm.
Joel:it's just a, it's a bit of a minefield and. I don't even know what's the recommended approach these days.
Marco:right? I personally would say ES build is the most sane solution right now. It's just, Easy to plug in and use, I feel like. Um, but I don't think it's, it's the best solution yet. And I think the problem being that all of those dependencies are now hosted on NPM and, um, we don't, we want to rely on those packages because they offer amazing packages and just leaving that out of the picture feels wrong because they want to build with those as well. But then again, sinking between a Ruby gem and a um, JavaScript MPM package is kind of hard to do if you want to ship assets with your Ruby Gem and want to support all the different solutions one could use to power their rails up. It's a lot of effort to make that work, and that's also what we figured doing so in stimulus rePhlex.
Joel:Yeah, that makes sense because you can't ship. Like do, do you bundle your JavaScript with your gem? That probably doesn't make a load of sense if you've also have the same version available via mpm.
Marco:Yeah. Right.
Joel:Yeah.
Collin:Yeah, that's definitely breaking my brain a little bit, thinking about it now.
Marco:I mean, consuming it is also confusing if you just want to plug it in and say, okay, now I need to figure out what am I using? Am I using import maps? Am I using web packer? Am I using ES builds? And then what's next step for my bundling solution? But on the other side, if you're creating or maintaining those libraries, it's kind of a nightmare to offer all those solutions as well.
Joel:Yeah. Do you think that there's like some other solution that that is gonna come out that will just like solve all of this stuff and be better than Es build and better than everything else we had before?
Marco:I have an idea that's good for workouts, um,
Joel:Okay.
Marco:but I'm not saying I know it, it's gonna work out, but that's what I'm saying, like, If you're doing open sort of stuff, you can just try to experiment with that stuff and see how it goes, right? And that's also why I love doing it, because I just get to work on those problems and trying to find solutions for those problems. So my idea is if you have this Ruby gem, which is having a child JavaScript variant available somewhere, probably on npm, you could specify in your GEM spec that there is an npm package for my gem.
Joel:Mm-hmm.
Marco:if you provide that and have a ruby counterpart, which is acting like a bundler, it could download those packages for you
Joel:Right.
Marco:hosting them via import maps. So you basically writing a JavaScript BUNDLER in Ruby, parsing the gem specs for whatever gems you have bundled, and then providing those as import, mapped, um, assets to your application.
Joel:This is, I think this is a really neat idea. I guess, is that something that you could maybe upstream to Bundler itself? I feel like this is even wider than Rails.
Marco:Right. I guess you could even say we could do that for system dependencies. If you have like, mini magic or something like that, which requires anub to this package and. Requires this package on Mac and this package on one two Linux. You have all dependencies, which just are not Ruby Gems anymore,
Collin:So you'd have some kind of a way to define all of your dependencies, and then some of them could be like system stuff, even that like maybe you'd install through home brew. So anyway, uh, Joel, you dropped out for a second, but you're back. Uh, Marco just told us how he's going to solve JavaScript bundling and bundling in general for, uh, Ruby Apps
Marco:I try to,
Collin:So, uh, so I think that's a great place to, to put a pin in it. Uh, if there's no further things, and then we can have Marco back once he's, uh, solved all of the problems that anyone's ever had in a Rails app. Cool. So, uh, Mar Marco, where, where can people find you? Where, where are you at?
Marco:Right. I am at Markoff underscore on Twitter and@markoffonruby.social, and I have a block which I want to put more post on on Marco do Dev.
Collin:Cool. And, uh, well, thank you very much for being here. Uh, to everybody else, thank you for listening. If you like the show, please hit the star or thumbs up or whatever it is in your app and, uh, tell your friends and, um, you know, maybe like if you need to like fix your mom's phone cuz you know her dad cuz they're older, maybe just go into the podcast app and subscribe there as well. You know, every little bit counts. They're, they're not gonna know. Um, and we will see you next week.
