The Rogues discuss Turbo and Hotwire with Alexandre Ruban, who created a course on Hotwire and Turbo for Rails at Hotrails.dev. The dive into its origins with TurboLinks and then discuss the various options and tools that come with Hotwire development in Rails and compare it to other front-end frameworks and solutions they've used.

Dave

Valentino

Chuck

Hey there and welcome to another episode of the Ruby Rogues podcast. This week on our panel we have Dave Kamura.

 

Hey everyone.

 

We also have Valentino Stoll.

 

Hey now.

 

I'm Charles Max Wood from Top End Devs, and this week we have a special guest, and that's Alexandre Roubain. Do you want to introduce yourself? Let us know who you are, why you're famous, all that stuff.

 

Yeah, so my name is Alexandre and I'm a Ruby on Rails developer from France. And I created a tutorial about Turbo Rails that I published. And apparently this tutorial had a great success. So here I am today. I'm really happy to be here.

 

Nice. So yeah, so this is a tutorial on Turbo and Hotwire in Rails, which has kind of been a hot topic off and on here on RubyRogues. I'm a little curious just to kind of get us kicked off. I mean, is there a story behind you putting this together? I mean, were you working with people that needed it or people asked you questions or does it come from somewhere else?

 

Well, yeah, at my previous company, I was working on a project of Quote Editor, so exactly the same as what we'll build in the tutorial. It was built with React, and at the time,

 

Boo!

 

it was the very, very beginning of Hotwire because Hey from Basecamp just went out, and so the gem was not included in Rails yet, I was seduced by the promise of not having to write any JavaScript to build some dynamic applications. And so I tried it out, and then I was completely blown my mind. So I later rebuilt this quote editor with Hotwire, and

 

Mm-hmm.

 

I thought it would benefit a lot of people if I just document the process I went through. And that's what I did. I've created this tutorial a bit like I didn't think about it. I just wrote it mostly as some documentation and published it. I guess it helped a lot of people. I have more than 10,000 visitors per month on the tutorial, which is

 

Oh

 

completely

 

wow.

 

amazing. I didn't imagine it would reach those numbers, so I'm really happy about it. The quick story of it.

 

We've got the expert here, folks. So let's ask smart questions, right? That's mostly a reminder to myself. So where do we wanna start? Do we wanna start with turbo? Do we wanna start with React sucks? Do we wanna start with hot wire, something else?

 

So I want to start with the history of turbo So if you remember way back in rails four days, we got introduced to turbo links

 

Yeah.

 

and

 

people

 

honestly

 

hating on it.

 

It was one of those things that I would just disable in my application because it caused so many problems

 

Mm-hmm.

 

You know because I was using a lot of different JavaScript libraries that did not work with turbo or turbo links. Sorry. And it was just really annoying. But then when Turbo Links five came out, that kind of like shifted things where a lot of the libraries just worked with it or worked with very minimal effort. And so that was really cool. And around that same time, we got react. And I think a lot of people. Jumped off of the action view because it provided a lot of client side UI UX components that you could quickly, and I'm not gonna say easily, but let's just say slowly create these components that you would then be able to have rich UI interactions. But then we got Turbo. And I think with Turbo and Hotwire, which is just stimulus and Hotwire combined, or I'm sorry, which is just turbo and stimulus combined, that completely changed the game. We don't need to really have this idea of client side frameworks within Rails applications and modern Rails applications. It's completely changed the dynamic and a lot of what people would reach for with React, you don't need to do anymore.

 

Well, yeah, exactly. This is something that, like in my previous company, when we decided to build a code editor in React, because TurboRails didn't exist at the time, we had like, we were a small team of four developers and only two of us knew how to write React code, right? And

 

Mm-hmm.

 

there's also this problem with React that it's kind of complicated. You have to, some time to learn. And once you're done with React, you also have other libraries to learn, like, for example, Redux, if you want to keep states somewhere. And all of this makes it really hard to learn. And then, yeah, in most teams, you end up with a back-end team and front-end team. And this is something that, when you're a very small company, like we were at the time, you want to avoid, I guess. And this is what one of the aspects that most amazed me is that if you want to learn Turbo, you only need like a couple of days because the API is very simple compared to React. It's a real bonus, I would say. And yeah.

 

I would love if you could walk us through it because I was going through your tutorial this week awesome and I Just love the the experiments that you have set up throughout to kind of test what is happening with turbo and and the various parts of it and I just want to Like we're when we talk about turbo drive Right,

 

Yes.

 

like that's a piece of the framework Which was formerly turbo links, right?

 

Mm-hmm.

 

Dave. So could you break down on a higher level like what else is included in Turbo Rails that makes it because the Turbo Drive basically makes a single page application right

 

Yeah.

 

available by default in Rails. So what what else is included in that Turbo Rails framework

 

Yeah, so...

 

that adds

 

snails.

 

to that? Snails.

 

Yeah, so in the JavaScript library, there are three different components, right? There's Turbo Drive, which makes it easy to transform your app into a single-page app because all the clicks on links and the form submissions become Ajax. So there's no full-page reload anymore. And then there are two other components, which are Turbo Frames and Turbo Streams. And so Turbo Frames, they enable you to slice your page into different independent frames. Like when you click in a link that's in a frame, then you're going to replace this frame with the same ID from the other page. So this enables you to slice your page into different independent pieces, just like you could do as well with React. And then there are TurboStreams. And TurboStream is kind of like in TurboRails, you can make TurboStream requests. And TurboStream requests, special format in HTML where you have an action and a target. And you can say, for example, I want to target this ID in the DOM and replace it with the HTML that's contained in the template. And so, yeah, this is for the JavaScript library. And then there's Turbo Rails, which is the turbo integration for Rails. And so it comes with a few things, right? object that is used to build TurboStream views. We can use the TurboStream.replace or TurboStream.append, prepend, all those things. And then there's the integration with Action Cable as well. You can say broadcast Append to or things like that if you want to broadcast some HTML each time, resources saved or updated or destroyed, things like that. So it's quite a big library if you take the JavaScript part and the Ruby on Rails integration. And actually, I have another tutorial. So there's the tutorial that is free, and the tutorial that's free is how to use the framework, so Turbo Rails. And there's another tutorial, but this one is paid, rebuild TurboRails library, but we're not talking about JavaScript, only the Ruby parts.

 

You know, one of the things that I love about TurboStreams is that it doesn't render out the requests back to the Rails application, doesn't render out the entire layout and everything. It's really just rendering out or sending back to the client just that TurboFrame tag with the ID. So the amount of data you're sending over the wire is much smaller. than Ajax requests, a lot of times you were going to get a lot more sent back over the wire.

 

Yeah, you don't have the layout by default.

 

Mm-hmm.

 

When you send back some TurboStream response, the layout is removed for you. And I think that there are kind of some interesting discussions around this, because, for example, this layout, you don't want it most of the time. But sometimes maybe you would like to have a layout just to render Flash messages, for example. the Turbo library there. I remember there were a lot of discussions about this. So it's kind of an interesting issue here. But still, today there is no layout, well, included by default when you make a TurboStream response. And so for flash messages, it's kind of boring because you have to, you know, specify it every time that you want to render a flash message or something like that.

 

Yeah, but also the nice thing is if you do have a situation where you are using a Rails engine or some other library where it does not play nicely with turbo, you are able to disable turbo on those specific areas.

 

Yes,

 

For

 

exactly.

 

example, like device.

 

Yeah.

 

rounds to get a device working natively with Rail 7 hot wire and all that good stuff but if you were not wanting to go through all those headaches of customizing the initializer and adding in your own failure handler then you're able to just add the data turbo false and then it just magically works it just skips the Ajax request does a page refresh if you're posting or whatever and it works really well.

 

Yeah, and it's actually one of the things that we do in the tutorial. Like,

 

Mm-hmm.

 

we installed Devise at some point, but I remember I was trying to find an issue or a way to make it work with Turbo, but I couldn't find one. There was a video from Go Rails explaining that you could monkey patch some stuff, and that was really complicated. And so I ended up saying, okay, maybe we can... on your login or sign-up page. So you can just disable it with a data attribute, and it works perfectly. So yeah, Turbo is really easy to work with, and disabling it is also very easy if you need. And so this is also something that is, yeah, it just works. And if you work with React, at some point, your application work with React because you already invested so much. So I guess this is one of the nice things as well about Turbo. But as of today, I still work with React, so I'm not going to trash talk React too much. I do React at my day job. So, you know.

 

I have to do react as well, but I don't have a problem trash talking it.

 

Ha ha ha

 

So speaking of talking, now that we're on the topic of React and that you have, you know, extensive experience with React Alexander and haven't gone through making all these tutorials and diving into Turbo, right? Have you found things maybe lacking in Turbo that you like from React and vice versa? Like are there things that are missing from each that could go well if they were cohesive?

 

Yeah, so that's a good question. I think that one of the aspects I like the most about React is that you can create your components. And so this is something that we don't have by default in Rails. You have to use either ViewComponents or Flex, which is the newest addition to the list of ViewComponents gem. And so, yeah, I mean, depending on the size team you work in. I mean, at some point, it makes some sense to have some view components because you want your UI kit to look the same everywhere. And so having components is nice. But this is something you can perfectly do with Turbo. And the Rails ecosystem has multiple gems to handle, yeah, to handle components in Ruby on Rails. And so, yeah, you don't need to to go to the React route if you don't want.

 

Yeah, and I will say in reacts defense if you were just using react is Just sprinkles in your rails application or some highly interactive content. It's not too bad especially if they are simple components. My issue comes into play when you try to, you create one component, but then within there, you have another nested component, and then you have another nested component, maybe like four or five components in this overall feature thing, but then you need to pass data from the component deepest within up to the parent component at the top level, and that's where things, I think, real nasty and react. And that's not even talking about using the react route or Redux or anything like that. There's just kind of like the organizational stuff on how React works and within the dock.

 

Yeah, like passing state through multiple components.

 

Mm-hmm.

 

And then you end up having, I don't know, many files open, trying to go from file to file with your states to know where it comes from. Yeah, that's something that's difficult. And yeah, like in my previous company where we had only this page, the code editor, that was really an interactive page that required React. because we didn't go all in into the React path. It was still a problem as a team because we didn't all have the same skills when it comes to React. And so, even if it's on a single page, then it already creates some barrier between all the developers because React is a skill and it requires some time to learn. And so, yeah, this is a... Even if you don't go all in into the React path, I would say, then it still can be a problem if you are in a small team, and then some of the developers can't work on this feature. So this is why also I really enjoy working with Hotwire.

  

Yeah, you know, working with Rails controllers and views for so long, it's definitely seems to be a common problem, right, of passing state around and where to put what, right, like, because it's so easy, you know, from an active record standpoint, just talking about that, right, like to create M plus ones or to cause downstream problems because the state isn't kind of exclusively set upfront. like, not necessarily, there isn't really a strong opinion on how to trickle those down through the views, right? And I feel like we're starting to see that too with Turbo in that, you know, we're trying to figure out where to put the state.

 

Yeah, that's also true. If you have some state in Turbo, well, sometimes it's hard to manage it. You kind of store it into the data attributes when you really have to. And so, yeah, there are some cases when Turbo alone is kind of complicated to work with. integration with a full calendar. And so full calendar is a JavaScript library. And so you have, like, if you want to create events into that calendar, you will have to create a stimulus controller that wraps the calendar. And then you have a form, but the form sends data to the server. And when the data gets back, it's kind of hard to put it back into the calendar that is really this kind of JavaScript library So there are some issues like this, like when you still have to do some JavaScript. And in that case, yeah, it can be a bit painful because you have to do it all by hand. You don't have libraries like React that just abstract the complexity for you. And so, yeah, but apart from this case, I would say that, yeah, it's mostly easier with turbo than react.

 

It's actually kind of funny you mentioned full counter because I just released at the end of Vox and episode on full counter and stimulus. And

 

Oh yeah.

 

then this weekend, I'm preparing the high interaction part of it where you have two different browsers. You make a event on one of the browsers and they get broadcasted through and then refreshes the calendar.

 

Yeah.

 

So it's definitely possible to do. There are some nuances with it, but I think you'll find that that's just part of the full calendar library and some of its limitations that you had to work around. But I just thought that was funny. But full calendar has kind of been one of those living JavaScript libraries that I always kind of go back to because it is and the different approaches to it over the years has been so different just throughout the years. The approach they use to integrate it with the Rails app.

 

Yeah, so,

 

So do you guys,I was gonna say, do you guys imagine now that the way that the, let's just focus on full calendar. Like, do you imagine like full calendar rails, turbo gems to start coming up that help wrap the complexity the right way in the turbo framework specific for the JavaScript?

 

I don't know, maybe Dave you have an opinion. I will definitely watch your video when it comes out, because that's my topic at the moment.

 

Yeah, I mean for a full calendar specifically, it would be very difficult because when you are recording an event or creating updating an event on the calendar, every company is going to have their own specific requirements around that. So to build an engine around it, I think would be a bit cumbersome or at least it would take on the end user. But as far as just having certain kind of features in a stimulus controller that you can enable or disable through the initialization of the controller, I think that that could be possible to have some kind of library board. But I mean to have it fully featured, I think would be a real challenge because everyone's use case is a little bit different.

 

Yeah, I mean, what I worry is that we start to head down the path that we headed down with Rails Asset Pipeline, right? Where we had like the RailsAssets.org for a while,

 

Mm-hmm.

 

where we were right, hooking into and then basically just like loading up the JavaScript libraries that we wanted to get it into the Asset Pipeline. I'm kind of worried that will go that way with Turbo, the way that it's set up with working with external libraries where they're like full calendar, to the libraries for JavaScript, right? That need that JavaScript feedback.

 

Yeah, I think as far as the asset the Rails asset org that you mentioned I used to love that because now I had a way that could actually manage what import maps and yarn will do. So I don't think it's a true fair comparison to say that we would need something like that. But there is a GitHub repository, I forget what it's called, but they have a bunch of different stimulus components that you're able to do a lot of like routine things that you would most commonly want to do. So I think something like that could be a good thing or just having a snippets of code stimulus controllers that can perform whatever function.

 

Now do you need stimulus to use the turbo framework? Or does it just make it easier?

 

You don't they are separate things, but they pair so nicely together So, Alexandre, what is your favorite part of the Hotwire Umbrella? Like, what is the thing that gets you really excited that you just want to use every time you work on the Rails app?

 

Yeah, so I think that stimulus is more like for finishing touches. Maybe you want to make a dropdown, so you are going to need to manage an open and closed state, things like that. But what I really enjoy about Turbo is probably TurboFrames, because then you just have to, you know, you take one page, and it's composed of different parts. I don't know, an article with comments, with different authors or things like that. And you can manage each section independently, just like if they were in different pages. So you can still have a very crud-like organization. You're only making crud controllers that are very simple. And you can have all of the different resources on the same page. And this is something that I use a lot I work with Turbo, one of my favorite parts. And also, there is this, if you want to make some real-time features, like I don't know, you want to make a game that could be multiplayer or something like that, then it makes it very easy to work with Action Cable, because you don't have to think about almost anything, right? There is a very simple API to work with Action Cable And so you can just broadcast a piece of HTML. It gets replaced in the page of everyone who's connected to that channel. And, and that's it with like only a few lines of code. So those are my two favorite features. What about you? Yeah. Yes. Yes. Yes, and you also have that React-like feeling. You know, when you have the little loader and you can lazy load your frames. So in the case of a dashboard, you can just have the first page with no data at first, with all the loaders, and with lazy loaded frames, you can just have requests get fired to the different controllers that each handle one resource, and then you get your dashboard just like this, this is a great great win I guess.

 

It's kind of funny, turbo frames to me seems like kind of just iframes, like re-implemented.

 

Ha ha ha

 

Right? Except where it used to be specific to, or I guess more specific to external embedded websites, right? Which I know I'm sure out there, I haven't personally done it, but I'm sure somebody abused it to make internal requests, to make a bunch of iframes to split in JavaScript, you could also target those frames like a turbo frame, right? But so to me, that's how I'm wrapping my brain around turbo frames, in that it's just using the DOM and making these external requests to swap stuff out and connect things to the backend. And what I like about it is that it doesn't use a virtual DOM, right? Like that's where I always see kind of some negative things positive when you have caching and things like that in a virtual state. But it also decouples it, right? So, like, now that it's in the browser, you know, all of these things are controlled by the browser rather than some external machine trying to resolve all of the dependencies in whatever is in it, right? Which is how React works. And I'm not I'm kind of excited about that idea, right? But I do worry because of how it's implemented so much in parallel with how iframes kind of are. And I'm suspicious that the naming of turbo frames is kind of a parallel to that. I worry that browsers will implement their own version. And then we'll have to worry about adopting this new thing. is too much to worry about at this stage, but it would be great if browsers had a native turbo frame that you can do this with, you know. Oh, I forgot about frames.

 

Mm-hmm. I don't know, the user experience on frames was amazing.

 

Alexander, I'm curious if you've looked into speed, if you've done any benchmarks to see if usage of turbo or hot wire has reduced latency or improved overall page performance. Are you tracking with Google Lighthouse or something to see if it's been improved there?

 

Yeah, so that's a good question. And unfortunately I will be unable to answer because I like at my previous company, I left right after we did the implementation of turbo and now I work with react only, so I'm very sad, but I don't have any, any answers to this. Yeah, and there's also how much JavaScript you have to download from the server on initial page load when you're using React, which you don't have when you use Turbo because the library is much smaller. So, yeah, I guess it's kind of hard to compare. Probably if we wanted to argue with a React fan, he would probably find a way to, you know, faster. But I like how DHH says it. It's fast enough for the users. At that point, do we care? I'm not sure. This is the argument that I use now when I have arguments about performance. Yeah, this is also a great argument.

 

up. Yeah for me. Yeah.

 

Yeah, and this is something I'm wondering about because like all the companies that started to adopt React heavily, like the company I'm working at right now, it's probably very difficult to migrate to Turbo because everything's built in React. You have your design system in React, all your components, the teams now how to use React. And so we're never going to migrate. And I'm wondering if the, Are they going to use Turbo much more than React? This is a question that I'm like, I'm eager to have the answer about that.

 

Yeah, it's interesting too because on JavaScript Jabber, I think it was last week, we talked to Mishko Hevery, who's the guy that created Angular. But we talked to him because he's created a new framework called Quick. And it's got some interesting features as far as, like, you know, the way that it fetches modules and things like that. But one thing that was really interesting quick and talking about the product that they're building called Builder. It has a lot of this kind of thinking behind it where instead of having like, you know, fully managed spa type approach, yeah, it's using some of the HTML2 features and, you know, some of the HTTP2 features and some of the other things out there and then letting you manage your pages in the same way that Stimulus pulling in part of the page or partial refreshes or things like that. And if you have a different UI, you may actually just click and it'll load another page that has different setup on it. Anyway, it was interesting to kind of see that some JavaScript folks are starting to look at an approach like this and kind of take it to heart.

 

And this is QUIC, the front-end framework, not to be confused

 

Yeah.

 

with QUIC, the new HTTP3

 

No, it's the front-end

 

stuff.

 

framework, QWIK. dot builder dot IO is the quick dot builder dot IO is the website for that. Anyway. So I'm just curious as we dive into this, a lot of people like to test their code. So do you provide any kind of test helper, test setup with the...

 

you

 

Rails Turbo.

 

There is a custom assertion in the TurboRays library. There is an assert TurboStream assertion that you

 

Mm-hmm.

 

can use. So to be honest, I don't know if it exists in RSpec. Probably you have to create it yourself. But I mean, this is something you can use if you really want to test that the view is going to be rendered properly. So what it does, assert TurboStream, if I remember well, the target, so the frame that you're going to target and the action that you're going to send. So for example, it's used in the controller test or request tests where you can say,

 

Mm-hmm.

 

like when you, I don't know, when you create a new command, then you can say, assert TurboStream commands, so the list of all the commands, and the action should be prepend or append. So this is the kind of assertions into the TurboRails gem. But apart from that, in the tutorial, I used only Capybara tests, if you want to have full

 

Mm-hmm.

 

testing capabilities. But otherwise, I guess it's also kind of uncommon to test views too much. You know, like for example, if you want to... Like, it's part of the framework Right, so maybe you're not going to test that the frame is properly replaced. And if you want to really make sure, then you're going to use assertTurboStream to make sure that it has the right action and the right target. But apart from that, I don't test that much the views.

 

Yep.

 

What about you?

 

Um, for me, it's basic. I mean, if it's, yeah, just basic, you know, you clicked here and it made an X XHR request and got whatever it got, right. Um, you know, I'll probably have some kind of unit test and maybe some level of, uh, controller test. If I'm really concerned about anything beyond kind of the basic functionality, it's already in rails. And then on the front end, it's the same deal, right? If it's, yeah, if it's just a fundamental, Hey, this is something that does over and over and over again, then yeah, I tend to not test that so much. But if there's a complex interaction, if I've written a bunch of JavaScript in one of the stimulus controllers and I'm trying to make sure that it does what it's supposed to, I'll write a test around that. But yeah, I was just curious if you, you know, kind of included Jest or something and said, hey, here's an easy way to test your stuff. I also test, I have tested some of the fundamental framework functionality, but usually it's because I have some kind of thing that I screwed up and I want to make sure that I unscrewed it up and that it stays fixed. So

 

Yeah, yeah. I mean, sometimes if we have like very complex stimulus controllers, then maybe it would make sense to test them with Jest. But this is

 

Mm-hmm.

 

something I don't do very much. Like

 

Yeah.

 

most of the time, my controls are really easy, kind of simple controllers. Like you want to open, I don't know, a model or a dropdown, just add CSS classes and remove them or things like that. And

 

Right.

 

in that case, well, I don't test my stimulus controllers. And yeah, as we mentioned earlier, I don't test views that much. And so, yeah, I guess it just works. And that's great. That's what's great about it.

 

You know, one thing I really liked about your tutorial was you built a design system from scratch and showed how kind of easy it is. I was really happy to see that, which I know there's a lot of like drive for tailwinds, that lots of people love that. And I enjoy it too, but it was nice to see that you don't need to do that, just follow these principles.

 

Yeah, this is really funny, actually, because everybody's telling me, like, OK, I like the tutorial, but I really enjoyed the CSS part. And this is really funny because that's not at all the goal of the tutorial, right? I didn't want to use Bootstrap because you've seen it everywhere. And so I wanted to make it like, as the code editor that we built is also on the website, I wanted to design it a bit. So this is why I ended up building my own CSS. But yeah, I really enjoy CSS as well. And so I have a lot of rules that I use on every project. Like I set variables for everything, like the colors, the spacings, the font sizes. I store all of it in a variable file. And right after, it becomes really easy to make some CSS. And there's also the media query mixing that I use everywhere, like include if the size of the screen is, so I named them mobile and up or tablet and up or things like that because I use mobile first approach. And

 

Mm-hmm.

 

so when you have media queries like this and CSS variables, you're already done all of the job, right? So I guess it's one of the reasons Tailwind is so popular, because it already gives you the media queries and all the variables. But apart from that, you have to build all the stuff yourself, right? So, I mean, I think that those two approaches are kind of equivalent, but yeah, it's a matter of preference after. So yeah, Tailwind people, they are going to say, well, I just want to stay in one file. I don't want to name my components. This is a strong argument in the Tailwind community. But in the end, you will still have to name your view component because most of the time, you don't keep the markup like this. Otherwise, it becomes hard to maintain. And so yeah, the CSS part was really appreciated. That's great. Well, yeah, but they match the CSS, right? So there's one utility per CSS declaration. And so, yeah, I mean, it's exactly the same. For me, it's exactly the same, but written in a different format, right? So if I say text large in Tailwind, then it's the same for me to use my font size variable, text large. exactly the same. But I mean, yeah, this is kind of funny because there's always this argument between Tailwind users and non-Tailwind users. This is why I don't want to give my opinion. But really, my opinion is that it's the same. Like if you use Tailwind and then it's the same as if you use media queries and variables in your CSS style sheets. I don't know what you think, Yeah. Okay. Yeah, yeah. And this is why I do like both approaches, but I prefer having my CSS into CSS files just because it makes my HTML nicer. But apart from that, it's exactly the same approach whether you write. I mean, what Tailwind provides really is the media queries and the variables. That's my take on it. And so if I define the media queries and the variables CSS file, then it's the same, right? But I have a nicer markup and I have to name my components. So that's kind

 

Thank you.

 

of the trade off here.

 

I know we're talking about CSS a lot, but it's kind of funny, right? Because Rails, their motto now is giving you everything you need to know from going from startup to public company, right? And CSS, styling your website, is a pivotal part of that. Without styling anything like people won't use it, right?

 

Challenge

 

Well,

 

accepted.

 

who uses Craigslist? To be honest, Craigslist has lost a lot of user base. And I think there's a lot to be said there. Right?

 

And it's still

 

It's

 

styled,

 

like

 

it's just minimalist styling.

 

the web is feature rich now, and people expect it to look a certain way. And personally, I would like to see some more opinionated where you can just rails new and it looks nice too, right?

 

Mm-hmm.

 

Yeah, I agree. And even those days, when I start a new application, what takes the most time is actually the design because Rails made such a good job at abstracting all the complexity. You want to make a crud app. With Rails, it's going to take you very little time. You just make a scaffold and you're almost done, right? And so, yeah, you're left with the styling, can be really tricky,

 

Yeah, let's

 

especially

 

talk about

 

now.

 

Rails G Scaffold.

 

When you can come back with a product that's making you enough money to live on your own, then I'll listen.

 

based on the scaffold CSS.

 

Based on the scaffold only.

 

Yeah, but no, what Alexandre's saying, which makes a ton of sense is that, you know, out of the box, you basically get all of the CRUD operations you want for free. And if you're good with JBuilder and friends, then you kind of get a JSON API out of it too. I mean, you know, it doesn't solve necessarily like authentication and stuff off the bat, but you can pull in some gems, bolt some stuff together, You're... you're well on your way.

 

Yeah. Yeah,

 

I miss jQuery.

 

but Bootstrap is like, it gives you a huge boost of speed. If you're really in a hurry to create your project, you get all those components and you don't have to redesign them by yourself. Because even though like whether you're using Tailwind or Vanilla CSS, you're still going to have to redesign a button, redesign a form, redesign a model. redesign a navbar, and all of this takes a lot of time. And yeah, I mean, if you're really making a project that you just want to try something, then I think it makes a lot of sense to use Bootstrap, for example, because you're going to have all your components and then, yeah, you just have to configure it a little to change the primary color to your brand color. I'm a huge fan of Bootstrap as well, because I think it's... If you don't want to write too much CSS, then you can just rely on that and customize it a bit, and it will look good enough.

 

Yeah, you know, with with view component, I was kind of hopeful that there would turn into some kind of, you know, front end library available that would snap into Rails, right? Which I know there is some work out there to make, you know, component view components like this, like mate stack as an example, which is built on top of view. But it hooks into Rails, because a lot of the back end can be written in Ruby. for some of the components, right? But I was hopeful that we would get that kind of which I know ViewComponent isn't part of Rails and I know why there's hesitation. But it's just I have a feeling, you know, we just keep recreating more alternatives too, right? To do these same things where we have these isolated things that we want which basically is where TurboFrames is driving, right? Is you have an isolated component and you want to update its state and, you know, swap it out with things. But there's no like opinionated way to display that, right? It's

 

Yeah.

 

use that use one of these frameworks if you want that kind of functionality, right?

 

Yes.

 

Oh yeah.

 

Yeah, I agree. And also probably is one of the reason like why less and less people are using Bootstrap today because they want their website to look more unique. And this is one of the pains I have with Bootstrap is like when I use it and don't heavily customize it, then the website ends up looking like all the websites. And yeah, so this is probably something you can't cut, you know, to have a really nice design, then you have to write your own CSS. There is no way around.

 

Yeah,

 

I mean,

 

but yeah,

 

the

 

you

 

advantage.

 

can you can bolt stuff on top of it to give it a different enough look anyway go ahead Valentino

 

Yeah.

 

I was just going to say that the advantage to something like Bootstrap, especially now with the current version, is like that, you know, you could buy a new Bootstrap theme that could make it look unique pretty easily and you didn't have to do any work.

 

Hmm.

 

And we don't really have that in Rails other than using Bootstrap and buying a theme for it, right? Or some other alternative, like there are Tailwind ones too. in certain ways and it forces you into whatever pattern that is. And that's kind of where I'm getting at is like, we have no kind of framework to inject some theme into it. which could be beneficial, right? Like I understand Dave, your point. We don't want everything looking the same, you know, for sure. And if we had a default, maybe that would encourage it to look the default every time for sure. You know, I certainly don't want to customize CSS if I'm just trying something out, right? But I don't want to customize CSS either way, to be honest. So I don't know where the best thing, I just know that there could be something extra that could be provided standardized right

 

Yeah, that would be nice. And I think that Joel Draper, who is creating Flex, but I don't want to speak for him. But I think it's one of his ideas, to have a standard library of components that you could just use, like view components. So it's kind of the same idea, but you would have some default styling. And probably it would be nice. not 100% sure it's going to happen soon. So we have to ask him.

 

All right. Well, anything else we want to jump on here before we do picks? All right, let's do picks. Dave. Share some pics. Cool. Valentino, what are your picks?

 

So I have two picks here. My first one is my coworker, Ben Simpson. He wrote this awesome article on how we're integrating Neo4j into our stack and building a kind of a data

 

Thanks for watching!

 

pipeline. If you're not familiar, Neo4j is a graph database and we use it for a lot of connecting data. It's super fast and makes things much easier to use than a traditional relational database. And my next pick is Ruby Kaigi's going on. I'm half following along with their virtual event where I can, and I'm really excited to dive into some of those videos as they come out, probably in a few weeks. So check those out.

 

Awesome So I'm gonna throw out some picks. I managed to get around to playing board games with my friends again, so I have new board game picks. Of course I have to go find the name of the game, so. So, I have to go find the name of the game, so. Let me talk about some other stuff too while I figure it out. Oh, here we go It's the game we played was called Irish gauge And It's relatively simple Board game geek gives it a weight of 2.36 it is we were joking, but it really does kind of Line up with it It's kind of a mix between a choir if you've played a choir if you haven't I should pick that next week because it's a fun game. But acquire and ticket to ride. And so effectively what you wind up doing is you build trains between cities in Ireland. And you can take actions like build trains. You can buy stock in the train lines. You can upgrade a city, stuff like that. and I've really, really enjoyed playing it the other night. They have two follow-on games with it too, and I haven't played those yet, but they get progressively more complicated. But anyway, Irish Gauge, you can play it with three to five people. We played it with four. And so yeah, you build the train lines out, and then when you call for dividends, then you look at the number of cities that it connects to of certain kinds, and then you pay out the money, right? And you could do dividend, dividend, dividend, right? And run the game out of money, I guess. But anyway, it was really, really fun and relatively simple to figure out and play. In fact, the instructions for the game, if you've ever played board games that have like a booklet that come with them, here's how you play the game. This one, it was one sheet front and back for the direction. So it was pretty simple. I think it took us about an hour to play it. So I'm gonna pick that. And then I've been playing with some stuff. I have been banging my head against the wall with like building courseware and stuff in Rails. And I've kind of been playing with Kajabi again, and I'm really liking it. So I'm gonna pick Kajabi. It doesn't give like the exact structure I want, but I think it gives stuff that I can use. And I wanna start putting stuff out there for people to use. So, Anyway, that's one thing I want to shout out. Then the other thing I want to shout out about is... I'm getting pretty specific on the things that I can help people with in their careers. Just kind of figuring out what you're going to do with your career and how that can make you happy and finding fulfillment and maybe doing something that's a little bit outside the mainstream of working 10 to 15 years in order to become a top-end, highly demanded senior developer and instead maybe be putting out courses or working for the company. company that really, you know, hits all the check marks that you have for the kind of job you want, or being able to move up more quickly than, you know, waiting around for the three, five, or seven years or 10 years or whatever it's going to take for them to want to hire you at the level you want them to. And I've kind of skipped a lot of steps in my own career and made it work. And so I want to show other people how I'm doing that. So if you're coaching on any of that stuff. I'm kind of working out my signature method for that and helping people figure out how to be trailblazers in their own careers. I'm going to be able to do that in a few years instead of a long time. So if you go to topendevs.coaching, topendevs.com slash coaching, you can get on a call with me and we can talk about what you want and how you can get there and how I can help you. So I'm just going to throw that out there as something that I'm doing. thing is I am starting a developer book club and we're gonna do weekly calls. I have enough connections to where I can typically get the author and if I can't then I can typically get somebody who's enough of an expert in whatever the book's about to come and you know participate in the call. So if you're interested in doing that just go to topendevs.com slash I think I'm gonna put but we'll just do a book every month or two, depending on the length of the book and the amount of stuff we have to cover. And we'll just kind of roll through them. I haven't picked the first book, so if you have thoughts on the book that people ought to read, let me know. But anyway, those are my picks. Alexandre, what are your picks?

 

I didn't really prepare a pick, but I watched one conference of the RailsConf. I don't know if it counted as a pick, but it was the one

 

Yeah.

 

on ActiveRecord. I have to find it back actually. It's a conference that explains the main classes of ActiveRecord and how they work together.

 

Oh cool.

 

And it was really, really, really interesting. Like my favorite talk for this year, I just found it back. So it's called Reflecting on Active Record Associations by Daniel Coulson. It was really, really interesting. Like in 30 minutes, you know the main classes, what they do, how they're linked together. And you can start, well, reading the source code of Active Record if you feel like it. but yeah, it was a really great talk.

 

Cool. All right, if people want to check out your tutorial or get in touch with you some other way, how do they find you?

 

You can find me on Twitter, my Twitter handle is alexandre underscore ruban and the tutorial is on hotrails.dev so you can find me there and my Twitter link is also on the website

 

Awesome. All right, we'll go ahead and wrap up here. Thanks for coming. This was a lot of fun to kind of dive into and talk about. And until next time folks, Max out.