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?
STEVE_EDWARDS: So you said you were involved in this and you said you were involved in creating this from the beginning or?
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.
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.
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: 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,
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?
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.
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.
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?
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.
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.
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.