Events Add an event Speakers Talks Collections
 
RailsConf 2021
April 13, 2021, Online, USA
RailsConf 2021
Request Q&A
RailsConf 2021
From the conference
RailsConf 2021
Request Q&A
Video
Hotwire Demystified - Jamie Gaskins
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Add to favorites
7.99 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About the talk

DHH stunned the Rails world with his announcement of Hotwire from Basecamp. Even folks in the non-Rails web-development community took notice.

In this talk, you will learn about the building blocks of Hotwire and how they compose to create a streamlined development experience while writing little to no JavaScript.

About speaker

Jamie Gaskins
Masters of Arts in Christian Apologetics at Trident Technical College

Experienced Digital Broadcast Engineer for the Distance Learning and Broadcast Services Department, at Trident Technical College. Currently serves as their primary support for D2L, YouSeeU, EAB Campus, EAB Navigate, as well as an audio video engineer for Distance Learning productions and support with the post-production editing of digital media. Currently has earned a Bachelor of Science from Liberty University, two Associate of Science and five Certificates from Trident Technical College. As of this January the journey to a Masters of Christian Apologetics will begin.

View the profile
Share

Akron's, my name is Jamie Gaskins. And today, we're going to talkin about Hotwire by now. Many of you have seen base camps Hotwire announcement screencast showing how to create a, a real working, a real-time chat application with multiple chat rooms without writing, a single line of JavaScript. By the end of this talk. My hope is that, you'll understand some of the science behind the magic that was shown off in that screencast. He's our agenda for this session, going to go over some of the pieces of hot wire and how they how they impact, how you build your application. The

first work, I look at what hot wire is. The books of Basecamp call. Hotwire an alternative approach to building, modern web applications by sending HTML instead of Json, Hotwire is an acronym that stands for HTML Over The Wire. Dollar Tree website, lists turbo, stimulus. Instrata is being its three main components. The first people to talk about his turbo Turbo provides the most basic building block for building. Hotwire applications, turbo used to be called and its main purpose was to make web page navigation, Faster by preserving the rendering and JavaScript

execution context. So the browser doesn't need to completely tear down and reconstruct this context. Every time you click a link that still here in Turbo and you still get that functionality for free, just by loading the jobs for payload. It also provides whitcoulls frames streams and an action cable, integration, all of, which will go into more deeply in a few minutes. Even though turbo provides a lot of functionality out of the box, your application may have some features that don't fit well into its capabilities for those features. You can use stimulate the stimulus framework to

provide some custom functionality to fill in those gaps. You won't be able to we won't be going into Depp's on stimulus because we wasn't actually change how you work with stimulus controllers inside your real. That you still use them the same way you did without holler. Strada is a bridge that lets you write native mobile apps, using web Technologies. The base camp scene. Haven't really elaborated on this. But if I had to guess it's likely an API similar to some of the things that you find in three native ecosystem such as native push notifications in a gratian with your photo

library, or maybe some of the other sensors and apis that are available. Primarily a native apps. We won't be going over strata during this talk because it hasn't been released yet, and we don't really have a whole lot of information about it. Another thing we won't be coming over is how to compose all of these Concepts will be learning to make us like web app for that information. You might want to check out any of these talks at rails comp listed in the order. They appear on the rails,. Once we are going to be looking at how the things they cover in their talks, work under the hood.

That's a brief introduction. Now. Let's get to the fun pit. The fun. Did the first thing. We're going to look at our turbo frames. So, turbo Friends of the primary building block, for hot wire mechanically. You can think of them as a chunk of your user interface small Blobs of HTML rendered into the resulting web page. And somewhat Frameworks, these may be called components in real skull, small chunks of the UI partials components, partials and turbo frames are largely all the same idea and a lot of the time partials or how you construct your turbo friends. Both of you have an e-commerce

application with a product catalog. The product catalog itself can be a turtle frame. A niche product, inside the catalog can also be at the turbo frame, you can compose frames with another frames. It's hooked up here in the corner. We have some secondary content that can also be considered turbo frames. In this case, is our cart showing the number of items in our cart and maybe some order notifications. But why would we do this? If we have partials? What do we need? Turbo French for what makes for buffering. So special? Who sang? We're on the product catalog page? Will

hover over a product, it brings up in add to cart button. When we add an item to the card, we want two things to happen. The first, as we want the background of that particular, product to turn green like this other one that's in our cart, because that's the design language were pretending. It's a good idea to indicate that we thought of the product or cards. And the second item of second thing we want to happen is we want the badge on the cart to update to reflect a new item counterpart. What's considered that would normally look like in a real duck? We looked

at the card button, which sends a request to the server, the show requital some bits in the database and responds with a with a redirect redirect maybe to the same page. We were on it could be a free check out page or some other page entirely for the sake of Simplicity. We're going to go back to the same product listing that we were on. Now, the browser makes a second request after the redirect to get the updated page content. The server response with the entire page, the only things that actually changed or the one product and the Cartwright account, but we send the entire page

this can use significant server resources and potentially send a lot more bites over the wire. Then we need to actually help his face. So if you're using Turtle frames though, it's pretty easy to get just those two things back. The rest of the page stays as it was. And we're only swapping in those two HTML Snippets that we see down at the bottom here into the containers. We want them in. We'll look at how that works. Once we get a little further into the talk because there's one more thing that we need to cover to learn how to process turbo frame to the response. I never been we can do with

turbo frames is to delay rendering until after the primary content looks so like this secondary content up here. Let's say for example, these the cart cart item count and notifications count. Take a fair amount of time to compute. Maybe the database table that they're in there in are the Davis cables that are massive are the Quasar, very complex, or they may have to reach out to external services. Would you are loading the product catalog for doing it so they can look at those products and hopefully buy some of them. So we want to load that part as quickly as

possible. We don't want to hold our customers back from giving us money. The secondary content can wait until after the primary content loaded. And we can do this by pulling out the cart item count and the notification count Badges and replacing them with turbo frame elements with an ID and a source. Attribute. That source is what tells turbo to fetch the frame? The continent frame asynchronously after the page loads when the request comes back, if there's a turbo frame l in it with the same ID in the response, body, its contents. Get injected into this turbo for an element. One thing

you might notice is that were explicitly, closing our turbo frame, even though it's being loaded asynchronously with the forecast for Butte. So you can render a Content inside of that friend indicate that floating. Maybe maybe have a loading in Decatur, or a placeholder element because maybe you want to keep, I want to keep in mind that if, if, if you're loading, secondary content asynchronously you make, you might want to provide a placeholder element to make sure that when the content comes back from the server, it doesn't move a bunch of content around. When it's watch that

content into the page, trying to click something that then moves out from under your cursor because things moved around after content secondary combat. Loaded is a pretty poor user experience. We want to avoid that but in our case we're just loading badges to have no way out applications. When is the external response from the server contains a turbo for an element with a card out of my account ID turbo will insert its contents into this element? Real ghost resides this helper method, if you'd like to use that instead of an actual HTML tag. Emily. Had this

action in our controller, our cart controller. It will respond to the request, referring to the partial that we extracted the content for. And so, when we see this on page load for our cart, we see this after that secondary request returns. Northwest behind-the-scenes, look, something like this. Notice the, we have this turbo frame, turbo frame header in the response, sing part. I don't count. That's the, that's the turbo friend were trying to populate the term, the turbo Turbo JavaScript library, makes the request for

the content and it populates that header. So we can, we can use that header to make sure that we provide the right turbo for a 90, back in our response and rails uses this under the hood. There's still more that you can do with your boyfriend, supposed to get a lot of ground to cover. So when I go ahead and move on to Turbo streams. Turbo streams. Remember how we talked about a being able to send over just the content that changed on the page? Truest dreams are the concept inside of hot wire that enable that functionality. This is the turbo

frame for our car, an account. That's been after it's been rendered on the server. Noticed that its ideas part-time count and that's an important piece of information. We set our response in mind type to be a turbostream response with this content content type header. And then our turbostream payload looks like this. It started as Reid has the same as the ID is the same as the idea of the turbo friend that we want to update. The action is what we're going to do with the contents of this turbostream here were saying. We're going to update the target frame. Which

means we're going to switch out its contents with the new stuff. The stream contains the turbostream contains a template element this element. Let's turbo know that what's inside here is going to be the content. The Rena, perform the action with Do we perform the action? On the target with the template. In this case, the new contents of the cart item turbo cart item. Count turbo frame will be just as fan with the update account. The turbostream for the product index, index item is very similar to this stuff during the new markup for the item in the product catalog. In

this case, the action is replace. This just means that we're not just replacing the turbo frame. Contents, the contents, where were in this case. We're replacing the frame itself, as there's no reason why we have to use our place here. It just gives us an opportunity to show a different action that we can perform. Super using replace, we would need to also include the turbo frame element itself. Otherwise future Updates, this turbo friend won't be applied because the it was it was replaced with something that doesn't have the turbo frame with his ID. These are

your, we looked it up to you in her place and but there are five actions that turbostream can turbostream can perform out of the box update. We'll, we'll swap out the contents of the of the target turbo frame with the streams template template, to setting the inner HTML property on the turbo frame element with JavaScript. To replace action. Swapped out the turbo frame itself. Not sure if its contents. This is equivalent to setting the outer HTML property of the turbo frame. And put the contents of the turbo frames

turbostream template at the end of the target frame. This use of the JavaScript element. Append method on the turbo right now in it. Pretend put the contents of the target of the turbostream temple at the beginning of the target, turbo frame, this use of J. F element. Prevention method. I finally remove the roof action does natural need a template. It just delete the target turbo frame from the page. We talked about updating both of these elements on the page. One. When we add an item to our card. You can send as many turbo streams as you like in a triple cream response. This way our

application can make all the change. It changes. It means in a single response. This way, we don't need to make to, to request to the server, in order to update, both the cart item count and the and the the new product, the next item in the new version of the product index out of and that all the turbo frames, you specify here need to be on the page. Maybe you have a turbo stream endpoint that up. It's a lot of different turbo frames in various parts of the application. And that's turbostream, said to her play, nice to your responses. And next, we're going to get, we're going to get real real

funky with sending sitting turbo streams carry across websockets with action cable. In order to use action cable with turbo streams, you need to import turbo action cable, and turbo rails into your application. JS file. If all you want is true in action, table isn't the only lines of jobs going to need. You don't need a ride anymore. You need, you don't need to find special action cable channels, in JavaScript. It's all done, by a HTML and server-side Ruby code. Then in your HML, there's a turbo cable stream Source element that you can use to, to render the

that you can that you can render to connect the tutor boat, which I would recommend writing in my hand. Though. The turtle real gem has an active record integration that bay 64 in codes in cryptographically signs. The string names for all the models that you broadcast a B for using your real secret key. So the browser just needs to be subscribed to that. Same screen name. This is not something you want to do manually in your views. Internal rails. John provides a turbo stream from helper to generate that turbo cable screen, Force element. It's

super clean and you can you can provide either a hard-coded stream name as a string or passing active record model to it. And it'll generate the turbo frame ID the same way. It does the same way that the real turbo frame tag helper does This is the same one we saw before about how turbo streams have to charge a turbo Afraid by name action cable streams, have to be subscribed to the same stream. Name that your models are going to be broadcasting through everything and Hotwire hinges on the sending side and the receiving side agreeing on names. Now we have a bunch of Turbo frames and turbo

cable stream Source elements on our page. What happens when you add a turbo cables stream Source element is to your page? Is that it opens a web socket to your Apple Action cable on point. And subscribe to all of those strings that you have rendered trouble cable stream for Solomon's for we didn't write any JavaScript for this. All we did was rendering HTML element. When we imported turbo rails into our application. JS. This is one part of that job is proof that we got is a custom HTML element that defines the behavior of the turbo cable string for a solvent. We have the

element into the page, the custom elements connect to call back. Is it about the browser? Does this transparently, we don't have to do it ourselves and that that connects to action cable if it isn't already and then subscribes to the Stream. Likewise when the element is removed from the page. It's disconnected. Call back, is in a boat and turbo rails automatically. Unsubscribe me from updates, to, on this particular strain. Super example, if you want to hear turbostream responses filter, some of the products from the catalog, you'll be automatically unsubscribe from those updates. You

don't have to manually. Subscribe, unsubscribe. Any more action cable the action? Communication? In turbostream, handles it for you. What are you working on a feature? Where if a customer has just purchased the last of a particular product in your inventory? You want to update the item in the catalog to reflect a lot. So somebody doesn't try it at their card inside the checkout process. You can update all of the products that were in that customers card by calling this line of code on them. So, what we're doing here is for calling broadcast for place to on the product. Which

and we tell her which stream to broadcast on. In this case. It's the product index item with the product ID. And which partial we're going to render connection cable and what local variables. We need to be available inside that partial. That's what I look at the tree off between hot wire and single-page apps built with a front-end framework. Like react, for example. The trade-offs that we're going to look at our things like the effort required to build each app, how latency affects them differently differences, in how quickly users can interact with them performance on slow versus

Fast devices. And how the server communicates changes in the client responses. The first Rudolph, we're going to look at his engineering effort. There are a lot of ways we can look at this, but we're just going to look at a few for the, for the sake of this, for the sake of this talk. The first big one, involves getting dinner out of the database and into a consumable form. For the end, user will call this getting data from the database to the to the screen. I'll take another quick look at how this happens with Hotwire. Look at it before but we're just as a refresher. We send the request

from the browser to the server for the product catalog and the server responds with that, the contents of that page. We are delighted to the card. We get only the HTML elements that need to be changed. Add more understand, the engineering effort that goes into this. We need to look a bit deeper into the interactions of all the objects in play. The dependency graph here, shows, most of the pieces of the puzzle. There's a bit more to it. So just the application layout, template that defers the rendering of the cart item count. So I can put that on the slide. So, well, when we render, the initial

page, we've got our products controller index action. Which catches the products from the database, using the product model? And we're under, and, and renders them into the products index, template, which renders each product into a partial, which contains the turbo frame for that product. When we go back up to stack the product index template also renders the turbo cable strain Source element that activates, the action cable string for this product. Bring back up stack once we've done all that our Pages. Now, rendered. When a product is updated,

may be due to fulfilling an order decrementing inventory, count to zero, we may have we may have a broadcast called back on the model as recommended in the turbo Trails gym. Just call back would know which template it's rendering. and which action cable streaming broadcast to And that's enough of the dependency graph for, for rendering the price of the product on the page when someone adds an item to the cart. We insert or update the cart item using a cart item model. Evidently the broadcast, call back on the model, knows to broadcast an update with the contents of

this template. And again reminder to a string sent to this action cable stream, which of the car title model does need to know about that. May sound like a lot. There's a lot of dependencies there a lot going on but thankfully reels conventions make this a lot can make to make a significantly easier. This app has a multiple representations of a product in its you I it's hypothetical but you can imagine that even though we're only showing the product catalog, you can imagine it being rendered on a detail page Details page in the checkout page and probably in several other places.

Offer models that aren't used in literally. Every other part of the application. This can be simplified a lot. For example, the code we saw before where we specifically broadcasted the updates to the product index. For something for something that's a good model that is not used everywhere. It becomes this very simple active record, call back. Call back declaration. We just say broadcast. We don't need to specify IDs because rails will infer those the same way for helpers. Do we don't need to specify which partial surrender to the action cable stream

reason, which action cable stream. It renders to. We also don't need to explicitly broadcast the update. When we perform the action, the use cases for rendering a shipment are very simple. So this single element does all that work for us. Things that are simple and rails tend to be dead simple. When you do have multiple representations, you need to specify those IDs partials and action cable stream names. Otherwise, you may end up rendering the wrong template when you update. It also. Now it's not going to look at how well that works for a single page Ave such as one built with reactor.

Another similar framework. The JavaScript that is has more pieces and everything is significantly more coupled. In our server rendered app, we had quite a few dependencies, but notice how most of them are flowing the same direction. Are drama script apps. The dependencies are kind of all over the place. And it's not a typical react app. Using Redux these for these four pieces here are often the dependency of the entire application. Components are all factions within call. The Rejection of the reducer to get the state which told reactor we're under

components connected to that updated State. This is how most react after I worked on have operated. When you're at the first render, the product list component, it might not have your product loaded yet. Do tigers offense product action? Which is the producer? Which involved a request to the products index in point? Which end load the products in the database? She realizes done with the product, serial iser. Back to the reducer. We fired off a load products action cuz fetching in loading are two separate actions when you're doing a synchronous IO.

Which involves the producer again? This time, it's updating the reader state, which then re-run, there's a product list component with a freshly loaded products, and rear end. There's a product component for each product, in that list. And this is just too loaded from the server. Their conventions that help you circumvent some of the decision-making here, but nothing that'll take away as much of the manual effort that rail does. I would also love to share the website and updates here, but I don't have any more room on this side. So that's, that's comparing the

comparing the engineering effort. The effects of latency can be another big deal in your application. How you make latency? Can mean the difference between somebody giving you money or closing the tab? Latency in your application. Can often be separated into several key metrics, which are all different based on whether we're measuring the timer. I use our first open the page or whether they're navigating around looking links. This is a typical waterfall representation of how wet uploads the browser connect to the server and in the browser and server discuss, how they're going to

secure the connection with TLS. Then the browser, I sent the actual a request the server uses that to generate a response with his chosen content-type. Send it back to the browser and then the browser renders that response. The reality is a lot more complicated when striding and like things like a load balancers, reversed Roxy's, cashing layers, and all that. That's all pretty specific to your on deployment infrastructure. But at least point out that even though we're going into some going to get into the fu gritty details here, that there are still things that were glossing

over. In reality, these are not all the same size. This is closer. It looks like when you're sending HTML over the wire. The generate response, step involves dutching a swerving into HTML using Erp Hamill or slim templates. And then after that the server sends a response back to the browser until the browser renders. The user is looking at a blank screen when you're loading, just ditched me or just an HTML body. With a single page app to generate response. Step is a lot shorter because it's only serving up a static

HTML page. Typically like that might be a no-brainer, but it's just because it's just serving up, static HTML with a bear or a very minimal HTML template. It doesn't do anything useful until after we load the JavaScript, which we haven't done yet. So now we have to make another request for the JavaScript noticed that the request slightly overlaps with the render. The browser can fire off the the JavaScript request while it's still processing processing. The issue out if recover it's not usually impactful but you may be able to save up a few milliseconds are in

there. I noticed that the steps for receiving the the response extremely, the JavaScript are a lot longer. JavaScript pillows for single page. Apps are often pretty. Pretty large generating. It doesn't take very long because the file exists to the stock file on desk. So it's a simple matter of loading off the desk and then sending it over the wire. However, if the user is on a slow connection, this can still take hundreds of Ms. Or even several seconds. I was just as long as a response in the HTML version even though it's not generating anything.

Truly. Then once and then once we get to executing the JavaScript, this can also be a huge slow down. If you use, if you're sending one bag of JavaScript over the wire, the browser is typically executing, you know, 326 Megs of JavaScript, which will block the, you lie until it completes. And even with a complete surrenders, we still have no data loaded. So we're still basically looking at a blank screen and we need to send off yet another request for the product catalog that we outlined in the last section. This is likely to incur the same generate response time that are HTML. Example

did one thing the single page at has going for it. Is that once all this is loaded it can now show a loading indicator. I did include one here. The first production quality single page app should probably have one. So that users aren't left wondering why there's nothing on the page from unknown. Of time. This is one thing that a single page app can do better than an HTML app. When you first load, we first learn HTML app, if it takes a good long while to load that to dinner at that HTML. The user is looking at a blank page until until it's done. Either way that we can measure the effects

of latency is how quickly the app response when you're clicking links and navigating through various parts of it. We're never getting around and already loaded web app that uses hot wire. You don't need to load all of your assets every time. But you do have to make a request the server for every navigation, turbo doesn't. So if you have a cash version of the pages out URL, it will render the cash version first while it loads fresh content in the background. And it does this exact same way that we saw before, using the turbo, frame source. Attribute exact

same concept. Turbo also renders a loading progress bar at the top of the page. So you have some indication that the new pages loading. It also attached is a busy attribute to Turbo friends on the page. If you're learning content for those frames while other questions in flight, you can design a loading indicator for them. And when you're navigating around and already an already loaded single page app, conversely. There are a few different possibilities depending on whether your job is to rebuild, project process is configured to use a concept called toads play. Code

splitting. Lets you do? What you love? Blessed, JavaScript up, front, and wait to load other parts of that. JavaScript payload. When you were only, when you render, components, that need them. The great thing about this approach is that it typically reduces first, load time, but loading the Javascript app, all at once means you have already have the entire app loaded when you're navigating the tree off of codes pudding is that you have to make round trips to the server when you need that JavaScript, which will possibly make cascading requests for data after that. So you effectively lose

the latency advantage of navigation until all of those components have been loaded in cash. You're not using Code flooding, though. Your application is likely to be blazing fast as you navigate, since it's simply re-rendering content that it already has a memory. It doesn't need to invoke the HTML parser because it creates the UI elements using da. Maybe I directly saving potentially dozens of Ms. The only time that you end up having to wait is when he needs to fetch more dinner for the server. We talked earlier about hydraulic JavaScript pillows for single page apps can be pretty large. It's

not entirely uncommon to see one matter. More of JavaScript being sent across the wire on on a web page, when you're building a single page app. You often have to take the performance of your users devices into account as well, and provide small are JavaScript. Payloads are fronts of the phone that's older than sand. Can still evaluate the JavaScript in a reasonable amount of time. A fresh react app using Create react app tool weighs in at over two and a half times the size of a half of a hot wire application. If you're even if you're careful, it's still common to see JavaScript single

pay jobs over 120 wire. This results in the browser, having to evaluate, three to six Max JavaScript because the the browser doesn't execute code until after it's been decompressed. So this it's really easy to overlook JavaScript payload size when building the apps on our laptops or desktops with extremely powerful processors. The people using them. On phones. May not have access to that kind of computing power. What you got in your own components, application-specific State Management and the dependencies you'll need to go copper production quality

single page app. It's incredibly easy to see this this job over the wire exceed one that I've worked on single-page, react apps, that actually sent multiple magic. I'm stretched across the wire resulting in 10 to 12. My bundles went after they're depressed. Comparative Lee is hot, white hot wire is, using is using JavaScript under the hood. Even if you don't have to be the one to write it, but that sounds correct size is, like I said before, two and a half times less than the in the equivalent Baseline. Reactor a baseline. Hotwire app that is only using turbo action

cable, and rails, those three, those three lines of JavaScript that I said, if you're near that, you may not have to write any more than those three lines. If if that's all you're doing, you can expect to spend less than 16 kilobytes of JavaScript Across The Wire. And that decompresses it to anywhere in the 40 to 50 lb range. A device. Can Parson execute 40K of JavaScript and a handful of Ms. But again, No pressure. When I come to mobile devices, you have to go back to the network latency impact. Even, the fastest devices can't speed up an app that's

running on a slow Network. So server round trips are likely to still be there, but most the time. Weather using Hotwire or building a single page app. The server is still your ear force of Truth, for all of your models and you have to send the representations back to the client, when the browser, send the request to create change or delete one of them. So I can have a capresso coffee with hot wire. You have a single layer to concern yourself with them. That's the you lie. When your region. Are you running rendering the same partial template that you rendered in the original

request for the Page Beyond that, you have to specify what to do with the model in that template. For example, a panda, prepend when you're creating a new record, remove if you're destroying or update or replace the original, you're modifying it, but everything else is States. Largely the same with a single page app. The surfer has to see realize it's here, lies the models over the wire and the Singapore, Japanese deserialize it. Stick it in some sort of JavaScript data structure. And then we're under all the UI components that represent model, how this all wires up may not be trivial in your

application. Like we saw. We looked at a react Redux example before, but you may choose to build a single page app differently. Other changes that they may come in over a websocket push from a server without the browser. Requesting it in this case is a single page app would need to perform the same set of operations. But the Hotwire app doesn't need to do much intact setting up the action can websocket with hot wire and subscribing. What socket for updates for a given model or some other concept is usually matter of rendering a single turbo kit Mustang for sale.

It's a to keep in mind that these are just trade-offs. The idea isn't to claim that the hot wire approach is better or worse than Singapore shops. In general. This is, these are just things to consider when you're trying to decide which approach to use. If your budget is tight, you're already rendering HTML and your team doesn't have a whole lot of JavaScript, experience, or time to First interaction, is your most important metric. Hotwire may be a better choice for you. However, if you already have a solid API or interactions interaction, latency after everything is loaded is your most

important metric, then you may want to choose a single page App instead it again, just because something works better for your specific use case. It doesn't mean it's the perfect choice for every single application. To take every take Elvis, all this with a grain of salt. And so that's our agenda for today. If you're attending reels, virtually. Feel free to hit me up in the hot wire demystified channel on the rails County escort. You can follow me on Twitter at the handle shown in the bottom right-hand side of the page. And like subscribe and ring the bell for notifications. Getting wear a

mask, not getting and enjoy the rest of virtual rest, 2021. Thank you for watching and I hope to chat with you on Discord.

Cackle comments for the website

Buy this talk

Access to the talk “Hotwire Demystified - Jamie Gaskins”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free

Ticket

Get access to all videos “RailsConf 2021”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “IT & Technology”?

You might be interested in videos from this event

November 9 - 17, 2020
Online
50
93
future of ux, behavioral science, design engineering, design systems, design thinking process, new product, partnership, product design, the global experience summit 2020, ux research

Similar talks

Jonas Jabari
Senior Software Engineer at jonasjabari.dev
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Vladimir Dementyev
Team Lead at Evil Martian
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Jesse Spevack
Staff Engineer at Ibotta, Inc.
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free

Buy this video

Video
Access to the talk “Hotwire Demystified - Jamie Gaskins”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
949 conferences
37757 speakers
14408 hours of content