The Changelog: Software Development, Open Source - Don't sleep on Ruby & Rails (Interview)

Episode Date: January 6, 2023

Welcome to 2023 — we're kicking off the year talking to Justin Searls about the state of web development and why he just might write a "You Might Not Need React" post. He's been so productive using Turbo and Stimulus (and tailwind) in Rails 7 that we had to talk about the state of Rails development today and a bunch of other fun topics around building for the web in 2023.

Okay, we're back. This is 2023. Welcome finally here. And we're back officially the very first full length episode of the change all this year. And we're talking to Justin Searles about the state of web development and why he might just write and you might not need react posts. He's been so productive using turbo and stimulus and tailwind in rail 7 that we just had to talk to him about the state of rails development today and all the cool things happening around rails and a bunch of other fun topics around building software for the web in 2023 a massive thank you to our friends and our partners fastly and fly fastly is fast so that means our pods are also fast globally. Learn more at

fastly.com. And our friends at Fly are helping us put our app and our Postgres database close to you and every other listener around the world. You guessed it, no ops required. Check them out at This episode is brought to you by Century. Build better software faster. Diagnose, fix, and optimize the performance of your code. More than a million developers in 68,000 organizations already use Century, and that includes us. Here's the easiest way to try Century. Head to century.io slash demo slash sandbox. That

is a fully functional version of Sentry that you can poke at. And best of all, our listeners get the team plan for free for three months. Head to Sentry.io and use the code changelog when you sign up. Again, Sentry.io and use the code CHANGELOG. Well, we're here with Justin from Test Double.

What's up, man? Welcome to the show. Hey, thanks so much for having me back. It's been about a decade since you last had me, and I didn't know whether to take that personally. I wouldn't do that. It was actually, we've been missing you. Yeah. Yeah, the wisdom. Bring it. Yeah, I don't know if I have wisdom so much as...

Opinions, wisdom. Yeah, I have... What's that thing we're supposed to have is strong opinions loosely held. Yeah, I've heard that one. I'm a firm holder, just constitutionally. And so I speak with zeal and passion, and I change my mind every couple of years. There we go. Well, then we have you back at a good time, because maybe your mind has changed.

Maybe it hasn't. One thing that's happened in the meantime, of course, any listener who remembered that first episode, congrats to you, I guess, for sticking around for a decade. That's right. And remembering Justin Searles was on back in the 100s, talking about linemen JS. You've also been on other shows around our network. So people can go back into the feeds and find more of Justin's strong opinions firmly held on our other episodes.

But you've also been running Test Double for a decade plus. This is a thriving dev consultancy shop. I'm not sure what y'all refer to yourselves as, but tell us about Test Double, just like size of the not sure what y'all refer to yourselves as, but tell us about test double, just like size of the company and what y'all do. Yeah. Well, um, first I got to correct the record that at really no point have I ever run the company. Uh, and so I think I credit a lot of our longevity and success, uh, to that fact, uh, my test double is really the story. Um, at least it's how we started of me me and my co-founder, Todd Kaufman.

Because he and I have, we share all these same principles and values and broad strokes opinions about this industry and the mission that we're on to improve how the world writes software. But if you looked at us from a temperament and a skill perspective, we couldn't be more different. And he's our CEO, and he's the guy who can, you know, run the company. And I, um, I used to be really good at tweeting and I've been working on that. Now I'm learning how to toot, uh, and getting back to blogging and YouTubing and all that stuff. Um, but honestly, I think that the, the thing about test double to know at this point in 2022 is we're about 105 or so, 100-ish consultants. We embed most of our engagements as a consulting company. We are embedded with engineering teams at companies who give a shit about trying to do things better. And that's

really universal. Anyone who thinks that software should be better and is striving to get better and wants some outside salt to both get stuff done, accelerate a team's ability to deliver stuff, and also leave their team better than we found it is a good partner for us. And we've got clients that really run the gamut from startups building new products to companies like GitHub and Gusto who are trying to renovate large and existing codebases in a nimble fashion. We are very adaptable to meeting our clients where they are and understanding that you've got to start somewhere. We've built a really gifted team who are skilled at hitting the ground running and understanding you know that they got to win win win hearts and minds by just showing up and doing the work and so you know i i think of us as sort of like you know we used to joke that we were like a blue collar

agile software consultancy back when people still use the word agile with some regularity it was the selling point right like the agile the agile agency, we must find Google agile agency for hire. Right. It must be a challenge running that kind of business, right? I mean, you said you don't run it admittedly, but I'm sure you're a part of how it operates and part of its success to some degree. I mean, be humble if you need to. I'm curious, is that a challenge? Like I think of like the top tiles and the placement agencies. How have you been able to survive, if not thrive, I don't know, for 10 years in a world where you've got top tile in the top 3%?

And I only say that because they're a past sponsor. We kind of know their message a bit. And that's the one I think of most when I think about a brand or a company who cares about placing software developers globally, really, like the one I think of most when I think about some, a brand or, you know, a company who cares about placing software developers globally, really in a realm of like ability to place the better ones, you know, like they've got a vetting process, a certain amount get through that process and they, you know,

engage with, you know, the get hubs and the gustos. Like how do you compete or how do you operate in a world where that exists? Well, if you went to our website, testdouble.com, which you should do, it wouldn't really tell the full story of how we're different from a staffing company or a placement firm like those or like Upwork or something. Because if you just compare our people versus other people based on hourly rate, as if you're doing an apples to apples comparison of what you're going to get. I think that's a flawed analysis because our company, what we really are is we're change agents. So if you go to Top Tail or you go to Upwork and you could take the highest

rated, you know, or rent a coder and you pull them into your organization, the best case scenario is that they onboard really well into the engineering system culture process code base that you've already built. And when you work with us, and what I think some of our best clients would tell you, is that our people change the culture that they're in for the better.

They work within your culture, and they're in it, and so they have all the context to understand ways that the team could improve or the organization could improve. But they're not of it. Our engagements are usually three to nine months long. We rotate on to the next thing. And so our consultants are driven by that mission and purpose. rotate between so many different projects, always meeting clients at really high stakes moments where they're trying to affect change in their organizations, it produces a pattern recognition machine in our brains as consultants that help us on each subsequent engagement. We show up and

we're like, oh, you know what? This rhymes with something I've seen before. Have you maybe considered this? Or, hey, I was at another client that had a similar problem. And, you know, would you be willing to give this a try? And that is a pretty big, I think, differentiator between us and a lot of other firms. And I think it's a big reason why we've been successful. Not because, you know, I've got firm opinions firmly held, but because I was able to talk a lot about them in public and attract a lot of people who've got, you know, strong opinions loosely held. And they may be able to live up to that mantra a little better than I can. So when people come to you and your teams, they've already sort of adopted or already bought into your view of the world, like what you think creates better software, or do you have to also

kind of sell them from the inside about the way you go about things? Because one thing I didn't know about you, Justin, is you do have a very specific view of things. And maybe it's changed over time. I remember maybe an older version of what it was. I could probably name a few things that I think you believe, but maybe we'll let you name off some of the things that Test Double believes in in crafting software. Is that a process that happens? Or do people come to you and they're like, we want the Test Double system? Yeah. You system. What's funny about that is if there's a spectrum, if there's two polar opposites between a staffing firm and a delivery firm that just claims to have figured out software development. We found the silver bullet. Our way is the perfect way. And when we founded the company in 2011, I was very cognizant because I was hanging out with people from Aethlite, from ThoughtBot, from HashRocket. I was hanging out at the offices of Pivotal Labs in Boulder and had some friends there.

And each of them had a different marketing strategy that basically said, we've cracked the nut on software. If you're frustrated about software, come pay us money and we will be the panacea to all these problems. Trust our people maybe up in this ivory tower who are going to hoist upon you this perfect code and you're just going to be able to pick up and run with it. And I thought that was both patently disingenuous because it doesn't respect the fact that I think software is just encoded communication between people and all parties need to be in the room working together through it. It's not like the artifact is what matters. It's the benefit is in the planning and the conversation and the shaping of that stuff. And so it's a joint collaborative exercise. And secondarily, I would look at a

company like Aethelite, which at the time had a kind of pyramid-shaped engineering progression scheme. I think I saw a diagram of this once with you're all craftsmen. And then the top was the master craftsman, and that was Uncle Bob, who was one of the owners in the company at the time. And I just remember thinking as somebody who likes, if I'm not humble, I at least like self-deprecating humor. I was like, I can't start a company, put me at the top of the pyramid, and then tell everyone that they've got to do things or think things the way that I would do. Because a big part of me and my co-founder Todd's ideology is inspired by D.W DW Deming, which is like in the Toyota production system, you've got to trust the people closest to the work to make the right decision. So if there's some talking head up in the clouds like me on Twitter saying like, no, this is how all your

tests should look, then it robs the team of being able to actually like look at their situation with all the rich context that they have and like make the right decision. And so I would say even from our first hire in 2012 and onward, there's always been a very healthy disrespect of Justin's ideas and takes. I'm more meaning to share them to be an exemplar of what it looks like to care a great deal about this craft and the journey that we go on as humans to kind of build, build great things together. Wow. Well said.

Great job. That's a great base to build from, honestly. I mean, to have that kind of, I mean, it is humble and it is self-deprecating in terms of humor, but I think that's a great base to build from because you need to, I like the idea of trusting the people that's closest to the work to have that rich context, as you said, to make the good decision versus somebody who's so far removed and potentially even domain-wise on something completely different. And your current thought may not translate well, so why would you disable them?

You've also stayed in the weeds for the most part, haven't you, over the years? I feel like maybe you're not, I don't know, you can tell us, maybe you're not deployed on specific projects and stuff, but I've seen you continually presenting your ideas in the public, showing real code, working on side projects, doing stuff that is real. And so while you don't want to have the ivory tower, Justin's, here's how we do things, I think it'd probably be fun working in your orgs because you probably do have to represent your ideas and let the truth come out through the discussion, through code, through argumentation. Do you feel like you've

stayed relevant over the decade? Or are you one of the people that's close to the problem or no? It's a great question. And I think that the answer kind of lies in my joking description that we were like a blue collar agile consultancy. A big reason that that answer kind of lies in my joking description that we were like a blue collar agile consultancy. Like a big reason that that was top of mind for me was I was seeing a lot of capital T, capital L thought leaders just slowly veer away from anything that looked pragmatic to just sort of becoming an echo chamber. It's a big reason why, you know, we'd never called ourselves like a capital A agile consultancy at any point, right? I'm not sure it was ever on the website, even the word. And if you think you've got it all figured out, then what ends up inevitably happening is you will be met with circumstances

for which like your prescription or your favorite way of doing things is not a good fit. Maybe it's no longer a good fit because the industry has changed, or maybe it was never a good fit for this kind of particular circumstance that you just hadn't run into before. And every time we as practitioners run into something like that, we have a choice. We can either dig our heels in and try to force the problem to be shaped like the solution that we like, or we can adapt and try something new. And maybe it'll have pieces of other solutions that we've seen in the past. But every single problem is a new one. And as a result, for me in my own practice, I'm very sensitive to the idea that if I just go off and speak at 25 conferences a year, or at least in the before time when there were that many conferences, if I just talk and talk

and talk, eventually I will lose touch of the work. And so I had a very fortunate, several very fortunate mentors early in my career. And one of them told me that everyone goes through seasons in their career. You know, we like to think of it as a progression. It's a step ladder that you're just like, okay, I'm senior one and now I'm senior two. And then, uh, you know, we've had all these kind of titles promulgate over recent years. Now I'm staff and now I'm principal. And like, that's the track. I think of it instead as in this season of my life, this three months or six months, I'm going to go heads down, sit really close to the ground and really listen for the pain points that I'm experiencing or that this team is experiencing. And I'm going to take notes.

And then, you know, Jared, when I went to speak at your conference at NEJS in Omaha, a big, what, what those events were for me was a chance for me to plant a flag in the ground and look back over the last six months of my life and say, what did I learn? Was it worth it? Like what, what from this experience that I just had might be useful for somebody else? And surely there's something, right? And there have been times when there really was nothing. And that's separate feedback about how am I spending my time and what am I choosing to focus on? And so what I've been doing this year has been to take dedicated time to build custom applications inside of our company at Test Double that a scaling business now

needs. You're a 100-person company. We've got a bespoke approach to how we staff people onto engagements to make sure that the client gets what they need and the people get what they need. And by building that, I've observed so many cool things about both new tools that are great as well as popular things that I think aren't so great. And that's the opportunity or that sewing gives me the opportunity to reap those sort of opinions from a more informed place where I can actually play ball with other people instead of just kind of talk at them. Yeah. Well, I think that's a great setup because that's kind of what we have you here to talk about to a certain extent today is some of your findings and some of your gleanings and learnings and thoughts about the state of web development,

about Ruby on Rails. I think there's some setup to this particular conversation. A few things. The first one is over the summer we did an episode, Adam, what was it called? A new set of web frameworks emerge, something like that. Where it was actually a trifecta, a sampler platter, I think we called it, of JS Party episodes

where we had interviews with Astro, Fred K. Schott from Astro, Mishko Hevery from Quick, and Luca Casanato from Dino's Fresh framework. And I was on one of those three original JS Party episodes and therefore was on the show. And one thing I said about Fresh at the time was, it seems like finally for me as a person who has roots in Ruby and Rails was my first big framework, if you don't count WordPress, which is where I really started, was Ruby on Rails. And then the Node thing exploded and we went kind of that direction as many of us did.

It seemed like the JavaScript community was kind of starting to finally come around and accepting that like a batteries included, full stack framework can be a good idea, can be a good thing versus the small libraries, you know, piecemealing everything together for yourself, which has kind of been the ethos of the JavaScript world. After listening to that show, we had a lot of feedback, some tweets,

kind of like saying Rails devs are out here listening to Dino team talk about Fresh and talk about some of these other things. It's like the Rails devs are out here kind of rolling our eyes because we've been here for a while. We've had this and Rails isn't cool anymore or whatever. People have to rediscover stuff Rails've been here for a while you know we've had this and rails isn't cool anymore or whatever and so like people have to rediscover stuff rails has been doing for a long time was kind of a part of the reaction to that um and then you had a post a tweet which today would have been toot but it was a tweet at the time which caught my eye and you said i've been so productive since getting up to speed on turbo and stimulus

which are parts of or sub components of a modern rail stack plus tailwind is your parentheses in rail seven that i'm at serious risk of writing a quote you might not need react blog post hold me back hold me back and i don't know if you ever wrote that post, but I replied. I said, sometimes just coming on a podcast and talking about it is like just as even more fun, right? Like none of the pain of writing and to which led to this conversation. So we've wanted to do kind of a rails catch up kind of an episode for a while. Adam and I have had in kind of in our list of things to do and didn't really see opportunity. And then your, your comments, I was like, okay, Justin's obviously feeling things about productivity with rails, with a modern rails set up versus some of the stuff you've been doing. Otherwise,

I guess react is the, the one named. So let's talk about it. Let's talk about where rails is. Let's talk about what's exciting and new or what it's good at, what it's gotten better at, maybe where it still fails, and how that compares to some of the other offerings out there in modern web dev land. So that's a whole lot of words. I will now stop talking and ask you to respond. Maybe give a little bit of your most recent experience

with what tools you've been using lately to build stuff inside of test double or otherwise. Yeah. Now as a contrarian with a lot of opinions, I have an inclination very often when I'm asked a question to ask if I can like answer a different question instead to start, which is to say I would, I would love to,

if it's okay. As a longtime podcast host, I say, no, you have to answer my question as asked. He's kidding. I'm kidding. Can we back up and just sort of set the table a little bit?

Because I'm sure everyone who's listening to this is coming to this conversation with different experience over the last X years. If you don't know me and you're just meeting me now, hi, hello. In the Ruby world, I was always sort of the outsider looking in for a long time. I helped start a Ruby meetup in 2006. We had an event.

I asked some hard questions about how Rails was working, and I was like, you know what? Screw this. And I went and worked in Enterprise Java for a few years. In my very first conference talk at RailsConf, the national Rails conference in Chicago, I think in the spring of 2014, it was a talk about why Rails was not meeting the moment of front-end JavaScript and single-page applications and rich user interfaces using JavaScript, and how you could marry the Lineman.js tool, which is incidentally what we talked about 10 years ago, with Rails to almost bifurcate your system between

a backend API and a frontend static site generator that you'd build your UI with. And a couple years later, I think it was the day as I became more enmeshed in Ruby land, gave a keynote at RailsConf. Later that day on the exhibition floor, me and DHH just had it out in the open like a 90-minute long debate. A crowd was gathering. If you've ever seen the music video, beat it. It was kind of like that.

But we actually, all in good fun, and it was a healthy debate about full-blown front-end static single-page applications versus what we used to call Rails views, server-side rendered HTML with JavaScript sprinkles on top, which is the pejorative way to put it. So just to be clear, I spent a lot of time on the other side of the fence here. The way in my mental model that I thought about the problem at the time and that I think I still think about the problem, the through line, is that in 2014, if I wanted to build an application with an interesting user interface, with drag and drop, or with simple actions not requiring a full-blown page refresh, you could start any application. I viewed it like a chasm, like the size of the mountain that I could build of an application

in terms of dynamism and user interactivity. And that stuff was possible to do with just pure Rails. But at some point, if my product owner or somebody else were to say, hey, and I need this, you know, I need an interactive map view for putting all of these like work orders on it. Then at that point I would just groan because now the JavaScript sprinkles would become too big, you know, and I have a backbone app at the time or whatever it is. And it would just be, it would create all this mess. And there's no easy way to go from, I'm an application that's a server-side rendered HTML template with a bunch of JavaScript sprinkles to wave a magic wand. Now I'm a fully formed, robust backend API plus logically organized frontend user interface application. There's this chasm in the middle where it's just so hard to jump from one to the other that my advice at the time was, if you think that there's any chance at all

that in the reasonable future, next couple, two, three years of development, that you might need that richer user interface, just let's make it really easy on day one to separate the two activities and just build APIs that talk to JavaScript front ends. All of that to say, I think that what's happened in the last few years is that

first Phoenix and LiveView and then in the Elixir stack, and then in the Ruby world, Rails and what they call Hotwire, which is really kind of a combination of a tool called Turbo, which does partial page refreshes and other kind of like navigation tricks to make sites that are actually phoning home and getting like you know fully formed html from the server but they're doing it over a web socket and it all feels very fast but me as a developer as far as i know i'm just designing these server-side templates just like i always was and stimulus which is a a very rails very Rails-aware, if not literally aware, like it's definitely in on the gag of how to bind events and actions to small, little, tiny, focused JavaScript functions and classes that themselves are arranged in a hierarchical way that mirrors the DOM.

So as I'm building out the DOM, I think David at some point has said the DOM is kind as I'm building out the DOM, I think David at some point has said the DOM is kind of in his mental model of an application, like the single source of truth. Turbo respects that because you're dealing with just sort of sub fragments of the DOM, and stimulus respects that because you're binding to sub fragments

of the DOM. And just like React taught us, as long as you're really rigorous about that approach to thinking about you're just snipping this subtree and swapping in a new subtree and letting the browser be efficient at repainting stuff, it moves the locus of control several notches further towards the server side, such that now when I think about this little tiny molehill of what I, seven years ago, was able to build with a Ruby on Rails

application. Now I can go way further. I can build, if you've seen the Hey email web client, it's basically Gmail in terms of its user interface. It's got lots of goodies. It's got a lot of very dynamic user interface features that we used to associate with single page application development. That's the only way to do it. And now what I'm saying is that like, there is still a gap. If you're building like a, an in-browser music player, right? Like with, with all sorts of, you know, very app like stuff, then yeah, you probably should be reaching for a single page application framework to build a true front end with an API back end. But if you're building what most businesses are building, which is not to be condescending about

it, but glorified CRUD apps with some cool components here and there, suddenly just pure Rails with stimulus and very, very few JavaScript dependencies is actually really appealing and completely enough, has been my experience over the last few months of working with the tools. This episode is brought to you by our friends at Square, developed on the platform that sellers trust. Here's what you can do with Square. You can bridge more experiences.

You can build online, mobile, and in-person commerce experiences that connect more customers and sellers. You can build custom booking solutions. You can create and track orders. You can accept payments. You can manage and curate inventory. You can organize customers. You can manage employees. You can extend Square gift cards to your app. You can use and curate inventory. You can organize customers. You can manage employees. You can extend Square gift cards to your app.

You can use Afterpay. And all this is powered by the world-class Square APIs and SDKs that enable you to build full-featured business apps for yourself or millions of Square sellers. So much is available as a Square Solutions partner. Learn more and get started at changelog.com slash square. Again, changelog.com slash square. Again, changelog.com slash square. So, when we compare, I guess, this stimulus library, and let's just focus in on that one, because I guess it's kind of where you work inside of the DOM, right? Where you're actually firing functions based on events and actions and what have you to me conceptually where i think react changed the game conceptually was the declarative nature of just defining what your component looks

like at the end of the day and then giving it certain ways of changing to get to that place and not worrying about anything else that That singular direction of mental model, I think is why, I think that's why React took off. And you can respond to that as well. And I wonder how much stimulus goes back to this feeling of like, well, it's better than Backbone, but you're still kind of just hooking up event handlers to click actions and fire and stuff, which I build web apps that way. I got no problem with it, but I know that as my web apps that I built that way get bigger and bigger, it gets more and more unwieldy. So maybe respond to the React paradigm versus this.

Yeah. Well, I mentioned one aspect, you know, when we were talking about Shadow DOM all the time when React was brand new and stuff. the reason that I think React was successful where Ember wasn't, for anyone listening, Ember was in a hot competition with React as like the thing to come after, you know, the 18 other frameworks that had preceded them, was that Ember really nailed like bidirectional data binding, right? For to make a better jQuery, like a sane approach to organizing applications that way. And where React, I think, agree with, totally agree, shine was the unidirectionality of data flows from a source of truth, and it lands on the page, and it doesn't go back from the page and upstream again, right?

I actually think that stimulus and turbo, when you work with them in concert, provides roughly the same effect. Because at the end of the day, if you look at React early days or now, the tricky bit is always state. When state changes, what happens? And who's tracking all the state? And with Rails and with the DOM, the answer is anytime state materially changes for anything that isn't totally ephemera the answer is you phone home and you get new html from the server over a web socket and the model that the controller is dealing with represents the new state and so this that it is unidirectional much in the same way where it is and it's also declarative in the same way in that like all of the stimulus binding stuff

is not happening manually it's through you know data the same way in that all of the stimulus binding stuff is not happening manually. It's through data attributes that you're decorating onto the HTML as you normally would. And so what the stimulus is really doing is strictly just saying, what do I kick off when somebody clicks on this? Or when I have a data attribute that has a particular value associated with it, when that value changes somewhere, how do I react to that? And it's not, you can totally still write the sort of like simple click handler, kind of like holding a lot of state in your head in the front end browser style of code. But if you spend the time to kind of shift your mindset a little bit and think in that unidirectional way, like if your brain's already been reprogrammed to think that way about React, then I would just replace the top node of your React application with locating that in the server-side router. And it's going to go to the controller, and then it's going to go render the

markup. And maybe it's only rendering a single little tiny div, but because of the optimizations that the framework takes care of for you, that's going to be done performantly because it's going to happen over you know a live a web socket connection that makes sense to me i think we have an allergic reaction as a industry to html over the wire like there's like something where it's like that's not pure it feels impure yeah is there something is there more to it or is it just like, that's not pure. It feels impure. Yeah. Is there more to it? Or is it just like there's a purity? I know as developers, we get idealistic, right? We have a purism that we desire. And then there's pragmatism. And we try to find somewhere in the middle

where we can be productive. Is there more to it? Like, are there valid reasons why sending HTML over the wire is a bad idea? Or is it just because it's not a data interchange format? Or I don't know. What do you think I am always so I should put on the table first that as a developer I I have a just a real

strong streak of believing that there is one true righteous answer to every problem and I have to temper that a lot because what I've learned through nurture, I suppose, over the course of my career is that there is just like there's infinitely many bad ways to do something in software. There's also infinitely many right answers. And a lot of the times the perfect right answer of, you know, pure functions and, uh, you know, unidirectional data flows and proper interchange formats that adhere to some kind of protocol or fit into some gigantic architecture

such that any two services in our enterprise could theoretically talk together, even though they all flow in just this one kind of tree-shaped direction, just like everyone else's services do. When you give in to thinking that that is going to be the solution to the problem of, boy, software is hard. It's hard to manage a bunch of complexity

and get everyone to agree about what this thing should do. Then I worry sometimes about, you said allergic reaction. I think that's the right answer. I worry about the allergic reaction that develops of an impure solution that like maybe is good enough and maybe is way faster to implement and actually, you know, like doesn't have a practical reason to be bad other than it feels bad and it doesn't suit my fancy of being, you know, being mathematically provable as correct. And that's where I had the same initial revulsion. I spent a long time before getting serious about trying turbo and stimulus.

I let it simmer for a couple of years before I really tried it in anger this summer. And the truth is, just like Rails itself was a pragmatic thing that was willing to say, you know what, all this stuff that your DBAs do with your databases and all the fancy keys and referential integrity, it kind of doesn't matter. Just treat the database like a hash and figure out the rest later. That was the thing that ejected me from the Rails community when I was much younger. And here, it's the same sort of thing where, in fact, that HTML over the wire thing, if you're actually using the framework and trusting it, once you get going, it's an implementation detail. I think I messed up and called it something else

a couple times to even remember that it's actually a WebSocket connection that is actually pushing HTML over a pipe because you just don't think about it because it just sort of just works. So here's a response to that. So I had this conversation, a similar conversation with Tom Preston Warner on JS Party,

talking about Redwood, which is GraphQL and SPAs. Well, okay, it's more complicated than that, but let's just say he believes in a strong API layer. We'll just say that. And his response to me when I said, kind of HTML over the wire, can't we just do it the traditional way? We have tools to get over a lot of the humps.

Obviously, there's times where you might need something else. But he said, it's all well and good until you have multiple clients. And once you have multiple clients, like for instance, we know we're going to have an iOS app. We're going to have a website and we might have a command line tool, etc. Now you're kind of stuck if you went this direction. Whereas if you went the other direction with a GraphQL API, for instance, and multiple clients, you're at least set up for that very possible reality for many people. Do you find that's the case? Is there a time where it's like, I think there's a lot of businesses

that think immediately, like I tend to get on the Yagney side of this argument. I'm not sure where you're land, but I feel like there's a lot of businesses that, you know, they do get some success and then they do want to go in these other directions. And then they're like, well,

do we like rewrite a whole new thing? Do we have to go back and re-architect our backend, et cetera? Do we bolt on a restful rails API, which in my experience has never been as easy as the sales pitch for Rails APIs? So yeah, his response to that was multi-client breaks that argument. What do you think about that? I think there's a couple worthwhile reactions.

One is when we say multi-client, we're mostly talking about phone apps. And the industry has changed quite a lot since the app stores were new, where to build any application at all would have required not only an API, talking to native Objective-C code or Java and Android LAN, but it would have to really sip the data

because the computing constraints were so narrow. And now we're in this other world where, if anything, with tools like React Native and with the advent of much more mature UI frameworks for those different clients, I'm not as concerned as I used to be about that exact question. It was something I worried a lot about in 2014 when I was thinking about like when you need an iPhone app, because everyone was like building those. And now what it is is, oh, it turns out that like we can actually run pretty far afield with just like, you know, really responsive web design and a mobile website. And if you need a, an application, nowadays when I talk to clients or prospective clients for Test Double, it's almost always not that I need my entire gigantic website of 800 controllers and every single thing that you could possibly do through

the web. It's I have a very specific use case where these people who are doing site inspections need to check for these particular things and they need to be able to scan barcodes really quickly and they need to be able to do this or that. And so the scope of functionality that's needed by mobile applications tends to be much narrower and it tends to come much later in the life cycle of applications than it did 10 years ago. And you asked me a bit ago, I seem to be coding a lot. Like, why is that? Like one big reason is I don't believe I'm not a believer in progress. I'm not a believer that like this industry is getting better over time and like innovation is happening. Cause when you're outside tech, everyone's like, Oh, look at

like, we're getting smarter and hotter all the time. And like all these new technologies are coming out and it's great. Like, I honestly feel like in many ways the industry has regressed since I joined it. And it's worth thinking about when we ask questions like this one of that may be what Tom shared is completely conceptually true. that you're going to need to build both a web client and two native mobile applications and maybe some third client on day one or near day one with full-fledged functionality. Even as I say that, I struggle to even think of how often I've seen that in recent years. And so I would instead say, if somebody had that consternation or that frustration, I would say, well, if you've got a small team and they're careful and they're experts, for example, when I do a Rails application in this way, the controller is kind of the controller in terms of like, you know, it's going to, my search feature is going to like take a query string from users and then it's going to go and figure out what are the results. And then it's going to call stuff that does all that hard work for me. And then the last little line is just going to like

render a template from that piece of data. And I could just as easily respond to a JSON format or header and just convert that to JSON and have like a quick presenter just do that. And in well factored Rails applications, while yes, building the whole separate API as a bunch of separate endpoints really never works because you end up with two code paths doing the same thing. You're really careful about being rigorous in how we structure the data that flows into the templates. The controller and the route is asking the same question. The inputs are the same arguments that might modify the answer. And then the answer is factored in a way that it's the same question. The inputs are the same arguments that might modify the answer. And then the answer is factored in a way that it's the same answer, it's just different shapes to present it

to the client. And so I've had really good luck of doing exactly what you've struggled with, and I've seen a lot of teams struggle with, of just, okay, cool, well, this particular set of routes needs an API response now, so be able to respond to JSON requests as well as to web requests. In fact, Turbo, which I've been talking about, has a TurboStream feature where those action cable little partial page snippets are also just another kind of request. It just goes through the same templating. It just knows it's only a document fragment instead of the whole document. So that's, I think, more functional than going whole hog on day one and saying, you know what, we just need a full-fledged API.

It's just like saying we need microservices on day one or something like that because we're afraid that in the future we're going to have more complexity. Sure, sure. Yeah, in my experience, and I don't have that much, I probably have like two or three go-arounds on that. It's that what happens with the, well, we can just take this controller action

and we can render it to JSON with a slightly different presenter and all as well, is that it seems like the phone client or whatever the second client is, ends up needing at any particular endpoint dramatically different representations of the data in order to do its job that it feels like, well, I'm just basically building two.

And so I can't actually just say.json and roll. I have to create an endpoint for this because the shape of the data is way different than that matching web page. So that was my experience. And you're making the point for me that it's easy to talk on a podcast about everyone's experiences

and then stake a claim that I've got this figured out. But the truth is I am very confident if Jared and I were to sit down and try to solve a problem and spend a few weeks on something, that by the end of that few weeks, we'd have something working. And there'd be zero surprises. And we'd both feel good about it. So there are cases where that's 100% true and vice versa. It really depends on the context.

Yeah. This feeling that you have of not progression but regression instead what where's that come from how does it manifest in actuality examples give us examples yeah so i think of it i think of it in terms of like a sine wave sort of is like how the industry it might get better overall over time but the we go through these cyclic patterns and when you've been through a few of them, uh, it's hard not to see them. And when you've come out the other end of a few of them, it's hard not to become a little bit jaded about it because it sort of feels like we're not going anywhere. Like we're just walking in circles. I'm not there yet. I'm not jaded and I'm not

cynical about the industry. But when I hear an example, like when I was coming out of college and I was working in big enterprise Java stuff, there was a lot of J2EE, Java 2 Enterprise Edition, which I think they kept calling J2EE until Java 5 came out. It was such a complex, burdensome, multi-person, the whole, everything about it was this assumption that you're going to need 18 layers of striation to do a hello world, to build the most basic application. And the answer to the question, why do we need this is, well, someday when you're, when you're a big application, you're going to need to be able to do that. Or if you're like IBM or BEA or Oracle who are selling these things,

the answer was, well, our proprietary Java application server has some feature like hot swapping the application in production without having to restart any servers or something. And in order to do that, it has to be packaged in a certain way. And at really high scale, you just need that. And so that's why we have these architectural decisions. And I pushed back against that. And so how I got into JavaScript front-end development was I was working in those environments, and I was like, nope, I need to move a lot faster. And so I was just building full-blown applications

in JavaScript and just sipping data however I could to get the user interface the way that the customer needed. And I think that that spirit of eclectic set of small tools solving very specific problems of the JavaScript open source world, as much as people look back and see all this churn as we moved from framework to framework and tool to tool, there was a certain pragmatism about, look at all this stuff that i can solve and bypass

the really silly complex machinations of my enterprise because they just literally don't care about what happens in the front end because it doesn't matter but what when i say like there's cycles like i get my years mixed up because it's bleeding together a little bit but like once react became dominant and once you started seeing Amazon and Google, in addition to Facebook really start to push open source, like their favorite open source tools through like, you know, paying developer evangelists to kind of like, you know, just press the flesh at conferences around the world and convince everybody that like, you know, no matter what scale you are, the answer is Kubernetes or like our favorite, you know, tool for, you know, just coincidentally

plugging into our, you know, cloud computing platform. Right. So that's why we want you to go serverless on our servers, you know? So there was a sort of enterprise of vacation of open source that occurred by just marketing really heavily towards the same impulses that, you know, you're expressing like, well, you know, like I might need it someday and I don't want to throw all this out. And so it's, you know, if it works well for Facebook, you know, using create react app and pulling in, you know, at a given point in time, hundreds of small dependencies, then surely it's, that's good enough for me. Or that's good enough for me or that's enough for me without thought of, well, Facebook has a much larger group of people pouring over those

dependencies and keeping them updated. And the complexity that you see now in front-end applications looks more to me like the average front-end application. Of course, you can write really lean ones. I strive to with very minimal dependencies, but the average one, the average team, they just have this, it's a disposition and a temperament towards looking to an authority and pulling in tools, external tools, wherever possible to solve problems. And the people who are kind of, you know, the loudest voices in that community are trying to solve problems at Facebook scale, Google scale, Amazon scale. And if you're just some startup, you just, it is the agony. You're not going to need a lot of that stuff. Definitely not now, maybe not ever, but you're either way saddling yourself with that level of complexity. Yeah. I've heard of progress described, you know, we think of it

as maybe a ladder or some sort of vertical ascent, right? Like maybe it's rocky or whatever, you're going up a mountain, but I've heard it described and it kind of matches your description to a certain extent, more as a helix where you're actually like circling something and you're slowly like going upward as the helix does make progress, but it's way slower than you think it is as you're just right there. You think you're going up this mountain and you end up doing a lot of the same stuff over and over again. And maybe you revisit the same concepts, but now it's five years later and there's different tools

and different capabilities. And so it's a little bit better than it was last time we were here, but here we are again. And I've also been in this industry for a long time now. And I've seen a lot of things, a come and go, but also come and then go and then come again. And a lot of excitement about stuff that isn't new ideas it's just newly discovered same ideas and so that can get for the next generation right yeah like the the this industry so many developers enter the industry every year and so many leave that like we basically replace ourselves every three years so it's no wonder that some some hot take some smart some smart wisdom that i had a few years ago no one's even heard it right

because like so many people come into this industry that i think we have to relearn a lot of lessons regardless i love the spiral staircase idea i think that there's a lot of truth in it but for anyone listening to this conversation you know at best i can offer up this sort of like amateurish prognostication about like what I've seen the industry doing, but how I bring it home and how I think it's, I make it relevant in my existence as a developer who's moving through it is I think about that helix. I think about that cyclic nature of gradual improvement through my own practice of each app I build, each thing I do, each time I solve a particular kind of problem is a new opportunity for me to do it just a little bit better and to like learn from last time. And the more cognizant I am of that and the more careful I am about like thinking about how I think about

things, the firmer footing and the more steady progress I have to actually get better each time. And that's something that if you can achieve that for yourself as an individual, and as somebody who consumes and lives in like the kind of information ecosystem that we all do as developers, I think that you also develop a reflex to know what you're looking at when some new splashy landing page, you know, of some new open source tool that's going to save us all. When that lands, you'll be able to read that and look at the different heuristics to tell you whether it's still going to be around in a year and whether it's going to actually make your situation better or just be the 17th tool in your stack.

One of the founding principles of this podcast has been to be not the Ruby show, not the JavaScript show, not the Kubernetes show, not the like our services. So you pick your buzzword, you know, and, and throw it in their show. It's been the show to look over the fence at all the cool things happening

throughout the industry, throughout software and see how they apply pretty much anywhere. And I, I wonder if, if we're in this chasing cool issue i don't know what to call it necessarily like you know there's a lot of cool things happening in the javascript world but there's a lot of really sturdy stable capable things in the ruby world and i i wonder, I thought maybe a part of your answer would have been the chasing cool. People are so focused on chasing cool and iterating that they forget to look at what's really stable, say, not just in the Ruby world, but elsewhere, that they keep

returning and recreating only to come back to where we've been. But it's not JavaScript, it's Ruby, so it's not cool. You raise a really good point. I think of this often in terms of life cycles of language ecosystems or tool ecosystems where the temperament and the disposition of an early adopter. None of these trails have been blazed. Maybe I have to produce a lot of open source on my own just to get the very basic stuff done versus somebody who, you know, very late in the process might be like, well, there's no such thing as a greenfield development of a Pearl crud apps anymore. So every new project that I get, I actually love it because it's a

chance for me to treat each project as a puzzle box to kind of like crack the nut and figure out how do I continue to make forward progress in this world of a stagnant ecosystem. Sorry to any Pearl enthusiasts. It's something that I think about in those terms probably a little bit more because we all, I think, will mature over the course of our careers and just go through different modes of sometimes I'm really excitable about a new technology and it's splashy and it's fun and it totally unlocks something for me. Other times I'm just trying to get something done. If you want to categorize it into two buckets, I think that we have technologists who are really in the game. They're just here for the music.

They want to be on the cutting edge and see the next thing and be there. What I have strived to do, when I think of the best moments I've had in my career, it's actually not thinking of the technology as an ends, but as a means to doing something else, to helping people, to sitting with a product owner who wants to solve a problem with software. I just take that bevy of technology experience

and I figure out, if it's a business, how do I make it make or save that business money through deploying the software? Well, where if you start thinking about technology as a means, as opposed to an ends, then of course the pragmatic solutions are going to rise to the top because you don't, you're not there to waste their time or yours to solve the problem. And that's where I try to spend more and more of my time is, where can I help bridge that gap where I'm both engaging with new technology, innovation, ways to think, not fall into that sort of cynical, stodgy old man yells at cloud persona that I sometimes play on mastodon.cloud or social.

Mastodon.social. Oh man, I should probably know the domain name of where I took it. Oh, he doesn't even know his instance. Come on. Got a mastodon noob over here. The big one.cloud or social. Mastodon.social. Oh, man, I should probably know the domain name of where I took it. Oh, he doesn't even know his instance. Come on. Got a Mastodon noob over here. The big one. Yeah. Yeah.

You can find me at justin.searles.co. That is a URL that will exist for a while, and it links to all of my, whatever my Mastodon is. I'll figure that out eventually. But that's, you know, I'm kind of curious if that adam is does that resonate with you based on where you were when you were asking that question yeah i mean i think well i'm kind of grokking what i think the undercurrent of your tweet might be even which was maybe you were not paying attention to, and you said you used,

I think you said you used Turbo and Stimulus out of anger even, less with blinders. So maybe your lack of usage and desire to steep deeply in it and determine whether or not if it would work for you and the kind of applications you build and the style you build them, I wonder if there's a part of the world that just simply has blinders on to because it's not javascript you know they won't look at the other side of the fence to say okay well i i could use that or that is actually really productive because it's only javascript or because it's because it's ruby and that isn't cool anymore that's that's kind of like to some

degree the world has said that ruby isn't cool anymore even though it's highly capable very stable etc etc i wonder if that's part of your undercurrent there because you said you're almost serious about writing you may not need react so it's almost as if you you kind of played a double part there where you did it out of anger, then you steeped yourself in it and you found it was pretty productive, et cetera, et cetera. I wonder if there's a population that were out there that just doesn't look at it at all because of blinders. A Ruby hero of mine is the late Jim Wyrick.

And he used to say that you don't really know a technology until you've used it in anger. And when I say I use something in anger, what I mean is I'm the dog who caught the car, and I'm holding onto that bumper for dear life, and I'm going to build this thing, damn it, one way or another. And so I'm going to go through the hard parts, and I'm going to come out the other end, and then I will have an honest appraisal of whether or not other people should use it too. Because it's the only way to really know, I think, whether the tool is going to work.

And to the point about JavaScript, it's interesting because JavaScript has been the trendy thing for so long. And the ecosystem, it's more of an ecosystem than a community, because everyone needs it. It's the lingua franca of the web, that you can spend your entire career there. And you could get lost for years and years and years in just JavaScript land and keep yourself completely busy and have a wonderful time and career but i'm fortunate looking back on you know just how much both like boutique like languages as well as just competition among primary languages there was when i was coming of age as a programmer because i first language i really felt like i got and understood deeply was Java.

And when I understood Java, I identified as I'm a Java developer and I want to find every solution I can in Java. But then once I cracked the nut on a second language and then a third, then I was able to relax that a little bit and think more in terms of what is the stack getting me, how do I feel, what kind of teams are successful or not successful with a particular technology. And I would wish that for anybody. So even if you spend a lot of time in JavaScript land,

trying to solve something in a radically different technology stack is just good life experience because it frees your mind, it liberates you from thinking that every solution has got to be JavaScript. Because frankly, you mentioned Ruby not being cool anymore. We joke about this sometimes internally at my company. We had a period of tons and tons of Node.js and server-side rendered React projects come through

in 2016 to 2018. But then they started to trickle off. And then we had a bunch of really, really massive companies invest in renovating their Rails apps because they tried either building a whole bunch of microservices and breaking up their monolith, or they tried rewriting their entire interface in front-end React, and they saw how much extra work that was

than I think Jared used the phrase batteries included earlier. They're like, it's actually much cheaper for us to upgrade from Rails 3.2 to Rails 7 and get up to speed. That's a jump. Actually, Test Double has done a lot of upgrade projects and we've got a whole knowledge base. That's four versions in the middle there, Justin.

That's a big jump. Yeah, of how to do that. You can check our blog for some advice. But now today, we're at the point where there's probably more Ruby developers getting paid to write Ruby and Rails applications than at any point ever. But we show up on Hacker News less and less because a lot of this stuff's been solved and it's less noisy and it's less public. But it's still making a lot of people a lot of money, I think.

It's an interesting time, too, because there's a lot of layoffs. I saw this one thing where somebody had, I'll paraphrase their scenario because it's not necessary for the conversation here, but they wanted to now take their new focus because their focus has changed and focus on founders and mental health. And the reason why was because there's gonna be a lot more founders out there because of all the layoffs and all the change in the job market. And actually, there's the people who don't want to go and work with these big companies anymore because of whatever the reasons are. I just wonder if there's some sort of gem, let's say, inside the Ruby world

that is not visible to folks because they just haven't because of the label, it's not cool anymore, even though I still think it's cool. I wonder if that's just taking people away from this cool land and that kind of thing where hey if you're in that space or whatever maybe maybe just go out there and build a rails project as a hobby project and realize what's still there I wonder if that's a this might be a good time for that I think layoffs are always concerning even just talk about them like if you look at all these press releases about layoffs, the vast majority aren't pointing

to actual economic conditions or business constraints. It's worry about what people are talking about. It's investor sentiment is what's driving a lot of it. But we're not immune as individuals because we're either affected by those layoffs or we think about, me as a developer, am I going to be affected or impacted? Or if I am, will I be able to find something? And what I can tell you as a consultant who has seen several cycles and come in that company, generally when we're helping companies, it's a really interesting time for the company, good or bad. That's why they're bringing in outside help. And the one thing that I guarantee for you as a professional

that's going to be recession-proof is an ability to solve people's problems that generate more value than your cost. And pragmatic tools are the name of the game in being able to demonstrate that repeatedly and to have a big impact and to leave a good taste in people's mouth when they work with you. And so if you have a sort of this mathematical purity approach to technology, or if you have a, an arm's length, sort of like if you're, if you're in an organization right now where you can't explain how the thing that you do makes or saves the company money. Like somebody else is probably also struggling to answer that question. And maybe you're right to be concerned, but if you, if you

want to be able to independently full stack, just build stuff, that's just sweet and rocks and does cool stuff. That is what I think the Ruby and rails community has been. That has been our purity of line as we focused on the tools that we build and use. How do we make it as productive as possible for solving problems with technology so that an individual, much less a small team, can run circles around much larger organizations? And that's always been true. as the venture-backed startup world started agglomerating into larger and larger human organizations that started demanding a lot of the cloud services, DevOps, and complexity that now occupy a lot of our brain space when we talk about technology. So on the lines of Rails again and individual productivity and progress, even if it's a helix,

what is Rails' current story when it comes to loading your JavaScripts, your assets, your... I'm from the days, so I've been using Phoenix myself for the last few years on changelog.com, which is really the only app that we work on. I'm no longer a consultant like you, which I was for many years.

I just have our app, and I work on it, and that's the one. So I don't have this experience, but back when I was using Rails for multiple people's web apps, it was Rails Asset Pipeline days. That was what I used. And there was like, NPM was blowing up and it wasn't the greatest way of doing things. It was slow and error prone. And I'm curious what the story is now with just loading stuff. How does it work? Yeah, well, the answer is, if you're coming into an existing application, whatever you used to be doing probably still works fine.

All these tools are still supported. But if you're running Rails new today, the golden path is one of the two following. First is, if you're targeting modern browsers that support import map out of the box, no bundling happens. You just create a manifest and say, Hey, these are my dependencies. These are the version pins browsers, you know, pull them in and cash them. And then, you know, now I've got low dash or now I've got whatever it is. And if you use tools that, you know, will work correctly when imported via an import map in a browser, then you're off to the races. And that's like, I couldn't dream of something like that. I guess I could dream of

something like that. It was called like RequireJS and it didn't really work super good. But now it's something that is standards-based and it doesn't require a custom Ruby gem solution for wrapping every single dependency, like we might have seen when Bower was the thing before NPM. The second path that you might take, and this is the one that I've taken because it only takes about 15 minutes for the first path to go sideways in practice, is there are new first class gems that Rails New will bundle if you say the right incantations on your command line. And if you get confused about that, toot at me and I'll try to help you because it can be a little bit confusing if you're new. I think it's called Rails CSS bundling and Rails JS bundling or something similar. The CSS bundling and the JS bundling, I think, is all driven by esbuild.

There's also a Tailwind-specific mode that will incorporate the Tailwind CLI and Tailwind configuration. So ultimately what gets built, now that, you know, I skipped over in the story because you mentioned the asset pipeline, which was like run by a gem called Sprockets. The bad years were when Sprockets was kind of falling over and couldn't really support NPM stuff.

And then Webpack was the like, Webpacker was the rails way to do it and it you ended up with 15 different configuration files that said the same thing and it was really it truly was a mess but now you know es build is so great it's so fast it's so it's no nonsense it's set it and forget it you don't really have to do any configuration rails handles all that for you i have literally you working on this project for a few months now. I've done two or three now with this tool. If I'm deploying to Heroku and I don't have any complicated infrastructure needs,

once I have a hello world, I haven't thought about this question at all. Nice. Well, that's the best story, right? The invisible story is the best one. In fact, even in giving that answer, I am very worried that I made several factual errors because I'm explaining a thing that I saw on a read me, you know, in June. Cause I don't know. Cause I don't need to know. And that's the best you're right. That's the best kind. We'll give you the benefit of the doubt. Well, that's a great answer because it was so painful for so many years. And especially

during the transitions, uh, like you said, where we were kind of like in this web this new webpack world but we were still in the sprockets world and the transition was was heavy that's why those upgrades you probably have some like serious intellectual property in your upgrade run books there at test double like here here's how we upgrade those are money makers for sure it was painful for that so that's excellent the other thing that I don't know about, because I, like I said, I haven't been in the Ruby world. I still, I'll echo Adam. I still love Ruby. I still use it all the time. Anytime I write any sort of script on my computer that has to take an argument and do his thing and shell out, like I don't even go for bash. I go straight to Ruby pretty much. And cause I love it that much. Um, but I haven't used it like in modern web stuff for probably five, six years. And so I know that

Ruby three was supposed to be like three times faster. That was like a deal. Like that was a marketing deal. Ruby three X or something. I know Ruby three is out. I'm curious about advancements in the language itself or changes that have happened of late. Have you read or read me back in June that told you the answer to this one? Yeah, yeah, you know, it's great. So if you're listening to this conversation and you're not a Ruby person, you're like, why do these three schmucks talk about why they have this nostalgic almost or this affectation towards this Ruby language when you might not see that or understand it?

I think one thing that Matt, the creator of Ruby, and DHH, the creator of Rails, have in common is that they're both optimizing towards programmer happiness. So if you are a developer and you're interested in being happy, you should check out Ruby. Because that is, I think, the north star for a lot of decisions in the language, as well as in the frameworks and tools that we use.

Because we always want to be productive, we want stuff out of our way, we want to like, you know, be able to express ourselves in a minimal terse way and just have the computer do the work for us. And it's easy to say that, but you see 1000 points of light that you can point to if you're going through a code base of like, here's an example of a config file I didn't have to write or a method where I didn't have to, you know, you know, copy paste the same basic thing five times to satisfy some framework underneath me, all the syntax that I didn't have to, you know, sprinkle in to make something compile correctly. And when you look at Ruby as a language, what's maybe most interesting to me is that the experience of trendiness, of popularity, of how much people talk about Ruby

has waned in the West. We talk about it less. The conferences have, I think, fewer people going to them. It has fewer committers from the West than it did. But I'm a student of Japanese language and Japanese culture and I've lived in Japan several times in my life and I'm friends with a lot of the, Matt's a Japanese person, in Japan several times in my life, and I'm friends with a lot of the Japanese Ruby

community members as well as committers and maintainers of Ruby overseas. And if you go to Ruby Kaigi, their national event, every year the crowds are bigger and bigger. It's a professional event. People take Ruby really seriously. They're really excited about Ruby as a language. They have a whole onstage discussion of all of the committers, like a Q&A session. And the committers are big enough to field an orchestra. It is so many people who show up on stage excited about, hey, here's an example. In Ruby 2.7, we used to have this way of parsing the syntax of a Ruby file listing called Ripper that like, it was very fast, but the API would produce sort of this like gobbledygook that

like you had to write a custom parser of the parser's output to try to figure out like, well, here's a method definition, here's a parameter. In Ruby 2.7, they released an abstract syntax tree module that like allows anyone who's writing Ruby to reflect on the Ruby and introspect the structure of the file listing and then dynamically play with that or build other interesting developer tools based on the awareness of what's the code actually do and what's its structure. Another example is the IRB, a little terminal REPL that you get with Ruby. And in any dynamic language, I think REPLs, if you're not familiar with the acronym, is read, eval, print, loop.

You type a little something, you hit enter, you see what it does, and then it asks you for more input. Working with the REPL is a really rapid way to get feedback from your system. I think the longer that I'm programming, the more that I think programming is really just a conversation that I'm having with my computer and anything I can do to ask my question faster and get a faster answer from the computer and then think whatever thoughts I need to ask the next question. That feedback loop is the most important thing to any developer's improvement and productivity. So the REPL has been massively improved both in performance as well as in features. Now you have a lot of introspectability available to you inside of the REPL. It's easy to

pull one up at any given code point. It's got much nicer autocomplete. It's visually just a much more, I think, pleasant place to be to help you understand where am I and what's this code doing and how's it behaving. So the REPL is another great example. Another one is there used to be a debugger that was kind of modeled after GDB, the GNU debugger, which you might be familiar with if you've written C or C++. It was called RDB. And it was not to demean anybody who might've worked on it, but it was roughly forgotten about entirely for like a period of like 15, 20 years. Like when I was coming of age in Ruby land, people would tell me, Oh yeah,

we just don't debug. Aaron Patterson. I think one of his most favorite or famous blog posts is I'm a puts debugger. Like he doesn't use the debugger. He just prints out statements because it's literally more, more pleasant and a faster feedback loop than like trying to fight with a step debugger and Ruby Shabbat.

Hassan, his handle is HSBT, took it upon himself. Oh, shoot. Did I give Shibata-san credit? It was either Shibata-san or Koichi Sasada. One of them came in, there's going to be a link or something. One of them came in and totally rewrote the Ruby debugger library and made a gem of it. And so now it can interact with, just like Node can with Node Inspect, it can interact with any kind of debugging user interface, whether that's VS Code, your IDE of choice, or a remote terminal session that connects to something that's listening on the other end. And it's a first-class great debugger. And I've got a YouTube video of how to set that up

in VS Code. I've had a really terrific experience with that. It makes Ruby feel fresh and modern. And those are a few examples. Ruby itself is indeed a lot faster. It is quite mature. They're adding new stuff all the time. And something that I hope to be doing more of in the future is to start unearthing more of the kind of new features that come out every year. Ruby has an annual release cycle on Christmas of all days. So Ruby 3.2, I think, 3.2 is next. I'm always playing with preview versions and stuff.

It comes out on Christmas, which is really fun if you maintain a bunch of gems, by the way. Because then on December 26th, you get a whole bunch of free GitHub issues from helpful people on the internet. They're gifts, consider them gifts. Yeah, they are. Yeah, it's Boxing Day. So all that to say, each new version of Ruby

does contain so much new stuff, but because a lot of the contributors are in Japan, speak Japanese, and may not be writing blog posts that get traction in the US, I would like to see myself and other people in the Ruby community do a better job of just surfacing some of the cool stuff that's happening. Because I don't think we've done a good enough job of really highlighting Ruby's advancements in the last few years.

So just take my word for it, please. What could bring that back, though? I mean, you said it's waning here in the West, not so much in the Far East. In fact, it's thriving, as you said ruby kagi is just uh killing it basically growing and you know maturing and innovating all the ings what can we do to like what are some pragmatic ways we can actually like stop that waning here in the west i mean is it is it simply a chasing cool issue where you feel like

the invoke thing to do is to basically just not look at Ruby, look at anything else, I suppose? Well, once you've been up or down the helix staircase of progress a few times, I think that you become comfortable with associating yourself or with working with tools that aren't necessarily

the trendiest thing. And the answer to the question of how do we reignite enthusiasm for Ruby in the West is first to just recognize that it is a stronger tool than ever and more people are using it than ever. Now it's true that if you build it, people won't come. They have to hear about it. They have to learn about it. And that's why I think the call to action right now is just celebrate the cool stuff that it does and talk about it. That's why I'm here today. It's exciting stuff to talk about because it's really fun to use and it's really productive. And I want more developers to have that kind of experience. And because the fundamental tools, both recent innovations in Ruby, as well as the

current formulation of what you get when you type Rails new, if you're writing a Ruby on Rails application, it's just so strong that I think that that will serve as a testament for anyone who tries it. People are going to touch that flame, and they're going to get excited about it, and they're going to share it via word of mouth. And hopefully, it'll be just like it has been on other moments of Rails ascendancy or anything else. people won't be able to shut up about the productive time that they're having well that's uh it's been fun talking about this this journey with you catching up i mean it's just been too long honestly we got to

get you back more more frequently than every 10 years uh maybe every one and a half maybe every uh seven and a half years 16 and a half months on the nose, I'm not sure. I won't take it personally. Well, please don't, please don't. Because we have respect for you and enjoy when you come on the show. But we're fans of Ruby. And I was actually thinking, as we asked you, how can we prevent the waning, I suppose. Jared and I have great passion for ruby we use it

whenever we reach for something but you know when we have the only application we work on is changelog.com we're not going to rewrite to ruby because we want to like see it thrive again in fact i mean there's a lot of things that we can compare with phoenix and ruby on rails and things like that and see the the differences but we can't really help and Ruby on rails and things like that and see the differences. But we can't really help that by building an application because we're not at builders anymore. We we've built one and we're going to maintain it and that's it. Keep improving it.

So that's a, it's an interesting aspect because I was just thinking, how can we, and to be clear, to be clear, I would not want you to write like, so test double, we've got a lot of Elixir clients.

We've got a ton of people in the company who don't like rails or ruby or they have moved on to you know elixir and phoenix and they're they love it uh i haven't you know had the opportunity yet myself but the moral of the story is it's great to get excited about new technology but if you've got something that's already solving a problem and you're having a good time you shouldn't feel bad because something else is suddenly cool. Right. Well, I do have one bigger question, but I'm going to save it for our Plus Plus members because we're at time and I'm actually not sure how it's going to land.

So you might see me get some egg on my face if you're a Plus Plus member and you're tuning into the after show or you might be like, hey, let me become a Plus Plus member so I can hear this. It may not be worth it. We'll see. Or it might go so poorly that it's not even a Plus Plus member so I can hear this. It may not be worth it. We'll see.

Or it might go so poorly that it's not even there for Plus Plus people either. I hope. Well, that's the egg on the face. If it's not there, that's basically the egg on my face, as you've said recently, Jared. Justin, thanks, man. Thank you so much for coming on and sharing your passion for Ruby and the productivity it's given you and the road you've been on. I think that's so true when you said about giving that talk to look back the few months or the year or whatever it might have been to say, what can you offer?

I think I want more people to do that. I think this is a, this is the kind of platform people get to do it on, which is a podcast. But I appreciate you sharing that here with us today. So thank you. I appreciate that. And, you know, this moment in time where we're living and we're kind of watching Twitter self-immolate, I am in a moment of reflection about just like recapturing some of what was magical about the web before all the web 2.0 companies sort of like sucked all of my attention and creativity. So if you're listening to this and you have things to share, I think there's

never been a better time to start a blog seriously. Even if it's just a link blog, even if it's just something little, you know, make a website, share your thoughts and link to other people. And hopefully they'll link to you because the best way, just like rubber ducking through a hard problem and talking to, you know, talking through the problem helps us solve it. You know, the reason that these talks or these blog posts or the open source that I've written has been so impactful to me personally is not because I'm imagining somebody with like, you know, this leather bound collection set of the Justin Searles tomes or something to serve as my legacy when I'm gone. It's because doing that work of digesting and sharing and articulating, like, what am I learning? That is where I get so much of,

I think the, the edification from this as a career because it helps me understand and contextualize like, who am I in this industry and what am I doing? Well, I'm glad we have you out there as someone to emulate. So if you are planning to take Justin's advice and you plan to emulate some of his learnings and this process of putting it out there, so to speak, through a blog or through toots or tweets or who the heck knows what's coming next. We have an easy way, Jared, right? ChangeLog.com slash submit. That's how you submit to ChangeLog News, weekly newsletter, online

all week long. We'll share your links. We want more blogs out there. We're for the open web. We're for RSS feeds. We're pro R rss we record entire podcast episodes about rss in which we state emphatically what justin just said please start a blog publish own your domain notice he has justin.searles.co and he can confidently say unless the dns system breaks down at some point that that sucker is going to be there right regardless of what that of what else happens. So we definitely...

As long as that's my name. And I'm bummed now because I actually spent on two different websites in the post-Elon Twitter purchase era written custom Atom XML feeds by hand to perfectly curate your experience if you subscribe to blog.testable.com or justin.serlz.co. Those feeds are immaculate and readable,

which was not true before. Talk about using a technology in anger. There you go, hand crafting, RSS. Each one's written by hand by me. When your client goes, I'm there doing it with pen and paper and then I'm relying on transcription technology to deliver that. Beautiful, it's a beautiful thing.

Well, Justin, thank you again. It's been awesome. Thanks, guys. That's it. This show's done. Thank you for tuning in. Hey, let us know what you think in the comments. We want to hear from you.

The link is in the show notes. And if you haven't yet, check out ChangeLog++. There is a bonus on this show for our listeners. So if you're a Plus Plus subscriber, you're getting that bonus. But hey, if you're not, you can easily check it out at changelog.com slash plus, plus 10 bucks a month, a hundred bucks a year. Either way you choose that gets you ad free shows that gets you closer to the middle. They get you bonus content, but more importantly, it lets you directly support us. Again, changelog.com

slash plus plus. Again, a big thank you to our friends at Fastly and Fly, and of course, to Brakemaster Cylinder for those banging beats. We love them. I hope you love them too. But that's it. This show's done. Thank you again. We'll see you on Monday Thank you. Game on.