Imagine those old days of building for the web, when everything was simple. Now imagine that you could have the user experience we have today mixed with the developer experience of yesteryear, of what felt like years ago.
That’s what Remix is, a web framework with laser focus on user experience. In this episode, Darko welcomes Kent C. Dodds, Director of Developer Experience at Remix. Kent explains what Remix is and why it’s so cool.
Listen to the full episode or read the edited transcript.
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Darko Fabijan (00:02):
Hello, and welcome to Semaphore Uncut, a podcast for developers about building great products. Today, I’m excited to welcome Kent C. Dodds.
Kent, thank you so much for joining us. Can you go ahead and introduce yourself?
Kent C. Dodds (00:17):
Sure, yeah. So my name is Kent C. Dodds. I live in Utah in the United States with my wife and four children. And it snowed today, even though it’s springtime. It’s April.
So I’m a software engineer. Currently, I work as the director of developer experience at Remix, where we’re building a web framework. You mentioned that you like to have people give a short history.
Kent’s career path
Kent C. Dodds (00:41):
So I started out as a BYU, Brigham Young University, ended up in the Information Systems program, got an internship, doing a lot of busy work, and decided to use some of the skills that I was learning at school to automate that. And so I built a Java program to do that and started becoming interested in software development.
Kent C. Dodds (01:03):
And so as I went through school, I had a lot of jobs on the side. My first was Domo, the business intelligence company. That was my first software developer job.
And then I converted to full time with them for just a few months before I moved over to a company called AtTask, they’re now called Workfront. And I was only there for two months.
When I switched over to a smaller startup called Alianza, and that’s a voiceover IP platform, I was their only frontend developer for about a year.
Kent C. Dodds (01:35):
And then I switched to PayPal, and I was there for three years as an engineer. And I worked on all sorts of things, lots of web infra-related stuff. So lots of tooling, just trying to help the PayPal developers be as efficient and effective as possible.
It’s been four years since I left them now, and they’re still using the tools that I built there. So that’s really validating.
Kent C. Dodds (02:03):
But I left PayPal to be a full-time educator. I created testingjavascript.com and epicreact.dev, and also my own website, kentcdodds.com that has tons of free content from podcasts to blog posts and stuff like that, and a YouTube channel and all of that.
And then last November after rebuilding my site in Remix, I decided that all I wanted to do was teach people Remix.
Kent C. Dodds (02:26):
And so I decided to join up with the Remix team, and so now I’m co-founder and Director of Developer Experience at Remix.
What is Remix?
Darko Fabijan (02:33):
Great. That was a very nice introduction and also our next topic. So for people who have never heard about Remix, what is a short intro that we can grasp?
Kent C. Dodds (02:47):
So Remix is a web framework with a laser focus on user experience and a foundation on web fundamentals. And so it does use React. Eventually, we’ll probably support other UI libraries, but it is a server-side rendering framework.
Remix is a web framework with a laser focus on user experience and a foundation on web fundamentals.
-Kent C. Dodds
The way it feels to develop a Remix app feels very similar to PHP or those days of old building for the web in the early web, which a lot of people really miss because it was very simple.
Kent C. Dodds (03:22):
So it feels like developing that, but there are reasons that we moved on from that. And so Remix remixes the things that we like about building for the web today, the user experience that you can have with the developer experience of yesteryear, of what it felt like years ago.
And we do that through various means, but primarily with the focus on the web fundamentals and a solid foundation on what the web does really well. And then we enhance that with modern tech. So that’s the idea of Remix.
Darko Fabijan (03:56):
Great. And now, I’m going to start explaining it to myself.
Kent C. Dodds (04:00):
Okay, great.
Darko Fabijan (04:02):
So, I haven’t touched on PHP and that I came a bit earlier with Rails but that’s, I think, a logical continuation of that developer experience. And I do know what, let’s say, React, AngularJS and those other frameworks bring and that separation between a backend and frontend.
So to someone as old as me or someone who still has that state of mind and stopped developing a couple of years ago, can you walk us piece by piece what are the essential components and what developer experience looks like?
What does developer experience look like with Remix?
Kent C. Dodds (04:43):
So the basic or the primitive of Remix is a route module. And so you have your directory, it’s in your app directory of your repo and inside of that, you have various routes that map obviously to the URL segments in the URL.
And so each one of these modules, these files, have exports for their data requirements, the UI that’s rendered when that route is active, as well as the mutations that can happen on that route. And when the user submits the format, it calls this particular function.
Kent C. Dodds (05:20):
One of the unique value propositions of Remix is its support of nested routing. And so as the URL segments nest, often the UI nest similarly.
And so when we’re talking about the loaders for loading the data, the actions for handling mutations and the UI that you export as a default, the only portion or the only concern that you have is your piece of the UI, and so as far nested as you go.
Kent C. Dodds (05:49):
This actually has really enormous implications as far as the developer experience, because it allows you to really focus on the area of the page that you are concerned about as you’re developing. Rather than having to worry about the shell of the application in every single route, you’re just worried about it in the particular route that you’re working in.
And that means that data loading also is much simpler because the data loading can happen for the shell in one place and then for any of the children in another. And so they can be decoupled in that way.
Kent C. Dodds (06:21):
And so that is the primitive for a route module. There’s also error handling that’s built in there as well. That’s like as far as the developer experience of what people are typically working with, they’re spending a lot of time in those route modules. I have more to say about that, but I can tell that you have maybe a follow up there.
Nested routing and server-side rendering in Remix
Darko Fabijan (07:00):
If I haven’t misunderstood, at some point you said that it is a server side rendering primarily?
Kent C. Dodds (07:17):
Yes.
Darko Fabijan (07:18):
I’m trying to connect that with that nested routing. And that you said that only I can be concerned about the piece of the page that I’m working on. How are those two things marrying together?
Kent C. Dodds (07:31):
Yeah, that’s great. So normally you typically say, “Okay, so for this route, with all of these URL segments, here’s the code that responds for that. And then we’ve got this other route that maybe has only one difference or maybe it’s an additional URL segment. So here’s some separate code.”
Kent C. Dodds (07:48):
In Remix, all URL segments are run for that particular URL that you’re trying to request. And so on the initial page load, that is what the server rendered.
And then once the user has loaded the application as they transition throughout the app, those transitions are all client side and data requests are made as they are navigating around the app, data and code requests.
Kent C. Dodds (08:10):
So on the initial page load, Remix is going to look up all of the routes that are relevant for the full URL. And it’s going to call all of the loaders to get all of the data, and then it’s going to take that data and pass it into the React components that you’re rendering. And then it stitches all of those pieces together to one holistic page.
Kent C. Dodds (08:33):
And so that’s how we get the separation or rather the co-location of data requirements with the UI that requires the data, which is a really nice developer experience. But then we also get the ability to focus just on the piece of the UI that is relevant to us because we render all of them together.
Requirements to get started with Remix
Darko Fabijan (08:54):
Clear, great explanation. And what am I required to bring to the table before I start? You mentioned React being a piece. And then as you were talking about loading data, I immediately thought about active record from the Rails world. Or a mapper.
So what are the prerequisites?
Kent C. Dodds (09:16):
Yeah, that’s a great question. As far as React is concerned, you can learn everything that you need to know about React to be effective with Remix in about an hour. Remix makes React a lot simpler than it is for people going through boot camp and just using Create React App or something.
Remix makes React a lot simpler than it is for people going through boot camp and just using Create React App or something.
-Kent C. Dodds
How is Remix different
Kent C. Dodds (09:33):
One of the unique value propositions of Remix is that it is what we like to call CentreStack. So you’ve got your backend frameworks and you have your frontend frameworks.
Remix very uniquely manages the network for you. And so lots of frameworks are on the client and others are on the server. Remix is on both very firmly.
Remix manages the network for you.
-Kent C. Dodds
Kent C. Dodds (09:53):
And it does this in part because it’s a JavaScript framework. So you’re running on node or you’re running on Cloudflare Workers or on Deno some JavaScript runtime, and we can run in all of those environments.
The other thing that Remix is that a lot of frameworks do not have in addition to being all in JavaScript, is that Remix manages your network by being your data fetching library and your router.
Kent C. Dodds (10:20):
And so because of the way that Remix is architected, we can determine deterministically what your data requirements are for your app just by looking at the URL. And we can determine all the code requirements because in the world of the web, we’ve decided years ago that you can load an app much faster if you don’t load it all at once, but you load it in pieces as the user navigates around. That’s code splitting.
Kent C. Dodds (10:43):
And so, we code split for you automatically. And then we look at the URL and we know exactly what data and code requirements you have, which means we can actually pre-fetch things as the user is navigating around.
So by the time they actually come around to click on it, it’s already loaded into the browser. So it’s really optimized from that perspective.
Kent C. Dodds (11:02):
We care a lot about the initial page load, but a lot of times I think developers fixate on the time to first byte metric. That only happens once and most of the time, users are navigating around.
And so I’m going to focus a lot on how we can improve that user experience as well. So because Remix is your compiler, it’s your data fetching library and it’s your router, it’s able to manage the network chasm better than anything else that I’ve ever seen. And because of this, it makes React a lot easier.
Remix is able to manage the network chasm better than anything else. It makes React a lot easier.
-Kent C. Dodds
Kent C. Dodds (11:31):
So that was a long way to talk about the React portion of this, so as far as React experience. In Remix, it feels a lot like you’re just using React as a template library, which in some ways is why we can support other frameworks, which we plan to do in the future.
As far as other technologies that you need to build a full app, we do not currently have an ORM or a database that’s built in. We may eventually have something like that.
Kent C. Dodds (11:59):
The JavaScript ecosystem is a little unique in that by and large, the JavaScript ecosystem values small pieces that you can piece together. That’s not necessarily a value of our own, but it was a good starting place for us to be able to say, “We manage the network tab. We take care of that for you. That’s our core focus and unique value proposition.”
Kent C. Dodds (12:19):
But the cool thing about starting with CentreStack is it’s the piece that nobody else has really managed very well. And then we can proceed out from there. And so we do plan on, I guess, eating up both sides of the stack further from where we’re at.
So eventually, we may have a built-in database or a built-in ORM or an email or library or something like that. But right now, you do need to bring those yourself.
Kent C. Dodds (12:45):
But we know that a lot of people don’t want to worry about doing all that. There’s some wiring up and setting up its boilerplate and stuff. And so until we can build out those solutions, we created what is called Remix Stacks. And so these are basically a feature of our CLI that allows you to point to a Github repo or a folder on your file system, or just some tarball on a remote repo or a remote server and generate a project for you.
Remix Stacks is a feature of our CLI that allows you to point to a GitHub repo or a folder on your file system and generate a projects for you.
-Kent C. Dodds
Kent C. Dodds (13:16):
And so we have three stacks ourselves:
- one that deploys to AWS Lambda functions and uses DynamoDB
- and another that deploys to fly that use a SQLite
- another one that deploys the Fly.io that uses Postgres and those use Prisma as the ORM.
- And so if you really don’t want to have to bother figuring out how to configure all of those things, then we’ve got you covered with stacks.
Kent C. Dodds (13:43):
And actually that’s really the best way to get going with Remix is to use one of those stacks and then you can just get rolling. And they come pre-configured with the models and accessing those models. They have authentication built in.
Actually, what’s really nice about it is that it’s not hidden behind some weird abstraction, but it’s actually code that you can modify and change.
Kent C. Dodds (14:03):
Our entire authentication implementation in the Stacks is less than a hundred lines of code, like barely. It’s 97 lines of code, something like that.
But yeah, it’s something that you can change, which is really nice. It’s not like some weird abstraction you need to learn. There are trade-offs there for sure, but I kind of like being able to make modifications to that.
Kent C. Dodds (14:22):
I think that mostly answers your question. You bring knowledge about React just a little bit, and then you use a stack for the stuff that pretty much every app needs.
The concept of Remix Stacks
Darko Fabijan (15:03):
The concept of a stack is very interesting. So you essentially don’t generate just, let’s call them dead files, in your file system. And then you have to figure out where and how to plug it somewhere so it can serve some real traffic.
But you approach it from the element that you’re essentially deploying it and provisioning the infrastructure, which is going to run that code. And yes, there is also that application that you are getting as a byproduct in a way.
Does this sound right?
Kent C. Dodds (15:35):
It’s close. So, Remix Stacks is a feature that allows you to make custom stacks. And in your custom stack, you can actually also ask questions of the user, like where they want to provision their database or whatever.
Remix Stacks is a feature that allows you to make custom stacks
-Kent C. Dodds
We have three stacks that we maintain, and those are the ones that I described and they do not go quite that far. They give you instructions on how you can use these other services because we don’t control those services.
Kent C. Dodds (16:03):
And in fact, some hosting companies are going in that direction where you say, “Here’s the stack that I want,” and then it’ll ask you a bunch of questions like what region do you want to deploy to, or maybe it’s a regionless environment, like an edge environment.
And so it doesn’t need to ask that, but it’ll ask various other things. And actually we also have built into the CLI the ability to ask whether you want to use TypeScript or strip out the TypeScript and use JavaScript instead.
Kent C. Dodds (16:29):
It’s a really cool feature and I expect that most people are going to be using custom stacks. I know Tesla, for example, they’re building their own stack that has their UI library already configured and everything.
So, Stacks is really an initial scaffolding feature. And then eventually we will likely have additional scaffolding commands from the CLI similar to Rails, where you can say, “Hey, I want to create this model,” and it’ll create routes for it and everything as well and tests and everything.
Kent C. Dodds (17:01):
But for right now, this is what you have and you can make your own custom stack as well.
Darko Fabijan (17:06):
Yeah. Clear. Yeah, for sure the community or providers are going to contribute for their own benefits.
Kent C. Dodds (17:13):
Yeah. There are already quite a few. I would’ve really liked this feature at PayPal because I built the template that every new project at PayPal uses. So when you use a new project, you’re going to be using the template that I created and it’s built on the underlying tools that I created as well.
So going forward, you’re using the CLI that I built. And so this is very much in my realm of experience and excitement.
Kent C. Dodds (17:40):
Really, what we’re trying to do is a lot of people who are attracted to Remix are frontend developers. We’re seeing a lot of interest from backend developers as well. You could actually build an entire REST interface or REST API with Remix, no UI at all.
There are actually really good arguments for doing that. But the primary interest is coming from the frontend world. And lots of those folks, myself included, we’re not very comfortable deploying databases and connecting ORMs and stuff like that.
Kent C. Dodds (18:09):
And so a big part of the motivation behind building stacks was so that somebody could have an idea for a project and get it off of the ground really quickly so they could have a weekend project.
And then what’s really cool is that when you’re done with your MVP, you can keep the code that you wrote because Remix enables that code to be quite simple. And then if you hit a home run, then you can run the bases, I guess.
The lowest level primitive that you have to face while developing
Darko Fabijan (18:38):
And let me for a second jump back. I hope that listeners will be able to follow. When you’re describing a piece about eliminating that network, I want to ask what’s the lowest level primitive that you really have to face while developing.
So is it like, I don’t know, library, network library dot get, and then you are handling, is it 200? Is it 404? Is it what?
I suspect that’s not what you have to touch when you are submitting a form or getting the data back for a component?
Kent C. Dodds (19:11):
Yeah, it’s a lot better than that, for sure. And better in the way that it’s less abstraction than what you’re probably thinking. And this goes back to our good old Rails and PHP days with building multi-age apps. The way that you have always done mutations on the web has been with forms.
And so Remix gives you a form and even if the JavaScript hasn’t finished loading yet, that form will work because that’s the way that web works. You didn’t need JavaScript to submit forms, which might be a surprise for some folks who just got out of boot camp.
Kent C. Dodds (19:48):
And so we have JavaScript because it enhances the user experience. We make the experience a lot better, but you don’t have to have it. And so the primitive is the web and even on the backend.
So I should have mentioned earlier that the loader, which is responsible for the data requirements of your route and the action, which is responsible for the data mutations of your route, those only run on the server.
Kent C. Dodds (20:11):
And so, because Remix is managing that network tab for you, it’s the one responsible for calling those functions and it calls them across the network in a client-hydrated situation.
And so the primitives that you have are the same primitives for the web. You want to go to another page, you use a link which renders an anchor tag. You want to make a mutation, you use a form.
And then on the backend side with the loader in action, you get the request. And the request object that you are dealing with is not some wrapper around the request.
Kent C. Dodds (20:44):
The interesting thing is when we’re talking about the backend, we’ve got a lot of different providers that are providing serverless functions and they have their own APIs for that. You’ve got V8 isolates with CloudFlare Workers or Fastly and AWS Lambda@Edge. You’ve got Deno.
And each one of these has its own idea of what a request object is and what you’re supposed to send as a response.
Kent C. Dodds (21:08):
And so Remix, we took a look at that and we said, “That looks a lot like the Wild West days of early JavaScript in the browser, where every browser’s different, you have to handle all these different cases.”
And so we did what jQuery did for browsers and we normalized it all. And we normalized it to the web standard for fetch. And so these request and response objects that you’re dealing with and your loaders in actions are web fetch request response.
Kent C. Dodds (21:33):
And so Remix is less a brand new framework that you have to learn and more a thing that exposes the web platform APIs to you so that you can build your website, or your web app if you prefer the distinction. You can do both if you feel like those two things are different. So you are working directly with these objects.
Remix is less a brand new framework that you have to learn and more a thing that exposes the web platform APIs to you so that you can build your website, or your web app.
-Kent C. Dodds
And what’s really cool about that is people end up spending more time on the Mozilla developer network documentation than they do on the Remix documentation. And so you’ll find yourself developing a lot of skills that are highly transferable, which is really nice.
Kent C. Dodds (22:06):
So as far as the primitives that you’re working with, the primitives you work with are web primitives. And the nice thing about that is, yes, it’s abstractable, but we do not abstract a lot for you.
We do have a cookie session abstraction for managing sessions in a cookie, because that’s kind of handy. But you’re the one getting the cookie out of the headers and passing it to us. We’re not going to do that for you.
Kent C. Dodds (22:28):
And so the cool thing is that because it’s abstractable and the primitives you’re working with are web primitives, the abstractions you build are actually useful outside of Remix. So long as wherever you’re using it is using those same web primitives, then you can use those abstractions there as well, which I think is a really nice benefit. So, our primitive is the web.
What is being built with Remix?
Darko Fabijan (22:48):
Great. And you just mentioned, are you making a website or web application and some people want to have a distinction between that. I’m one of those, and you described that maybe majority of people today that are approaching Remix are frontend developers.
But what are you seeing? What’s mostly being built these days with Remix?
Kent C. Dodds (23:12):
So we just came open source in November. Before that, Remix was licensed software. You had to pay a yearly subscription to have access to it and its updates and stuff. So just becoming open source was when bigger companies started to look at using Remix.
Kent C. Dodds (23:27):
So, a couple of the folks who’d licensed it were some smaller companies that had a Create React app and maybe they had a Python backend or a Rails backend with just like REST APIs and stuff. And we’re seeing those folks migrate their entire app, both their backend and their frontend to Remix over time.
And that’s actually a really awesome thing is the vast majority of React apps at least are using React Router. Remix is created by Ryan Florence and Michael Jackson, the creators of React Router.
And so there’s a very smooth and iterative migration path for that. You can do like one thing in five minutes, commit it, push it, deploy it, and it all works. And you just keep on doing that until it’s all done.
Kent C. Dodds (24:05):
And so we’re mostly targeting people who are building existing React apps that want to have better user experience and easier developer experience. And so as far as the types of apps, it’s literally anything that you build on the web.
For people who are just playing around with it themselves, they’re typically building their own personal website. For instance, we had somebody build an NFL tracker and then somebody else forked it and made an NBA tracker of all the games and stuff, it’s all over the place. So, somebody built a Wordle clone, yeah.
Kent C. Dodds (24:36):
So I built my website. It’s very possible my personal website is still the largest production deployed app of Remix as far as I know, but it’s not small. My website is 26,000, 27,000 lines of code with thousands of users. And my website is not your typical developer website.
But yeah, we are seeing Microsoft, for example, has a big consumer facing product that they’re migrating over to Remix right now. That’s definitely a very client side, heavy application.
Tesla is also … I don’t know if I’m allowed to tell you what they’re making a proof of concept of, but I’ll just say that if you have ever experimented with what it would be like to buy a Tesla, then you’ve probably used that piece of software that they’re experimenting Remix with. So pretty serious application there as well.
Kent C. Dodds (25:25):
So yeah, it literally goes up and down and this is actually a really cool piece of Remix is that it scales down really well. So for very simple, simple stuff, we give you all of the levers and everything you want to have your basic static site.
And then it scales up really well to the really complex stuff like you could build Figma or whatever in Remix. And I can’t think of another framework where building either of those provides a better user experience than Remix.
How does Remix relate to REST and GraphQL?
Darko Fabijan (25:52):
Clear. So in terms of just REST and GraphQL and those two approaches of dealing with data and so on, where does Remix sit in respect to that?
Kent C. Dodds (26:05):
Yeah. I’m glad you asked that. That’s a great question.
So one of the original motivations of GraphQL was to reduce the amount of data that you’re sending to the client because with REST, you’d have a bunch of properties and maybe you only need a couple of them.
And so if you’re sending a bunch of data and then just filtering out the data that you want on the client, whether it be like a native mobile app or a website, you’re going to send more data than you need.
Darko Fabijan (26:28):
Or multiple requests.
Kent C. Dodds (26:30):
Exactly, yeah, especially in a very solidly REST environment.
And often, you end up with waterfall requests because you’re like, “Well, first I need to go get this so I can get all the IDs for the comments,” or whatever.
And so yes, that absolutely was a significant motivation behind GraphQL, is to reduce the amount of data that you’re sending to the client. Especially if you just need that data to perform some simple calculation and all you actually needed is just like the total or something, it’s very wasteful.
How Remix pushes everything to the server
Kent C. Dodds (26:59):
And so the cool thing with Remix is that we push everything over to the server. So much of it goes onto the server. So all of your data loading requirements, even for client side transitions, like once the app is up and running for those client transitions, or when you make a mutation and you need to get the latest data because a mutation was made, which by the way, you don’t have to worry about Remix handles all of that for you.
So you make a mutation and all of the data on the page is up-to-date automatically, which is like 50% of the code that people write is managing that sort of thing.
Kent C. Dodds (27:29):
And so because we move it all to the server, now it actually doesn’t really matter whether you’re getting more data than you need or not, because it’s all happening on a server. That’s probably geolocated near to the other server. So it’s going to be very fast and you can optimize it further, but you’re in control of that now. It’s not running on some user’s browser.
Kent C. Dodds (27:48):
And so as far as using GraphQL, you absolutely can and some people are inside of your loader. But you don’t need to for that particular use case. On my site, I have one API that I’m hitting for my podcast that sends a silly amount of data as the REST API.
And so I’m able to make all of the requests that I need, calculate all of the values that I need for my UI, and send just those values, those calculated values.
And then of course, I can cash that because it’s a podcast, it’s not like user specific or anything. And so it ends up being a really fast experience and I don’t need to worry about, “Oh man, I have this big problem I need to solve with GraphQL.”
Problems with GraphQL
Kent C. Dodds (28:29):
On a personal level, GraphQL was never super exciting to me because it was an enormous amount of complexity to solve a problem that only affected a very small subset of the number of people who are actually using GraphQL.
And so personally, I never was super excited about it, but I know lots of people are, and you have existing GraphQL things. At PayPal, we were actually moving a lot of stuff to GraphQL because we had lots of different teams that needed each other’s data.
So you just have a single GraphQL endpoint, you can get all that data.
Kent C. Dodds (28:58):
So there are other reasons to want GraphQL, but that one’s not one when you’re using Remix. And so you feel the pains that lead you to GraphQL a lot later if you’re using Remix. And interestingly, because of nested routing, you also feel the pains that lead people to micro frontends a lot later as well.
And so a lot of people who are using micro frontends probably wouldn’t need to if they used Remix.
Remix simplifies web development
Kent C. Dodds (29:21):
The reason why I left the lucrative full-time teaching gig to join up with Remix is because Remix eliminates a lot of the problems that you typically have when you’re a web developer. It doesn’t solve them, it eliminates them. They are not problems when you’re using Remix.
And so it just drastically simplifies web development. And that’s why I decided to join up with them because all I want to do is teach people how to build Remix sites.
Darko Fabijan (29:50):
Great, great. I absolutely love that. Absolutely the best solution is if you eliminate something and not have to solve it and not have to work on it, so it cannot get any better than that.
And I like the answer about GraphQL because I share your position on GraphQL. Never got me really excited as there is so much complexity to solve something which ideally I wouldn’t even want to solve.
Kent C. Dodds (30:14):
Yeah. Yeah.
Darko Fabijan (30:15):
Well, Kent, this was an amazing episode, a great introduction into a technology stack that makes me excited. I love Rails because it simplified so many things, and you had a number of examples where things are just eliminated.
You don’t have to worry about that. It’s great you don’t have to worry about this and it’s not highly opinionated, but it’s getting back to just standard components of the web, which sounds very amazing.
Darko Fabijan (30:44):
Thank you again. Good luck with Remix and your new position. And yeah, I hope that we will have a reason to talk again about the Remix and how it’s going.
Kent C. Dodds (30:54):
Yeah, there’s plenty more to talk about. So I’d love to come on again.
Darko Fabijan (30:57):
Great. Thank you so much.
Kent C. Dodds (30:59):
Thanks, everybody.
