Steve and AJ catch up with Jonathan Reinink, the creator of InertiaJS, a utility for seamlessly connecting front end Javascript frameworks with back ends to create a seamless and performant web app monolith. 

They discuss TailwindCSS and Jonathan’s work at Tailwind Labs, and then get into InertiaJS, how it works, and many of the different features. They also discuss the new SSR capability currently in private beta, and Inertia’s growing inclusion into other frameworks, such as Laravel Breeze and Laravel Jetstream.

Panel

Guest

Sponsors

Links

Picks

Special Guest: Jonathan Reinink.

Sponsored By:

STEVE_EDWARDS:  Hello everybody and welcome to another exciting episode of Javascript Jabber I am Steve Edwards, the host with the Facebook radio and the voice for being a mine, but I am still your host. With me today on our huge panel, I have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from the sun. 

STEVE_EDWARDS: The sun, as in the surface of the sun? 

AJ_O’NEAL: No, it's just some sun like poking in, so it must be there. 

STEVE_EDWARDS: Oh, so some sun. Gotcha. Okay. And our very, very special guest today is Mr. Jonathan Reinick of InertiaJS. How you doing, Jonathan? 

JONATHAN_REINICK: I'm doing great. Thanks, Steve. 

STEVE_EDWARDS: So before we get started, why don't you give our listeners a little background on you, who you are, why you're famous, what your death history is, what you're working on, where you're working, etc. and so forth. 

JONATHAN_REINICK: Yep, that sounds good. So as you mentioned, I'm the creator of InertiaJS. So in terms of what's made me quote unquote famous in the development community, that's one of my projects, although I don't know if I've reached famous level status quite yet on that project. But it does continue to gain popularity and it's yeah, I'm kind of blown away. It was sort of a fun little side project that I started. It kind of had an idea for what it could be and it continues to grow. So that's cool. It's neat to be here today to talk about that project. The other project that people probably know better that I was involved with and I'm now still involved with is a project called Tailwind CSS, which is a CSS framework that I started with a buddy of mine, Adam Wethen, back in 2017. And that project continues to grow and gain in popularity. And I actually recently, so Adam Wethen and Steve Shoger actually created a business kind of out of Tailwind CSS where they created a product called Tailwind UI, which sells all sort of like predesigned components that you can use to build marketing websites and web apps and different things like that with. And that business has done well. And in August, I actually joined Tailwind Labs, kind of the parent company. So I'm now involved in that, which is super excited. It's been a super fun couple months getting to know the bigger team. We have four employees and kind of just helping out more day to day on Tailwind. So that's super exciting. And then yeah, outside of that, I've been doing software development for about, I guess, about 20 years now. I run a small little software as a service product as well for churches, which keeps me busy in my spare time. And I'm active on Twitter and GitHub and stuff. So if you'd like to hear what I think about programming, that's where you can find me. So that's a little bit of a background on me. 

 

Have you ever really been happy with your project management tool? Most are either too simple for a growing engineering team to manage everything or too complex for anyone to want to use them without constant prodding. Shortcut is project management built specifically for software teams and their fast, intuitive, flexible, powerful, and so many other nice positive adjectives. Let's look at some of their highlights. Team-based workflows, individual teams can use shortcuts, default workflows, or customize them to match the way they work. Org-wide goals and roadmaps. The work in these workflows is automatically tied into larger company goals. It takes one click to move from a roadmap to a team's work to individual updates and vice versa. Tight VCS integrations, whether you use GitHub, GitLab, or Bitbucket, shortcut ties directly into them update progress from the command line. Keyboard friendly interface. The rest of Shortcut is just as keyboard friendly as their power bar allowing you to do virtually anything without touching your mouse throw that thing in the trash. Iterations planning, set weekly priorities and then let Shortcut run the schedule for you with accompanying burn down charts and other reporting. Give it a try at shortcut.com slash dev chat and get two months free. Again, that's shortcut.com slash dev chat. Shortcut because you shouldn't have to project manage your project management. 

 

STEVE_EDWARDS: So Tailwind, that rings a bell. No, I'm kidding, I'm kidding. Don't know what Tailwind is. Whether you love it or hate it, or are indifferent about it, it's certainly more than a word, well, don't think so. I remember-

AJ_O’NEAL: Tailwind is something completely new that has come out of nowhere. So I could, I, I don't know how anybody would know what tailwind is unless they live on Twitter because it, it, I'd never heard of it until I don't know, three months ago. So that's not to say that it's not one of the most popular things in the world, but I might be like one of those PHP developers, you know, where they never hear about programming languages and they just stick with PHP. 

JONATHAN_REINICK: Hey, easy. I'm a PHP developer too. 

STEVE_EDWARDS: Yeah, me too. Yeah, I'm on the Laravel side of things. So yeah, I mean, so I'll give my description, Jonathan, you can back me up. So Tailwind is what's called atomic CSS or utility type of CSS. And the idea is that you have all kinds of classes and each class has one thing that it does, you know, the color of font or whatever, for the most part. And that's just the basics. And the idea is that instead of when you're doing your HTML, instead of having these definitions in your CSS, that'll have, you know, seven or eight different things that one class targets with a color, a font, a size, and being high to max height, you have one class. So then all you have to do is apply various classes to your HTML instead of actually writing CSS, and then it gives you customization options such as defining new classes, new shades of a color. Then you have apply functionality where if you have something you use over and over, you can use that to apply. So there's various customizations, but the core functionality is utility CSS where you don't have to write CSS. You just have to apply the classes to your HTML. Is that a fair description, Jonathan? 

JONATHAN_REINICK: Yeah, absolutely. I think that's the key and one of the big benefits of not having to write CSS and just kind of applying all these hyper-specific utility classes. Example of that might be a text-center, which centers some text, or pt-6, which applies some top padding on an element, or flex, or block, or rounded to add some border radius. By using all of these really low-level utility classes and building up your design right in your HTML that way, it actually makes you really, really fast because you don't ever have to jump over to a CSS file and write some CSS and name, whatever it is that you're creating. That's kind of one of the big wins that you don't necessarily realize until you start working with Tailwind. So you don't need to name stuff. So often with CSS, you've got to come up with good smart names for classes so that you can apply those classes appropriately into your HTML where with Tailwind, you just drop those utility classes right into your HTML or right into your React components or right into your view components. And, uh, and then you end up naming kind of at a different level, you end up creating components in kind of your JavaScript framework. So you create view components, you create rack react components, or you can even create server side HTML components. And that's kind of how you deal with the abstractions of stuff. Yeah. I remember like I always tell, I always tell people when I first heard of this idea, like Adam shared this idea with me and I was like totally disgusted at first. I was like, nah, man, this is a terrible idea. But I gave it a shot because I trusted Adam's opinions and I was converted quickly. 

STEVE_EDWARDS: So you said you were involved in this and you said you were involved in creating this from the beginning or? 

JONATHAN_REINICK: Yeah. 

STEVE_EDWARDS: Okay. I didn't realize that. I thought it was Adam and Steve. 

JONATHAN_REINICK: No, no. So me and. Yeah. 

AJ_O’NEAL: Why would you, why wouldn't you just use style tags? Cause it sounds, it sounds as though you, it's something where there's every possible combinatorial permutation of CSS. In which case it sounds like you'd have to learn all of CSS. So why not? And if you just wanted to put things in line, why put them in line as proprietary classes as opposed to just style elements? 

JONATHAN_REINICK: Yeah, that's a great question. Yeah. Like, so I think in reality, I think if style attributes weren't so limited, I think there would be an absolutely an argument to do that. And I think that you could create a wonderful designs with that approach. But the problem is that the style attributes actually extremely limiting. For instance, there's no way to do responsive styles within a style attribute. There's no way to do things like hover and focus and other states within style attributes. Those are all features that are only available in like real CSS. So that's kind of like the two major constraints with style attributes that basically make it a non-starter because nowadays you need all those states. You need dark mode variants, you need responsive variants. You need your hub. 

AJ_O’NEAL: No, you do not need any of those things. No, seriously, if you're not good at CSS, make a website that works. Don't make a bad website that has lots of cool features. Nothing 

JONATHAN_REINICK: fair enough 

AJ_O’NEAL: than having black background on black text with a calendar widget that you can neither click on the button nor type in the date like that's. But anyway, 

JONATHAN_REINICK: OK, yeah, so that's one reason. That's one reason. I was going to just say just to kind of flush that answer out a little bit further. The other reason is if you can just write whatever you want, that works, but like what we've seen over the years, and when we first created Tailwind even, we analyzed like a lot of websites out there. We analyzed sites like GitHub and other sites that were kind of writing more traditional CSS. And what we noticed is that a lot, just the way that the existing tooling worked, you ended up creating a lot of like inconsistencies in your design in terms of like what sort of margins you use, what sort of padding you use, font styles, colors. Colors is a massive one. So the thing about that's really interesting with Tailwind is we very, like you actually get a limited sort of constrained set of styles to work with. So there isn't just an unlimited number of styles. You work with kind of what we call this design system and you build up your design from that and it does have constrained values. It only has so many colors. It only has so many margin and padding values. And of course you can modify your design system if you need to add more. But by doing it this way, when you're in the HTML, if you want to extend kind of outside of like the default things that are included within your design system, you got to go to your config and add it there. So there's like a level of pain that comes with that. And we think that that's a good thing because otherwise it's way too easy to just create 500 different versions of gray on your website if you're not careful. So that's kind of the other big win that you get with using it a tool like Tailwind is that you kind of have this constrained set of styles that you work with. 

AJ_O’NEAL: Okay. So, but why not use CSS variables for those sorts of things? Because that is, if I'm not mistaken, that's ubiquitous support for the last two years now. So if you're targeting people who literally have not connected their computer to the internet for updates in two years, I'm not sure that that's a real person outside of the government facilities and banks.

JONATHAN_REINICK: Yeah, and you can absolutely use, in fact, we use CSS variables a lot even to make certain features within tailwind work. But that's not just that benefit, right? It's the whole, it's the whole way of authoring your code, the idea of authoring your styles right alongside your HTML. It's similar in a way, think about it in a similar way to writing JavaScript, but using it, you know, writing it as JSX where you're the functionality and the actual HTML like coexist, like they live in the same place. And with Tailwind, it's the same sort of idea. You're bringing the styles in and they all live in one place. And it makes it really, really powerful and really easy to work with. Cause you kind of have all that context. You have your design, your functionality and your styles all in one place. And I acknowledge that for some people, it's not something that they necessarily think makes sense at first. And it can kind of like scare people off when you look at the HTML and you see all these classes in there. But we always say to people, like, give it a try. Try to build a project with it and see what it feels like. And so often people are like, oh yeah, I totally get it now. You gotta kind of try it to really feel the difference. Anyway, we're getting deep into Tailwind CSS here. 

STEVE_EDWARDS: Right, so anyway, yeah, I just wanted to get into that because I know that's a big part of what you're doing these days. But as we mentioned off the top, the big reason is to talk about inertia and what's going on with inertia and so on. So let me get, I'll give my description. I've been playing with inertia quite a bit over the past few months. So let me see if I can give a big description and then you can tell me what I missed up. So the idea is that we're sort of going back to the, I know the term you've used is monolith. I don't know if I would call it a monolith, you know, way back when late 90s, early 2000s, when you first started seeing the some of the CMS has come out, like what was, what did Joomla come off of? Joomla was a fork of another CMS and I forget what it is or WordPress. Yeah. or Drupal, you know, where everything top to bottom was in this one stack. You know, you got a lamp stack with MySQL, PHP, Apache running on Linux. And that provided your backend and your front end with templating like PHP, uh, PHP template or, or any of the other templating languages that were out there. And then he, once you had node coming out early 2010s teens, however, you want to refer to that decade, then you had the, initially the mean stack, Mongo express, Apache, Angular node and then he had other frameworks with you and React. And so you could start piecing everything in together. Well, then that opens up, that's like too much choice. And so people started, then inertia came along. And when we talked last year, it was about sort of creating a monolith, but you can choose your pieces. So the idea of inertia is that you can mix and match your front end and your back end. So on the back end, you've got what Laravel, you got Ruby. And I know you didn't have full on node support. You have Node.js support? 

JONATHAN_REINICK: Yeah, so we like officially out of the box for server-side adapters, we have Rails and Laravel adapters. But people have created like community adapters for all kinds of other frameworks. So WordPress and Django, and I think it's called Adonis or Adonis, maybe Adonis.js, Node, ASP.net, Phoenix. 

STEVE_EDWARDS: I don't know that one. 

JONATHAN_REINICK: Yeah, lots of server-side languages and framework support. 

STEVE_EDWARDS: Wow.

JONATHAN_REINICK: via community adapters. 

STEVE_EDWARDS: And then on the front end, you got the, you know, the big three Angular, React, Vue. 

JONATHAN_REINICK: No, no, no, no, close. 

STEVE_EDWARDS: I myself have been. 

JONATHAN_REINICK: We actually don't do Angular. The three that we do is Vue, React, and Svelte, actually. Yeah. 

STEVE_EDWARDS: Svelte, okay. So personally, myself, I've been using the Vue, Laravel combination, which is really nice, just because I have years of doing PHP in my schoolwork. So that gives me something that I'm familiar with instead of having to use, go and learn Node.js or something else. But the gist is basically you would have an adapter that went to the back end, went on for the front end as we talked about. And so that when you make a request, your initial page load is a full page load. You know, I have everything CSS, JavaScript, and then it uses your X Inertia header. And I think there's some other headers so that when you make a request, instead of doing a full page load, it just communicates directly with your back end. And then your backend does its things, gets your data, whatever, and passes it back up. In the case of Vue, it's props to a Vue component, and you're not doing a full page load. Just, so it's very quick. And I know there's some other intricacies in there, but that's the big picture. 

JONATHAN; Yeah, the way I like to compare it, the thing I like to compare it to, for people who are more familiar with the JavaScript space, is I like to compare it to a client-side routing library. So like Vue router or React router, any sort of like, routing system on the client. That's really kind of like the heart of what Inertia does with kind of like one big exception is that you don't actually define any of your routes client side. So the way it works is more like, if you're familiar with the library by the Basecamp folks called Turbolinks, it's more like that. And so kind of the gist of it is, is you build your server side, your backend, your server side framework, or app in whatever server side framework that you like using with. So working with, so layer, layer bell or rails or whatever. And then on the client side, you build all your templates using a modern JavaScript framework like view react or spell. Those are the three that we support right now. But the difference is unlike kind of like a more traditional way of building a completely client side, a JavaScript front end where you actually have like a totally separate API on a totally separate project that you run and then you make requests to from your client side. Inertia, the way inertia works, it's way more like a classic, what I call a classic monolith application where you're working with like a classic framework, like Laravel or Rails, where you define all your routes in your server side framework. So let's just say, we're at Laravel for now. So in Laravel, you define all your routes there. And then, but instead of creating all your templates in the Laravel templating tool, which is called Blade, you instead build all those templates in Vue or React or Svelte. And then what happens is, kind of getting to the way that the client side routing works, is inertia is this light library, this light little like glue that kind of ties your server side framework with your client side framework. And what happens is if you click a link, we intercept that link click, so you don't get like a full page reload. And instead what we do is we make that request over XHR over AJAX instead. And what that does is it hits the server. But then when it hits the server, the way the inertia adapters work on the server side, it detects that, hey, this is an inertia request. This is in a full page request. And it's smart enough then to only return the response just as some JSON. But the JSON response isn't like what you typically get from an API where you get, say, some data that you then have to parse and figure out on the client side. What it does instead is it gives you a page component name of whatever page you're about to visit and any props or data that's required for that page. And then it just dynamically swaps it out for you. So the experience for you as a developer is it really just feels like you're building just a plain old Laravel or Rails app where you just have endpoints and those endpoints have controllers and those controllers get data from the database maybe or, and then it passes that data to a template and that template just, you know, in this situation of inertia just happens to be a view or react or svelte template, these JavaScript components, and then it passes the data through. So it's a really, really nice developer experience if you, you know, for anyone who's worked with those tools for a while. So what it means then is you don't need to build any sort of API. There's no work there. You can kind of just get this single page app experience with this like rich client side, a JavaScript ecosystem available to you without having to, yeah, without having to do all this extra work, like figuring out complicated things like OAuth for authentication to your API and different things like that. You can literally just use session auth. It works perfect. And there's a lot of other like things that you get with that just kind of for free, you get any sort of like middleware tools that you get with your server side framework. They just work right out of the box with inertia. So it's actually a fairly simple library. So it's not really that big of a thing, which I think is kind of a neat thing about inertia is when you look at it at first, it might feel like a big project, but it's not that big of a project in a way. Like we say right on the landing page on the inertia website, we don't consider this a framework. This isn't like choose, view, react or inertia. That's not the idea. The idea is that you're able to work with the existing tooling that you already know. If you already know Laravel and you already know Vue, great. You're going to be super productive. If you already know Rails and React, great. You're going to be super productive. You're not learning a whole new framework. It's more like you've chosen to use a different client side routing library. And that client side routing library is just like really leaning on the existing functionality that already exists in your server side framework of choice.

STEVE_EDWARDS: There's some in-between cases too that I want to talk about how inertia addresses. So as you described what you're doing, let's say I'm making a Laravel app and I have a user's page and I have, I don't know, I'm trying to think, let's say I have a widgets page, you know, I want to list some widgets. So I'm going to define in my Laravel side, I'm going to define my routes, you know, in my web.php or API, PHP, whatever I choose to do. And then in there, I'm going to return, I think it's called a inertia renderer with the name of my component. And then the second portion of that is a callback that gives me whatever data I want to pass back as props to my page. So how would you handle a case where you need to make a request to your backend, but you don't necessarily need to go to a new page or to refresh your whole page? So here's an example. In my particular use case, I have a calendar app. And so it's just a month calendar on a page. And I have using view and I can change the content of the page without reloading the page. Okay, so I just want to click an arrow and it changes to the next month and then it brings up the data. So I don't need to call it. I just want to call an endpoint says, 

JONATHAN_REINICK: okay, yeah, so when I was trying to tell people, so two things, one, just because you're using inertia doesn't mean that you can't use just plain old XHR or fetch to do anything, any sort of like manual requests to your server. So if you're ever in a situation that you just feel like inertia isn't what you need, there's no you're not breaking any rules by just reaching for fetch directly. So that's like one thing to keep in mind. It that's like, we have it all this. I have that question all the time. Like just, just use fetch. That's totally cool. The other thing though, I would say is as a rule or, you know, maybe it's better to say in general, the way that inertia is designed to work is to mimic kind of that classic server side web app sort of approach to building something meaning whenever you did like in sort of like a classic web app that does full page reloads, you could click a link and it reloads the page and maybe does something. So maybe I'll give you an example. So maybe you have a create user form. What would happen in kind of a classic app with no JavaScript involved at all is you'd have a form with say the user's first name, their last name, their email, whatever you would hit. You'd fill that out. You'd hit submit. That would submit to the server, right? Some, some post endpoint, which would then validate that data. And if it was wrong, it would fire it back and show errors. But if the data was valid, it would probably like create that user record and then redirect you somewhere else after the user was created to then, you know, maybe you'd land on the user index page or maybe you'd end up on a new user edit page or user show page. But the point is that you're always kind of going with this flow where like you're making a request and then after that request, you're redirecting to somewhere else. So that's kind of like very much the same principle with inertia except those requests aren't full page reloads. Those requests are done over XHR. And so I would say in the situation that you're talking about right now, you said you're not really fetching new data, but I think if you're going from one calendar month to the next in a way you are grabbing new data. So I actually have this exact thing in my own web app. And the way it works is I have a calendar which has forward and back buttons for the previous month and the next month. And when...So the link to the next month is literally just a plain old inertia link. There's nothing fancy. And so that would be like calendar slash, you know, January or, you know, next month being December now. So maybe it would be like calendar slash December slash 2021 or something like that. Right? So then inertia is going to go off, make a visit to that endpoint is going to get the data that's required and it's going to return it back. But here's the interesting thing about it. If you're just going from one calendar month view to another calendar month view, the actual component, the page component that's being rendered there, the calendar page component that's being rendered isn't changing. The only thing that's changing is the data for it. And because framework, frameworks like view, react, and spelled are all like, they're, they're like, they're fully reactive. Meaning when you give a component new props, new data, they dynamically, they automatically re render to display that new data. And that's exactly what would happen in this situation. If you'd visit the next month, the data is gonna come back from the server and it's gonna reload that, it's gonna refresh that component, re-render that component with the new data. Now, I think maybe what you're getting at with your question is, well, what if I only want to get the updated calendar data and not anything else that happens to be shown on that page? Like maybe you don't wanna reload the current user cause you know, it's unlikely that the current user changed. And maybe you have some other data that you're displaying on that page and like, well, you know, if I'm going to make a request just to update the calendar from November to December, why do I have to reload all of that data? And you don't. So by default it does just like it would in a classic full page app. You know, if you made a, if you're on page one in a regular server side rendered application and you make a link, you click a link to visit another page. Well it's going to reload that whole new page. It's going to reload the current authenticated user from the database you know, anything that shows a kind of like a template or whatever, and it's going to do a complete reload. And, and let's be honest, that's actually been fine for many, many years. And it's a totally fine way of building web applications still. So that, that in and of itself is not wrong. The thing about it is that's limiting with that approach to building web applications, you don't get any of the benefits of these server side or should these client side JavaScript frameworks like view and react and kind of all the power that comes with them. So with inertia, what you can do in a situation like that is you can do what we call a partial reload. And what you can say is, yeah, I want to make this visit to load the next month of data. However, I want to specifically say when the user clicks this link, only load the calendar data. Don't load the currently authenticated user. Don't load any of these other extra pieces of data that aren't relevant to what I'm trying to update right now. And then inertia, what it'll do on the server side, it'll be smart enough to only grab the data that's specifically needed for that request which is the new calendar data. But what's cool about it is if you were to, that only works when you're going from say, one calendar view to another calendar view. If you hit that, if you go from November to December, it can just load just the data it needs. But if you hit the December endpoint directly, well of course, like for the first time or whatever, it of course needs all the data. So inertia is smart enough to say, well, yeah, in this situation, I need to grab the currently authenticated user and everything else so that it has that data available. Does that answer your question? 

STEVE_EDWARDS: Well, so I was actually trying to guide you to a specific thing and maybe I'm doing it wrong, but I was looking at inertia visit, which is what I'm doing inside of mine. So, you know, I had found CSS tricks has a great post from a little while ago about how to build month calendars strictly with view. And so I did that. It's got the switch and everything built in and calculates everything. And then, you know, when I did a change, I just needed to hit the back end. So I just use inertia visit. Is that what you were thinking of? Cause I'm looking on your, there's a separate partial reload section where you're talking about something. So I mean, you might be looking at something different than what I was thinking. 

JONATHAN_REINICK: As almost like, it's kind of like the, so all requests basically run through inertia visit. It's kind of like the low level function that everything runs through. So when you use inertia visit, you have to, you know, you got to call, find the method. So get, post, put, whatever. And there's a whole bunch of arguments and parameters that you can set and different options things like, like partial reload. So it's, it's called only, you choose only the props that you want to reload. You can set headers in there. You can choose whether to preserve your scroll position when you use visit. So it's, it's really, that's the low level method that everything, all visits are run through. So you can absolutely use visit. Yeah. So everything else is kind of like a shortcut. So even when you click a link, like when you use the inertia link component to make a visit from one page to another page be under the hood, it's still using inertia dot visit, or when you use inertia dot post, it's going to use under the hood inertia dot visit. So, so when it comes to partial reloads, what's actually happening is you are, you're basically saying visit this page and give me only these props. So for example, the users or the data for a specific piece of the page, such as the calendar data, you know, that kind of idea, but that's again using the inertia visit component to do that.

STEVE_EDWARDS: All right. So one of the things you mentioned, I think, or maybe you didn't, is the preserving of the scroll. So that's a case where, going back to my calendar example, where I've scrolled down the page a bit and I click and it changes everything in place really slick because I'm using inertia visit, but then it jumps to the top of the page. And you got to scroll all the way back down to where you were because you lose your place. And in a long page, that can be sort of the pain in the rear. So preserve scroll should just keep you where you're at and keep your reload from jumping to the top. 

JONATHAN_REINICK: So again, like the way a classic full page reload would work. You know, if you click on a link in just a regular server-side rendered application, you click on a link, it's gonna reload the page and automatically the browser is gonna reset your scroll position back to the top. That's just standard browser behavior. So inertia does the same thing by default. When you click a link, it resets you back to the top of the screen. However, that's not always desirable for the exact situation like you just said, it's like, well, actually if I'm browsing through a calendar, I might want to maintain my current scroll position. And there's other situations like that where it's actually really nice to just kind of keep your scroll position. Like imagine like a big form or like a big edit page for say a user or something like that. And it has like a little toggle to like make them active or inactive or whatever. And you click that toggle, which makes an inertia request, right? When you click that toggle, even though it's an, or a server, even though a request is being made to the server using inertia, you're not really thinking about it as like a page visit. It's just like you are making a page visit, but you really in the UI expect the scroll position to stay exactly where it is. So that's another good use case for preserving the scroll position. 

STEVE_EDWARDS: Right. Okay. Now, when here's a question that I've been running up against and I think I found a case. So with this structure where you're directly accessing your backend and it's directly passing to a specific component, where do you see the use of state management for instance, view X. Yeah. 

JONATHAN_REINICK: So I haven't used state management yet to date with inertia. Like I kind of feel like it's not necessary in the same way that if you have like a server side rendered application that does full page reloads, there is no state, there is no client side state because that state disappears when you go from one page to the next, you know, it's like it's wiped out. So the whole kind of goal with inertia is that you you don't need a library for state management because your server is really considered the state. You know, so as you make a visit from one page to the next, that's where you get your updated state from. So it's kind of like every single page visit gets you the data that's necessary for that new page. And there's no real need to keep any state around. 

STEVE_EDWARDS: And I can't remember where it is. I have to go look at my code. So, but that was a question is where you see that coming into play. Now, the other thing I want to talk about that's similar along those lines is shared data. So if you have some piece of data you want available to everything, every time a component loads, you want this piece of data available. Obviously, you gotta be careful with that. But once you talk about that, then handle inertia requests. 

JONATHAN_REINICK: Yeah, so basically the way it works is inertia kinda doesn't care what, yeah, how do I explain this in kind of a simple way? So basically what you're describing right now is a situation where you have your web app and there's some piece of data that you maybe want always available to your templates. And a good example of this is the currently authenticated user. Because quite often in a web app, you'll show the currently authenticated user, maybe their little profile and their name, profile photo and their name in the top right of the screen. Well, that has to come from somewhere, right? So the way that that would work in a traditional server-side rendered application is literally every single time you load the page and re-render the page template, it would just re-render that user's name and their image over and over and over every single time you visit a new page and that works totally fine. But the challenge is when you're working with inertia is how do you get that data to your layout on every single page visit? Because obviously you don't want every single endpoint in your application to be responsible for saying and here's the current user and here's the current user and here's the current user. So you go to your dashboard and the dashboard endpoint would have to give the current user and then you go to the create user page and it would have to give you the current user and then you go to the edit profile page which gives you the current user and on and on and on. So the way you ideally like to do that is you'd like to have one place in your server side application where you define any data that needs to be globally available. So in Laravel for instance, that's handled using what we call the Handle Inertia Request middleware. And what you can basically just do is you can say on every single request, always include the current use and you can do the same thing for other things. Like maybe you want to keep track of the application name for whatever, maybe it's dynamic in some way. You can include that. Or if you want to include some information about their current plan, their billing plan or whatever, you can include that as globally accessible data. But then on the inertia side, it's really simple. That's the shared data is not really treated any differently than the per page specific data. So it's just all available client side and you can kind of just use it. And it's really up to you to just make sure that you you don't create a conflict between your page data and your global data, which sounds like a bad idea at first, but practically it works out totally fine. I know in my application, what I typically do is I create an auth key, a top level auth key, a prop for the currently authenticated user, which might have their name and their email, maybe the company that they belong to or the account that they're associated with that kind of stuff. And once that's been defined, then it's available everywhere in the application. And you can just render that out in a template or wherever you need it. 

STEVE_EDWARDS: Yeah. And, but as the documentation says, something you got to be careful of, because if it's a bunch of data, then it's going to slow things down. So does that mean, so every time someone what's going on behind me, it seems then is that every time you navigate to a new route as defined in your backend, it's gonna run this middleware and load up that data. 

JONATHAN_REINICK: Yep, yep, that's exactly right. Again, just like a classic server-side rendered application, every single page request is making a request to your server to figure out who the current user or to the database, to figure out who the currently authenticated user is. That's just kind of just the way that we're used to building web apps and Inertia builds, builds a kind of on that classic sort of way of building. And it works great because here's the thing sometimes I get people asking me, well, why would I want to keep reloading the current user every single time? You know, does it really make sense to grab the current user on every single request to the application? And my question always is, well, what's the alternative? The alternative is to load it once and then risk that it's become stale. And once it becomes, you know, has the user logged out or, you know, has their email been updated or their name been updated or their profile photo been updated? So by doing it this way, like it always grabs the current user on every single request. Of course, it only if you don't do a partial request, if you do a partial reload, then it only gets the data that you asked for and not the current user. But yeah, honestly, it tends to just work out really, really nice. The thing about it is, and I think maybe this is not something that people consider enough, is that when you make an HTTP request, so much of the overhead is just in the process is just the process of actually making that HTTP request you know, doing the SSL certificate handshake and kind of just sending the request across however far away your web server is away from where you are and then how far it is from the web server to the database server. And, you know, that's kind of where a lot of the costs come. In reality, to include the current user on every single request, while it seems inefficient, practically it just really doesn't actually amount to anything. Passing an extra bit of practically slow things down very much. So that's what makes, that's like kind of a key point because that's really like, it ends up meaning, what it ends up meaning is you don't run into these state issues. You're always getting fresh data from the database, from the server on every single request. So you're never worried about the state. You never have these statements. And that's why I say it's the state is really handled on the server. So that's why I haven't ever used any sort of client side state management systems. 

 

Time is of the essence when identifying and resolving issues in your software and our friends at Raygon are here to help. Their brand new alerting feature is now available for crash reporting and real user monitoring to make sure you're quickly notified of the errors, crashes, and front-end performance issues that matter most to you in your business. Set thresholds for your alert based on an increase in error count, a spike in load time, or new issues introduced in the latest deployment, along with custom filters that give you even greater control. Assign multiple users to ensure the right team members are notified with alerts linked directly to the issue in Raygon, taking you to the root cause faster. Never miss another mission critical issue in your software again. Try Raygon alerting today and create a world-class issue resolution workflow that gives you and your customer peace of mind. Visit raygon.com to learn more. Their simple usage plans start from as little as $4 per month with unlimited apps and users. That's raygon.com to start your free 14-day trial. 

 

STEVE_EDWARDS: To me, let's, okay, the example you've been using is user data, logged in user data, and obviously for any type of web application, that's something you wanna keep current to because they could log in, they could log out, you know, any number of things. But let's say you have some other piece of data that's common to me, that would almost be a good place for Vuex, right? If you have a piece of data, you know, you have a set of data that you're going to load once, once they initially log in, that's not going to change, then it almost seems like state would be a good place for that as compared to having it while they're logged in. Does that seem reasonable or what's the counter argument to that? 

JONATHAN_REINICK: Yeah. So, so I guess I would say there's absolutely, so at the end of the day, an is really just a Vue React as felt project in a lot of ways, right? So there's absolutely some people who've chosen to use Vue X with inertia. I just, I don't see the performance win, I guess is what I'm saying. Yes, you know, when the user first logs in, if there's some data, let's like, I'm trying to think of a good example of this. Like maybe it's a list of, maybe it's all the countries that are available in like your countries drop down and you have that like defined server side somewhere, right? You could theoretically load that country's data at the point that they log in. You could say that in client side state. So you have it moving forward. Absolutely it could so that any, any endpoint or any page that you visit that has a, a form on it that requires all the countries to be listed, you know, already has that data client side. You don't have to get it from the data, from, from the server again, when you visit that page. I am highly skeptical that process of actually saving that data, caching a client side, just so you don't have to grab that data when you load some form is actually going to have any sort of meaningful impact on the performance of the application. And then you are introducing more complexity on the client side. You are introducing a level of caching because now if those countries get out of date for whatever reason, that's going to be an issue. You got to find a way to reload that. So I just, I guess I just don't see the wind. I've built numerous inertia apps obviously at this point and I've just never seen the benefit of caching that stuff client side, even though yeah, technically you can in some situations, the cost of grabbing that data when you hit those endpoints is just so small that it just doesn't seem worth it. Now if you did have some super costly data, that would maybe be a different situation. Because like maybe I'm trying to think of an example, like maybe you have to reach out for some reason to stripe quite often to get some data, whatever that data is in your application or some other third party service. And that's like very slow. Like maybe it takes like a a second to get that data from this third party service. In those situations, you might be again inclined to save that in client side state, but again, I probably wouldn't handle it there. I would say I would be way more inclined if I had to introduce some level of caching, I would introduce that caching in my server side frameworks, either in Laravel or Rails. I would use whatever caching mechanisms that are available to me there. Maybe I'm using Redis or something like that, or even just session, you know, whatever, wherever my sessions being stored. I think I would introduce the caching there and I wouldn't introduce that on the client side. I don't know. I just, I feel like so many like tricky situations come up when you put, try to push state and caching into the client side. And it's kind of just been something that we've done because the traditional way to build web applications or you know, JavaScript rich web applications is to use APIs. And, and when you have APIs and you kind of have this whole dance where every time you get data from the API, you like save it in client side state and you build that up over time and you try to reuse it for performance reasons. And just with inertia and kind of just that the approach that inertia takes, it just doesn't practically become an issue. You just, yeah, you got to make sure your endpoints respond quickly. And if you're writing really poorly performing server-side code, yeah, you're going to run into performance issues, but that's no different than if you're running, running, writing poor API code that takes long to respond. So yeah, that's a bit of a long winded response. 

STEVE_EDWARDS: I guess that makes sense because you can just from a capability standpoint, I think your back in your servers, you're going to have much more power and memory resources than a browser running on a computer, especially if you get like a, maybe someone's looking on a phone or, you know, a low end phone and doesn't have good connectivity. So you want to do as much as you can on the server side. So moving down the list here. So authentication, basically what your page says is let your back end do it. Right? you're going to send your request, they're going to authenticate you and give you your, you know, log you in and so on. And it's just best to let the server side handle that. 

JONATHAN_REINICK: Yep. Yeah. There's nothing fancy there. You know, you can use whatever you want. If you want to use OAuth for whatever reason you could, that's just like, that's not kind of the classic Laravel rails, you know, even Django and these other frameworks like that just use session auth. Session, session auth is just like the simplest, simplest form of authentication. And you kind of just get it for free with inertia cause inertia it doesn't concern itself with that. It's kind of like outside of its scope. So when you hit an endpoint and you want to authenticate that endpoint, well, you have some middleware that that runs when, you know, if I hit the slash profile page and I need to be logged in to see the slash profile page, well, then my, my server side frameworks gonna, that end points gonna run, it's going to load the controller or whatever for that endpoint. It's going to run the middleware for that endpoint. The middleware is going to say, well, you need to be authenticated to see this endpoint. If it's not, it's going to be like, Oh, well, you can't see this endpoint. So we're going to redirect you over to the login page, the login page is then gonna return a response and you'll get the login page. So it, yeah, it just, it kind of just works really, really well. The authentication side of, the authentication story with Inertia is amazing. 

STEVE_EDWARDS: Okay. So next topic, validation and error handling. So obviously you're going to want to do that server side as well. You're going to pass your data and run your rules, you know, if you're in Laravel or validation or whatever. And then, so talk about errors, how errors are pass spoken in terms of the error pop and the error bags problem. 

JONATHAN_REINICK: Yeah, so this is kind of like so at the end of the day, the way inertia works is like so simple. But I find it kind of a bit of a challenging thing to explain because there's kind of two camps of people. The one camp is they're building like a classic Laravel or Rails app. And what happens is when you submit a form server side, if there's a validation error, so like imagine you're trying to create a new user and the new user needs to have a name set. Well, that request is submitted down, the form is submitted down to the server. Their server says, hey, is there a name? Oh no, no name was included. Okay, well then you got to redirect back to the form page and then somewhere, somehow the framework will include the errors that failed. So the way Laravel does this, it actually flashes the errors from that validation check to the session so that when the page reloads, when the form page reloads, you have the ability to to display those errors on the page. And it also includes the old input, so you can repopulate any form inputs. So that's one way, and that's the old school way. The other way that most people are doing it nowadays, if you're building a form using JavaScript, which more and more people are, because it's just a really nice way of doing it, is you fill out the form, and then you use Viewer React, and you intercept the form submission. You grab the data, then you fire the data to the endpoint, but you fire it over XHR or Fetch. The server then does a validation and then if there's again an error, instead of doing a redirect, what if it's made over XHR or fetch, what it then does instead is it just returns a 402 or sorry, 422 I believe it is, which is the validation error and then includes the errors in the in the body as JSON. And then client side, you then look at those errors and say, okay, well I got an error for the for the the name field. So I need to display that error. And you use you use Vue React to actually add that error to the page. You use JavaScript to display it. So those are like the two sort of camps. Those are the two approaches of handling validation errors in kind of like a standard, more classic web application. So the way Inertia does it is actually a blend of both. And it's really cool the way it ends up playing out. So what happens is you have a form and that form of course is written in as a JavaScript component, Vue React is felt. And what you do is when you submit that form, again, you would submit it using inertia. So there's actually an event handler that intercepts the form submission to prevent a full page reload. And instead, you submit that form to whatever endpoints, so the create user endpoint, for example, and you pass down any data. And that form submission is then done using inertia, an inertia request. What happens then is, let's talk HappyPath first. You hit the create user endpoint. The validation is all good. The data is solid. Then what happens is you do whatever you want with that data. So in this case, we're going to create a new user. So a new user record gets created in the system. And then what you do is you redirect back to wherever you want to go. So quite often after you create a user, you'll redirect to the user index page or the show user page or whatever, like I was saying earlier. So that's exactly what you would do. And that redirect is done server side. So you create the user, and then you return a redirect server side. And then what happens is, and keep in mind that this is all happening within an inertia request, which is technically an XHR request. That redirect happens server side. You land on another page. Let's call it the user index page, so the page that lists all your users. It does a redirect and it returns an inertia response. That inertia response includes the page component for the user index page plus any of the data required for that page. That all comes back client side to the form page inertia then dynamically swaps it out. So you go from being on the user create page to being on the user index page with your new user created. And of course you could pass through like flash data to show like a success message or whatever. So that's happy path. But now the unhappy path is you submit that form data and you again, you submit it using XHR, but that's done. You submit it, not using XHR, sorry. You submit it using an inertia request, which technically is XHR under the hood. But for, you know, all intents and purposes, you're submitting that form with inertia inertia hits service the server side endpoint to create that user and some validation error fails you know there's some or some validation fails and you have an error so maybe the name is missing so the way it works in inertia and also in the rails adapters is it then flashes that error to the session so it keeps track of it and then what it does is it does a redirect back to the previous page that it was on so the referring page which in this case is the create user form page that we're on. And then it provides to that form page as new data. So keep in mind here that we're submitting, we're getting the errors, we're redirecting right back to the same page that we're already on. So it's doing a redirect back to the same page you're already on, but it's getting some updated data. So this, you know, keep going, we keep talking about the props. It's so, so much of how inertia works comes down to the props. The props are updated. And the reason why the props are updated is because we now have these errors available. The errors prop is populated. So then what you do within your form component, literally all you do is you just check to see at any point, do I have an errors.email prop? You know, is the errors.email property set? And if it is, you just render out the error. And the same thing for, sorry, that would be for the email or for the name or for whatever sort of input you have. And this, I'm switching out my examples here, but yeah going with the name example, if the name has an error, well then you display the name, then you'd render the error for the name. And because Vue React and Svelte are all designed to be reactive when props change, this all happens just automatically. So that's kind of like the long explanation of how it works, but the short explanation of how it works is the validation works with inertias. You submit your form using inertia, because you can pass the data from the form down with inertia. You submit to the page that you want. And then if that validation fails, the errors prop within your view reactors felt component is immediately populated automatically for you. You don't need to do anything and you can just display it. And because it's all reactive, it displays automatically for you. So this is, this is really, really, really nice because there's so little work that you need to do. You don't have to have an on success handler in your form submission code that checks and say, well, was this a 422 response? And if it was a 422 response, well, then we need to handle these errors. But if it was a it was a 200 response and it was successful. Well, then we need to do this other thing and redirect elsewhere. You don't need to do anything like the actual, the actual JavaScript code to submit an inertia form is so simple. It's literally like, like in its simplest form, it can be just like form dot or sorry, inertia dot post, and then you specify the end points of slash users. And you specify the data, the data from the form and that's it. And you don't have any handlers after the fact at all, cause it just is all handled automatically by inertia for you.

AJ_O’NEAL: So is that an on submit equals inertia dot post? 

JONATHAN_REINICK: Yes. Yeah, you'd have to do event dot prevent default to prevent the full server side form submission, like the classic full page reload. But yeah, exactly. 

AJ_O’NEAL: And you just give it the event? 

JONATHAN_REINICK: Yeah, and if you're working with Vue, it's really easy, right? Vue has this idea of you can do at submit. So that's the event handler shorthand. So right in your template, you can do form. And then at submit dot prevent, which prevents the default behavior. And then you just pass the name of whatever handler you have for your method. So for me, I often just do submit. And then farther down in my component, I create a submit method that does inertia.post. 

AJ_O’NEAL: So you said you don't have to handle the 422 versus 200, yada, yada. But don't you still, you just handle it on the server side? Because you're still rendering the error message, right? 

JONATHAN_REINICK: Yeah, when I say you don't have to handle it, I mean as a developer, you don't have to handle it. Because the server side frameworks are already designed in such a way that they do this. So this is like, default Laravel behavior already. So yeah, the server is doing it, the framework is doing it for you. But what I mean is you don't need to write like, catch code for those response codes. It's just being handled for you automatically by the server. So the only thing you need to do, or by the server side framework, I should say, the only thing you're responsible for to do is when you actually create your create user page component, you have to be aware that, hey, there's a possibility that there could be form errors here. So I need to like choose how I want to render those form errors. That's all you're responsible for handling. And the rest just kind of, you know, handles it. It all just kind of gets taken care of automatically for you. Does that make sense AJ? Or is there like, is there a piece there that's missing for you still? 

AJ_O’NEAL: So I'm guessing, well, I'm not, it's been forever since I've used Ruby and I've never, I've never used Laravel, but I'm guessing you're just saying as part of the model controller, it's going to generate the HTML that has the flash message or whatever they call it these days. And so that's why.

JONATHAN_REINICK: No, so it doesn't. Yeah. So it doesn't do any of that. So literally all it's doing that all the server is doing. 

AJ_O’NEAL: No, no, no. I'm saying that the server is generated, not inertia. The server is generating the error codes or codes, the error message for the user 

JONATHAN_REINICK: messages. Yes. Yes. Correct. Yeah. Now I'm understanding what you're saying. Yeah. So like for instance, in Laravel, it has a whole bunch of predefined error messages that automatically get generated. So if you say like, as an example, name.required in Laravel, it's going to give you an error message that says the name is required. And you can override those, those error messages to your heart's content, but it kind of provides, it provides you a default message there that then gets made available on the client side after the, the inertia form submission is done. 

STEVE_EDWARDS: I wanted to touch on real quick with error bags where the case where you might have multiple forms on a page or something like that, and you want to be able to separate your errors to the applicable section of the page. 

JONATHAN_REINICK: Yep. So error bags are like... So the thing to be aware of with an inertia app is that all the props that come back at any point when you're on an endpoint is designed for the whole page. You get all the props for the whole page in a response, right? So if you were to have multiple forms on the same page and they were to have conflicting keys or field names, what you could run into is... So say you have the first input, your first field create a new user in the second field to create a new company, for instance. And the user one has a name field and the second one, the company one has a name field. If you submitted and they both were required, say the names required for both of them. If you submitted one of those without a name by default, because you're looking when you're rendering the errors out, because you're looking at errors dot name for that validation error in both of those forms by default, it's going to automatically show errors or name is required under both of those forms. And that's because they're both looking kind of in the same scope. So we have this concept of error bags in inertia, which allows you to scope a form to a specific error bag. So then you could say something like errors dot user form dot name or something like that. Practically speaking, it's not something you end up using that often. It's just a nice little escape hatch when you need it. 

STEVE_EDWARDS: Right. Okay. So there's a couple more things I want to touch in where we're getting a little long in time here. One is server-side rendering. And from the last email that I saw, that's sort of been a, what do you call it, a private beta or early access to sponsors. So talk about where you're at with that and what's the roadmap and timeline, at least what you hoped your timeline to be. 

JONATHAN_REINICK: Yeah, so it's in early access right now. It's been in early access since June. So basically what server-side rendering is, is yeah, what's the right way to explain this? Basically, what happens is when you build an inertia app, you're building your entire client site, your entire front end, you're building with view, react, and svelte. So these are JavaScript pages, right? These are JavaScript components, fully JavaScript run. So what you need is a browser to actually render them in order for you to see them, right? Because that's just how they work. However, if search engine optimization is a concern for you, well, then you might run into issues using a tool like inertia because essentially what Google will see is just kind of like that root template and none of the data because the page isn't actually being rendered, which isn't even entirely true because I know like Google nowadays actually will execute JavaScript and will still probably index pages with JavaScript. But I think if SEO is a concern for your business, then that can be a little bit risky and you probably want to actually server side render your page components. So what we've done is we found a way to make it possible using node to just take whatever page content that's gonna be rendered in the browser and actually return it on the first page load as rendered HTML. So this is similar to how libraries like Nuxt and Next work where they all, like you just get server-side rendering by default. So that was a little bit tricky to get working, kind of just learning the whole SSR story, kind of on the view and react side of things. But it turns out it actually works remarkably well and it works really, really fast. And what's cool with inertia is it only has to happen on the very first page load because that's all you care about, right? Once the page is loaded and it's just a user clicking around, you can kind of go into single page SPA mode. But for a search engine, you always want it to show it. And for a search engine that's doing, and that's indexing your site, every page visit is a first page load. So they're always gonna get their server-side rendered version of the content. So yeah, that was a pretty awesome addition. I was really, really, really happy that we could do it. And I was really happy we could do it in a super performant way. It's like really, really fast. The inertia website itself actually is server-side rendered. So if you view the source and you hit the line wrap button in Chrome, you can see that it actually has all the rendered HTML there, which is just kind of bananas to me in a way. Because it's like, this is like a server-side rendered framework, like layer of all that's what the inertia docs are. That's now using react as the, as the templating layer, which is then using node to server-side render it back to HTML. well indexed by a search engine. So in some ways, the stack kind of feels like more complicated, but practically it actually works out really, really nice. And yeah, so that's server-side rendering. So it's in private beta, just to our sponsors right now. And that's been in private beta since June. And our goal is to have it available for everyone by the end of the year. The main reason it's not yet is just a few little webpack related things that we're trying to clean up to make the whole just the the whole experience of getting it up and running a little bit nicer. 

STEVE_EDWARDS: Okay. So I'm confused a little bit. So if I'm running a view Laravel stack with inertia, you said, you've got to use new node to do the rendering. So how does that, can you give more detail on how that setup works? 

JONATHAN_REINICK: Yep, for sure. So fortunately nowadays, most people on their web servers have node installed. It just seems like node is everywhere these days. So if you don't have Node installed, you're not going to be able to use the SSR features in Inertia. So Node is a requirement. But like, again, for a lot of Laravel related apps, Node, you know, you need it anyway, because a lot of people are using Node to run Laravel Mix, to run Webpack, to do their build processes for their assets, like their CSS and their JavaScript anyway. So you need Node. So then essentially what the way SSR works is Inertia has this tiny little Express server. It's actually not even Express. It actually just uses the built-in node web server that's a part of node now. And what it does is it just listens for requests. And what it does, well then what happens is when someone visits an inertia page and you get right before the response is sent back to the client, to the browser, which includes the name of the page component, right? Whatever the page is, your dashboard, or your user index page, and any of the data and the props that are required for it, what we do with inertia is we actually take that data. So basically the whole page object is what we call it, which is the page, the component name, the data, the URL, and the asset version. And we fire that over just internally, kind of like a, like kind of like a forking out a command, but we fire it over to that little web server, that node web server. And all that node web server has to do is take that data and run it through either view or reacts SSR tooling and just convert it to HTML. So the actual, the whole web, like the whole node server that we give you that, that little piece of code that does that work is like, I think it's like 30 lines of code. It's really, really short and all it does is it converts the JavaScript to HTML, spits the HTML back to the web server. So back to Laravel and then Laravel, when it actually renders the page, the default, like kind of that initial page, it renders all the HTML. And then when, which includes like whatever the page would, whatever the fully rendered JavaScript component would be. And then it automatically then boots viewer react on top of that. And we use something called client side hydration so that you don't end up regenerating all that stuff client side, because it already exists. So that's a feature of view in both view and react where if you've done server side rendering and all that HTML is already pre-generated when viewer react boot for that first page component, uh, it doesn't have to like re render it all a second time. You can just say, Hey, no, I've already done this rendering server side. So just use what's there already. So that's kind of like the high level of kind of how it works. And yeah, it works pretty slick. It's a little bit of like a little bit of setup, getting that Node Express server working. You basically just have to run it as a separate process. But yeah, again, I set it up. I think it took me on the inertia docs to get the SSR part of working. It took me less than an hour originally. And I started that process and it's been running ever since and it's never broken. 

STEVE_EDWARDS: Awesome. Yeah, I must say though, as a view developer, I'm sort of bummed that you're using React instead of Vue, especially with Adams Affinity for Vue. But I guess we'll let that slide this time. 

JONATHAN_REINICK: You know what it is, honestly, Steve, like for me, it's I love Vue and I especially love Vue 3. For me, it's not even so my own like personal project, my SaaS business, I use Vue on that one with Inertia. But on the inertia docs, I have it all in react for kind of two reasons. One, I need to be familiar with both of these frameworks to be able to like service them properly and give them both the respect that they need and the attention they need as far as just maintaining those adapters. So it's nice for me to have a react adapt, react project. And then the other reason is the initial version of the inertia docs was actually built with Next.js which is all react based. So it was way too much work for me to convert it over to Vue at that time. So that's why it's React, because it was React originally, but I couldn't use Inertia originally because we didn't have server-side rendering originally. But now that we have server-side rendering, it obviously made sense to just use Inertia straight up. 

STEVE_EDWARDS: Cool. Cool. So last thing I want to talk about is how I'm seeing Inertia implemented into other projects on a larger scale. So being a Laravel user, you know, that's the stack that I use at my day job, as well as my own projects. And the LaraCast is sort of the go-to for learning how to do Laravel and all the different cases. And I noticed that, so Jeffrey Wei currently is in the process of developing a course on inertia. They had a little initial one where he goes through and figures out how the heck does this work. And so, but now he's got a full-on course, Laravel with you, and he's building it as we go along. And in one of either that or on his LaraBits podcast he mentioned is that he recently redid his entire Laracast site in Inertia, which I thought that was pretty cool. So he obviously knows it enough to use it. And that's not a small undertaking, I would imagine considering that site. But then also the inclusion of Inertia into Laravel itself. So I myself am when I started my project, I used Jetstream. So they've got a couple of different components. There's Livewire and Jetstream. Livewire, if I'm correct, is just using Blade templates, but Jetstream uses Vue, Vue slash Inertia with Laravel on the backend. And what's really slick, and what I liked about it, is we were talking earlier about how with Inertia, you don't have to handle the user login authentication. You let your backend handle that for you. So there was a distro that I loaded. It was a GitHub repo, I believe, that has Laravel, Jetstream using inertia. And so I downloaded, I've got authentication and templates built in. It's just, I don't have to do anything to handle that. And I can just immediately start working on my own, whatever it is that I'm making that's unique and not have to worry about all that backend and authentication and stuff. So I thought to me, that's been really cool is that you see people having pre-built distributions with certain pieces for you. So then you can just focus on what you want to develop and not have to reinvent the wheel every time you build an application. Yeah, it's unfortunate that Chuck couldn't be here today because he's a Rails developer. That's where he got into development. And so he had some illness issues and other things. And unfortunately, wasn't able to be here to talk about that, but apologies for everybody's listening. I'm not a Rails developer. I'm not a React developer, so I can't speak to those portions. But I think the general concept is the same. It's just a matter of which pieces you're plugging in. Inertia is inertia regardless of which combination you're using. So all that will be useful. 

JONATHAN_REINICK: Yeah, although I would say that because we have first party support for Rails, it's even better than average. The Rails adapter is well maintained and the whole concept fits so well with Rails as well. And we've had a lot of people very happy in the Rails community with Inertia. 

STEVE_EDWARDS: So real quick, last question before we get to PIX. Talk about community around Inertia. You've mentioned earlier in the podcast about how you have official support for Rails on Laravel, but there's been community adapters developed for Node or Adonis or whatever. So talk about the community involved in it. It's growing and where's the best place, I guess, to partake in that community. 

JONATHAN_REINICK: Yeah, so I would say like one, if you're interested in using inertia. So in some ways inertia, if I had to do it all over again, I don't even know necessarily that I would have made the inertia, the like first class adapters. In a lot of ways, what inertia is, is the client side piece and really all the server side adapters. It kind of doesn't matter what server side framework you're using. You can use inertia because it's really in so many ways, it's just a protocol and it's kind of a bunch of preset HTTP things like a bunch of headers and just the way that you format the data when you return it. And that's why people have been able to make inertia client-side adapters for all kinds of things. Like I think I maybe told you in the last podcast, I can't remember now, but someone actually created an inertia adapter for cold fusion. I didn't even know cold fusion was a thing anymore. Yeah, people have created inertia adapters for WordPress and I didn't even know how that was possible, but they have. There's a Go adapter, you know, so there's a Statomic adapter, a Cake PHP, an ASP. So it's like, it's really cool. So people have been able, and this is like, I will admit, that works on the documentation, but like I really need to actually write a, here's how you write a server-side adapter and the language and framework of your choice. So that's always, that's something I still wanna do, but despite not having that official guide, people found a way to do it. So that's been really neat. We have a super active Discord channel as well, which you can get the link to that on our website. So there's a lot of people on there who are helping each other out, which has been really amazing because for me personally, trying to maintain inertia and actually build it and keep on top of like kind of everything that we want to get done. Well, also helping the community, all as an open source project, like it's just, it's way, way too much work and the project's grown to a size that it's just not feasible for me to do that. But the community has been great because there's been a number of people in the community specifically who've just really stepped up and been just an enormous amount of help. Who have just like been totally cool with just helping people out on Discord and answering questions or on GitHub or whatever. So I'm really thankful for that as well. The community, the whole, in general, the whole community has kind of like blown me away a little bit because yeah, there's just been like a lot of love for the project. Which kind of makes it a little bit stressful for me too because I feel like a high level of responsibility to make sure that the project continues to succeed and stuff. So, yeah more to come on that front, trying to figure out kind of the right way to make the project sustainable into the future and trying to find ways to make that happen. So part of that is also with the sponsorships, which has helped a bunch. So yeah. 

STEVE_EDWARDS: Good. So yeah, so I'm a yeah, I'm in the discord channel quite a bit. I pull through and read it and there's some other good people and I see what Claudio Decker, Linus Juhlin. Yeah, there's some good people giving answers and that's such a good place to hang out to learn about Laravel. All right, so before we go to picks, anything else you want to talk about that we didn't cover about inertia? 

JONATHAN_REINICK: Oh, yeah, there's there's more, but that's OK. I think that's there's some feature that I'm working on. The main feature I'm working on next is what I call dialogues, which is basically first class, like modal support, a way to do modals in inertia. Modals are always a challenging thing to do, right, especially if you want modals to have their own endpoints and and have direct linking to them and different things like that. So I've come up with a really, really cool system of doing dialogues and modals in Inertia. So that's upcoming. I gave a whole talk on server-side rendering and dialogues at LairCon online. Just forget when that was, but this year, the last LairCon online. So I don't know when the videos are going to become available there. But definitely, if you were there and you didn't see the talk, definitely check that out, because there's some pretty cool things coming in the future when it comes to dialogues. So but that's I think that's other than that. We covered most of the most of the goodness. One other fun piece is we rewrote the library and TypeScript earlier this year, which was a whole learning experience as well. But I think that's going to be good because tons of TypeScript users these days and gives you a nice auto completing and stuff. So you can work with the inertia APIs and get a nice auto completing in your editor and whatnot. So that was a nice addition as well. 

STEVE_EDWARDS: Good deal. I know for Modals one of the things I wanted to get into I'm saying we certainly have time with some of the tailwind headless UI modals and some of those things. I've been using those and those are super nice to just be able to drop something in and tweak it as you need it. It works really well. 

JONATHAN_REINICK: Yeah, for sure. Yeah, that's kind of the whole other interesting part of all this is like the neat thing with inertia is that like I kind of said earlier inertia is this light little library that sits between like these beasts, these powerful massive ecosystems like Rails and Laravel on the server side and view and react and svelte on the client side. Those are huge projects with massive ecosystems and all kinds of tools and extensions and plugins and learning materials and all that, all built around those things. So this has been a huge reason that people have liked Inertia so much, is they feel like they don't need to learn some big new tool. They can continue using the tooling that they know already and are super familiar with and already really productive with, but then they can just put Inertia in between to get the benefits of that single page application feel. So yeah, I think, you know, things like Headless UI, for instance, if you're using Inertia and you need, and with Vue or React, and you need really good Headless components for drop downs and modals and things, Headless UI is available and just works with an Inertia app, because Inertia doesn't care. It's just Vue or React. 

STEVE_EDWARDS: Right. 

 

Hey folks, this is Charles Maxwood from Top End Devs, and lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast, and you can actually hear a little bit more about my story about why I'm doing what I'm doing with Top End Devs, why I changed it from devchat.tv to Top End Devs. But what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with devchat.tv, and I renamed it to Top End Devs because I want to give you the resources that are gonna help you to build the career that you want. Right? So whether you want to be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever, I want to give you the resources that are going to help you do that. We're going to have career and leadership resources in there and we're going to be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com. If you sign up before my birthday, that's December 14th. If you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com. Alrighty. 

 

STEVE_EDWARDS: Well, with that, we will move on to picks. And so we'll let AJ go first today. 

AJ_O’NEAL: Okay. So I'm going to pick, oh, I had one on top of my head earlier, but now I don't remember. I'm going to pick the laws of UX again, because I think that they're always worth picking and you can get the poster or you can just look at the lovely website, which is almost as good as the poster, or you could get the book, but I think that the world would be a better place if more people know the laws of UX. So, and that's at lawsofux.com. Also, I, we have a problem in that there are ten different standard bodies for the web, and none of them even bother to get into the same room or even look at what the other ones are doing. Despite this, a miracle has occurred. Input type Datetime local does in fact work on all devices and browsers most likely far better than whatever type of component you're using I've run into so many websites this week where I can't put in a date and it's blown my mind so I'm I'm also picking input type equals Datetime local one of the benefits of mobile is that people don't necessarily try to rewrite everything that's already there and that works. For some reason, people try to do this in the browser. So my strong encouragement is just the way that Android users and Apple users have a different date time picker, it's okay if Safari users and Chrome users have a different date time picker. If it works and people can use it, then you are a winner. And then other than that, let's see, I think I'll keep to those those two things today and then the rest is just my usual creeds of craftsmanship.com for learning good stuff and follow me on Twitch and YouTube if you want to see the live streams or the Beyond Code channel if you want to see when I put out little snippets of condensed content. 

STEVE_EDWARDS: So as most people know, the high point of any of our podcasts anymore is my dad jokes. And so I've got a couple to share. One is actually a couple of stories. So I was...I went into a bar one day and I just wanted to use the Wi-Fi. I was out and about. So I asked the bartender, I said, hey, what's the Wi-Fi password? He says, you need to buy a drink first. I said, fine. All right. I'll have a Coke. He says, is Pepsi okay? I said, sure. How much is that? He says, three bucks. Geez. Gave him the money. I said, there you go. So what's the Wi-Fi password? He says, you need to buy a drink first.

AJ_O’NEAL: I've actually done that before. 

STEVE_EDWARDS: Good times, good times. And then we used to be in office. It's been a long time, but my boss always laughed at my dad jokes, but, uh, he quit laughing at him in, in zoom chats. And I asked him why he says because your jokes aren't remotely funny. Thank you. Thank you very much. 

AJ_O’NEAL: Yeah. I had the laugh track on that one. That one was good. 

STEVE_EDWARDS: Oh, okay. There we go. You know, I'll add some applause too. Thank you. Thank you. 

AJ_O’NEAL: This is good. This is good. 

STEVE_EDWARDS: I love sound effects. I love sound effects. Okay. 

JONATHAN_REINICK: It's better than us having a fake laugh, I guess. 

STEVE_EDWARDS: You a lot of times I just get groans more than anything. So that's why I add that's why I add the laughs. 

AJ_O’NEAL: Well, and there's a there's a little bit of lag, you know, in the audio sometimes. And so the comedic timing can be off. 

STEVE_EDWARDS: Well, when I push the button on the laughing, there's like one or so two second pause. So I'm working on clicking that right before I'm about done so that it comes in. Right. So I'll have to 

AJ_O’NEAL: get that sounds that sounds like a good idea. 

STEVE_EDWARDS: Yeah, I'll have to work on that. So anyway, that's my picks on to Jonathan. 

JONATHAN_REINICK: Yes. So I'm a dad as well. And I thought that maybe it would be appropriate to share a good dad joke as well. And by a good dad joke, I mean, a terrible dad joke, because that's what makes a good dad joke. Right. Anyway, so I was this last weekend was Halloween. And I saw this on the side of the road. What kind of pants do ghosts wear? 

STEVE_EDWARDS: I know I've seen this. Boo. 

JONATHAN_REINICK: Boo jeans. Boo jeans. 

STEVE_EDWARDS: Oh, that's good. That's good. Hold on. Oh, sorry. I was on the wrong. I'm bad. Thank you. Thank you. Delayed reaction. That was good. Boogies. My son will love that one. He likes it. Tell me.

JONATHAN_REINICK: Uh, yeah, so no other picks. I've got a few things, I guess, like to pump my own thing, you know, obviously tailwind we talked about at the beginning of this. If you're using tailwind, be sure to check out tailwind UI as well. That's, uh, that's our paid product that helps support the whole, the whole open source product as well. So, um, tailwind UI.com if you haven't checked it out yet. Outside of that, I don't know if it's really a fair pick because pretty much everyone knows about these, but the new Mac book pros came out, fancy MacBook Pros where they fixed a lot of the issues with the old MacBooks like the keyboard and the screen and lots of lots. 

AJ_O’NEAL: And nothing about it being pro. 

JONATHAN_REINICK: It has inputs. It has new inputs on the side. I'm a fan. I like what they did with it. It's a bit clunkier now. 

AJ_O’NEAL: Yeah. The new one's great. The new one's back to the 2012 style.

JONATHAN_REINICK: Oh, you mean you mean the old ones, nothing about them being pro yet. No, exactly. Yes. Yeah. 

AJ_O’NEAL: Like they, they neutered them. 

JONATHAN_REINICK: Yes, exactly. 

AJ_O’NEAL: They were expensive aluminum Dells. 

STEVE_EDWARDS: Yeah. I want to get the M1 for sure. Cause a buddy of mine who lives on his computer all day, got one of the original 13 inch MacBook Air M1s and he loved it. He's like, I can go battery all day, 13 hours without problems. So fast. The fan never comes on. And my daughter just got one here recently too. And she loves it. It's just is so much better from a performance standpoint. So yeah, I'll have to, for mine, I'll have to get the money together. Hopefully my boss and I are talking about them. So maybe I can get the company pony up for work. So yeah, those are definitely looking good from everything I've seen. Now I know that, I don't know how much you guys are aware of this. I know when the M1s first came out because of the different chips, there were issues with apps and other things. I know Homebrew was one initially that had to do some coding changes to be able to changes to to be able to work with those processors. Are there still issues with that or a lot of that? 

JONATHAN_REINICK: I don't yet. Actually, to be honest, I don't own a machine yet. So I don't know. But from what I hear, yeah, a lot of the issues have been resolved because I feel like the chips have been out for a little while now. So I think a lot of the apps have been updated already for it. So I'm hoping that when I get it, like most of that stuff, you know, if I'm a few months behind here, that most of that stuff is going to be resolved by the time I pick one up. 

STEVE_EDWARDS: Alrighty. So we're going a little long. So we will wrap it up for today. Thank you, Jonathan for coming. I've been looking forward to this episode for quite a while. And yeah, check out Inertia when you get a chance. InertiaJS.com, I believe. And we will see you next time or talk to you next time on JavaScript. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y.com to learn more.