The panel talks with Jonathan Reinink about his new library, IntertiaJS. InertiaJS is a tool that allows you to create a monolith server rendered site, but where you write your own custom back end, and then use a front end framework like React, Vue, or Svelte. We discuss how Intertia works at a very granular level, how it compares to tools like Next.js and Nuxt, why monoliths are better than using APIs, how Interita handles authentication and form submissions, and much more.

Follow JavaScript Jabber on Twitter > @JSJabber

Special Guest: Jonathan Reinink.

STEVE_EDWARDS: Hello everybody and welcome to another episode of JavaScript Jabber. Today with me on the esteemed panel, we have Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville.

STEVE_EDWARDS: AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from planet earth. 

STEVE_EDWARDS: Planet earth. Wow. Yeah. It's around earth, not flat, right?

AJ_O’NEAL: Never know what people think. Don't get into religion and politics on the show. 

STEVE_EDWARDS: Okay. Sorry. Sorry. I am your host, Steve Edwards, the host with the Face for Radio and the Voice for Being a Mime, but I am hosting today. With us today as our guest, we have Jonathan Reinick, and Jonathan is going to talk to us about his latest project called Nursha.js. How are you doing, Jonathan? 

JONATHAN_REININK: I'm doing great. Thanks for having me on.

STEVE_EDWARDS: Our pleasure. 

 

Your app is slow and you probably don't even know it. Maybe it's fine in most places, but then the customer loads the page up that one page and after a couple of seconds, their attention disappears into Twitter and never comes back. The reality is there are performance issues in your app and they're affecting your customer experience. What you need to do is hook up your app to Scout APM and let it start telling you where the slowdowns are happening. It makes it really easy. It tells you how slow things are and what the problem is, like N plus one queries or memory bloat. It's also built for developers. So it makes it really easy to identify where the fix needs to go. I've hooked it up to some of my apps and I saw what I needed to fix in a couple of minutes. Try it today for free and they'll donate $5 to the open source project of your choice. Just go to scoutapm.com slash dev chat and then deploy it to your app. Once you do that, they'll donate the five bucks that scoutapm.com slash dev chat.

 

STEVE_EDWARDS: Why don't you give us a brief intro, tell us who you are, what you do, why you're famous and all that good stuff. 

JONATHAN_REININK: Yeah. Why I'm famous. Yeah. Not quite there yet, but when I'm working on it. Yeah. So I am a software developer naturally, and I live in Ontario, Canada. That is also part of the earth. Just so you know, AJ, that is kind of in the same area roughly just a little bit more specific. 

AJ_O’NEAL: What did I say about getting into religion and politics? 

JONATHAN_REININK: Sorry, sorry. 

AJ_O’NEAL: I don't know about what you believe about what you think is on my earth. 

JONATHAN_REININK: Moving on. 

AJ_O’NEAL: That's great. 

JONATHAN_REININK: And I've been doing web development since basically the early 2000s. And my main focus, kind of a few different areas of focus, most of kind of started out working with PHP and that's still largely what I work with these days. Most of my work is done with the Laravel framework and I'm pretty actively involved in the Laravel community. I've also done some work in the CSS space. I worked with a buddy of mine, Adam Wethen, and helped him get the first version of Tailwind CSS out, if you've heard of that library. So that's been a fun, fun project to be involved in. And then more recently, last year, I started Inertia JS, which is my answer to making basically creating single-page applications a little bit easier for developers who have historically worked and built applications with more classic server-side rendered frameworks like Layerbell or Ruby on Rails. So that's kind of my JavaScript first kind of foray into the JavaScript space. And more recently, I actually spent the better part of the start of this year putting out my first learning product. I actually created a video course, a 28-lesson video course all about database optimizations and that went out at the beginning of June and that went really, really well. The course is called Eloquent Performance Patterns. So it's basically how to run and write really performing database queries using Eloquent, which is Lareval's ORM. It's an active record style ORM. So that was a lot of fun. It was a real challenge. That was something new to me to get that out the door, but the response has been amazing. So that's good because it basically helps me finance some of my other open source work so I can spend more time on inertia.js. 

STEVE_EDWARDS: So those are, I take it that's for SQL databases as compared to like a NoSQL database? 

JONATHAN_REININK: Yeah, yeah, yeah. Yeah, but it's all relational stuff. So kind of I looked at the three I look at primarily are MySQL, Postgres and SQLite. 

STEVE_EDWARDS: Okay. So I'm going to insert an interesting bit of trivia here and you guys can correct me if I'm wrong, but we always use the term relational databases. And everybody always thinks it's because the way tables relate together. Did you know that's not where the term relational comes from? 

JONATHAN_REININK: No, I had no idea. 

STEVE_EDWARDS: I read this in a SQL for dummies book in a bookstore one time, and it's always stuck with me. So as I understand it, and maybe someone to correct me if I'm wrong, it has, it's a term that has to do with set set theory, which is the area of mathematics that is used in building SQL databases. But there's your trivia for the day. 

JONATHAN_REININK: I had no idea. 

STEVE_EDWARDS: Yeah. 

AIMEE_KNIGHT: Thanks for enlightening. 

STEVE_EDWARDS: Yeah. I'll have to look that up later and make sure that what I just said was right, but that's what I remember. So anyway, so inertia JS, obviously, I'm thinking of the XKCV, you know, cartoon that talks about well, hey, there's all these tools that don't do it right. So I'm going to add one more and then you know, pretty soon, you know, now we've got set of 14 linters, we have 15 linters or whatever the case may be. So obviously, you felt that the current tool set didn't do things the way you liked them, so you decided to do something the way you liked it. So why don't you tell us about, I guess how you got started into inertia, what you saw that you didn't like and the process from there. 

JONATHAN_REININK: Yeah, so guilty as charged, yes, I brought another JavaScript framework to the world. Although I argue that inertia isn't a framework, I argue that it is a library. So my goal wasn't to create something that you use instead of React or instead of Vue.js, my goal was really just to make those libraries easier to work with for a certain type of developer. So that's my defense. But yeah, so the way I got going with Inertia.js, so again, got to back up a little bit here. So I primarily worked with Laravel, which is a server-side rendered application or web framework in PHP, very similar to Ruby on Rails or Django, that kind of style framework where you have a set of routes and those routes are defined client side. And when a request comes in, your server-side framework picks that up and redirects you or loads up a controller typically. And that controller then gets some data from the database. And also then from there takes that data, maybe does some work on it and then spits it to a view. So in layer about there's blade views rails, you'd have like ERB templates. So and then from there it gets rendered client side and gets spit back to the browser. And that's great. I love building web apps that way. And I've done it that way for a long, long time. However, as I moved from doing more, I would say kind of public facing websites to doing more web applications, I started feeling kind of the limitations of that approach. And I sort of wanted to introduce more interactivity into my applications and that required more JavaScript. So any sort of control that you might make that you can't do with just plain old HTML, you have to introduce some JavaScript. And there's obviously lots of different ways to do that. And the way that I enjoy doing that is with the library view.js. So I was still using Laravel and still using server-side render templates. But what I wanted is, what I started doing is just dropping in view components into my server-side render templates when I needed some extra interactivity. And I was building, I actually have a little SaaS product that I run for churches. And this application has a ton of these view components. And what I started having in my application is I had this whole layer of my application of my front end, which was these blade templates that rendered client-side. But then I had a whole set of also these view components, these JavaScript components that kind of lived in a different place, but then kind of got matched together when the template got rendered. And practically speaking, it wasn't really nice to work that way because every time I wanted to make a change to some UI in my application, I had to think, okay, well, is this in a blade template, or is this in a view component? Or worst yet, is this some sort of mix between the two? Do I have, you know, part of this page being rendered, this server-side and part of it client side. And it was always just like, it just became this frustrating thing, trying to manage that and just context switching. You know, I would have a page that I want to just add a little thing to it, like maybe a dropdown or whatever it was. And I'd have to say, okay, well now I have to do a trade-off. Do I have to convert this now to a view component just so I can do what I want to do is or some other way. 

STEVE_EDWARDS: So how does that work? When you combine the two like that, if I can interrupt real quick. So yeah, yeah. Some of it's in templates, some of it's blade templates and some of it's view components. So you have different components handling different routes. Then it's how that works. So this route is handled by a view component because I need interactivity where this route is handled by a blade template because it's all static and can come from the server. 

JONATHAN_REININK: No, not quite like that. Well, it would all ultimately start by rendering a server-side rendered blade view. But if there was needed, like if I needed a view component, then that view component would just be rendered as part of the page. And then view, when that page loaded, view would kick you know, kick into gear and boot up that view component or 10 view components, if that's what exists on the page and, and make those active. Does that make sense? 

STEVE_EDWARDS: Sort of. So I'm just trying to understand the handoff between the blade to the view component. 

JONATHAN_REININK: Yeah. So the thing, the thing with view JS, I don't know how familiar are with view, but view doesn't have to be only used in like a classic SBA sort of the view way. You can also just drop in a view component. So it's, you know, my component and you can just drop that into an HTML server-side rendered HTML template. And it literally, when the page loads, it'll spit that out as HTML, so your component, but then the component actually then gets booted up by Vue.js, and you can do the same thing with React after the fact, so it loads client-side, it just puts up the tag, the element into the page, and then when the JavaScript boots up, then that Vue component becomes alive.

STEVE_EDWARDS: So using like view single file components or just like a new component object written inside of the template.

JONATHAN_REININK: I yeah, I tend to use single file components, but you don't even have to do that way. You can do it either way. 

STEVE_EDWARDS: And so it's attaching to your app element or whatever you've identified as your root element. 

JONATHAN_REININK: Exactly. Yep. Which gives you the ability to do a mix of server-side rendered HTML and client-side rendered HTML. 

STEVE_EDWARDS: Right. 

JONATHAN_REININK: The trade off and the unfortunate thing is not only that you kind of have these two different paradigms. The other thing you get is these like basically flickers when the page loads. Cause imagine you have some page load, it renders the HTML server side. And then there's, you know, a button or there's a dropdown or there's some sort of input or whatever that's controlled by view. It then has to load and it flickers because it takes a second for that thing to initialize. Right. So, and that kind of just makes for a bit of a janky user experience because it's not like this nice seamless thing. Does that make sense? 

STEVE_EDWARDS: Yeah. Okay. So yeah. 

JONATHAN_REININK: So moving from kind of like server-side rendered, entirely server-side rendered, to partially server-side rendered with a certain amount of JavaScript kind of in there. And like back in the day, when we used to do this with jQuery, we would still say we had a list, right? We'd have a list that would be server-side rendered, but then jQuery would pick it up after the fact and add some additional interactivity to it, right? That's kind of like how the jQuery approach worked. But with Vue and React, these components are designed to like work on their own. If there is a a list that gets some data passed to it as props, then the actual view component is responsible for rendering itself. So there's no rendering that's happened on the client side, or sorry, on the server side for that component. So it really, you have to wait for the client side library to boot up before that gets rendered. What I kind of ran into is, yeah, I didn't really like one, the flicker, and I didn't like kind of the experience of working with these two different paradigms. So what I really wanted to do is I wanted to be able to build my applications in a way that was like I could do everything as a client-side component. I wanted to build everything in Vue from the template perspective because I really just enjoyed working with Vue. And I've enjoyed all the power that having a client-side framework gave me to make whatever sort of interactivity I needed within my application. So I started basically, I came up with a system originally where all I would do in my server-side controller is go to the database, get some data, and then I would return a response. And that response would have only two things. And it would basically be the shell of my HTML document, and it would have a single div in it. And that div served as a place where view would boot. And that div had two props assigned to it. One prop would be the component name, the page component name. So, you know, maybe it was called users page or create user page or whatever. And then some props, which would be any data that that JavaScript component required. Now, that data would be passed in as a JSON-encoded set of data. So that when the client-side adapter booted up, it would detect, okay, I see this page, you know, kind of that root element, that app element. It would look and it would see what page component had to render. So it would render that component, passing through the props that were also added as an attribute to that base div. And this allowed me to basically do everything as view components, but still have all my server-side routing and all my controllers where it gets data from the database, all the exact same way it was before. So I didn't have to like switch to using an API or anything like that. So it was like a really nice, simple step forward. And I did that and what I had been was all my pages were client-side renders using Vue, but it was still doing full page reload. So if you clicked on a link, it would just do a full page reload like a classic server-side rendered application does, and then reload the page, and then it would boot up the new Vue page element and display it, and it kind of went that way. So what I did was actually to kind of give that more of that SBA feel, I actually used a tool developed by the folks at Basecamp called Turbolinks. And I implemented that. And so that when you click from one page to the next, it wouldn't do a full page reload. It would just swap out the HTML with the content of the new page. And that worked okay. But the problem with that approach is that works good. Like Turbolinks works great if you have a fully server-side rendered application. But because my application was now client-side rendered, when they reloaded the page, but did it you know, client side and trashed all the old HTML and put in the new one. It meant that view had to be rebooted every single time, which again, meant that I got a page flicker because really TurboLinks and Vue don't really play all that well together. And there's some tricks that I've tried to make this a little bit nicer, but ultimately anytime you click on a link to visit a new page, TurboLinks would destroy the content that was there. The HTML was what that was there and force it, force Vue to re reboot it, you know, kind of the entire framework which came at a performance cost, but then also more than that, it kind of just had this flicker to it. So I was like, man, it would be really nice if I kind of had this concept of TurboLynx. And if you're not super familiar with TurboLynx, basically what TurboLynx does is when you click a page, a link on your page, it basically intercepts that link visit, so be a click or whatever, and it prevents that from happening. Then it goes off and behind the scenes makes an Ajax request, gets the page itself when that HTML comes back, it swaps it out client side and then it updates the URL using page state. And that works really, really kind of neat. It's kind of a neat little trick that the folks at Basecamp use for that. But the trick is, and the problem is, again, that didn't play well with view. So I'm like, how can I take this TurboLinks idea and bring it to kind of view? And what I came up with was a similar sort of concept, except when I intercept a page click link. Instead of going off and getting the HTML, I actually go off and I get some JSON back. So it's similar to just making a standard JSON XHR request, except in this way, the way that inertia works is it's designed so that the server detects if it's an XHR request, so if it's an inertia request, it doesn't give HTML back. Instead, it just gives me the JSON back that on the first page load, what it would normally go into that base div, that root div for the app in the props value, it goes to the server and it instead just gets that data and the name of the page component, returns it back to inertia, the client side and inertia says, okay, well, you want to go to, you know, you're on the user's page and you want to go to the create new user page. Well, we know when you hit me when we requested the new user page that we got the page component new user back. So it's a view component called new user page. And here's some props that are needed to render that component. And then it dynamically swaps them client side and updates the URL again, using by updating the page state. Yeah. The, I forget what it's called, but basically just updating the URL dynamically the way you would with a normal client-side routing library. 

STEVE_EDWARDS: So let me make sure I get this straight. So using inertia, if I click a link and I want to go to a new page, I'm going to your inertia backend, getting whatever data I need and returning it. So how is that different where in normal view we're using a view router where you wanna change pages. So you click a link and you make an AJAX call, you get your data, it switches component. There's a term I'm looking for, provides the data to that component and displays it. What's the difference between the two approaches? 

JONATHAN_REININK: Yeah, so that is kind of like, that's the big question. So for one, typically if you're using a library like view router, it's designed to work with all your data's client side, right? And you're making, you're using something like, I forget what it's called, Vue X, I think it's called for state management. 

STEVE_EDWARDS: For state management, yeah, Vue X. 

JONATHAN_REININK: Yeah, and you got to build an API to return all that data. And there's kind of like a whole bunch of like, there's just a whole bunch of architectural changes that you make when you go about it that way. Even something like how you do your authentication, it's kind of like an entire paradigm shift when you when you go that direction. Whereas with inertia, I didn't want to have to say, well, just because I want to build an SPA, I don't want to have to throw out server-side routing. And I don't want to have to throw out being able to get data for a specific endpoint using my ORM. I don't want to have to necessarily build a REST API or a GraphQL API in order to do this stuff. So inertia is just like a really, really simple way of essentially doing the same thing, except it just makes it really, really easy which is why I always tell people that it's, Inertia has really been designed for, for people who are used to building classic server-side rendered applications, where you have all your routing server-side, and you have these controllers that get data for a specific page and then return it. Whereas if you go more the classic SBA approach, what you would do is you'd use Vue Router, you'd set up all your routes client-side, you would then have your state management which would then interact with an API that you'd have to go off and write, and you'd have to kind of like build all that stuff. And there are obviously advantages and there's definitely use cases for those style applications. I just think that there's, it requires more work in the end because you're essentially building two different applications at that point. You're building an API and you're building your client side application and those kind of live in two different places.

STEVE_EDWARDS: Right. So I think I get what you're saying just because I come from PHP2 world from the Drupal side of things, actually living in that world again for a couple of months. And so I understand what you're saying about being able to access your data. Whereas if I'm writing something server-side in PHP, I can just query my database from there. I can do whatever the heck I want, whatever query I want. Whereas if I'm dealing strictly with a friend and I got to have that bridge, that API bridge between myself and the back end. And so if I want to change, add a new query or something, I got to change my API and write that code so that it gives me the access that I want. So am I making the right comparison here? 

JONATHAN_REININK: Absolutely. Exactly. And at first, it doesn't seem like a big, like it doesn't seem like a huge win at first, but if you've ever built an application where you're, you have the separate API from your client-side application, you, you, you know, the kind of pain that you run into even just with versioning and keeping things in sync you know, well, we need to make this change for the client side, but that means we're going to introduce this change to the API. And that is that change is going to introduce breaking changes for some other place. And it's just kind of like this whole thing you need to manage. And of course, there are times when that makes sense. You know, for instance, if you're building a significant application, web application that also has a significant iOS and Android app that go along with it, you know, then it might make sense to build an API. I just think that there's a lot of applications where the classic monolith, the classic server-side rendered approach, the old, you know, the Ruby on Rails, the layer bell approach just makes so much sense still because you can work and move so quickly. But the problem is, if you are building an application using layer bell Ruby on Rails, and you wanna have that SPA experience, it's not a simple little switch. It's not like, oh, well just do this and now you have an SPA. It's like, well, actually you need to build a REST API now, or you need to build a GraphQL API, and you need to figure out your whole authentication layer, and you need to do this, you need to do that. It gets really, really complicated and hairy quite fast. And that's really where, with inertia, I wanted people to be able to kind of like create a new Rails app or create a new LayerVal app and start creating your routes just like you always would, and create controllers just like you always would, and get data back from the database just like you always would. But not, and then on the client side, not have to do server-side rendered views, but be able to use clients, like a client-side library, like Viewer React, and build your whole client side that way without kind of like going all in on kind of that SPA, you know, the classic SPA setup and architecture. 

STEVE_EDWARDS: So, okay, so from a front end standpoint, I'm gonna get into the weeds a little bit here, a la Adam Weldon. And so we're writing code in my view template and I need to access some information from my back end. So what's the mechanism that makes that happen? Is it just a matter of calling a route in your controller, handles everything for you based on parameters or how does that happen? 

JONATHAN_REININK: Yeah. So basically I'll just try to walk you through a simple example. So you're on your dashboard of your application and maybe you have a link on your page and that link goes to edit a user, maybe edit the current user, whatever. Okay. So when you click on that link, Inertia intercepts it and goes to the server. And it says, I need to, basically it goes to visit the edit user endpoint, which is an endpoint that's been defined server side. So somewhere in your route definition file server side, there is a route for editing a user. And then that route will typically link to a controller method and that controller method will historically say, get some data about that user and then return it back using like a blade view or an ERB template, except with inertia, it doesn't do that. It's gonna return, it's gonna get the data from the database or wherever. It doesn't have to be the database, but typically you're using your ORM to get the data from the database. And then what you do is you return an inertia response instead. So instead of returning a blade view or an ERB template, you say, return inertia render and again you give it the page component name which would be edit user and then any data that you need for that edit user page which in this case would be a user object with maybe a first name last name and email address and whatever other parameters that you want to show in the edit user page. So then that data then comes back to the client side because it's an XHR request right and inertia again sees that response and then swaps out you're on the dashboard swaps out the dashboard page component with the edit user page component, with the props, so the data necessary for that page, and then updates the URL accordingly. 

 

Are you building applications with Vue.js? Then you need to check out the Vue's on Vue podcast. Every week we bring in a guest panelist from the Vue community and talk about the interesting things being built with Vue or the changes coming in its ecosystem. You can find it all at viewsonvue.com. 

 

STEVE_EDWARDS: So this must be, so I'm guessing there's some sort of serving, it's basically serving as your API is what it sounds like. It's intercepting your call, going to your backend, getting your data, passing best off to your view component. 

JONATHAN_REININK: Yeah. I guess you could look at it like that. Yeah. I think of it kind of like, yeah, it's kind of like a protocol is what I think of it as. So when inertia makes a request, the client, so the server-side knows, okay, if it's an inertia request, it knows not to just return HTML and it knows not just to return plain JSON, it knows that it has to return this response in a you know, a very specific way. And that, like I said, that primarily includes the name of the page component that you want it to render and the data for that page component. But yeah, like, yeah, to answer your question, there is kind of like, yes, a preset protocol, which I should maybe have mentioned the way that this all works is that inertia, because it is really this protocol, when it makes a request, the server also knows how to respond to an inertia request. So when a request comes from the client side, the inertia request being an XHR request, right? It actually passes through a header that is X inertia equals true. And what that does is it tells the server that it's an inertia request so that the server then knows how to respond. So we actually have, so we have three client-side adapters is what we call them, three client side adapters for the various client-side frameworks. So one for Vue.js, one for React and one for Svelte. And then we have a bunch of server-side adapters as well. So we have a Laravel adapter, we have a Rails adapter, and we have other adapters as well in addition to that. So what happens then is these two adapters, because they understand this protocol, they work together. And it just, and it kind of like, it maybe sounds like a lot, but it's actually really, really light client. Like practically speaking, the way you build your server-side app is almost identical to the way you'd normally build a Laravel app or the way you'd normally build a Rails app. The only difference is instead of returning just some HTML from a Blade Viewer and ERB template, you just return an inertia response instead. But really the way you build the whole rest of the back end is all the same. And even on the client side, I tell this to people too, inertia isn't this framework that you're really committing to. Really what you've already done is you committed to a framework like Vue or React and inertia is almost like just the, it's kind of like a different type of React router or a different type of view router. It's like, it's really the piece that handles the routing, the client side routing, except instead with, you know, classics SPAs, the routing is all done client side. It's all done with the expectation that you have some API. It's done with the expectation that you're going to have some client side state management with inertia. That's not at all. All it does is handle your page transitions and swapping out the page components when it goes from one page to the next. And it handles your history state so that you can go forward and back and whatnot. But really, it's really, really light because it really relies on the server-side framework to do the bulk of the work still. So I always say with inertia, there is no client-side state because essentially the server is still your state, just like it would with a classic server-side rendered application. 

STEVE_EDWARDS: So what are, I don't know if you've done any benchmarking then, so how is this, is this I'm assuming a little more performant using this approach as compared to a standard server-side rendered setup. Is it similar? Where does it come from? 

JONATHAN_REININK: Yeah, so there's, there's, yeah, so the performance is lots of interesting things around performance so you can talk about, it depends on what, what kind of performance you're talking about. So the, the big trade off, like the trade off is anytime you're using a client side framework like Vue or React is that you're passing a bunch of JavaScript to the browser. So you have that problem. That is, you know, that's a trade off of using inertia because you're using a client side framework and that framework and all the page content, all that functionality all needs to be bundled up and passed over the wire to the client. Unlike a server side rendered application, which is just spits out HTML and that's you get the minimum amount of data possible because it just gives you HTML back. But that trade off is often worth it because it's the same reason everyone uses view and react is because that you get all this additional functionality that comes with it. You can build these really rich client side applications because you have this full JavaScript framework at your disposal. So that's kind of one thing to keep in mind. I should mention right away that there, even there inertia works really, really well with code splitting. So if you want to use code splitting, that works basically out of the box, especially if you're using React, or sorry, especially if you're using Vue. Vue has awesome code splitting built right in. You get it for free with the framework. Meaning if you land on the home page, you're gonna get your initial bundle, whatever the minimum amount of JavaScript is required, and you're gonna get your first page template, whatever the page component that you're landing on. And then if you click to go to another page, when Inertia does that request to get the new page component, it's gonna then lazy load that next page component if you have code splitting in place. So that's just a little heads up if you're wondering about how code splitting works with inertia. It works really, really well. As far as performance compared to a classic server-side rendered application, yeah, like the actual time that it takes for the page to respond is identical because it's returning an HTML or it's returning some data back just in the exact same way. The difference is compared to a server-side rendered application is that a server-side HTML right away and the browser can then immediately render that HTML. Whereas with inertia, you're going to get back some essentially a little bit, just that base div, that root div for your application, which includes your page component name and your page props, and then Viewer React need to boot up and actually render that template the first time. So for the very first page visit, which I call like the HTML page visit, There's that kind of like that boot up time that has to happen that you wouldn't have with a classic server-side rendered application. However from that point on moving forward you now have you and react Initialized it's it's active in in your browser in the client so from then on any subsequent visits you make new endpoints they're made over xx HR and And then what happens when those response come back inertia dynamically swaps the existing page component with the new page component. And it's just getting that back as plain old JSON from the server. So then it's really, really fast. Like it feels, it feels awesome. I've built a few applications now with inertia and it really, it's, it feels great. Of course, if you're using code splitting and you visit a new page that has a ton of new dependencies, I rec, you know, they all have to download those, those JavaScript dependencies need to download. There's a cost there but again, that's the kind of a trade-off you make by using a client-side rendered framework. And then kind of the last kind of piece of performance I would talk about is the challenge. So this is something that's always kind of had me hesitant to building kind of the classic SPA sort of applications. And I've built them and we've run into these problems is you have, and it's primarily a problem with REST APIs, although it can happen also with GraphQL APIs is you have a page that needs a bunch of data, but it needs it from a bunch of different endpoints. So you have a page that loads really quick. So like in an SPA, it loads really quick, but then it needs to go off and it needs to get some data from this endpoint and some more data from another endpoint and some more data from another endpoint. And you think, well, you know, if we have three to four requests getting data for this page, that's not so bad. But I've seen practically speaking applications that end up, and I've seen this in my own applications, and I've seen this in other applications, where suddenly you have a page that's now making between 10, 20, 30 requests to get all the different data for that page. And that's because with a tool, like with a design pattern like a REST API, you can't necessarily bundle up everything you need for that page just in one request, which is the whole beauty of something like GraphQL, where you can say, well, I want this here, and I want that there, and I want that there, and then you can return that all back as, as one response. So the nice thing with inertia is you don't have that. Anytime you make a request to an endpoint, so I want to go to the edit user page or I want to go to the users page or I want to go to whatever page it is that I want, it's making a single Ajax request, a single XHR request to the server. And that server endpoint, just like it would if it was a classic server-side rendered application where that controller method would go off to the database and get some data, it's the exact same way. You do the exact same thing in that controller endpoint. And you say, well, I need this data from over here, and I need this data from over here, I need this data from over here. And you can make that really quick and efficient because your server-side has quick access to the database and it can package up just the exact data you need specifically for that request and return it back. So that's like the huge advantage Inertia has over even just building a REST API is that you can get exactly the data that you want back specifically for that request. Now the trade-off there, again, it's all about trade-offs. The trade-off there is you've created a tight coupling now between your client-side page components, so your client-side view and your server-side endpoint. And that's for me, in a lot of situations, that's a trade-off I love, because I love the performance that I can get from it. And I don't mind that tight coupling because it's easy to understand and because the lack of coupling creates all sorts of performance issues because with the REST API, I need to make some requests. So, and this is a trade-off that anybody who's ever been building server-side rendered applications, that's a trade-off they're already making. That's just the way you build server-side rendered applications. So- 

STEVE_EDWARDS: Well, if you know you're within a monolithic structure, then the coupling's not a problem because you know the front end and the back end are designed to work together specifically. 

JONATHAN_REININK: Exactly. 

STEVE_EDWARDS: As compared to being two, I'm gonna choose this and this and throw them together, and then you got different issues.

JONATHAN_REININK: Exactly. And obviously if you go off and build a GraphQL API, then yeah, then you can make a single request to just get the exact data you want. But now I'm saying that's cool. You can do that. And I think if I was going to build an application that needed an API, I'd definitely be reaching for GraphQL. But my point is for a lot of small applications or for a lot of applications that, you know, that's a huge undertaking to build a GraphQL API. That's a whole bunch of work that maybe I didn't want to do for my simple little project. Maybe I just wanted to create a new layerable app, create an endpoint that's starting to do some things. And I wanted to be able to use Vue React on the client side and to have to say, well, in order to do this in the most performant way, I'm gonna have to start by making this, I have to have a client-side application repo now and I need to have this GraphQL app and repo and hosting and all that hoopla that all comes along with that. Again there's use cases and good use cases for that tooling. I just think there's a ton of applications. And I mean, I think there's a lot more than we even realize. I think there's so many applications that are well suited for just a monolithic sort of design. And even if you do need an iOS or an Android application at some point, at least in my experience, quite often the iOS and Android apps don't need to have the full functionality of your web app. At least in my experience, almost never. Now, of course, there are situations and there are applications that you do want complete feature parity. But I think there's a lot of applications that don't need that. You can have your main web app that does the vast majority of things and then iOS and Android apps that have a subset of the features that are kind of most appropriate to have on mobile. And in those situations, there's still nothing stopping you from then within your monolithic application creating a simple API endpoint for whatever you need for those iOS and Android apps. And I've done that, I've built my own app in that way and it works really, really nice. Like if you think about it, like here's one great example in a lot of web apps and a lot of web, you know, a lot of web software, there's a whole layer of like system management. So whoever's, you know, maintaining that software, whoever owns that software, it's an area that your clients don't have access to. It's just an area that you use from you know, just to manage the system, manage billing, manage customers, whatever. And that might all be built within your application. That stuff can really add up all that code and all those pages and everything else. And that's all stuff right there. It totally, totally doesn't have to exist in iOS or Android app. Just because it exists within your web app, it doesn't need to be over there because you're typically not going to be doing that administrative work on a mobile device. Or maybe even if it would be nice to, you don't need to. Right? So that's kind of an area that you could just build in web form and completely leave out of the iOS and Android apps. 

STEVE_EDWARDS: So, okay, so let's step out of the weeds a little bit and go some bigger picture questions. So if you're in the React community and generally you want a server-side rendered application, you're gonna reach for Next. If you're in Vue, you're gonna reach for Next. And I'm more familiar with Nuxt and so you have your three different ways you can do an SPA, you can do universal where you're actually using a node back in, or you can do now with 2.13 you can do straight static mode, which is a Gatsby type of site or a Gridsome type of site. So is there cases where inertia would be better than a Nuxt site for somebody? Obviously inertia isn't something you would want to use for a static site because you can. The whole idea is that you have your controllers on the back end that can dynamically generate your data for you quickly. 

JONATHAN_REININK: Yeah, 

STEVE_EDWARDS: so let's say I'm looking at something in next in universal mode with the node back end or inertia. What's the pro where does inertia do better than then say next. 

JONATHAN_REININK: Yes, so I would think like right off the bat, if you're using NUXT in that format, you're using a node back end. Right. So if you if you're a layer of L developer, if you're a PHP developer, you're a Ruby developer and you're totally familiar with that ecosystem and that whole way of building server-side applications, you may not wanna build a node backend, right? So that's just one thing right off the bat. So that's really, again, like I didn't build, sorry, you were gonna say something? 

STEVE_EDWARDS: Well, I was gonna say, I mean, the node backend comes with Nux. Most of your work is doing on the front end. I mean, in some cases, if you're using ASIC data, for instance, or middleware, you're gonna intercept the data that's coming back from Aria calls and you can do things with it, mutate it, whatever you want to do before it to get past your front end. So you're not necessarily writing a node back end from Scripthlyte, like you would be with the Laravel or Ruby. It's there for you to use as need be, but it's still a node back end as compared to, like you said, something you're more familiar with, like Laravel or Ruby or whatever. For your own system back end.

JONATHAN_REININK: Yeah, I guess my question would be, well, what is the expectation then with Nuxt? And I'm assuming it is the expectation is that you would have an API that you would use to do anything that you need to do custom on the back end. 

STEVE_EDWARDS: Yeah, you're still going to need to call some sort of API endpoint. Yeah, so that's your data and there's different ways and places to do it. But yeah, that's the gist of it. 

JONATHAN_REININK: Yeah. So then the big advantage of using inertia is that you don't need to build that API. So you're building it, you would build a classic server side, like kind of a classic server side application that does things, but you wouldn't have to build an API specifically for this client side application. You could just build a normal monolith server-side rendered application. And when I say server-side, I don't mean it's actually server-side rendered, but yeah, like a normal server-side app like Laravel or Rails. And you wouldn't have to build the API that would then work with the kind of the Nux front end or whatever. You would just build it as a normal Laravel or Rails app.

STEVE_EDWARDS: Right. So, so one of the things you can do, you know, with view and Next, you know, Next provides your server-side rendering because you can use it a couple of back end, you know, a Contentful or a Strapi or a Prismic or, or whatever. So your inertia obviously is designed for your developing soups and nuts front to back, top to bottom, whatever phrase, phraseology you want to use. Now I did notice under your inertia site, I don't know if we've talked about this too much is the array of front and back ends that you can use together. So you could use Laravel with Vue, you could use Ruby with React. So there is a little bit of plug-and-play in terms of the toolset that you can use on both the front and back end. Is that correct? 

JONATHAN_REININK: Yep. Absolutely. Yep. That's it. You can use on the client side, you can use Vue.js, you can use React, or you can use Svelte. We have adapters, client-side adapters for all three of those. 

STEVE_EDWARDS: What about vanilla.js? Could you use just straight JS or do you need to use one of those frameworks on your front end? 

JONATHAN_REININK: Yeah, like that's kind of the, that's kind of like the value prop, right? Like you, the, the whole, the whole, the whole idea is that you want to use something like view or react because they provide all this tooling, right? And make it really easy to do this stuff. Nobody has done vanilla JS at this point, because I would, you know, the, the main feature that inertia needs in a client side component swapping so that we can switch a one page component to another page component. Now you could write theoretically your own vanilla JavaScript front end, but that kind of 

STEVE_EDWARDS: seems like a lot of work. 

JONATHAN_REININK: Yeah, it's not. Yeah. You'd be creating a new framework at that point. That's not really the idea. The idea is really the goal with inertia is to allow people who are already familiar with server-side frameworks like Laravel or rails or any one of those server-side frameworks and are familiar with a tool like viewer reactors felt to be able to use those two things together in The more classic monolithic way and avoid having to do the whole API setup and having to build a separate API from your client It's really the goal is to keep those things together. Keep them tightly tightly coupled so that you can iterate and make applications really really quickly 

STEVE_EDWARDS: Gotcha Okay, so a couple more things we that I think people would be interested in. One is authentication and form submissions. Two very common, you know, things that you're gonna need to set up with any application. So how does Inertia handle those two things? 

JONATHAN_REININK: Yeah, so I'll start with auth because it's so easy. So this is one of the things that I think people, at least in the community, the programming community that I follow along with, authentication is always this complicated thing. Anytime you wanna move to using kind of going to the SPA API way. You need to use something like OAuth or people choose not even to roll their own authentication systems and they start using services that do it instead. The nice thing with inertia is you really don't have to think about authentication at all because typically your client or your server-side framework, so Laravel for instance, has an awesome session-based auth system built in ready to go. So with Inertia, you don't need to set up OAuth. You don't need to use some third-party service. You literally just set up basic session auth, just like you would with any Laravel application and you're up and running. Because it's all, again, it's all within one application. It's all just one monolith. So when you log in, it creates a cookie, right? Which tracks your session. And as you browse around your application, Inertia makes requests and they always get validated just like they would with a normal full-page visit to your application. So authentication is like really, really nice and simple. It's kind of like one of the nicest things that you just don't have to deal with at all when building an SPA with Inertia. So then the other thing is form submissions and just doing form stuff in general. So kind of one thing I haven't mentioned this whole time is when you make an inertia visit, so there's two ways you can make an inertia visit. One is by clicking a link. So you have an inertia link, which is basically just an anchor link that has an href to a page. So the only difference is it's an inertia link so that when you click on that, inertia knows to intercept that and do the, visit the backend via XHR via AJAX and get the data that way instead. However, you can also make requests using just programmatically you can call inertia.visit and visit whatever page programmatically as well. And you can do that not only for get requests, but you can also do it for put or post or patch or delete. So this is kind of where it's kind of unique, because you're making these page visits, but they're using, they're not just get requests at that point. They can be other, they use another methods instead. So the way that you typically set up a form in inertia, and this is kind of a little bit different than how you would with a classic view classic view app is you would set up a form and it would have your inputs in it. And if you're using view, you're going to have some data that's assigned, right? You have some data that's predefined and you have some V model attributes set up so you can keep track of that reactively. But then when you go in it, when you submit that form, typically what you would do with you is you would intercept that form submission and submit it down using XHR, using Ajax. The difference is, and then what you would do is you would inspect that response manually from that request, from that response, from that form submission. You would inspect that response manually in JavaScript and say, well, if an error came back, well, then we're going to update the page to show some errors. However, if a success message came back, well, then we're going to redirect to some other page within the application. So if we're creating a user and the email address validation failed, well, we'll show an email validation error. Or if we're creating a new user and the user was created, well then we got the ID back and we're gonna redirect to some other page. It doesn't work that way with inertia. It's actually really, really simple. What you do is you still intercept that form submission, client side with Vue.js, except what you do instead of submitting the request using Ajax and passing down the data and looking at the response and then updating based on the response, you literally just do. Say for example, if you're creating a user, you would do inertia dot post, and then you pass the endpoint where you'd create the user. So slash users, and then you pass in the form data. So first name, last name, email, whatever. And that's just an object that you pass to inertia post. And then what inertia does and that's it. That's literally all you write. It's one line of code. You don't do anything else. And then what happens is that gets submitted down to your server as an inertia request, but it's a post-inertia request. What happens then is it hits the create user endpoint. It does some validation. And let's just start by saying, let's go happy path first. Let's say there's no validation errors and it creates the new user. And then what it does is in the Ajax request that gets submitted down, that inertia request that gets submitted down, it then, you would then do just like you would in a classic server-side rendered application is you wouldn't return some JSON at that point that gives you the ID of that user classic server-side rendered application, what you would do is you would do a redirect to the page that you wanna go to. So let's say after I create a user, I wanna go and visit that user page. So the way it would work in a classic server-side rendered application is you would do a redirect after you create the user that redirects you to the new user's page. And you do the exact same thing with inertia.js. So when that request comes down, it creates a user and it does a server-side redirect in the XHR request. Okay, so and then it goes from there and it lands on that new user's page. However, because the server can recognize that it's an inertia request, it says, hey, this is an inertia request, so we're not gonna return full HTML here for the view user page. Instead, we know it's an inertia, we're gonna return an inertia response instead, which says, well, we want the view user or the edit user page maybe, and here's the data for that new user that we just created. That response then comes back to inertia. Remember from you made that from your create user form and inertia says hey, I got an inertia response back I know what to do with that I got this new page which is view user and I have some data which is a new user data and it dynamically swaps out Client side and now you're on the the the view user page. So without any work on your own having to inspect that response it all just happens automatically because it's really been. This whole tool has been designed to work like a classic server-side rendered application, except it's client-side rendered. So that's kind of like the happy path. The validation failing path is also very, very similar and very, very easy as well. When you do that inertia.post and you pass it to the user's endpoint that's going to create the new users and that validation fails, let's say the email address, it doesn't return back to you a bucket of errors in the J, you know, as some JSON from that response. What it does is exactly like it would do in a normal server-side rendered application. It's gonna redirect back to your create user page. So when it's doing this within the XHR requests, right? So keep that in mind. So you hit the create user page, validation for the email fails. It automatically redirects back to the create user page, which you're actually already on, that comes back to the client now and sorry, before I go there. So it goes back to the create user endpoint within your application, except this time it has in the session, it has some flash data. It has some error data from the validation there that just failed. So in a classic server-side rendered application, you would then take that and throw it into your blade template or your ERB template and you'd render out those errors manually. But what happens is with inertia, it comes back as an inertia response, which comes then says, well, we're gonna pass these errors now automatically to the create user page. And then what happens is it's because inertia is now essentially made a visit right back to the same page, it then updates the page, which doesn't change at all because you're still in the create user page component. So that doesn't change. But what does change is the props that are being passed to that component. And because tools like React Svelte and Vue.js are reactive, when that new prop comes in, that bucket of error messages, it'll dynamically and automatically refresh your pay template to show that error for you because that's just how the reactivity works in these libraries. That's a long description and maybe sounds complicated, but practically speaking, if you go to inertiajs.com and go to the forms page and you look at the examples for view and react, it's really, really simple how you end up building these things you don't have to inspect these responses. It just works automatically because you're getting these inertia responses back. 

STEVE_EDWARDS: So you obviously would have to write your component to handle the props and, you know, display here and, you know, display this error here. It says, Oh, your email address is the incorrect format or whatever. 

JONATHAN_REININK: Yeah. 

STEVE_EDWARDS: But it's just basically taking advantage of the, of the data binding, the reactivity within the front end library. And then you have to handle that reactivity change. 

JONATHAN_REININK: Yep. Exactly. Yeah, but you still have to actually display the error. That's your responsibility and you can do that however you want, you know, obviously. It just means that it just means the code to do the work is much simpler. You're almost going to think about it like, if you were building a classic server-side rendered app, when you would do a form submission, you know, the way that those work is it actually does a full page reload, right? And that might be a get submission or a post submission. And then you'd have to do some validation and then re-render that whole page. And what sucks with that approach is that you actually, any existing form data, so like the first name or the last name of the email, you have to then like manually repopulate the inputs, right, with that data, which is annoying. But with inertia, the whole, the component is still there and the local state's still there. It's simply getting some updated props from the server after the inertia response comes back. And it's, and because of the reactivity, those props just get automatically used by the component. So there's no like repopulating form inputs. It just, that just works automatically because the page component isn't being destroyed. 

STEVE_EDWARDS: Awesome. Okay, so we need to start wrapping up here a bit. So before we get into Picks, where can people help out if they want to contribute to Inertia or just watch what's going on with this project? 

JONATHAN_REININK: Yeah, so inertiajs.com. That's a good place to go. I'm on Twitter, that's where I'm pretty active, most active on Twitter, so it's just my last name, twitter.com slash reink, R-E-I-N-I-N-K. That's my username there, so I talk about inertia and database stuff and Laravel stuff a lot there. And there's also an inertia Twitter, there's an inertia Twitter page account as well that you can follow. There, we're on GitHub, obviously, and we also have a Discord channel, and we also have a newsletter that you can follow along, and I send periodic updates as well about that.

STEVE_EDWARDS: So what is, what's the inertia JS, the Twitter account? 

JONATHAN_REININK: It's just inertia JS, 

STEVE_EDWARDS: inertia JS, and then a discord channel. 

JONATHAN_REININK: There's a link on the website for that. 

STEVE_EDWARDS: Oh, okay. Good. 

JONATHAN_REININK: Yeah. 

 

One of the biggest pain points that I find as I talk to people about software is deployment. It's really interesting to have the conversations with people where it's, I don't want to deal with Docker. I don't want to deal with Kubernetes. I don't want to deal with setting up servers. I don't, you know, all of these different things and in a lot of ways, DevOps has gotten a lot easier. And in a lot of ways, DevOps has also kind of embraced a certain amount of culture around applications, the way we build them, the way we deploy them. I've really felt for a long time that developers need to have the conversations with DevOps or adopt some form of DevOps so that they can take control of what they're doing and really understand when things go to production, what's going on, so that they can help debug the issues and fix the issues and find the issues when they go wrong streamline things and make things better and slicker and easier so that they'll more generally go right. So we started a podcast called Adventures in DevOps. I pulled in one of the hosts from one of my favorite DevOps shows, Nell Chamerell Harrington, from the Food Fight show, and we got things rolling there. And so this is more or less a continuation of the Food Fight show where we're talking about the things that go into DevOps. So if you're struggling with any of these operational type things, then definitely check out Adventures in DevOps and you can find it at adventures in DevOps podcast.com. 

 

STEVE_EDWARDS: Alrighty. So we will move into pics. So we lost AJ and I think we lost Amy. 

AIMEE_KNIGHT: Still here. 

STEVE_EDWARDS: Oh, Amy's here. Woohoo. Okay. So we're dropping like flies. Do you have any pics, Amy? 

AIMEE_KNIGHT: I do. Let's see. I'm trying to think. I have a couple here. I'm going to go with this kind of, well, not kind of. It is pretty much completely unrelated to what we've been talking about unless you host your stuff on AWS. But I'm going to pick something. It's more geared towards startups. So maybe it could be tangentially related to what we're talking about, because monolos are good for startups sometimes, because you want to just do something fast. But how to reduce your AWS bill by 2%. Or no, I misspoke. Our AWS bill is less than 2% of our revenue. So that sounds pretty good, because that stuff can get really expensive really fast. And you want to be careful what you're clicking on. So. That'd be my pick. 

STEVE_EDWARDS: All right, I'll go next. So I got sort of an interesting one. I'm gonna go with colonoscopies. And here, there's a reason for this. I'm 51 and generally it's recommended that once you're 50, you get a colonoscopy. And my wife's been pestering me for quite a while to get mine done. And so I had one scheduled for May or April, it was April or May. And then it got put off when medical organizations weren't allowed to do procedures because of COVID restrictions. It's been rescheduled tentatively for August. But then this week, I heard an interesting story. A friend of mine is almost exactly 10 years younger than me, was diagnosed with colon cancer. And I was talking to him yesterday about it and he was telling me how, started a few weeks ago, he started getting all this pain in his gut. And he goes, we went and did like ultrasound, didn't find anything. We went and did like a CAT scan and conclusive. Did a colonoscopy and endoscopy and that's where they nailed it. That's where they found the cancer. It's like a golf ball size malignant tumor, right? Whereas a small and large intestine pain, I believe. So they'll do surgery to remove that. And I joked with him that he's now going to have a semi colon instead of a full colon. But anyway, the point was that it was the colonoscopy that found that where other procedures did not find it. He's only 41. And so which is considered young for something like that. So his doctor wants to submit his case to a local medical school, just as a case study of what can happen. Anyway, that's the whole point, get checked for stuff like that because sometimes those tests will find things that maybe other tests miss. So that's my cheerful pick. On to Jonathan, what do you have for us? 

JONATHAN_REININK: I didn't know if I had to have a pick. 

STEVE_EDWARDS: Oh, okay, well that's fine if you don't have one. No, I think if you could think of anything you want TV, movies, books, you name it. Good recipe you've cooked lately. 

JONATHAN_REININK: You know, I got nothing off and I guess I'll just pass then because I don't want to say something silly. Oh, 

STEVE_EDWARDS: we're all about silly here, right, Amy? 

JONATHAN_REININK: Well, OK, well, then I will say that I just finished watching Lost in Space, the on Netflix for the second time, which I think is amazing. Love, love it. I think it's so well done.

STEVE_EDWARDS: Is this a series? 

JONATHAN_REININK: I'm trying to think about it. Yeah, there's there's two series now or two seasons now. And I think they're going to be doing one more that they said was coming out in 2021, I think, which I don't know if that's changed now with all the covid stuff. But yeah, it's I think it's an awesome series. 

STEVE_EDWARDS: Is it? Do you have you ever seen the original? 

JONATHAN_REININK: He like, well, doesn't like isn't it based on like the the book, the Robinson Family book, whatever it's called? 

STEVE_EDWARDS: Oh, Robinson Crusoe? 

JONATHAN_REININK: No. Oh, shoot. I forget what it's called. 

STEVE_EDWARDS: Twisted Family Robinson. 

JONATHAN_REININK: Yes, that's I think. Isn't it lightly. And then there's also, yeah, the original movie, right? The that Lost in Space movie, which I have seen as well. Yes. 

STEVE_EDWARDS: Well, actually, no, there's a I can remember watching this when I was very young. Won't tell you how old I am, but you already have. I already did. Dang it. Cats out of the bag. No, back in the 60s, there was an original episode that kids might remember watching cartoons.

JONATHAN_REININK: Got you. 

STEVE_EDWARDS: And then Matt LeBlanc did a movie, I know if I remember correctly, a few years ago, sometime after Friends. I don't think it ever did very well. 

JONATHAN_REININK: Yeah. 1998. That was the first one I watched. 

STEVE_EDWARDS: Okay. Yes. And you are correct. It was inspired by the novel, The Swiss Family Robinson. 

JONATHAN_REININK: There you go. And I've been saying like, I've been saying, saying Danger Will Robinson for years and my wife has no idea what I'm talking about whenever I say that. 

STEVE_EDWARDS: Right. 

JONATHAN_REININK: But now she watched it with me. So now she knows. 

STEVE_EDWARDS: Right. Exactly. Alrighty. Thank you for coming on and talking about inertia. Hopefully this podcast will give your project some inertia going forward. And yeah, thanks for joining us and we will see everybody next time on JavaScript Jabber. 

JONATHAN_REININK: Hi, thanks Steve for having me. 

 

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.