The Relicans

loading...
Cover image for Modern Front-End Developent For Rails with Noel Rappin

Modern Front-End Developent For Rails with Noel Rappin

Mandy Moore
Single Mom 👩‍👧 🐶😺😺😺😺 Owner/producer: Greater Than Code 💕 #DevRel 🥑 WiT/D&I 👩🏻‍💻 Podcast Production 🎙 #BlackLivesMatter #python 🐍 she/her
・27 min read

Relicans host, Kirk Haines talks to Noel Rappin about the new book he has coming out: “Modern Front-End Development for Rails,” which is in part about what is interesting about Hotwire, Stimulus, and Turbo and what they bring to the table that's different than what people might be used to right now when it comes to web development, and talks about writing technical books for close to 20 years.

Noel says, “It's a lot of time that goes into something that you can't control. You can't control what the world's going to be like when you put it out. You can't control whether people are still going to be interested in it. You can't control whether something's going to make it obsolete two weeks after it comes out.”

This is why he’s also started playing around with releasing newsletters like buttondown.email/noelrap.

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.

play pause Polyglot

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.

Kirk Haines: Hi. Welcome to Polyglot. My name is Kirk Haines. You can find me @wyhaines on Twitter. And today I'd like to welcome my guest, Noel Rappin. Welcome to the show. Would you like to introduce yourself to everybody?

Noel Rappin: Sure. I am Noel Rappin, as you said. I am currently an Engineering Manager at Root Insurance. And, in the past, I have been various things, but mostly a web consultant of various stripes, a Rails developer, the author of a number of technical books, the most recent of which is “Modern Front-End Development for Rails.” I think I got the title right. Sometimes I forget what the articles are. And you can find me online in a couple of places. I'm @noelrap on Twitter, and noelrappin.com, and buttondown.email/noelrap for a newsletter. You get all that boring stuff out front right now when people have the opportunity to stop listening in immediately.

Kirk: [laughs] Fantastic. So, Noel, would you just give me a little bit of background on yourself? Obviously, you've done a lot with Ruby and with Rails. How did you come to this ecosystem? Where did you come from?

Noel: [chuckles] Where did I come from? So I am what is technically known as old. And so I actually became a...well, I was a grad student and then became a professional developer just as web development was starting to become a thing. I started off in the ColdFusion JSP. JSPs were brand new at that point, Java Server Pages, yeah, just Java Server Pages. And eventually, came through in doing the frameworks of the early 2000s, the Java 1 Struts, and towards the other one…I don't remember. And I came to Rails largely because those were so complicated and irritating to deal with. And I started working on it earnestly for just some internal tools that I was writing for my team. I wasn't working in Ruby professionally, but Rails looked really cool. I had a team that was distributed globally, and so I built some tracking tools for us in Rails and really came to like it. It had all the things that I was looking for. It had a number of things that I had been in advance looking for frameworks to do. And it was in Ruby, which was a language I liked but hadn't had an opportunity to use yet. And so, yeah, this is all very early, this in the Rails 1.0 timeframe. And shortly thereafter, I was able to get a professional job as a Rails consultant specifically. Well, as a web consultant but largely doing Rails work. And sometime after that, I started writing Rails Test Prescriptions and started publishing books in the Rails ecosystem as well.

Kirk: Very nice. So you were a Java programmer before you came to Rails.

Noel: I mean, as much as I was anything, the job that I was working on at that point was we were writing Java code, but I had done a bunch of different things, some Python, some little bit of Active Server Pages, ColdFusion, Perl. I actually left that job where I was doing Java programming in part because they were asking my team to take over a Perl project.

Kirk: And what year was that?

Noel: 2007 or 2008, something like that.

Kirk: By 2007, Perl 5 had been out for a very long time at that point in time.

Noel: Yeah. Perl had probably sort of come and gone as the web tool of choice. This was actually not even a web project. It was just a system, this project. I usually joked that I left because they asked me to do Perl, but that's not quite it.

Kirk: [laughs]

Noel: They were asking my team to start to do dumb projects that happened to be in Perl. And I looked on the horizon to see more and more bad choices for what my team was going to do with their time and decided it was time to move on.

Kirk: Interesting. So what was it? So you said that Rails had a lot of the things that you were looking for in advance. What was it? I mean, what were the things that really when you picked it up you said, "Yeah, this, this is what I'm doing."

Noel: Here's kind of a funny story about that. The frameworks of the early 2000s, the pre-Rails frameworks, were very clunky. And they were not noticeably necessarily better than not using a framework. The Java ones were very, very verbose. They had a lot of configuration, Struts. PHP was a thing at the time, but there were not significant frameworks abstractions on top of PHP. Active Server Pages, and Java Server Pages, and Java Servlets were all things, but there was nothing really coordinating them that did the thing that Rails did, which was figure out what you do all the time and make sure to make that as simple as possible.

So I had already done some technical publishing. I had co-written a couple of books where I had been brought in to help with somebody else's book. And so I was in a position where I was trying to write other things, and I pitched in, I don't know, 2004 or something like that. I pitched a book to a technical book publisher where it was about building your own framework-level stuff out of the existing Java tools. So it was putting together your own combination of Hibernate and some simple stuff on top of Java Servlets to simulate what a framework would do for you in terms of building in the common things. I think I pitched writing a SQL code generator and writing an HTML generator, and a couple of other things. I don't remember the whole thing. And so that was the kind of thing I was looking for, a tool that did that kind of thing. The project foundered in part because the publisher wanted to call the book “The Little Web Engine That Could,” and I just did not like that title at all. And it didn't work out, and I wound up doing something else. And it turned out the idea was not necessary because people were having that idea and building it out more elaborately and with more depth than I probably could have.

So Rails came along, and it had convention over configuration and then had ActiveRecord, so you didn't have to write SQL. And it had ERB, so you didn't have to really mess with...so you could deal with the view layer really quickly. It had a separate test database; it had database migrations. It had all of these things that were clearly meant to optimize somebody who is building a lot of different websites and doing a lot of things over and over again. And it was exactly what I had been looking for, explicitly what I had been looking for and had not seen. Django came out at about the same time and did about the same things and, for various reasons, caught on in a different way. But that was what I was looking for, and that was what I found there. And it turned out that the Ruby community was really welcoming. The Rails community was very welcoming at the time; it still is in many ways, and the Ruby community is still great. And so I wanted to be a part of that and became a part of that professionally for our job and became a part of that in terms of that was where I focused my hobby-level stuff outside of work.

Kirk: That's fantastic. Yeah, it's interesting when you talk about web development as it sat in the early days of the web, that late '90s timeframe. We're talking about Perl. Perl had some web development frameworks-ish.

Noel: Yeah, It had CGI-bin. It didn't have...

Kirk: Well, it had some bigger tools than that. I mean, it had some actual frameworks, but it wasn't the same. They were toolkits that got you part of the way there, but yeah, it did not...you still had to roll a whole bunch of your own stuff. And it is really interesting to me because I started doing web development actually with Perl for my living in 1996. And the state of the art, so to speak, just didn't really substantially change for probably a good eight years.

Noel: Yeah, something like that.

Kirk: Yeah. I mean, there were little evolutions but nothing really major.

Noel: Yeah, you had ColdFusion and PHP, and that level of tool came on in that timeframe, and that, I think, was an extension. ColdFusion, of course, was commercial, which killed it eventually. So both of those tools were...I mean, PHP is still around. People should know it. People probably know what PHP is. It's essentially an enhanced HTML markup with logic. ColdFusion was very similar, except that you had to pay thousands of dollars to get it, and the syntax was terrible.

Kirk: Terrible.

Noel: Yeah. I don't think the Perl community as it was; the values of the Perl community in 1998 would have really supported a Rails-style omakase, for lack of a better word, structure. In much the same way that I don't think the current JavaScript ecosystem supports that kind of all-in-one, we'll make all the decisions for you, and they're all going to be great; you’re going to love its aesthetic, which is essentially the Rails aesthetic. I don't think the Perl community of the year 2000 was going to be super excited about that.

Kirk: No, it really wouldn't have been. And yeah, it's very interesting to me the way the technology came together with the community and everything else to foster this development that turned into Rails and then turned into all these other frameworks that were essentially Rails' copies. The world is full of frameworks now that are on some level Rails’ copies. And it really did; it took that lucky combination of community and language and everything else all happening at the right time to make it all possible.

Noel: And somebody who is cocky enough to say, "I know how to do this better than you do and just do what I'm going to do."

Kirk: Yeah. I mean, that sort of blitz marketing where everywhere you turned, there was DHH stating, "I've got this thing, and it's better than what you're doing, and you should come take a look." It was a very interesting time.

Noel: Yeah, that 15-minute video, the 15-minute Build a Blog in 15 minutes video. It was a thunderbolt. Obviously, people saw that and were amazed by it.

Kirk: Yeah, it was. It changed the world, so to speak. So you've written a lot of books. You commented that you had done some technical publishing back almost 20 years ago.

Noel: Yeah. Almost exactly 20 years ago.

Kirk: So what is it about...this is just, I guess, a larger curiosity for me because I've contemplated writing some books myself, but I've never really fully jumped into it to embrace it. And so I'm always just curious, as somebody who has written up a bunch of books, what is it about writing the books that appeals to you?

Noel: There are not very many of us that serially write technical books. There's a lot of people who write a book about the thing they are an expert in but don't do it over and over again.

Kirk: Yeah.

Noel: I think part of it is that I wanted to be a writer before I wanted to be a programmer. I wanted to be a fiction writer, but it turned out that I don't think my brain really works in a way that would make me good at that, or at least I've never been able to figure out a way to be good at it. But I do think that…I mean, I flatter myself to think that I'm a good non-technical explainer writer. I hope that that's true. Certainly, if it's not true, I've been wasting [laughs] a lot of people's time for a while. And so, I've always been looking for a way to do that. And this is, I think also slightly to some extent, generational. If you became a professional programmer in the late '90s in the early 2000s, you became a professional programmer, and you were guided by these gigantic technical books. You had The Camel Book for Perl, and you had the Java in a Nutshell book, and all of these O'Reilly books that were big deals, you know, Java in a Nutshell, and the big, humongous Python book that was like Program in Python that was four million pages because they never thought they would be able to do another Python book. So they put everything they could think of in the one book.

And so I wanted to do that. The market changed. You can't really do that in the same way anymore. The internet happened, and publishing trends changed, and things started moving too quickly for a book to have that kind of influence; I think in the same way that the Perl book did in particular as the one...But it was something that seemed to be the way that I could help out people in the community. And it was something that I enjoyed doing, and I thought I was good at and managed to talk myself into the opportunities to do it. And you get enough positive feedback to keep doing it [chuckles], and pretty soon, you got a bunch of them.

Kirk: Fascinating. Fascinating. So, do you ever see a time when you will decide, “Nah, I'm done writing books,” or is it something that the reward is worth the grind? Because I'm sure, it is kind of a grind getting through a book.

Noel: I like the implication that you think that I've not said that already four or five times. [laughter] One of the things that's changed…The book that I have coming out that is in the process of coming out, so it's done, and it's about to be printed, is the “Modern Front-End Development for Rails” which is about Hotwire, and Stimulus, and Turbo, and React. And it has taken two and a half years from initial conception to final publication in part because we paused it for about nine months while we were waiting for what became Hotwire to be released. The book was completely finished last April before hey.com came out. But we knew that they were planning on releasing something that would immediately make the book obsolete. So Pragmatic was very open to the idea of, well, let's release the book after that. [chuckles] And for various reasons, they didn't release it until December. And then we had to turn around...it required rewriting two-thirds of the book almost from scratch, and so that's a lot of stuff. And then, of course, as the book is coming into publication, you had a serious amount of the issues that have happened with Basecamp and the Stimulus team, which is not great on a number of different levels and not happy with anything about how that turned out.

So it's a lot of time that goes into something that you can't control. You can't control what the world's going to be like when you put it out. You can't control whether people are still going to be interested in it. You can't control whether something's going to make it obsolete two weeks after it comes out. I love the process of doing it, and I've spent a lot of time trying to figure out a way that I can still reach an audience and make hobby level of money to keep me in Kindle books for a year without having a two and a half year cycle on it, which is why I started playing around with newsletters. And I don't think I have the patience for video production to put out video subscription. I don't think I'm very good at that. I think I'm better at writing. But I've explored, you know, I've thought about doing that kind of thing too. I love doing the writing, but the life cycle of it is...the grind is a lot. There's a lot you can't control when you have a one-year or two-year life cycle.

Kirk: Yeah, that's a rough lifecycle to deal with. And that segues me into something that I have actually been waiting for the opportunity to jump on, which is Hotwire and stimulus. So for people who aren't familiar with those two things who might be listening, can you summarize what is interesting about Hotwire and Stimulus, and what does it bring to the table that's different than what people might be used to right now when it comes to web development?

Noel: Sure. So there are three separate technologies here. There are actually four, but the fourth one hasn't been publicly released yet. So you have Hotwire, which is the blanket term for Stimulus, which is a JavaScript framework, and Turbo, which is a JavaScript tool more than a framework. The general idea behind both of them is to keep the server as your source of truth for your client-side development. And particularly in a Rails context, be able to do as much as possible by leveraging the normal Rails actions that you would already be doing. A lot of it can be thought of what if I did this normal Rails action but only updated part of the page in response to it or only updated like this, this, and this, on the page in response to it rather than doing a full-page load? But what if it was basically a normal Rails form update but instead of refreshing the whole page, I only change this name field and this other indicator somewhere else on the page?

And it turns out that that's a lot simpler for a lot of things certainly than a JavaScript single-page application. And even for the use of the JavaScript frameworks to manage a lot of clients, I'd state the JavaScript frameworks to my mind, manage a lot of state that browsers and servers are already extremely good at managing, and you end up duplicating a lot of effort. So you have Stimulus, which is a very small JavaScript library, which allows you to annotate your HTML markup with special attributes that tie various actions to various JavaScript code and various data. To be easily accessible to that code, Stimulus has this concept of a controller, which you declare in your HTML with a data attribute data-controller. And then, you can send actions to that controller again just by specifying data attributes in your HTML markup.

It winds up being extremely concise and extremely explicit in the sense that you can look at your markup and see exactly where the data is coming from, how it attaches to the JavaScript controller, and what actions are used to call it, stuff that can sometimes be kind of hard to find in JavaScript frameworks. I like Stimulus a tremendous amount. I find it is very good at relatively straightforward interactions. I click here, and I want something to happen to the CSS on this page. I type here, and I want something to happen client-side. The server doesn't need to care about it necessarily. I just have some client-side interactions that need to happen. It's very good for that kind of stuff. You can, of course, use it to talk to the server as well. But it's extremely good at very small applications, especially where you can make your client state part of your HTML markup.

And then the other part of it is Turbo, which is an extension of the Turbolinks tool that Rails has been using for several years, and it extends it in a couple of ways. It has this concept of an idea called a Turbo Frame where you specify a section of your page, and you say, "Any link within your site from this region, we're only going to redraw this region." So you have a bunch of articles on the page, for example, and each one of them has its own Turbo Frame. And you have an edit button and the edit button rather than redraw the entire page; the edit button looks in the response for a matching Turbo Frame. It only updates that HTML against that particular part of the page. So what that enables you to do really easily is leverage existing controller Rails view stuff with a few simple markup augmentations. You can get a lot of inline editing kind of behavior, clicking here to only update, clicking in a space, or doing an action in this space that only updates a particular part of the page rather than the entire page. You can essentially do that without writing any JavaScript.

And then there's an extension to that, which is called Turbo Streams, where you submit a form, and you receive a series of HTML templates in response, each of which is annotated with an action. So you get an arbitrary number of HTML pieces back in your form response. And each one of them is, rather than updating the entire page, they're tied to a particular DOM id, and they either append to or prepend to or update or replace that particular element. So if you say this is a shopping cart, I'm adding something to a shopping cart. So when I click here, it submits a form, and it updates the indicator in my upper right that tells me how many things I have in the shopping cart. And it updates an indicator in the middle of my screen that says this particular item is in my shopping cart. And it updates the button to say the button which did say add to shopping cart it now says remove from shopping cart. So you submit the form, and then you get something back that is three different snippets of HTML, each of which tagged with a DOM id that you wanted to do. And it just makes those replacements for you. And again, you can do that without writing any custom JavaScript.

Kirk: Neat. Yeah, that's really, really interesting. It's actually kind of funny. Back when Java first came out for browsers, I thought, wow, this is really cool. You can run Java in your web browser. So what would happen if I went and I used Java GUI elements, and I implemented all of the form controls for HTML as Java GUI Controls? Then I could take an HTML form, and I could render it inside my Java Applet. But then what would happen if that Java Applet didn't disconnect from the server it was talking to? It had bi-directional communication. And so I wrote this entire little framework just as a gosh, wouldn't this be fun to just play with and see what would happen? Sort of thing. And what it did is you could submit a form, and it would send that data to the server. And then, the server would respond with updates that could be applied back to your original Java form. So you could change the state on your form. And this was about 1996-ish, 1995 when Java first came out. And I thought, well, that's a neat toy, and then never did anything at all with it. [laughs] And here we are.

Noel: There's nothing really new, ever.

Kirk: Yeah.

Noel: That actually reminds me of another piece of the whole Hotwire ecosystem, which is that it works extremely well with ActionCable, which is the Rails tool for doing WebSockets, so that it makes it super easy to automatically send a WebSocket broadcast when an ActiveRecord changes. So not only can I update my own shopping cart, but if I have another browser open to that same application, I can automatically send it an ActionCable broadcast so that the shopping cart is updated on that page as well. If you use hey.com as an email service and you have it open on your mobile device, and on your desktop, and in a browser, and you mark something as read, it will use that technique to update all of the devices at the same time. You change the status of something, and it updates the ActiveRecord, and it sends a Stream message with template HTML to update each and every device. The 15-minute video example is a chat room that uses this technology to send the chat messages between all of the windows that are attached to the same chat.

Kirk: That's pretty neat. So what are some things that Stimulus and Hotwire would be poorly suited for compared to...normally, if you're going to go build, say, a brand new application today, a lot of people are going to reach for something like Vue or React on the front end with a Rails API server on the back end. And you do this traditional single-page apps sort of architecture. And a lot of the stuff that you just talked about, a lot of the things that you would do in that kind of architecture, would be vastly more complicated than just letting Rails handle it all with Stimulus and Turbo. But what are some things that might be poorly suited to that sort of implementation where you would want to stick with the traditional?

Noel: Yeah, I think that the Hotwire and Turbo tend to work best…and I don't know for sure. The tools are relatively new. And I think that there are a couple of years of people trying to push the border on them to try and figure out. I think that they are most suited to things that are essentially augmented browser kinds of tools like Hey, which could easily be a regular browser application, but it's augmented to make it look snappier and do some cool things in the front-end interaction. I don't know this for sure, but I think that the further you move away from regular browser kinds of things, the more the client-side flexibility and the complexity of React or Vue are valuable.

I'm not sure that I want to build a game in one of those, in Hotwire or Stimulus. I'm not sure I would want to build like Zencastr in it, although I think you probably could. I think it would be challenging, though. I think you'd have a little bit more...you'd be leaning a little bit more on Stimulus for client-side bits. But I'm not sure what the complexity ceiling of Hotwire is. My inclination is to think it's higher than most people probably think it is. I think that there's some...I think that most of the things that you would try to use it for I think it's a good choice at least to start because I think that it makes a lot of relatively complex things possible without writing a whole lot of code, which to me is a great place to start. I can always add more complexity in the places I need it more easily than I can take complexity away from places where I've already put it in.

Kirk: Okay. That sort of builds a picture for me. That's just one of the things that I was personally wondering about because these are two technologies that I've been curious about, but I have yet to really find a good excuse to use them. And so it was actually just kind of fortuitous that you were here. I've done a lot of React and a lot of things like that.

Noel: Yeah. There's something about the way that React apps seem to grow in complexity very quickly. They start off really simple, and complexity seems to attach to them. And I haven't quite figured out to what extent that is the way people use React or something inherent in the way that React separates into components or something about the way React makes it really easy to mix domain code and display code. But I find that the React apps seem to have this property of getting very, very complicated very, very quickly. And I think that at least for people who are comfortable with the Rails paradigm, I haven't seen that so far in the Hotwire and Stimulus stuff that I've worked on, which admittedly is not very much. They haven't been around for very long.

Kirk: You know, one of the things with React I think that is my personal assessment of it is that things in the React world have changed so quickly. And the paradigm of what is the right way to build a React application has changed dramatically in just a couple of years.

Noel: Yeah, that's true.

Kirk: And so that by itself can very easily contribute to that sort of creeping complexity issue. Because okay, how do we manage state? Do we use Redux? Do we just use Hooks and use state types of things? Do we start in one place and then move to the other? So now we use both, and that sort of creeping featurism that's happening really quickly, I think, has definitely contributed to that sort of...I know exactly what you're talking about, that thing where React applications seem to just become very complicated very quickly.

Noel: They seem to get complicated.

Kirk: And that is one of the things with Rails that I appreciate is the fact that there is so much...it's so prescriptive in a lot of ways. You're going to do it a certain way that I think helps trim the opportunities for that creeping complexity.

Noel: Yeah. And I think there are a couple of things that are interesting about that. I tend to like the concept of Hooks and React, although I think there's some weirdness about it. But I also think that I don't think that they had a clear idea of how much people would try to hide complexity in custom Hooks and how hard that would make React code to follow potentially. And I see that as being a definite issue where people will make the perfectly rational decision to create a bunch of custom Hooks, in fact, the encouraged decision to create a bunch of custom hooks for their stateful behavior. And then it becomes super hard to follow what's going on in the React code; at least that's my experience.

I think Rails has settled down in this thing. Rails is very prescriptive along certain axes, but there are a couple of ways where it's not. And I've certainly had the experience of looking at old legacy Rails code and thinking, oh well, that was the year we all did service objects this way. And this was the year we used decorators, and this was the year we used form objects. I think that some of that has settled down in the community in part because I think that people who were frustrated with the way Rails did some of those things have moved on to other tools. So I think that there's potentially...there's a sort of a selection bias within Rails for people who think the Rails way is good. And I wonder if three or four years from now, React will have settled down a little bit as people will have tried a bunch of different things and figured out the ones that work.

I also kind of wonder, I ask this question from time to time, if React and Vue are the big dinosaurs of the JavaScript ecosystem, who are the tiny mammals that are going to take over the world in four years? And I kind of feel like I have this weird sense, I've had it for a while, and I've been wrong for a while. I had this weird sense that there's something out there that is the next generation of that kind of tool that will synthesize some of these lessons that we've learned about building these client-side component-based tools and do it in a slightly new or more prescriptive way. But I'm not smart enough to know what that look would look like. I'm only smart enough to see that there's a space there, but I don't know what fills it.

Kirk: And it's also possible that it could just be another evolution in that ecosystem like what you're talking about with Hooks and how Hooks can make it very difficult to follow the logical flow of your code. It's one of those things that you run into anywhere that you have...I mean, Hooks are essentially callbacks. And did you ever use EventMachine in Ruby?

Noel: Only a little bit.

Kirk: Okay. So EventMachine for people who aren't aware, EventMachine is something that came into the Ruby world around 2007. And what it was, was a C library that implemented an event-based I/O reactor so that when you have things like, say web servers that are doing a lot of I/O, you could build it in an event way where your Ruby code would potentially have a whole bunch of different events that it's waiting for. And when something happens that triggers an event, your Ruby code acts on it, and it does something. And the neat thing about EventMachine is that it was a framework to do this, and it was very, very fast. The bad thing was that it was all implemented with callbacks. And so you ended up with this situation where when you had a complicated application, it was very difficult to understand what was happening. It was very difficult to reason about what might happen. And when you had an error, it was often really hard to find where that had happened at.

Noel: And I think a lot of pub/sub systems have that feature where it's very hard to figure out what's going on.

Kirk: And that is basically where we're at with React right now.

Noel: Yeah, the execution model of when React decides to redraw stuff and when stuff happens in React I think is confusing would be a good way to put it or at least not surprising, maybe. I would bet that there are a lot of React programmers out there who don't have a super clear idea of exactly what React is doing. I would probably count myself among them.

Kirk: Yeah. I would count myself among them, and I've written quite a few lines of React code. Sometimes you're just guessing. You're like, okay, if I do this thing here, if I do this little magic incantation, it'll do what I want, but I'm not really sure why it does it this way. So it's interesting. I think we could probably keep talking about this stuff for a very long time. But I just looked at the clock and noticed we've already been going for 40 minutes.

Noel: [chuckles] Yes.

Kirk: So why don't I just turn the floor back over to you if there's anything that you're currently working on or you're excited about, or you want to just mention and talk about a little bit.

Noel: Yeah, I should mention the book again, “Modern Front-End Development for Rails,” and the sort of a spin-off companion volume which is “Modern CSS with Tailwind,” which is what I did with myself during the nine months while we were waiting for Hotwire to be released. So I think that's the first print book about Tailwind, the Tailwind CSS utility library. It's very short, but it exists in the world. And yeah, I'm interested in that and kind of interested to see where that tooling goes. The continued evolution of CSS and the movement of things that we used to do in JavaScript to CSS I find really interesting, and then the sort of concurrent evolution of CSS tools to manage it. I'm pretty curious to see where that winds up after a couple more years of churn. If you want to see me talk about this stuff again, buttondown.email/noelrap, I think, is the newsletter URL. And then you'll get occasional rants, code samples, tutorials, things like that from me about all kinds of topics. There's a bunch of essays that I'd done over the last year about Agile and XP, and how they play out against the way web development works in 2020 and 2021, and how all of these practices are great but not very resilient against deviation from them. And some other thoughts about Rails and JavaScript and things like that.

Kirk: That all sounds really fantastic. Well, I want to thank you very much for coming onto the show. This has been a lot of fun.

Noel: Yeah, thank you. Thank you for letting me talk.

Kirk: And I guess you already told everybody where they can find you online, so thanks much. And thank you, everybody, for tuning in and listening. For the Polyglot Show, this is Kirk Haines. You can find us on Twitter @PolyglotShow. And also, we have a forum, therelicans.com, where you can drop in and read articles, and get a lot of interesting information on a regular basis. So thank you very much.

Noel: Thanks for having me. I appreciate it.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.

Discussion (0)