Hey, welcome back to another episode of the Ruby Rogues podcast. This week, I'm your host, Charles max Wood, and I am talking to Ayush Nuwatia. Did I get anywhere close on your name? Yeah, coming to us all the way from London, and yeah, I ran across i USh. I don't remember if we bumped into each other over something else, or if I reached out about the rails and hot Wire codex or something else.
I've been getting into hot wire quite a bit. Most of what I've done is uh, stimulus, but I'm starting to pick up turbo and I'm definitely interested in seeing what strata can do for me. But yeah, so the codex, it looks like is is it a course or is it a book? It looks like it's a book. It's a book. Yeah, it's an ebook. Yeah, it a comprehensive ebook that I got it printed just for keepsake. And it's honestly more like a brick than a book. Oh
wow, it's that big. Huh Yeah. Yeah, And it says it says written by human not by AI, which, well you did it, you did it in hard mode huh oh yeah, I don't believe in shotcuts. Yeah. Well sometimes the shortcuts help. But yeah, I've seen people that yeah they do they do most or they have AI do like ninety nine percent of the work, and yeah they miss stuff, or the AI gets stuff wrong that they don't catch, or any number of other issues. Yeah, so you got to write the book you wanted, I guess, is
what I'm meaning at. So, yeah, pretty much like a lot of the stuff in the book, I was actually learning while writing. And I find that the best way to learn is to do it on what what you called hard mode, because you tend to go you tend to go down dead ends, you go down other paths, and you make mistakes and you learn
from all those things. You learn things you didn't expect to learn. And for me, that's the right way to go about it because that gives you a lot more context than just asking an EI a question and getting an answer back that you can't actually be sure is accurate. Right. Yeah, I like that too, the kind of the idea of learning as you go. And I wrote a book about finding a job. I feel like things are
shifted some so I need to rewrite it. But it was the way that I found jobs for the first fifteen years of my career, and yeah, it was interesting, like going back and seeing what was out there today and how that worked and stuff like that, and so yeah, I feel that quite a bit. But yeah, it's tough writing books a ton of work. Yeah it was. I mean I thought it was going to be pretty hard, and it was way harder than I imagine it could be. It
took about twice as long as I had anticipated it to take. Yeah, it was quite an undertaking. It's it's definitely the most challenging thing I've ever done in my professional career, but so far it's it's also been the most
rewarding. So I took eight months completely off client work to write it, oh wow, because I'm a freelancer and I was trying to do it side by side with client work and it just wasn't working for me because it's quite a Writing is quite an intense mentally intense task, and after spending like four or five hours a day on client work, I just didn't have enough in the tank to then put in some properles for writing. So I was like, while I'm still excited about the idea, let me try and see it
through. I'll take three or four months off surely that'll be enough to write it, And eight months later I still hadn't finished it. So it was a bit of quite a big financial hit. But in the long term, I think it's all been quite worth it because it's really helped my freelancing career as well. That's awesome. So the book goes into all kinds of stuff.
I'm assuming it also does Turmo Native. It does. Yeah, so it's well, I mean I would say this, but I think is the most comprehensive resource out there on rails and hot wire because it covers all the bits. Like it is primarily a book and how to build a rails app, but where it kind of does things that other courses and books don't is it firstly does quite a lot from ratch, so like I use very few
gems, so like authentication, all that stuff is from scratch. And the other thing is it teaches me. It teaches native apps as well, so it's not just build a rail's website, it's build a rail's website, iOS
app and Android app. Oh wow, that's awesome. Yeah. We had Joe Masilotti on a while back to talk about Turbo Native and it looks really terrific as far as it goes, and you know, I mean I've talked to some people and they just want that native, full on native experience where you know, you load the data onto the phone, you know, so you're hitting APIs and then you're you know, loading native components and stuff like that. But some apps, So the thing that I've been looking at is
building like a media app for podcasts and videos and stuff like that. I guess you can have your media downloadable, you know, to the point where you can watch it on the phone on more I guess of app, But for the most part of people are going to stream it. I don't see what the difference is, right, Yeah, Honestly, I think there is
a huge misunderstanding around the actual benefits of native apps. Like for some use cases they are the best tool for the job, but for a vast majority of use cases, a well executed hybrid app will do the job really well because a lot of the arguments are usually here for native apps, as things like offline use and just the fidelity of the UI and things like that. But I used to be a native app developer, so I only switched to
rails in twenty twenty. Before that, I spent five years doing iOS and Android development, and I worked on a few apps fort at an agency, and then I worked for a company called answer Whys now known as YS and our dirty little secret was that the apps were fully native, but they were
useless offline. They were completely and utterly useless offline. Like I can't comment on the state of the app now, obviously because I left the company five years ago, but when I worked there, every screen made like a minimum of half a dozen API calls and then rendered native views based on those API calls. Yeah, you got any screen, you will see your loading spinner. It's not going to load instantly. There is no offline persistence or anything
like that. So if you were going to add all those things in a native app, in my opinion, the level of complexity is about the same as doing it in like a web context now because with things like service workers, you can make your web app and a hybrid app work offline just using web technology, and I think the challenges and complexities of doing it that way are very similar to the challenges and complexities of doing it the native way.
Now, there are great arguments for using native apps, and if you're going to have like tight integration with stuff like GPS and all that kind of thing, and you need like a really high fidelity UI which is not properly serviced
by web technology. Like my favorite example to reach for is Uber. If you are building Uber which doesn't really need a web app, but it needs top notch native apps because like there is no use for Nuber website, but there like it's it's pretty much exclusively going to be used through mobile just because of the nature of the app. That is, when you go fully native, because your entire business depends on the mobile app and you need the best
possible experience on it. But if you build like a a crowd app, which I think, like, I mean, people won't like to admit it, but eighteen ninety percent of weare apps are just crowd apps, then yeah, true, Yeah, then a well executed hybrid app using something like the Turbative very similar philosophy will do absolutely fine. Yeah that makes sense. That makes a lot of sense. I kind of want to dive into more of the hot wire stuff here. So the codex you actually build out an app.
Yeah, that's right. So, like you said, it's it's almost more. Here's how to build an app with Rails. Yes, yeah, it is pretty much that. Like the fact that it teaches native apps and the fact that hot wire is a core part are all just kind of add ons to it. The core proposition is, here are all the tools and
techniques you need to build like modern rails applications. Because my vision for it was to be the next step after the Rails tutorial by Michael Hortel, so because that's how I learned Rails, and I think it's a rite of passage
pretty much for every Rails developer to work through that book. But after I finished that book, I didn't know where to go next because it teaches you the basics and it does that really really well, but you need a next step, right, Like, I didn't really know where to go from there, and I was learning quite a lot when I was just starting with my
freelancing career and stuff like that. So I thought I'd put my slightly unique career trajectory of having specialized in mobile apps and then having switched to web to some use and write a book on how to build modern Rails applications and as a unique selling point throwing the native side of things right. So yeah,
so I guess I guess. One of the other cases that I know some people have to make is why then use hot Wire, Stimulus and friends instead of something like React or view or Angular or one of these other heavier duty front end systems. It's I'm not the best person to compare and contrast because I've never used React, So my pitch for it would be React and stuff
have a very different philosophy. They kind of take away your apps front and you don't really write htble and CSS, you right react goud and true. I don't really see the point of building model and web applications that way in like with an all in kind of approach, because he just like, the web platform gives you so much out of the box, and it just feels like React as the philosophy has said, you know, we're going to take everything to the web platform gives you, throw it out of the window and
then build it back but worse so. So that's just not a philosophy that I kind of buy into. I like writing HTML and CSS, and I like enhancing that with JavaScript. I believe that HTML is a declarative UI programming language, which I know it's it's a statement that could start fights on the
Internet. But that's my stall and the reason like the hot Wire approach kind of fits my brain so well is that philosophically, it's exactly the same as it was building websites like fifteen years ago, when it will all jQuery and jQuery UI, when you still wrote HTML and CSS, but you had this crappy procedural JavaScript code on top of that kind of doing all the dynamic stuff.
So we moved away from that and we have excuse me, much better way to kind of structure JavaScript now, so we still retain the philosophy of you build your core UI in HTM and and CSS and then you enhance it with JavaScript with hot Wire. With Turbo especially, you can get so far without writing any custom JavaScript at all. Just data attributes on HTML take you so far because Turbo Drive in itself is just a huge performance boost because you're
not doing full page realer gerony reloading the body element. And now at Turbo eight you also get like prefetching, so when the user hovers over a link, it'll prefetch and cash the response, so when you click the link, it's almost instantaneous the transition. And that's like without writing any JavaScript yourself.
At all, and then you throw in turbo frames into the mix, which kind of lets you break the page down too smaller chunks and then update those chunks independently of the rest of the page, again without writing any custom JavaScript
at all. You just get so so far with so so little. And let's say you have certain parts of a page where it's really really interactive and you really need to build out something complex, then you would probably just throw in a JavaScript framework for that little a piece of like me, you're building like a car configurator, which is a really complex piece of work, right
because it is lots of logic, lots of moving parts going about. So for that little island on the page, you'd probably throw in a framework. Like I couldn't tell you whether i'd pick React of You or whatever, because I haven't used them, so I couldn't tell you what I would use. I'd need to research it. But you would choose a framework and throw it in for that tiny island and the page, But the majority of your website would still just be using HTM and cs as just the way I think the
web platform was designed to be used, right. That's just my ty cents and the whole thing I think we've gone down this rabbit hole of complexity that we just need to go back from a little bit. Yeah, I'm just going to add a couple of things because I've done some React and what I found is, yeah, I mean you talked about the complexity, and you've talked about how it kind of takes over your page or takes over you know,
whatever you put it into. One thing that I found is that so typically when I see people building a React application, what they're doing is they are essentially working off of something like Prisma or you know, some back end API system that just delivers an API and then they build everything else on React. And that makes sense from the standpoint of right, you're only learning one system and so then you're building it out. I found the whole process of
putting together React components just to be really, really clunky. And you know, there are things I like about the idea of JSX where you're putting your effectively from the rail standpoint, you're putting your view, controller and model in one file file. But what I found is that people tend to still complicate that way more than it needs to be. And then the other issue is is that, yeah, like you said, you're not really working in the
web medium anymore. You're working in the React medium. And what I've gotten to love about Ruby and Rails and hot wire is that I just add stuff in where I need it, I kind of enhance it where it makes sense, and then you know, just kind of pull in the pieces where they they tend to work well, and then I get to work in the web medium. So exactly. Something that I kind of learned back when I was a native app developer is that if you fight against the platform you're working with,
it's never going to go well. So especially like on iOS, which I specialized in towards the back end of my stint as a mobile developer, because and roads just too Leanna, I can't be bothered with this anymore. An iOS, there was a proliferation of really complicated patterns, Like you know how tech goers, right, things come in and out of fashion, so there were it was just becoming fashionable to use these really complicated patterns, like
there's one called viper, which I load with an unbridled passion. Uh. And all those things did was they fought against what the iOS platform gave you. So like the iOS runtime has a lot of similar philosophies to Ruby, like in terms of things like metaprogramming and quote unquote magic provided by metaprogramming and all these patterns came in and said that, you know, we're going to fight against a platform that gives you all these things and rebuild all of these
ourselves by with these patterns and things like that. And it did my head in because it just made simple codes so much more complex. And I've kind of taken that learning into web development and said that if I ever find myself fighting against the browser, I'm probably not doing something right. I need to rethink my entire approach. And that's kind of where I am with the whole reacting. I just feel that it fights the platform instead of working with it.
Yeah, that tension is definitely there. I agree with you. So let's dive into what Rails and hot wire give you here, since I'm assuming that's why most people who are listening are listening. By the way, we have like sixty people on Twitter right now. I never say X because I feel dumb saying X. So yeah, I still call it twitter as well, so anyway, and everybody knows what I mean when I say Twitter.
So anyway, So in essence, I think the thing we've talked about the most is stimulus right on this show, just because I think it's kind of the I don't know if it's necessarily the easiest to understand, but it's usually what we're reaching for when we're trying to have some kind of custom thing on
our web page. Right, Yeah, exactly. Stimulus is the thing for which you'll actually write JavaScript code yourself, because turbo is more just to something you drop in and then you kind of call using data attributes in HTML. Yeah, unless you want to customize something. So yeah, stimulus is where you actually write JavaScript. Right. So I was going to say, let's let's talk about Turbo here for a minute. So do you want to just give people an idea of what turbo is and how it works? Yeah?
Sure. So Turbo's actually made up of three parts itself, turbot drive, Turbo frames, and Turbo streams. So turbot is like a natural successor to the library turbo links, which if anyone has worked with reels for a number
of years would be familiar with. It kind of builds on a concept called p jacks, which was I think pioneered by GitHub way back when So the core of turboat drive is that when you click a link, instead of like letting the browser do what it do, it does which is goes and gets the response, throws away the entire existing document, and then renders the response
that it got from the server. Turboat drive will intercept that link click and it'll make a fetch request to the path, get the response, and then just swap out the body element on the existing document for the one that it got from the response, and it'll merge ahead. So you still your your document still stays intact. If you're on a store some state on it,
you can. And it also helps with performance because you're not like throwing away the entire page and then downloading less and stuff again, although I mean that problem is a lot less obvious now with caching and HGTP too, but it's still it's still there visually, it does make a difference when the entire page isn't thrown away. And I think the biggest difference between turbot Drive and the
predeceassor turble links is that turbot Drive works with forms as well. So turbo Links was exclusively for link clicks, but for turbot Drive, it does the exact same thing for form submissions as well. Right, And the one thing that when I've found myself in discussions with people who only ever used React is they say, oh, what if you want a persistent element on the page. You can't do that with this approach because it's still a multipage app.
And Turbo actually has an attribute called data Turbo permanent, so if you put that on an element, that particular element will be persisted across page loads. So like, so let's say you are you had like audio player or something that was playing sound, but you wanted the user to be able to browse your website while that was still playing. You just set this attribute on that element and it would just be retained. It would still be there across all
those multiple page loads. So you still have like a multipage architecture, but you have the behavior of a single page application. So I think that's a great, great approach to kind of just simplify your architecture. So that's like, yeah, so that's like Turbo Drive. Turbo Frames kind of takes a similar concept but localize it to like smaller parts of the page. So let's
say you have a page with a lot of content. And then you have a turbo frame on one small part of the page, so that turboframe is basically just a turbo dash frame htmltag which is implemented as a custom element. And then any link clicks or form submissions in that turbo frame will expect a corresponding turbo frame. So the I D of the of the frame that the call is made from, it would expect an I D a turbo frame with that same I D in the response. And then instead of replacing the entire
body element, it would just replace the contents of that one frame. So you can make very like uh, you can decompose your entire page into smaller parts using turbo frames and then update just those parts. So that's just taking the whole turbo drive concept and making it a bit more powerful. And just these two things I think takes you so unbelievably far without writing any custom JavaScript,
right. Can I ask a couple of questions here on this because well, for one, so turbo you said turbo drive, and I guess turbo frames as well work on both link clicks and form subeditions. Yes, so I'm looking at the turbo page. So for example, it has like an edit this message link, so if you click that link, it would just replace the contents of that frame with I'm assuming your rails just renders a partial
with no layout and it just drops it in there. Yes, exactly, So you can either yeah, just render the partial with no layout, which would be the more performing thing to do. And I think I think there is a help in the Turbo rails gem that does set the layout to falls
if it's a Turbo frame request, but I could be wrong there. But you don't have to do that because all the Turbo really wants in the response is a Turbo frame with the with the matching I D. So you can have a full HTML document that you send back, but Turbo will only remove the corresponding Turbo frame and then replace that, so you can be right, Yeah, you just got to get the idea, or you can sign whatever back from the server as long as it has a Turble frame with the I
D. Okay, that makes sense. So one other thing, and we might dive into turbos streams here a little bit with it. But and I have to admit, like like I said, I've done I've done a bunch of stimulus freaking love it. It feels so easy to follow along with when I'm doing stuff. But yeah, Turbo's kind of new to me. But I'm looking at this and I'm going this seems like I think I've done some of this stuff with stimulus, not realizing that Turbo did it for me.
So one other thing that I have a question about, and this is something I ran into last week. So I've kind of been looking for work lately. The contract I was working just slowed way way way way way down, and so I applied to this other It was kind of a contract and they
sent me basically I'm rambling, I'm talking way too long about this. Anyway, they told me to build them a sample app, and I spent I think three hours debugging rails, sending a Turbo stream request back when I submitted a form, and then not actually loading the page right when it got a response. Like I could see in the rail server that it was hitting that back end endpoint and that it was doing the work to you know, render the other page, but it was right, it wasn't rendering the page.
And so I'm curious, is there something fundamental with like just maybe I had the wrong idea on something or didn't understand something fundamental about how rails works with Turbo to manage forms that I did wrong, because eventually I just found I found the key word. I can't remember which one it is, but the keyword to just turn it off. I think it was remote false or something. Okay, Yeah, So were you sending a turbo stream back from the
server or were you sending a full page? I don't remember it was requesting a turbo stream. It was showing up in the log as turbostream. Okay, I don't remember if it was it was sending back. Because so Turbo has a requirement that on a firm submission you either render a turbot streams that has to have a mind type of turbous stream or I or you have to redirect. You cannot you cannot render HTM and okay, so that that's a
feature of turbo streams. It's a it's a requirement of Turbo. So if you look at the Turbo docks, somewhere there is an explanation for it. I can't remember. It's something to do with clicking back. I can't remember the exact experts in it's in the docks. But yeah, you have to either render a turbot stream or redirect on a farm of submission. That's a requirement of turbot drive. Okay, so what is the turbo stream then, So turbo stream is also a custom elements or just turbo dash stream and it
okay, hang on time out for a second. So when you're saying I needed to render return turbostream, I was still returning HTML. I was just it needed to be in a turbo stream element. It needed to be in a turbo stream element. I needed to have a mind type of whatever the thing is, VND turbo stream whatever it is. The actual Yes, a turbo stream has to be in a turbot stream tag. That's what makes it
a turbo stream. And that kind of gives you what I what I describe in my book as a scalpel to make fine grained adjustments to your page. So, uh, turbot drive and turbo frames both have quite like general approaches to making updates. So you like either change the entire page or a whole
portion of the peature. Let's say you want to target one tiny thing like a counter or something somewhere, and you want to change just that, So you would render a turbo stream with a replace action, and then in the content of the turbostream targe you put the new content and then turbo would I would use the target attribute of the term stream tag define the element you wanted to change, and then the action you define is replace. It will replace
the targeted element with the contents of the turbostream tag. Now there are I think got seven or eight crowd actions that turbo streams give you out of the box. I think like a pend and replace and update. Can't remember all of them, it's in the docks. So those kind of those are the updates you can make using turbo streams to very specific elements that you target using either an ID or a CSS selector. So you can make like really targeted
adjustments to your page. But it's quite easy to let things get out of hand with turbot streams because if you find yourself making quite a few updates, you're probably doing something wrong. It's really stuff that's really targeted, really fine grained, really one off that you kind of want to be making with turbo
streams because especially now with Turbo eight. So I'm going to segue into Turbo eight a little bit, because everything we've spoken about so far has been in Turbo in some form or the other since Day one, which was Turbo Turbo came out with the version seven to match Rails's version, So that's a bit of counterintuitive, but I digress. A. Turbo eight has this new feature
called page of fresh is using morphing. So a common pattern in Rails is you kind of make a change to an entity and then redirect back to where the user was. So let's say the user is on forward slash posts and you have an index of posts with like delete buttons, and the user clicks delete and then the controller action will redirect the user back to posts where they already were. But obviously what they'll see is that one post that they deleted
it should now be missing because it's been deleted. That's like it's a very small change on the page. So in the past, you would probably render
a turbo stream that targets that particular posts entry. It will probably be like an ALI element or something, and it removes it from the dome, or you would do like a full page load, which is obviously more expensive and it's a bit jarring for the user as well, because like let's say it's a long list of posts, and the scroll like halfway down and then they click delete and you do a full page load, it will take you way
back, right back up to the page right. So eight kind of attempted to solve this problem without adding any back end complexity, because if you use a turbo frame, you're adding more logic on the back end. So it uses a library called idiomorph and it uses that to just morph the new page into the old page. So by that what I mean is it kind of makes it diff of the two domes and it only makes updates for the things that have changed. Right, So you can opt into this on a page
by page basis with a meta tag. So now, if let's take the same use case and you've opted into morphing page refreshes using the meta tag, you do the exact same thing on the server in the in the destroy action, you delete the post and you redirag back to the to the post index. H but on and on the server obviously you render the entire posts index.
But now what turbo will do is because you've opted into morphing, is that it will diff the current dorm with the dormant gets from the server and then just morph the two so as a user, your scroll position will be retained and all you'll see is that that one post that you de it has
been removed. So after this new edition, the use cases for turbo streams, I think, just drops down significantly, and you already really want to be using it very sparingly when there is no other option, because it's the kind of thing. It's the kind of thing that I think you'd refer to
as a sharp knife in rails. I know that it's a phrase that you used quite a lot with both Ruby and rails, and you want to be using them when the time is right, and not just across the boat, because it's quite easy to make a mess, right, that makes sense.
Yeah, I was at Rails World last year when David I don't know why I was calling David instead of DH but when David was showing us Turbo eight with that feature where I think what he did was he had like a conbind board and yes, and so he you know, he dropped in a new column and then removed it, and he showed the old behavior where when you would do that, it would, yeah, would jump to the top. And then afterward he said, now it doesn't do that basically, so yeah,
I think I think that was from horz Talk. Actually, he's the guy who I think spearheaded the whole morphing effort, and I think that was the the use case for which it was developed and then extracted into turbos. I think that can band style interface in base Camp. And I think probably hate calendar as well, So I might have been hate calendar actually, but yeah, it was. It was That's the reason for which it was developed. So turbo links is or yeah, not turble links, turbome Turbo native.
It's a wrapper around your web application essentially. Yes, So okay, let me zoom out a bit and explain exactly how debonative works. So there are a few approaches to hybrid apps, because hybrid basically means you're mixing web technology with native technology and using both together. That's where the term hybrid comes
from. A lot of apps do that. Though. We had an iOS show on this network for a long, long long time, went on hiatus in November of twenty nineteen, but that was one of the tricks if you had some UI that wasn't how do I put it, It wasn't exactly what Apple gives you in their UI kit, then yeah, a lot of people would pull in web technology and just seamlessly lay it in there to get what they wanted. So this isn't a new idea by any means. It's not
a new idea. I think what derbonative does is just standardize, standardizes it a little bit. So actually gave a talk on this at a couple of conferences last year called native apps are dead, long lived native apps because it's I'm honestly astonished that the determinative approach isn't more widely used because what it does is it builds the backbone of your app natively, so all your the navigation and stuff like that. And let's like, let's say you have a tap
bar, which most apps do. Those are all built natively. You're not gonna get You're not going to get away from having to write swift cotlan. You're going to have to write some native code. You're going to have to
have an excurt project and an Android Studia project. But what turbinative does is that instead of like rendering uh, instead of you recreating each view in native code within that kind of backbone that of the native elements, it renders web content, So you have your navigation bar at the top, you have your tap bar at the bottom, but in the middle where a content is,
it's just a web view with HTML in it. And that I think is really powerful because stuff that's kind of just users expect out of a platform is just there. Like on iOS, when you kind of go forward through pages, you can just swipe from left to right to go back. Stuff like that just works out of the box. iOS just gives you that kind of stuff out of the box, and since you're working again, you're working with
the platform, you get all that stuff for free. So Turbonative just standardizes that kind of architecture so it when you start up a Terminative app, it will install itself that it's the Turboonative part of the library will install itself as an adapt on Turbo itself, which is the web part of things, and it kind of hooks into that whole mechanism to kind of trigger native code.
So like let's say, when you tap a link in a Turbinative app, instead of just making a fetcher question and replacing the current body, Turbonative will now get the response, create another screen like a view controller, an ioas sort of fragment or Android and it will slide it onto the screen from right to left, So that's like turbinative. The library does that for you,
So that's kind of where it comes in. It's just kind of like adapter to help you build apps which render web content within this native frame, which I sometimes refer to as a custom web browser. So you're kind of just running your web app within a custom web browser that you've built yourself using native app technologies. Gotcha, So I guess a couple of other questions I have are you know, just kind of the things that don't that aren't built into
your application. So for example, what if you want it in in app purchases or well, let's just talk about in a purchase for a minute, right, So, because you have a native project, your app is basically still an expert project or an andro Studio project, and you are writing some Swift code or coughtland code, you have access to all the native APIs,
right, so you can just write native code to do that. So like like in AP purchases, for example, Apple would have APIs for that, so you just write swift code and then you'd have some kind of way to communicate that web app, either you're hitting an API or some of that. Like obviously the exact architecture would depend on your use case. But because like the native side of things has not been like hidden away or abstracted away,
you can do anything native that you want. I got you. So let's say that I have a button on my application, and when you tap the button on the web page, it takes you to the stripe form. But on the on the native app, there's some way for me to trigger the native API that says this isn't in that purchase. So that's why Strata comes under the picture. So both iOS and Android have native APIs that let you communicate to and from JavaScript. So you can from JavaScript you can post messages
a quote unquote post messages that are received in native code. So you can like call like whatever the method signature is dot post and send some Jason and then uh, a fully native native method in Swift or Cortland will be called with that Jason message that you that that you sent from JavaScript. And to go the other way, you can evaluate JavaScript within a web views from native code. You can like literally call like web you' thatt evaluate JavaScript and pass
in a JavaScript string which will be executed in your web page. So Strata takes this pathway and gives you an abstraction layer to communicate from web to native and vice versa. So it's built on top of Stimulus, So it's basically it gives you a concept of components. I think it's called a bridge component, which is which is a subclass of a Stimulus controller, and it gives you just some standard methods to send messages to native apps. So you would
have a component. So you need to subclass bridge component and create a component for yourself on the web and then create a counterpart component in your native app using native code, okay, and then that using Strata. The two would communicate with each other like on a Podcast's kind of hard to go into the details because it's all get Curry, Curry, but that's basically the gist of it is you have fully native components and then the same thing on the web
and then they communicate with each other. And that's how you can send messages from the web to native and back. So your exact use case, we can accomplish that with Strata. I gotcha. What about push notifications? So you would have to write some native code for that. You need to like register push notification token with your server and stuff like that. That's what it's
it is fully native territories. I wanted to write about that in my book, but as I dug into it, we were going too far into fully native world and I wanted to stick to like just like Web in the book. So it's the same kind of technique as you would use in a native app. You do it the same way on the back end. Again, you just need to google, like how do I send Apple Push notifications from
a Rails app and follow the instructions. And I think Rails eight is actually going to have a framework called Action Notifier, which kind of healthy sid push notifications, I think, both on the web platform and on iOS and Android, So that should hopefully make life a lot easier. I feel like I lucked out that the other guys didn't show up, because now I can ask I got to ask all my dumb questions. So because yeah, I mean, this is all stuff that I've wanted to do for a long time that
I just haven't done. Yeah, I'm not sure that there's a whole lot more necessarily that I need to dive into. Rails uses a lot of the at least Turbo by default. I don't know if it pulls in strata for
anything, since it's a native bridge. But yeah, so let's say that you were going to build like a complete ecosystem on your Rails app, right, So you were gonna and the thing that I keep dreaming of is kind of a Netflix for developers, right, so it's, hey, you know, you've got all this content from all these series, shows, podcasts, whatever, right, and so you can come in and you can get any content that we've either created or licensed, right, And so you know,
building the Rails app, and then you know, I can totally see doing something with say Turbo where you know, it's like you click the play this video button, right, and then it just you know, replaces parts of the screen with relevant stuff, or if it reloads it, right, maybe it just does Turbo drive and just you know, replaces the body. However I want to do that, you know, So I can see a lot
of ways that I can make that do what I want. I'm pretty familiar with Stimulus, but I could build the native app right and just do Turbo Native and have it load up the video library. I guess one question I have is is, yeah, is there a way to do how would I do the offline mode? If somebody wanted to watch one of those videos they
say this for later, right I'm getting on an airplane. Yeah, the best way to do it would be service workers, because you're kind of already in the web world, so like building out a full like native persistence architecture would be just a bit much, I think, right of service workers, That's how I'd do it. You have service workers go basically download the video and yeah, I want it. I can't comment on exactly how that would
work because I have a basic understanding of service workers. I don't have actually built anything with it myself, but like ninety nine percent show that kind of use case is perfect for service workers. Fair enough. I'm also curious, and I think I think the answer to this is going to be You're going to have to ask the Turbo team because what I'd like. The other thing I'd like to do is expand it to other parts of the ecosystem that's out
there. So lately I've been looking at I have like six or seven fire TVs in my house, right, firestick TVs, and so i'd like to, and you can load a web app in as your app, And so I'm wondering if Turbo or Turbative. I'm assuming turbonative doesn't apply there, but I guess maybe it does because you can also run it as an Android app. You build it an Android studio. So do you know much about that or uh? No, I couldn't tell you off the top of my head.
But if it kind of works as an Android app, maybe you could adapt it. I don't know the APIs well enough, because I mean, Terminative is very much built I think with the adoption, that's going to be a mobile app. So if the APIs, if the native apps, the native APIs are the same, like it's still using like an Android we have an activity and a fragment and stuff. If it's still using those same APIs, then it probably would work, But if it's different, then probably not.
Okay, is there anything else that I didn't ask about? Do you think people are going to want to know about? No? I think we've covered Turbo quite well. We could talk about stimulus if you want, but if you've covered that before, then I think we have. And we're getting toward the end of our time anyway, we've already been talking for fifty three minutes. So yeah, I'm also looking at bringing David or not David Nate Hopkins on to talk about some of the stuff that he just released, so,
oh nice, the other stuff. Let's talk about the codex here for just another minute. So you talked about you know, you basically took eight months off to write it. If people want to buy it, they just got railsand hot wirecodex dot com. That's right, and it's it's ninety nine dollars. But it'll write you through. It'll walk you through writing the whole
the whole mess. Yeah, so it teaches you all the rails, constitution frameworks are like active storage, auction, railbox, action, cable, everything, And it doesn't just teach you how to use them. It gives you an understanding of how they work. So what kind of really annoyed me. In most tutorials it will say that, okay, you want to get this working, write this code and it'll do what you want, and like,
yeah, well, I don't understand. You haven't given me any understanding of that code you just said, right this, So I wanted to make sure that every tiny bit of code that I teach in the book has an explanation of what it does and why I choose that approach, and if there are
any alternative alternatives what they are. So like, when you read the book, you should have not only a really good understanding of like the entire rail stack, how it works, and the different ways in which you can use it, but also like certain alternatives that are not covered in the book are
signposted. So like have a chapter on search which teaches search using Postgress's native full tech search, and there's an entire discussion at the end of that chapter about the different kinds of searches that Postgress off offers but that I didn't cover in the book when you would use those kind of searches. And then it also has a discussion on like mainly search and elastic search and when you want
to use those. So like all the questions that I kind of come up with in my head when I'm trying to learn, I've tried to answer all those questions, because, like it's I always find it quite frustrating when people don't cover things from all angles and editorial, so I kind of wanted to I know it's a cliche, but I wanted to write the book that I wish I had, So I've just tried to be as comprehensive as I could. I know that's kind of made the book quite large and maybe not quite
as easily accessible just because of the size. But I kind of on the size side of being comprehensive over the side of being succinct. All right, well, I'm gonna go ahead and pick push us into the the last part of our show, and that is picks, and then we'll wrap up. I'll go ahead and go first, and you can kind of get an idea of what's involved, so picks or just shout outs about stuff that you like. I mean that that's essentially it. So some people show up and they
pick a bunch of tech stuff. Other people show up and pick other stuff. I'm gonna go ahead and throw out some picks on my own. So the first pick that I have always do a board game pick, and I'm gonna pick a dice forge. So it's kind of an interesting take on deck building, except your building dice instead of instead of building a deck or a
hand. And so what you wind up doing is every turn you get an option of either grabbing a die face or you know, taking a card that gives you victory points and special abilities, and then you and you buy either one, so you either spend goal or you spend Sun or Moon tokens to get them. And then you when you buy die faces, you pull the face off of your dice and put the new face on and they're kind of
like legos that way, a very fun game. Played it last night with some friends of mine, and yeah, it has a Board Game Geek weight of one point ninety seven, which means it's fairly approachable for casual players. It went kind of fast too. I think we played it in forty five minutes, maybe maybe a little longer than that, pretty close, and we were teaching our friends how to play it. So anyway, really enjoyed Dice Forge, and so yeah, if you want kind of a different take on
yeah, on how that works, then that's awesome. I'm going to post to the YouTube and Facebook and stuff links to Board Game Geek and to Amazon where you can buy it. The Amazon link is going to be an affiliate link, just so you know, so if you buy it there, I get a little piece of the action. It doesn't cost you anything extra, it's just anyway. And then other picks. So I am on the tail end of a book series, and the book series the let me look it
up on my phone. So I've been listening to it and it's I picked other books by Brent Weeks in the past. This one's called Beyond the Shadows. The book is it's the third book in the series. I'm trying to remember the name of the book series itself. Title details, there we go. It's the Night Angel series. This is the third book in the series.
Anyway, I'm really enjoying it. It's about this kid who basically becomes an assassin, and there's magic and politics and anyway, it's been really really good so far, so I'm going to pick that the Night Angel series. The first book in the series, if you're interested, is called The Way of Shadows, and it looks like there's a prequel that's two hours long too that I haven't read. So anyway, it's The Way of Shadows and then Shadows Edge, and then the last one is Beyond the Shadows. So yeah,
really really enjoying that. Looks like there might be another series that's a sequel to it, because it says book one Kyler Chronicles and Kyler's the main protagonists. So anyway, terrific book. Really enjoying that, and then of course, just a couple of shout outs about Rails geniuses. I'm gonna start
inviting experts to come in and talk to us in May. If you sign up before May, it's gonna be me, and we're just gonna chat about what you want to learn and who I can get on to be experts to show up to some of our calls and make sure that we're providing you kind of the value you want. I'm also gonna let everyone know I'm still looking for, you know, freelance contract or a full time job if I have to, so that you know, I got to pay the bills. And
finally I got this set up when Monday. So if you go to Ruby Rogues dot com slash Premium and you sign up, it's nine dollars a month. You get all the shows without the ads, and I'm planning on putting extra content in there as well. So I was supporting the shows off of my contract income, and so I'm trying to find another way to do that too, and this seems like a good way. So you know, if we have one hundred or so people sign up, then it should cover most
of the costs of producing podcasts. So anyway, that's that's everything I've got. I USh, what are your picks? Right? So I think I'm going to start with a music pick because if you're watching on the YouTube and stuff, you can see a massive the case a CD is behind me because I am still that rare breed that buys CDs and exclusively listens to music on CDs rather than streaming sentences. So I'm gonna start at the past. Weird, yeah, and in my friend group we find people who don't buy CDs.
We had I'm like part of a it's definitely not a cult. Not a cult. We never call it a cult. That's what I say about my board game group. So I'm gonna start with a band called Life Signs,
who actually are actually oh nice. So yeah, They're a band I've been following for a couple of years and they are just absolutely fantastic, and I'm constantly astonished that they are still playing in pubs two hundred people rather than theaters to a few thousand, because the level of the music is just unbelievable. It's just yeah, they struggle to get the support of the industry, so I want to give them a shout out. So that's life Signs.
Highly recommend it to anyone who's into like rock music of any kind of description. I'm sure you like it. And I'll make a tech pic as well. So there's a reals dashboard library called AVO made Adrian Maren who also before have you. Yeah, it's also he also Yeah, he's the nicest guy
and he also runs a friendly that RB conference in Bucharest. And I got to use AVO for the first time on my current client project where we were shopping around for a few different admin dashboards and I was just kind of just blew the others out of the water, to be honest, Like I played around with some others and this was just the docs were unbelievably good. The UI is really good out of the box. Pretty much any question I had I could put into the docks search and I got an answer for it.
Yeah, highly recommendative. There is an open source free version and if you need something more involved, that are like paid versions as well. And yeah, AVO, AVO, dot, AVO, HQ dot io or something of that. I think is the u r L. You highly recommend it. For admund dashboards because I'm using it right now. Yeah, the U r L that I have is avo dot cool, but it redirects to avo hq dot IOK. Nice, that's a good r L. So yeah, I'll drop that in the comments. If you're on Twitter or YouTube or Facebook,
you'll see it show up in the comments. Unfortunately, Twitter, which is where most people are watching this, doesn't do the comments. So anyway, go find us on YouTube and you can get you can get it on the recording of the live stream and that's at YouTube dot com, slash at topendevs cool deal. If people want to connect with you Ayush, they have questions for you, anything like that, where do they find you? So best ways probably email or masterdon So my email is a us A y U s
h at radioactivetoy dot tech. That's my business website as well. Cheers. Yeah, that's my business website as well, Radioactive Toy dot tech. And I'm on masterdon at ayush at Ruby dot social. Those are probably the best ways. I do have Twitter, but I honestly don't use it a whole lot these days, so you may or may not get a response if you ping me on there, so email a master on is the best? All right? Good deal. Well we'll go ahead and wrap it up here.
Thanks for coming. This was fun. Thanks for having me. Yeah, I'd love to chat about Bridgetown some at the time as well. Yeah. Absolutely, well we'll get you on for sure. Sounds good. Thanks very much. Until next time, folks, max out