Episode 49 - Radan Skoric

What happens when a seasoned Rails developer with 17 years of experience decides to document their journey learning Hotwire? Radan Skorić joins us to discuss his ebook "Master Hotwire" and the fascinating parallels between writing and coding.

Unlike most tutorials that start from ground zero, Radan's approach assumes you already know Rails—because that was his experience when learning Hotwire. "When I was picking up Hotwire, I had tons of Rails experience. I've just not done Hotwire," he explains. This focus allows his readers to skip the basics and dive deeper into what makes Hotwire powerful.

We explore the meticulous process behind creating technical content, from researching pain points on forums to managing a beta reader program. Radan shares a powerful insight about feedback: "With positive feedback I feel good. With negative feedback I can actually go and improve it." This mindset led him to completely restructure portions of his book based on reader experiences.

The conversation takes unexpected turns as Radan reveals how he overcame writer's block by applying software development principles to his writing process. Just as he might write tests to overcome coder's block, he found success by allowing himself to write "crap words" initially, knowing he would refactor later—a technique that mirrors how many of us approach code.

Perhaps most compelling is Radan's observation about Hotwire's place in the ecosystem: it allows backend-focused developers to "stop lying" about being full-stack by providing a framework they can realistically master without diving deep into JavaScript frameworks like React. It's a refreshing perspective that reframes how we think about the full-stack developer identity.

Check out masterhotwire.com and use coupon code "CodingCoders" for 20% off the book, and join the growing community of Rails developers embracing Hotwire!

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Honeybadger
Honeybadger is an application health monitoring tool built by developers for developers.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

Introduction to Radan Skoric

Speaker 1 0:01

Hello everyone and welcome to another episode of Code and the Coding Coders who Code it. I'm your host, drew Bragg, and I'm joined today by Radan Skoric. Radan, for anyone who is unfamiliar with you, would you please do a quick introduction? Thank you.

Speaker 2 0:13

I would be guessing that actually most of your listeners are unfamiliar with me because I've been programming professionally for 17 years, but I've only recently started putting stuff out on the internet in a more focused effort. I've had a website for a while but it was like almost nothing there, just like my CV. But a year and a half ago I started actively writing on the website and recently I published an ebook called Master Hotwire which, surprise, surprise, it's about Hotwire. And for anyone wondering why another Hotwire resource, I actually have a little bit of a different take than I think most of the tutorials. I decided to focus on experienced Rails developers who just haven't picked up Hotwire yet, because that was me.

Speaker 2 1:01

When I was picking up Hotwire, I had like tons of Rails experience. I've just picked up Hotwire yet Because that was me. When I was picking up Hotwire, I had tons of Rails experience. I've just not done Hotwire. And that focus allows me to kind of be more to the point, right, I don't have to spend time going around explaining a bunch of stuff. I can explain it a little bit more focused and then I can also, with the time I save, I can also go deeper on certain topics.

Speaker 1 1:25

Yeah, that makes a lot of sense. I mean, when you're doing a beginner Hotwire course, the beginner might also be beginning with Rails. So there's a lot in Rails to cover. Maybe a little bit less if you're Hotwire focused, but certainly being able to skip and just run with the assumption that this person knows Rails and has Rails core concepts down Definitely could see that, allowing you to go deeper into the actual topic of Hotwire, which itself is pretty broad.

Speaker 1 1:54

There's a lot to Hotwire, but I'm sure we're going to get into all of that because the way this is going to work for anyone who's new to the show. So I'm going to ask Radin three questions. I'm going to ask him what he's working on I think we know what we're going to talk about there. I'm going to ask him what kind of blockers he has If he doesn't have a current blocker, it can be a recent blocker he had and how he went about solving it. And then the last thing, my favorite question to wrap up what is or discovered or built or wrote? Maybe it doesn't have to be coding related, but it could be. So now that that's out of the way, let's get going. Reden, what are you working on?

Speaker 2 2:30

I'm working on the book. So actually I'm consulting for a company halalbookingcom, it's not a secret. I'm consulting for the company and I'm migrating their front end actually to Hotwire. I have an arrangement where I'm four days with them and then Friday is kind of like the book day. So I published the book. I split it into three parts and part one, which is getting up to speed on all the web parts of the Hotwire. That's completely done, so that's in the hands of a bunch of readers already and that's available on the book's website, masterhotwirecom. But I still have the rest of the book to write right, especially now that I have people who gave me money for the book. Now I really need to finish it.

Speaker 1 3:12

Stakes are a little higher now that there's money involved. Yeah, now.

Speaker 2 3:15

I actually really need to finish it, but I'm also enjoying it and I'm moving that forward, mainly on Fridays and then here and there when I get the time. So the part that I'm currently focusing on is the KotLine native part, which is the second part of the book, and then third part. I kind of plan to cover a sort of range of topics that are a little bit more advanced. So part one gets you to the point where you can launch a website. Then part two is intended to get you to the point where you have a working KotLine native app, and then part three is intended to get you to a point where you have a working KotLy native app. And then part three is a few other topics that you like to run into when you actually have something running and you need to go a bit more deeper with it.

Speaker 1 3:52

I guess that's kind of the nice thing about doing it as an e-book. If it was a print book, you'd have to be done before anyone could buy it. With an e-book, you can be like hey, if you like what you've read so far, there's more coming. Do you solicit feedback from people of like, hey, what do you think the book is missing so far, or is there anything that I can expand on to make the sections that are already written even better?

Speaker 2 4:16

Well, first of all, initially, before I even wrote anything, I spent a fair amount of time going over forums, mainly Reddit, but also Falkwild forums, some Slack groups. I mean I'm kind of taking notes, structured notes, on what people are struggling with, where they are stuck, what are problems, taking that into account, and then before I published, I ran a battery the group. I used a bettering tool for that. When I put it out and I didn't know cause I didn't put anything out there. I was like if I get a few people interested, that would be great, and I had like on my list I had like 150 people subscribed then and about 20 something of them were interested and in the end, 10 of them gave me very detailed feedback, the ones that went through the whole thing, which was really good. That's a good signal Like they didn't give up and also they gave me very detailed feedback. A few of them were also personal friends, so that was really unfiltered feedback.

Speaker 1 5:15

They were just like very blunt.

Speaker 2 5:17

People who don't know me personally. They also gave great feedback, but I could see that they're kind of trying to sugarcoat it. Sure, the friends, yeah, have the kind of like honest relationships. They were just like you know.

Speaker 1 5:28

That's good, though. That's good to have friends who will give you straight feedback.

Creating Master Hotwire Ebook

Speaker 2 5:32

Yeah, that is excellent. That is really really good For the better readers. When I bring them there's like a short intro blurb that they see. And I emphasize I said positive feedback, you know it makes me feel good. But actually negative feedback is infinitely more actionable. Like with positive feedback I feel good. With negative feedback I can actually go and improve it.

Speaker 2 5:52

So for part one I time-tracked myself and drafting and editing put together, I spent like 38 hours initially, but then I also spent like 19 hours just addressing beta feedback spread over multiple cycles, and I made sure that I get in there. I get a sort of mix of people. I had a few people who are actually already experienced with Hotwire, then I had some people who are very experienced with Rails but they have no Hotwire experience at all. And then I had even a few people who are sort of earlier in their software in general software development journey. They're sort of a bit earlier and maybe dabbled with Hotwire. So kind of like in between the two groups and that helped me a lot. I ended up not only fixing like small things, but I ended up rewriting sort of chapters, so in the book.

Speaker 1 6:41

I guess not even in the book, but form a. Coming up with the idea like I'm going to do an ebook because you go a significant amount of your career not putting anything out there. Some people hit the ground running. Nowadays I feel like they, even in boot camps, are encouraging you to have a blog and build stuff out of the gate and put stuff out in the open and build in public. But you've been doing this for a pretty darn long time where that wasn't as commonplace, and now it sounds like you kind of was like I want to put stuff out there. So how did you come up with like I'm going to do an ebook? Because I chose podcasting. I tried blogging. I'm not a good writer, I'm barely a good speaker, but I'm good enough that I can move a conversation along and that's how I got into podcasting. It's like that's my contribution to the community. Is I'm going to do a podcast. What made you think ebook? Like that's what I want to do an ebook on Hotwire.

Speaker 2 7:36

Let's break it out. Let's first say an ebook, because that was a decision that came before the Hotwire part, so I haven't been writing publicly. Ever since I've been working professionally, I've been doing a lot of writing. I've often been the guy who cleans up the documentation, makes it easier. For a long time I've been very detailed in my git commit messages because far too many times I try to figure out a code, I do git blame and it's like tests. That's the commit. I am guilty. Figure out a code, I do get blame and it's like tests. That's the commit, or like or the commit.

Speaker 2 8:06

I am guilty commit messages is like works. Now I'm like what, what? What was it before? What happened? Try one.

Speaker 1 8:16

Try number two. Let's see if this works. Try number five.

Speaker 2 8:21

And then I would do like a commit message where I had people come to me and say, like I don't have the patience to do what you did, but I'm happy that you did it. Because my commit message would be like oh, we had this issue, it was identified by a customer here and then we looked at this and this and then, because this other stakeholder asked for this, it's because we did this and now the fix is this one line. So, like, the Gitco message is like and I enjoy doing that, communicating and trying to make it as clear as possible and I put a lot of value on that. So I've done a lot of writing and writing internally, non-public, inside the companies and the teams where I worked on. So when I sat down I wanted to write the blog. It was very nerve wracking putting it out there because I'm like oh, it's going to be judged, but in the end, like, especially in Ruby community, that's why I like being here. People are nice in general. Like people are nice. So it all went well. It was unfounded fear, but I did enjoy the process of writing and getting better at it. So naturally I was like I'm going to do an ebook.

Speaker 2 9:23

It's also it's easier to fix right. I'm new to the game. If I did a video course and then I have better testers and they point something out, I have to go and rerecord the video. Like, at least I need to have to rerecord the significant segment. I can't just alter a sentence, I can't rerecord one sentence or the video isn't just not going to look good.

Speaker 2 9:44

So from that perspective an e-book is a very good starting point. And also I've seen quite a few other people do good work with that, for example, nate Berkopec. I went through his speed shop and there's an e-book but there's also a video course and also him in-person coaching. But he started with the e-book and then later that recorded over that the key part. So I think it's kind of easier In the future. I do have some ambitions to start doing some video content when I have the time to try my hand at that. But I think if I ever do end up doing a video course, it's going to be an ebook first and then it's going to end up being something that goes on yeah, a companion to the ebook.

Speaker 1 10:26

That makes sense. It makes a lot of sense. So how did you decide I want to do it on Hotwire? Was it just because Hotwire is the new hotness?

Speaker 2 10:49

no-transcript. I wanted to use it with as many people and then looking for the intersection of that and what people are interested in and I was putting stuff out there and actually initially I really wanted to do something. I wanted to do an ebook on debugging Ruby, and then I put out a few things on the blog around debugging and a very small number of people liked it a lot, but in general it didn't get much attention. And I put out a few stuff on the hotwire and it got like a ton of attention. It got a lot more attention. Actually, one of the halal booking company I'm currently working with they actually read one of my blog posts where I go into deep on how morphing works and I just released how morphing works on Turbo and they basically reached out and said, oh, we need somebody to help us with the Turbo migration.

Speaker 1 11:47

That's a cool way to get a job. I wrote a blog post on a thing and a company reached out and said you sound smart, Please come work for us.

Getting Feedback and Book Structure

Speaker 2 11:54

There was a lot of interest and I started digging into it more and I liked the concept even more. So it all kind of came together to saying, okay, well, maybe I'll come back to this debugging thing again in the future from a different angle, but now this is both interesting and I see a lot of interest in it. Right, because I'm putting in now. At the moment I'm something like 150, 160 hours into working on the book in general, so it's probably going to be 200 and a bit. If I'm going to put 200 something hours into something, I would like you know that I have a reasonable idea that it's going to be useful to a reasonable number of people.

Speaker 1 12:35

One thing, and maybe it's because the notion of writing a blog post, let alone an entire ebook, terrifies me because I'm not a good writer. But like, what kind of blockers do you run into in writing an ebook, your first ebook on a topic that you have a decent command of, but you still have a lot to learn? What things have you learned that you wish you could go back and tell day one self hey, don't do this or do more of this. What kind of things really came out of writing the ebook that you were surprised to learn?

Speaker 2 13:10

I would say probably the expected blockers, like the writer's block. You've got a coder's block. There are multiple things to do to break the coder's block. There are multiple things to do to write the coder's block. Like for me, quite often if I get a coder block, I will go and I will write the tests. Right, I will go and I will start writing the unit tests. I'm like, well, let me just write down what I want this to do. And then usually when I have the test and it's read, I'm like, oh okay, well, now I know what to do and there's a bunch of other techniques.

Speaker 2 13:35

So with here it's the blank page. It's just that with a blog it's much smaller, so I can kind of just go okay, a good technique that's not invented by me but I use is imagine just that if you're answering a question where somebody has a problem you've maybe seen it somewhere Think about if it's your colleague that came to your desk and like, hey, drew, I've got this problem, what do I do with it? You would explain it to them. You wouldn't just stare at them silently until they walk away.

Speaker 1 14:06

I don't know, maybe you would. There might be a long pause while my brain worked, but yeah, so you write that down.

Speaker 2 14:13

First you write that down and then you look at it and then you kind of work with it, you shape it into what it is. And later, when I was stuck at some point I was trying to write and it was not going, at some point I just decided, okay, I'm going to put the number of words for them and I'm going to allow myself for them to be really crap words, because I know that I'm going to go back and I'm going to rework it. And I started doing that. At some point I realized this is not actually that different from coding, because quite often I'm going to hack away and I'm going to put code that I'm comfortable with, because I know that I'm going to go back, I'm going to rework it before I actually committed an open request. So I started doing that.

Speaker 2 14:54

With the writing, I'm just I'm going to today, I'm going to do this topic and I'm going to cram out 2000 words and I'm just not going to care about the quality, and that unlocked it. So I was just spitting out words going forward and that unlocked it so much for me. Like I started moving very, very fast and then I went back. When you go to edit. It was actually much, much easier, because I'm not now standing at a blank page. I'm looking at a bunch of text that I'm like I don't like this, this is bad, let me rework it. And that's how I drove through the block. So I wish I kind of made that connection in the beginning, because I wasted a few good days that I didn't put out much, I was just just mostly staring at the screen and going in circles.

Speaker 1 15:40

I feel like that's how a lot of us code just get the code working. Then you can go back, refactor it, make it pretty code, make it a little bit more cleaner, and then you might go back again and make it fast. But the step one of getting it out being the hardest part, just get it out. It doesn't matter if it's good or not.

Speaker 2 15:59

And there's a lot of analogies with writing. That's why I really like you. Yeah, get it out, refactor it. You're refactoring the text.

Speaker 1 16:05

Yeah, I guess I have a question that might sound a little odd, but I'm going to ask it anyway. English is not your first language. No language, no, croatian is. I'm Croatian, so it's a challenge for me to write anything Like half the time I need to write anything, I'm going to probably use like a dictation software so that I can talk and it will write it for me, because, whatever it is, I don't know why, but whether it's handwriting or typing, just long form writing is not my jam, but I already think in the language that I'm also writing in, and I assume that you're and this is an assumption, so tell me if I'm wrong but like you probably think in your native language and then translate it to English and then you can write it down in English. No, I've used English long enough, okay.

Speaker 2 16:55

So I started learning English in school. It's standard as the first language in Croatian schools. So I was 11 years old. I started learning English in school, just regularly, and I've been exposed to English.

Speaker 2 17:11

Like it's hard for native English speakers and I have quite a few friends for native English speakers. All the rest of us who are taking English as our second language, we have the benefit of being exposed to a ton of English content. If you were to, for example, sit down, I have a friend who lives in Zagreb, who's from Seattle originally. He's American. He came here for a short amount of time and then, as things go, met a girl, so he's still here years later. That'll get you stuck fast for a short amount of time. And then, as things go, met a girl, so he's still here years later. That'll get you stuck fast, yeah, and so he's learning. He can speak Croatian at the very sort of basic level. It took him a while, but the thing is, even for him here living in Croatia it's quite hard. But for you in US you would have to actively seek out especially Croatian, but any other language you would have to actively go out and seek out. I've been exposed to it a lot because, like a lot of the movies that we get in Croatia are because Croatia is such a small market there's only 4 million of us Our movies are not dubbed.

Speaker 2 18:09

We have subtitles. Only the kids' movies are dubbed. You can't get kids into the theater. They have to read. They can't read. So even in theaters and cinemas I'm looking at movies. When I go to theater they're in English. I just get subtitles. So I'm exposed to them a lot. And then also in high school I got a scholarship and I did two years of high school in London and there actually, it's where at some point I realized I started thinking in English when I'm speaking English. So I stopped translating and it's much, much easier.

Speaker 1 18:39

I was going to say yeah, I mean, that was something that I was thinking about. As you're talking about this. I was like, dang, this dude has to like think about something, then translate it into English which English is just such a weird language to begin with and then get to write it down Like you've got a whole extra step. I'm challenged with writing and, but turns out no, turns out you're rocking and rolling.

Speaker 2 19:00

When I'm talking to creation developers, we don't use terms in creation. We use English technical words with just the creation in between. It's like a blend Because all of the professional terms are in English. If we try to explain a programming concept purely in creation, it would be harder for us.

Speaker 1 19:19

Okay, well, my assumption blown out of the water. That's why you don't make assumptions and make it an ass out of yourself. So is there any other interesting blockers that you ran into writing the ebook that you sort of weren't expecting to hit and were fun?

Speaker 2 19:32

One of the things is the ebook has a code along project. As you go through, you implement a very simple condom board with Hotwire and I just kind of pull a thread through where I introduce concept and then you get to code it. And I keep it very simple because I want it to be just enough so that you can kind of try the concept and then move on to keep the pace. But also I want to keep the code very simple, very clean, and I did it so that you could follow along. It's all in commit. So there's a repository. The repository is actually completely public. It's on my GitHub. As you go along, I keep the repository very clean and I was like okay, well, I'm good with Git. If there's an issue that battery gets fined, I'm going to alter the history so that whoever comes and looks at it looks as if I knew exactly what.

Speaker 1 20:27

I was getting from first commit.

Speaker 2 20:29

So it really follows the bug and it's really hard. I've rebased that repository like 50, 60 times now Because when a new version of Rails, like a minor version of Rails, comes out, I want to have that. But I can't just go gem, update and then do another commit. It has to be the first commit. So I always rewind the repository, I update and then I rebase it. And then I realize when I the repository, I update and then I rebase it and then I realized I need to run when I do specs.

Speaker 2 21:00

I actually can't just run specs, I have to run specs on every commit for the specs for that iteration of the commit. So I ended up having a script where it will rewind and then it will go commit by commit and rerun the test and so on. So that was kind of more involved than I expected and it reminded me I try to keep the Git history clean but while sometimes I make like in real life I make a pragmatic choice, I'm like, okay, well, I just want to be that this is the cleanest Git history I've ever done, because I need it for the book.

Writing Process and Overcoming Blocks

Speaker 1 21:31

A clean Git history is nice to have, but like the real world, hits so fast.

Speaker 2 22:22

Yes, and it's a very simple repository. I need that for the book. I need the readers Because as you go through the book I put in references to specific commits where I'm like, oh, if you want to take off from this chapter, check out this commit, and then it's going to put you exactly in the spot where the code is to follow this specific chapter. Because I also want people to be able to go on like, oh, let me try this, what about this? And they can go on a tangent and then they can just get to the next chapter, they get this Git command and they can reset and continue following the book. That's one thing.

Speaker 2 22:55

Another thing that kind of surprised me, which is not about sort of around the book, is I'm writing it in Markdown and I'm following sort of the Git Markdown flavor and I thought, well, surely I'm just going to get something off the shelf and I'm just going to compile it into PDF and HTML.

Speaker 2 23:13

And the answer is no, nevermind.

Speaker 2 23:15

I was like, surely there's an open source project and I guess it's just it's way too niche for a useful open source.

Speaker 2 23:22

And then I went around and asked some people who have books and I researched and it turns out that actually it's mostly either you with a publisher and they have a proprietary system that they have some team that's iterating on and that just plugs into their whole framework and goes into print as well, or people have rolled their own. So, because I'm decided to be self-published for various reasons, I'm rolling my own. So for PDF I've got basically a Ruby script that does cram down and I'll use some CLI tools for converting mermaid diagrams and so on, and I also got I don't have a website yet, I have a prototype, but I've realized that it's actually more useful for people that I finish the next block of content than to get the same content in website form. So my plan is finish this now, the FOT180 part, start beta reading, hopefully in the next few weeks, and then, while I'm waiting for beta reader feedback, here's the time to prepare the website version.

Speaker 1 24:17

Yeah, that's definitely one of those things that I would have expected there to already be. A project out there like markdown to PDF. Can't be that? I mean it doesn't sound that niche, but I guess it is.

Speaker 2 24:29

So there is, but then it doesn't do everything I want. So I've got a few little things. I have got highlight boxes in Git Markdown style. I've got highlight things and I've also got code snippets that I need to format. And then I also wanted to do this custom. So I've got this reference to the repository, I've got tags on the repository, but I want to make sure that I didn't do typos. So I want to have a step where it takes and then it verifies it against the repository where it's generating the PDF, and I couldn't get all of that together, working or like okay, I want to this style a little bit differently, and also for the web.

Speaker 2 25:06

For example, basecamp put out Writebook. I think we've all seen it. For example, it's really, really nice. It has code snippets. It doesn't have mermaid diagrams. I have mermaid diagrams. Like I said, a lot of tools didn't have mermaid diagrams. So I could modify Writebook, but it's not actually open source, it's just source access. Write book, but it's not actually open source, it's just source access. So if I do it, it's something I can't put down. I can't open source that. So I decided I'm going to put the website myself. I mean, it's literally just a static website with an application in front, so it's not that complex.

Speaker 1 25:38

So you went from being a ebook author to an ebook author and a project maintainer. Yes for myself.

Speaker 2 25:44

Yeah, if it turns out nice, maybe I open source it and then somebody else can look at it to realize that it's not quite what they need and then go do their own thing.

Speaker 1 25:53

That's a cool tangent to get to go off on. It's like I'm writing a book, so I'm going to go build a thing, because we all like building things I had to stop myself.

Speaker 2 26:01

I was like, no, I have to go and write a book Priorities. I was like, oh yeah, I could do. And then this generator if I reflect on it, I'm like, no, it's generating the PDF. No, it works Stop touching it it works, it works, it works. It's generating the PDF. Go do something else Like I have to actively stop myself.

Speaker 1 26:22

I can see that Yep, been there, done that, although I feel like maybe we just spoiled a little bit or took away one of the answers, because now you have to find a different answer of what is something cool, new or interesting that you've recently learned or discovered or built, but it can't be the thing you just talked about.

Speaker 2 26:39

Okay.

Speaker 2 26:39

So I do actually have a thing very recently. I'll rewind a little bit. So in Turbo 8, the biggest thing that landed was morphing. It's very cool, but it's still got rough edges. You have to be kind of like people are running into issues and so on, and it's all about how it morphs the page, because sometimes you lose the state and that can be very painful.

Speaker 2 27:02

At the heart of it is the idiomorph algorithm that rearranges your page to match the next, and it's limited by what the browsers can do. Specifically, you can't move a node without it losing JavaScript state, or you couldn't until very, very recently, because in Chrome 1.3.3, elementmovebefore landed. It's part of the standard, but Chrome is the first one to implement it and what it does it's like insert before. So insert before is you get a DOM node and you can insert it. Parentinsertbefore you can insert it before an existing node. Movebefore you can give it a node that is somewhere on the page and you tell it to move it before a different node and the browser will move it with all of the state intact, which means that if, for example, you've got a playing YouTube video and you move it, it's not going to skip a beat, it's going to continue playing and Ideomorph actually already has support for that. They added it three months ago. They started adding it in anticipation of this being added in the browsers. So if the browser has moved before, they'll use that and if it doesn't, it's going to fall back to insert before and it fixes automatically for you without doing anything.

Speaker 2 28:24

If a browser has moved before. It means that, for example, if you had a list of YouTube videos and they're all playing and you start rearranging them, then somebody who's looking at this list in another browser and it also has the videos playing as the refresh goes through, it gets broadcasted by Turbo and the refresh is caught and Turbo does the page morph. The videos will rearrange the order but they will continue playing. Nothing will be lost. A YouTube video is just like. Why would you have a bunch of videos playing? It's the most visual example.

Managing the Codebase for the Book

Speaker 2 28:56

But it starts to come into play because you might have an interactive. Imagine if you have an interactive list and you're interacting, you've got a bunch of stimulus controllers attached to that and you've got some state in them and you're interacting with it and somebody makes a change, a morph comes in. You don't lose the state Right now with turbo and morphing. If you want to avoid losing the state, you have to do like some gymnastics you have to either make it the element permanent, or you have to listen for the morph event and then prevent it and do something yourself. Once this has wide enough support and I'm guessing after Chromium added it, it's going to be in a bunch of browsers, because a bunch of browsers are just Chromium. But after that, once Firefox and Safari added it, then we're going to have a pretty wide support for morphing being significantly less troublesome Although I think Safari might take a hot minute to do it, since Safari is the new IE.

Speaker 1 29:53

When it comes to like, hey, can we use this everywhere, not in Safari, sorry, no, yeah, that's the issue.

Speaker 2 29:58

But we can look forward to it. It's coming down the line. I'm really excited because currently like with, for example, with hollowbookingcom it's a very large and legacy website and I actually had to disable TurboDrive completely for now. I'm getting a ton of value just from TurboFrames, TurboStreams and Stimulus, but I will be able to get TurboDrive enabled. I don't know when I would be able to enable morphing on it. It's really cool when you start from scratch with it. It's very hard to retract when you add it and I think this will be a big step towards where it starts to get significantly much easier to add it to other things, because it's not going to trash your JavaScript state as much around once this is widely not adopted. So, yeah, I think that's pretty cool and, yeah, I'm kind of excited by it. I think it's very valuable for Hotwire.

Speaker 1 30:53

That is a good. What is something cool, new or interesting that you've recently learned or discovered? I like that one. Is there anything else that you want to talk about before we wrap the show up?

Speaker 2 31:04

There's one thing I wanted to comment just kind of generally, one angle of why I like Hotwire that I recently thought about. I label myself as a full-stack developer and a lot of Ruby and Razor developers do that, but if we're really being honest with ourselves, in 95% of the cases full-stack means backend and I know some from that.

Speaker 1 31:25

I'm a backend and I can center a div.

Speaker 2 31:28

Yeah, something like I said I can do a little bit of JavaScript right, I can do just enough to do a stimulus controller. I don't remember last time when I met somebody who's like, oh, they're super heavy front-end. But then I also know a little bit of back-end, and when you step aside what full stack means to the client, the thing they're really interested about is, well, can you ship this feature on your own? That's what I really care about. And Hotwire allows us to stop lying, because actually you need that little amount of front-end that it's very feasible. I can't master React, but I can master Hotwire, while still being primarily backend focused.

Speaker 1 32:08

Hotwire makes us stop lying about our frontend. Yeah, hotwire the solution to lying about being a full stack engineer. Yes, that's something I like and yeah.

Speaker 2 32:19

So for anyone interested, the book is on masterhotwirecom, my blog. You can find it on radendev. That's R-A-D-A-N. Don't be alarmed, it's going to redirect you to a different domain. It's going to redirect you to ranscouragecom.

Speaker 2 32:35

I have to migrate my domain because I had that domain for a long time and recently, when I've been finally on conferences after a long time, I realized that when I say Radon's courage, people have no idea Sure. So I had to spell it and just Radon. Usually they can get it much easier. Radoncom was taken. Apparently it's some CAD software. So I took Radondev. I'm apparently the world's most powerful metal sheet CAD software. It's called Radon. I didn't know until I went to check if I can buy the domain. I was like I really wanted it. I was like, oh, the domain is taken, let me see if I can maybe negotiate with that. I'm like, no, that's no way. So yeah, it's radondev. And for anyone going, I put a code If you use the coupon Coding Coders, you're going to get 20% off. That's just a little gift to the listeners, and thank you for enduring my rambling on this podcast.

Speaker 1 33:33

Yeah, no, I appreciate the code. Hopefully folks will use it and grab the ebook and give you lots of great feedback, both positive and negative, in the form of constructive feedback.

Speaker 2 33:44

Yes, please. Negative feedback is more useful. I like the positive but negative feedback. Actually I can act on, so please don't hold back.

Speaker 1 33:52

Actionable feedback is the best kind Cool man. Well, I really appreciate you coming on taking time out of your day to chat with us all about Hotwire and all that, and as the book is closer to completion and you learn a whole bunch more about writing an ebook, we'll have you back on to talk about all the new blockers and new things that you discovered in wrapping up an ebook.

Speaker 2 34:13

Awesome. Thank you so much for having me, and I would be super happy to be back and listeners.

Speaker 1 34:19

we'll talk to you in the next one. Bye.