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