Ben: Hello, and welcome to PodRocket. Today, I am here with Jonathan Reinink, who is the co-author of Tailwind and the creator of Inertia JS. How are you doing Jonathan? Jonathan Reinink: I'm doing great. Thanks for having me on Ben. Ben: Yeah, I'm really excited to have you. We'll probably talk both about Tailwind and also Inertia. And Tailwind, I'm going to be honest, I hear a lot about it, but I've never really looked into it that much. So I'm excited to learn from you because I do hear a lot of people talking about Tailwind. So maybe we start at Tailwind and circle back to Inertia a bit later in the episode. Jonathan Reinink: Yeah. Sounds awesome. Ben: So can you just give us a quick overview for folks like me who have never used Tailwind, what does it do? How does it help you build great front end applications? Jonathan Reinink: Yeah. So I'm maybe a little rusty on my elevator pitch on this, but let me do my best here. So I would say at its core, the way we pitch Tailwind is we call it a utility first CSS framework. And it's utility first in that, the way you build your website is using all these really small CSS classes that focus just on specific properties and values in CSS. So one that's the classic one that you've maybe seen in the past, even on non-utility style frameworks is the text center utility. You put text-center as a class on some element in your HTML, and now that text is centered. And then early on as me and Adam were building the framework, or even before me and him started working on it together, this was an approach that he was experimenting with. Jonathan Reinink: And he pushed it like, "What can we all do with this?" And he started doing things like margin. Margin is a really natural thing to use utilities for. So you'd have something like margin-top four, and that sets a top margin of whatever value your four is referencing. And what he realized was that this whole technique works for a lot more than just basic things like centering text or setting margins or making something bold, or whatever it might be. And you can actually take this to an extreme and use this technique to build your entire website. And there's all sorts of interesting things that fall out of this technique, but at the heart of it, the one thing that really, really stood out to me when I first started using this... Adam was pulling me, kicking and screaming. He's like, "John, you need to try this technique." Jonathan Reinink: And I came from way more of a classic style background of doing BEM style, where you write everything actually in CSS and you give it names and you create modifiers, that really established approach that a lot of people were using a decade ago already and are still using today. I came from that angle and I was like, "Is BEM, is that approach even really broken?" So I was skeptical, which I think we run into that a lot. Even today, people are skeptical at first when they see Tailwind CSS. But anyway, so the thing that stood out for me was how fast I was using Tailwind and using this utility approach to building websites. And the big thing that I just absolutely loved was that I was able to stop thinking about naming stuff. Jonathan Reinink: This is always the crippling thing. You're building a new component, maybe it's a header on the website, maybe it's some sort of card or a form or whatever it is, a team layout, and you're like, "Okay, I'm going to go to my CSS file and the first thing I need to do is, I need to give this thing a good name because we're software developers and we've learned the importance of naming things." But when you're just trying to get a site built, and you're just trying to create this design, spending all this time naming really slows you down. And so with Tailwind CSS, you really don't name things anymore, because you're working with all these utility classes. And you instead just drop those writing to your HTML and it removes this whole need to name things. Jonathan Reinink: And that was just so empowering. And you still end up naming things, but it's farther down the line and only when necessary. And what I mean by that is, with Tailwind, where you create your abstractions changes. And I got to be careful how deep I go here, but just to flush this out a little bit further. Normally with the BEM style of approach to building a website, you're creating your abstractions in CSS. Whereas with Tailwind, you don't do that, you just add all these classes to your HTML. And then when you want to create abstractions, you actually create those abstractions using some sort of templating tool where you actually move your HTML or whatever. And you create your abstractions in the form of components. Jonathan Reinink: So kind of that classic examples of this would be, maybe you are creating a form and you're like, okay... Let me go simpler than a form. Maybe you're creating a button, and your button is like text center, BG, red, 600, text white, font bold, patting this. And you're like, "Okay, well I know that I want to use this red button in 30 other places in this particular application, and I don't want to have to repeat those classes every single time." For me, the way I approach that is, I'll create a button component in Vue or React, or even if I'm used in a Server Side templating framework, like ERB templates in Rails or in Laravels, something like blade templates, these tools all have forms of creating these components and these abstractions. So you basically move those abstractions elsewhere and it just feels a lot more natural. Jonathan Reinink: And you're creating those abstractions often anyway with your HTML. So that's the thing that really just felt great for me. I love that you could essentially start developing in the browser, because you have all these classes available and you can just start adding them to your HTML, and your design just starts coming together in front of you. Yeah, so I don't know if that gives you a bit of a sense of what Tailwind is and the big benefits to it. Something we often tell people... The thing that people see is they look at it and they see this HTML, and this HTML has all these classes and people get really... If you haven't tried, it can be a bit of a turnoff. Which I totally get, because I felt the same way. Jonathan Reinink: But once you tried it... and I always say that to people, "Don't knock Tailwind CSS until you've actually tried it on a project," because you really have to experience the workflow to truly appreciate what it's like to work with and the benefits. Ben: Yeah. And lots of people knocked HTML and JS so to speak. The early days of React when JSX was first coming out as a paradigm and now that's a widely loved paradigm, so I think... Jonathan Reinink: Exactly. Ben: Sorry, go ahead. Jonathan Reinink: I was going to say, that's a good lesson right there. I think as we push forward on any new technology, at first things can look different and weird and that can be intimidating. But I think as developers, I feel it serves us well to not be turned off just because something's different and to give it a chance. Especially if you get a huge amount of people saying, "No, there's some serious merit to this approach, to building websites or web applications." Keep your mind open because that's the way you learn and see new opportunities. Ben: And I'm curious, the idea of having these utility classes that out of the box give you a lot of functionality that you can start adding into your HTML, and quickly wire up the interface of your app, reminds me a bit of the pitch of Bootstrap or Foundation or some of those older CSS frameworks. So I'm curious, are there any areas or paradigm to those tools that you brought in to Tailwind, any similarities, differences? Jonathan Reinink: Yeah, absolutely. So Bootstrap, I would say is... We have a lot of respect for Bootstrap and it's a massive project and it's really had a huge impact on the internet in general. It's crazy. I forget the stat, but I heard the other day, how many websites on the internet are run on Bootstrap, and it's a mind boggling number. It's a little bit like, how many websites on the internet are running on WordPress. Even though everyone disrespects WordPress, but a massive portion of the internet runs on it. So for sure, with Bootstrap in particular, what we were noticing and I'm trying to remember if it was version three or maybe the dev version of Bootstrap four, the early alpha release, we were seeing more and more utility classes appear actually in Bootstrap at that time. In particular for things like, text center, font weights, margin, padding. Jonathan Reinink: And it was funny because I still had Bootstrap projects that I was working on myself, older projects before we even had Tailwind. And I would go back to those projects and I would want more of those utilities, but Bootstrap has a more limited set of what it does with those utility classes. But the real big difference between a framework like Bootstrap and a framework like Tailwind, is that Bootstrap aims more to be a component framework. They want to give you a whole bunch of ready-to-go components, be that a modal or an input or some sort of table design, buttons, all the things that you'd expect in a typical web application. Bootstrap is a lot more opinionated in terms of design, you're working with components. And we thought early on more about Tailwind as a lower level than that. Jonathan Reinink: We actually said that you could theoretically build something like Bootstrap with Tailwind. So Tailwind is very un-opinionated in terms of design. We don't give you really any ready-to-go components at all, we just essentially give you these classes that link to these CSS properties and values. And that's very much different than Bootstrap. Bootstrap has a distinct look and feel that Tailwind doesn't. So yeah, definitely got inspiration from that. I would say that Bootstrap's more in line with our paid product, which is Tailwind UI, which provides a bunch of ready-to-go components, that's a better comparison. And yeah, maybe another example of that would be Bulma and similar frameworks like that. Ben: Yeah. And I guess when Bootstrap came out, I'm pretty sure that predated React and Vue in the modern Vue layer framework. So my guess will be back then, there was more need for an opinionated way of doing these common components, like a button or a modal, but- Jonathan Reinink: Totally. Ben: Yeah. So curious to learn a bit more about Tailwind UI, you mentioned, that's a paid product built top of Core Tailwind, and curious what that does? Jonathan Reinink: Yeah, for sure. So Tailwind UI is really our answer to people who would start using Tailwind and they'd be like, "Tailwind's great, but I'm still not maybe a designer, and I still want to make my website look nice. I'm creating some website or some sort of web application. And I love working with Tailwind because of all the freedom and how easy it is to make changes using these utility classes. But I feel I need to keep using Bootstrap because I'm not a designer and I need help designing components." So Tailwind UI was really our answer for that. It basically gives developers just a huge library of ready to go HTML basic components. That's really the deliverable, HTML. It's not entirely true because we do offer React and Vue versions, so there's JSX versions and the Vue component version. But essentially what we're selling there is HTML, which is very much a similar story to what Bootstrap is doing. But the really cool thing I think with Tailwind UI, which I feel makes it unique is because it's built on Tailwind, it's extremely easy to make changes to these components. Jonathan Reinink: And so this was something that we really felt, and myself as a developer back when I was using Bootstrap more often, is Bootstrap was great when they had the components that you actually needed for your project. But the second you needed to veer from what they offered and you started to have to make changes, either in the overall branding and looks, so in terms of the colors and stuff, or more significant changes in terms of how a component or an input or a button or whatever looked, the customization story was really, really difficult. And I don't know if you've ever worked with Bootstrap, but their customization story is you basically have a page or two or three of variables. And I think back in the day there were SaaS variables and maybe they still are, and you could go through and you could start making changes that way, which was neat. Jonathan Reinink: It was neat that they made that possible. But it was always terrifying because they would have these padding variables, and it's like, "Okay, if I make a change to that padding variable, because I want to modify this button or this input or whatever else, you were never totally sure what that was going to all impact throughout the rest of the website." Whereas Tailwind's components and the Tailwind UI components really don't suffer from this problem, because all the components are just built with these low level utilities. So what you do is if you want to make a change, you copy the component from Tailwind's UI, let's say it's a button, and then you paste that into your application in your Vue or React or just your HTML file. Jonathan Reinink: And then you're like, "Well, I actually want this component... It has small rounded corners, maybe I want large rounded corners or maybe I want a full pill style or whatever." You can just go to that HTML, you modify that HTML right there and you're done. It's not going to have any impact on any other area of your application. It's really nice that you can just make these tweaks to it. And then you can take that to much bigger extremes. So if it's a table, maybe you add stuff in those tables that we don't ship in with Tailwind UI, images, drop-downs, whatever. Because you're just working with HTML, using Tailwind as this base to style it, it's really just so easy to make customizations. Jonathan Reinink: And that was the big win that we saw when we started creating Tailwind UI, because it's something that I could see myself using in my own projects. Grab a form, start modifying that form, remove some HTML, add some more HTML, change some colors, change some padding, whatever it is that you need to do, but at least you have this really awesome, really well designed component to start with. So we have a couple of designers obviously on our team, Steve Schoger is the one who's done a lot of the design early on, and their very gifted individuals and the components just really look awesome. Jonathan Reinink: So yeah, and the benefit for us and really the benefit for the whole community is that Tailwind UI being a paid product is something that helps pay the bills for us and means that we get to invest more time into Tailwind and the whole ecosystem. Which has really created some really cool opportunities in terms of how far we could take this open source project, that initially me and Adam, when we first built it, we weren't really sure if anyone would ever use it. And here we are now, I looked the other day and it's been installed over more than 40 million times, which is just mind boggling to me. Ben: Yeah, no, congrats. That's pretty incredible growth of the tool in what is often considered a very noisy space of so many front end tools out there, to break out as one of the leaders is pretty impressive. So congrats on that. Jonathan Reinink: Yeah, I appreciate that. Ben: I'm curious, a couple of questions I had on the concept of some of these components that you get with Tailwind UI, for example, a form. Do you also include JavaScript around some of the things that everyone does in a form like validation and states, and they require JavaScript or is that something you leave up to developers to implement, if you're building React or Vue, you let them implement it themselves? Jonathan Reinink: Yeah. So that's always a tricky line to draw, to know what we should be doing and what we should leave out of Tailwind UI. As a general principle, what we try to deliver in Tailwind's UI specifically is the visual components. So for instance, for a form, we will handle whatever makes sense to handle in HTML. So if it's a form that would potentially have an error message, we have examples of how to do error messages. But we don't necessarily try to implement any of the Server Side validation of course, that you could use Tailwind's UI with really any Server Side solution out there, so that's not really somewhere that we try to fix or something that we try to solve. Jonathan Reinink: We also I think if there... we'll put basic validation. So if it's an email input, we'll make sure that we actually make it an email input, so that you get that basic client side validation, but really that's as far as we take it. And the idea is that a developer can take the component, take the HTML and then wire it up within their own application in whatever way that makes sense. Be it whether they're working with React or if they're working with Vue, or if they're just working with plain old HTML in a Server Side framework like Rails or Laravel. Ben: And I'm also curious, when we were talking about some of the downsides of Bootstrap, having to have all these global variables that you tweak to change things. It got me thinking of there are some areas, even in a modern application where folks often want global variables like, colors or fonts. Does Tailwind have an opinion on how you do those, both in core Tailwind and Tailwind UI, when you have more out of the box styling that would be affected by those things? Jonathan Reinink: Yeah. So absolutely. So the cool thing on the Tailwind side is, which we haven't really touched on... One of the really, really neat things of Tailwind CSS is that it's extremely customizable. So we have this file called the Tailwind.config.JS file, which allows you to basically override almost all the colors and fonts, and font-weights, and sizing scale like margins, paddings, border radius's, and the list goes on and on and on. So Tailwind ships with a really, really good sensible default config. But this is what makes Tailwind so neat, you can publish that file, and then when you generate your CSS, you can go in there and say, "Well, Tailwind's red color scale doesn't really fit our brand." So you can literally just remove the red color scale and use your own red color scale. Jonathan Reinink: And basically all these utilities that then get generated are based on your own config and not the Tailwind defaults. So in reality, I would say that a lot of people try to stick with the defaults because they are a good sensible default, but then as you need to make tweaks... So the common ones really are colors, because you have your own brand, you have your own brand colors, you want to use those fonts or another really common one. Every project maybe uses different fonts, so you can tweak those. And then from there, the changes maybe become less common. Jonathan Reinink: So the thing, to get maybe a little bit into the weeds on the technical side of things, prior to a more recent version of Tailwind, where we introduced a just-in-time mode where we generate classes on the fly, previously what we had to do is, we took the config, we write all the values and then we generated a big, massive CSS file of all the possible values. And then from there we would do something called purging. And what that would do is, it'd go through and get rid of any of the styles that you don't want. Jonathan Reinink: But not everyone knew how to purge and not everyone used purging. So we were always really concerned, or people shipping too big of a CSS file? Because in reality, Tailwind makes it really easy to ship a super small CSS file because once you purge away the classes you don't use, you end with just these this really nice subset of CSS that tends to be extremely small. Way smaller than what you'd get with say something like Bootstrap, which has to ship everything in it. But anyway, with this new just-in-time mode, we now can ship even more options with Tailwind and more utilities with no expense, because this purging happens automatically on the fly. So things like this scales like margins and padding and stuff that, where we are maybe a little bit more nervous to ship a whole bunch of different options previously because of the size issue, that's a total non-issue because everything just gets purged automatically and we don't have to worry about that anymore. Jonathan Reinink: So TLDR, Tailwind's extremely customizable and the way it does it is just very, very natural. And it feels like you just have this config file and it doesn't feel like, "Well, if I'm make it a little tweak-er, it's going to break a whole bunch of things over there. It's a much better customization experience. So that all said that's all on the Tailwind CSS side of it. On the Tailwind's UI side of it, it's a little bit trickier because Tailwind UI, when we build those components, we have to build it obviously knowing that a certain number of classes are available, a certain number of utilities are available. So we've built Tailwind's UI in such a way that it relies basically on the default Tailwind config, and then in any situation... so maybe we have a component in Tailwind UI that adds some unique color or has some unique font style or something like that. Jonathan Reinink: When ever that happens and it strays from the default Tailwind config, we say, "Hey, just so you know, you're going to have to add this into your config or make this change here." And then the person who wants to implement that component, goes to the Tailwind.config.JS file, adds that little customization and now that component will work as well. Ben: Yeah. Well, thanks Jonathan. Been super interesting learning about Tailwind. Let's move on a bit to Inertia. So this is another tool you created. I think Inertia is maybe a little bit less well known at this point than Tailwind, so maybe you could give folks a quick introduction to what it does. Jonathan Reinink: Yeah. All right. So Inertia... Yeah, how do I introduce this? Switching gears in my head here a little bit. Okay. So the goal with Inertia basically is to allow developers to build single page applications without building an API. That's the elevator pitch for Inertia, but there's a lot more to it than that. And the way I like to often describe it is more from, how it came to be, because I feel it's maybe easier to understand that way. So what I was doing... so I'm primarily a PHP developer and I work in the framework. I work with Laravel framework a lot on my own projects. And on the client side I historically have used Vue, although these days I'm using more and more React. Jonathan Reinink: But that was the way I would build web applications historically. And in the Laravel ecosystem, when you're building a web app, what you do is, it's a lot... Maybe, I don't know if you're familiar with Rails at all, but a lot of people are familiar with Rails in the ERB templates, so I compare it to that. You Server Side render all your HTML and then you ship that to the browser. And it works the same way in Laravel with what are called Blade templates. So what you do is, you'd create all your routes in your Server Side framework, that classic monolith approach. And then anytime you needed more interactivity, then what I would do is, I would basically drop in Vue components as I needed them into my web application or my website. Jonathan Reinink: And that worked for already good, because I had the whole thing Server Side rendered with Blade and Laravel. But then whenever I needed more interactive pieces, I would drop in Vue components. And I would actually drop them right in as components within the HTML of the Blade template. And then when the JavaScript actually run, then Vue would pick it up and those components would become enabled. So there was two main issues with this approach that I found, and I used this approach for years. The one main issue is when those Vue components, when they initialize on a Server Side rendered page, because it has to wait for the JavaScript to load and run, there was always this little annoying flicker. And there was techniques where you could hide the flicker, or hide the component until it was ready. Jonathan Reinink: And there was techniques you could use to make that flicker less annoying, but it was very much just a problem that existed because of the architecture. So that was one thing that always bugged me. And then the other thing that I think in the end bugged me more was that my HTML lived in two different paradigms. One was in Blade, this Server Side templating engine, and then the rest of my templates lived in Vue or React a very much modern JavaScript approach to using components and stuff like that. And it really got annoying jumping between the two. And sometimes I'd be like, "Okay, I'm on this particular page right now, maybe it's got a table on it and I want to add a dropdown, and I'd be like, 'Oh shoot, this is a Server Side render template, I can't just add a dropdown because I know a dropdown it's going to require some JavaScript and maybe there's some state and different things like that.'" Jonathan Reinink: And it's like, "Okay. So then for the next half an hour, I would then be converting my Server Side rendered Blade template into a Vue component so that I had the whole thing in a page component, that I could then do whatever I needed to do within Vue." So what ended up happening in my own particular SaaS application, is more and more my Server Side templates more and more started getting converted to client side Vue components. So then on the server side, I would have a Blade page template that all it was is a single component, which was the Vue component. Jonathan Reinink: So that had me thinking, "Well, this is weird. I have this weird pointless in-between step, where all I'm doing on these pages is outputting a Vue template and it still suffered from these other issues where that Vue template would take a second to render and different things like that." So then kind of in an add into this mix is I like the idea, I like the feel of single page applications, just a snappiness of not having to do a full page visit to get to the next page. And I had used for quite some time at tool from the Rails folks called Turbolinks. And Turbolinks, just a real quick description of it. What it does is, it's sits on the client side and a little piece of JavaScript, and what happens is anytime you click a link, it basically intercepts that link click. So maybe you're on the dashboard and you go to the user's page, when you click on the page link, it intercepts that. Jonathan Reinink: And then what it does is that it actually makes a request itself to the server over XHR, and gets the HTML back from the server. So just like it would, if it hadn't intercepted and then what it does is that it dynamically swaps the body content out from the previous page to the new page and updates the URL to whatever page that you were going to. And that was a really unique technique that the Rails folks came up with, because it was you just dropped it in and it just worked. The problem is, it just worked until it didn't work. So a lot of people in the end hated Turbolinks because it promised that there was like, there's no work install, you install and it just works, but there's actually all sorts of annoying situations where things break. Jonathan Reinink: But the thing for me was that, I actually really liked that experience of just saying, "I want to make a link and I don't want it to be a full page visit, I would love it to just be made over XHR, but then there's all these issues with Turbolinks, with how it handles things and in particular around JavaScript. For example, Vue and Turbolinks did not play well together at all, and it's because they're radically different paradigms. Turbolinks was designed to work for an application that's completely Server Side rendered. Where I had these Server Side rendered pages that were combined with Vue templates, these Vue page components or even smaller components, and then I was using Turbolinks and things just broke down. Jonathan Reinink: Anyway, so that's the whole background. So where Inertia came from was me thinking, "Well, what if I didn't make any of my templates in my application, if I didn't make any of them in Blade anymore, if I didn't Server Side render any of them?" Because for me, the ideal was I would love to build my entire client side part of my application, I would love to do it in Vue or React. Because that way, anytime you need to add any sort interactivity, I have the full power of JavaScript at my disposal, and in particular, the full power of Vue or React, which are massive communities with all these amazing plugins and everything else. So I really, really liked the idea of being able to build my whole application that way. Jonathan Reinink: And then I thought, "Well, what if instead of returning HTML back like Turbolinks does on subsequent requests, what if Inertia could be smarter about it? And when it makes its request on subsequent... after when you go into SPA mode, the Single Page App mode, what if it, instead of returning HTML, only returned the information necessary for Vue or React to swap to the next page component?" Jonathan Reinink: So, and that's what it does. So what happens is, you land on an Inertia site and boots up the initial render, which loads the root template that has your HTML, your assets and that HTML element with the skeleton, if you call it that. And then what happens is Vue or React boot within that and load the initial page that you're on. But then any subsequent page visits that you make, so any link clicks you make... So again, going from the dashboard to the user's page, with Inertia, when you click on the user's page link, what happens is Inertia makes a request back to the server, and then there's an Inertia adapter that actually gets installed on the Server Side. Jonathan Reinink: So Laravel has an Inertia adapter, Rails has an Inertia adapter. Anyway, it returns a JSON response back, not an HTML response back. And that includes three key pieces of information. One, the name of the JavaScript page component that you're going to be going to. Two, the props or the data that's required for that page. So imagine the user's page, the page component might be /user/page.vue, and the props or the data might be all the users that you want to list on that page. And then three, the URL that you actually ended on, so /users. And then what happens is client side, it dynamically swaps out the current page component, so the dashboard page component with this new page component and frameworks like Vue, React and Svelte have this concept of dynamic components, where it's really easy to swap an existing component out with a new one. Jonathan Reinink: And then what Inertia does, is it updates the history state, so that you have the right history, it resets scroll position and does a few other things like that. So that's a long drawn out way of explaining how I got there, but that was really the evolution, that's really how it happened. Because I was struggling with this really simple problem. I don't like having this mix of templates in my applications, I'd love to just do it all in one language or one templating language. And to me, the obvious choice there was Vue or React because I want to build these really rich client side applications, where I can do all this interactive stuff, that's just is not possible with plain old Server Side rendered HTML. And then I wanted the single page app experience. And Inertia just took all the existing tools that were already in place and just leverage them. In a lot of ways, Inertia the simplest little library ever. Jonathan Reinink: It's like just this little piece of glue that lives between your server and your client, and it's just passing this data back and forth between the server and the client. You can almost think of it as a really, really light client side routing library. Except unlike, say Vue router or React router, there's no routes being defined client side, all your routes are still defined in your Server Side framework. So there's a lot of layers, I call it the modern monolith. Which is to say that historically, if you wanted to build a single page application using Vue or React, if you looked around online, the way that everyone would tell you how to do that, is they would say, "Well, if you want to build a Vue SPA or a React SPA, what you need to do is, you got to go off and build an API first." Jonathan Reinink: So either a Rest API or a GraphQL API. And that's fine, there's absolutely times where that makes sense to do that. Maybe if you have an iOS app and an Android app and a web app, and who knows what else, that might actually make sense. But for so many of the projects that I was working on, I didn't want to have to build a whole separate API. I really just love that classic monolith experience, Rails or Laravel allows you to have, where you create a route, that route has a controller, that controller gets some data from the database, use an Active Record or whatever your favorite ORM is, and then passes that data to a template. And to me, it just felt insane that if I just wanted to have a fully Vue or React based front end, that the only answer to that was, "Well, you got to build an API. You got to learn OAuth." Jonathan Reinink: And OAuth is not fun to learn, it's not fun to work with at all. And again, those tools have their place. But with Inertia, it just massively, massively simplifies the whole process. It feels like really you keep your entire monolith application with the exception that you don't use Blade templates, or you don't use ERB templates anymore, and all you do instead is you create Vue or React or Svelte page templates. That's really what it feels like. So the learning curve is so low because it feels like you're just building an application the way you always have in these Server Side monolith frameworks. Ben: Yeah. That all makes a lot of sense. I feel some of the problems you described that led you to solve them in the way building Inertia, are similar to what led to Next JS and Gatsby. That exact fact that, having this completely monolithic front end, that doesn't have the advantages of Server Side generation Server Side rendering. And so Gatsby and Next have solved that problem by letting you build a modern React front end, do Server Side rendering where it makes sense, static [side 00:38:43] generation where it makes sense. So I'm curious what you think of those approaches, and maybe some overlap or some differences with Inertia. Jonathan Reinink: Yeah. So those are always interesting to compare to. So I would say historically... this is changing with more recent versions of Next JS, but historically what Nuxt and Next offered was the API approach that I was talking about just a moment before. Where if you wanted to build a Nuxt app, or if you wanted to build a Next JS app and you needed to get data for that application, you still needed some Server Side framework like Rails or Laravel, where you went and off and built an OAuth based or GraphQL, Rest API. That was historically the story. Now that ironically is changing, and it's funny to see how things change. But Next JS now is offering more and more ways where you can get data even from a database directly from within your Next JS application. But ignoring that fact, I would say that was the big quote unquote issue for me with using Nuxt or Next. Jonathan Reinink: It's okay, great. I love Next, we use Next all the time actually even a Tailwind labs. And it's an awesome framework and I think it's going places for sure. But it did mean you still needed to build this API, you still had this data problem that you needed to solve one way or another. And if you just wanted to have a quote unquote simple monolith application with routes and controllers, use an active RAC to get some information from a MySQL database, it still felt a leap. Especially if you historically have been a Rails or Laravel developer, there was a whole bunch of extra knowledge that was required, even the client side routing. And of course, Next and Nuxt do a good job with the way they handle the routing side of things. But again, that routing is how handled in those frameworks and not say in Laravel or Rails. So that's the one big difference. Jonathan Reinink: And I think the other thing that's interesting is that Nuxt and Next, they're JavaScript, they're Node frameworks, this is what they are. Whereas there's lots of people using other tools and many, many other languages and frameworks that, maybe they're not comfortable in the JavaScript ecosystem quite in the same way or in the Node ecosystem. And that's what's really neat about Inertia. Inertia allows people to continue to work with whatever Server Side framework they know really, really well. So for me, that was Laravel, for others that's Rails. But we have adapters for all sorts of different frameworks and languages, so Python and Django. There's someone that made, believe it or not a cold fusion adapter. I didn't even know cold fusion was still a thing. So there's a cold fusion adapter. Jonathan Reinink: There's people who've made adapters for WordPress, and Go, and Closure, and ASP.net, and Flask, and all these different Server Side tools. And so I think for people who've been working in a particular ecosystem, and let's carry on with the Laravel example, there's so much knowledge you have after working with a tool like that for years and years and years to say, "Well, I want to create my app using Vue or React. So I like that client side experience." Because I like that client side experience, someone says, "Okay, well, you should use Next, for example." So say, I've been building Laravel for five years and I have all that knowledge. But now I want to build a React front end. It's like well, okay. Maybe you got to go use a tool like Next, but with Next... Jonathan Reinink: So either you are now in position where you have to build an API to get that data to bridge, or you build it all in Next, and now you got to learn how to connect... How do you connect to a MySQL database in Node? A Laravel developer probably doesn't know that, that's something they're going to have to learn. Or how do you throw a job onto the queue in Node or in Next? How do you send an email in Node and Next? How do you import in parts a CSV file? And this list goes on and on and on. There's so much knowledge that you tend to just learn working in a particular ecosystem, that it's a shame to have to throw that all away, just because you want to build your client side using this JavaScript tooling like Vue, React or Svelte. Jonathan Reinink: So a huge, huge goal with me with Inertia was to say, "Yeah, we will help you move the client side part of your application, the HTML, from being Server Side rendered and all the limitations that come with Server Side rendering, and we'll create a really nice system for you to create those using Vue, React and Svelte. But you can stick with that Server Side framework you know and love and that you can work so fast in." So that's how I would answer that question. I think it's not that those tools are bad and it's not even that you can do less in the tool and that Inertia offers more, it's more about, who's the developer, what knowledge do they know and what's the best way for them to make a better application using Vue or React without dropping all this institutional knowledge that they already have? Ben: So we're almost out of time. I want to end by talking about, what's on the roadmap, both for Tailwind... Maybe we start with Tailwind, and then we can talk about Inertia after. So what are you most excited about that the Tailwind team is building both for Tailwind, CSS and Tailwind UI? Jonathan Reinink: Yeah. So on the Tailwind front, the big thing that we have our eyes on right now is Tailwind version three. And with that is the just-in-time, so the JIT mode enabled by default. So that for us is a huge, huge milestone that we're going to reach, where we go from this ahead-of-time compilation to this just-in-time compilation and all the amazing benefits that come out of that. So that's really the big, big, exciting thing. And along with that, we're doing a whole refresh to the brand and the website. So it's all going to look a little bit more polished. So we're deep into that right now, which is super exciting. So 3.0, hopefully land before, or at least the alpha before 2021 is out. Jonathan Reinink: And then on the Tailwind UI side, we just launched a huge update to that. So historically there was two pieces to it. One piece was the marketing components, which are components that are designed to help you build marketing websites, pricing pages, home pages, about pages and different things like that. And then the second one, the other one that we had was application UI, which was all the building blocks that you need to build some sort of web app. Forms, input buttons, and all that stuff, page layouts and that. But a number of weeks ago, I don't know if its maybe four or five weeks ago now, we added a third one, which was something that tons of people were asking us for, and that was an e-commerce bundle. Which has everything that you'd expect to have in order to build a nice looking e-commerce website from product pages to shopping carts, to doing reviews or order summaries and checkout forms and all that stuff. Jonathan Reinink: So that's the exciting latest and greatest thing on the Tailwind UI front. On the Inertia front, there's... Yeah, let me think here. So the big, big thing that we solved this year, that it's currently in early access but we're rolling out, is Server Side rendering. So even though Inertia is a client side rendered... because it uses Vue, React and Svelte, it's all client side rendered, we've come up with a way to still offer Server Side rendering. So that when you visit a page for the first time, so if it's a public facing page, it'll actually generate in the background, your page component, it'll convert it from Vue or React and actually generate on the fly DHTML, which is important for SEO purposes in particular. Jonathan Reinink: So Server Side rendering is something we've added and that's coming soon. And the other thing that I've been working on is this really, really crazy dialogues feature, which will help you make modals more easily. If you've ever built modals, you know that they can be a really tricky thing to get right. And obviously with Inertia today, it's easy to build modals because Vue and React makes it really easy to show and hide a modal. But we wanted to add is the ability for modals to have their own history state, and endpoints and stuff. So that's something we're adding to Inertia that I'm really excited about because it's a tricky thing to do right now, if you want to have history state or have a modal have its own URL or endpoint. So that's the other thing that I'm working on there. And there's a few more edge casey things, but those are the big things that I'm pumped about right now. Ben: Awesome. Well, Jonathan, thank you so much for joining us. It's been awesome to learn about Tailwind and Inertia, and really excited about the future roadmap for both products. Jonathan Reinink: Awesome. It's always fun for me to be here and I always love talking about these things, they're near and dear to me. So as you can tell, I'm able to ramble on about them pretty good. So, thanks for having me. Brain: Thanks for listening to Pod Rocket. Find us at Pod Rocket Pod on Twitter, or you could always email me, even though that's not a popular option. It's Brian@LogRocket.