Channel
Interviewed Person
Theo Browne (t3dotgg)
No, the title isn't clickbait. We did actually move T3 chat off of Nex.js. There's a lot of reasons for this and man, it's been a wild journey. I know your first question, what did you move to at handstack? This was quite a PR. Shout out to Julius for all of the work to make this happen as well as the rest of the team for the 478 comments on his 14,000 lines added and 10,000 lines removed PR. Yeah, this one was a doozy. There has been a lot for us
to do and even more to learn as a result of this migration. And as much as I'm loving Tanstack start, and believe me, we are loving it. It's a very, very good framework that is a solution to a lot of problems that we and many other developers have, there are plenty of catches as well. This was not an easy migration and the reasons it was hard were not ones any of us would have predicted or expected. We're at the point where we're patching tan stack start in order to add things we need to be exported so we can actually make this work at our size and scale. It was worth it though. The reasons why are not the
usual. If you're watching this video so you can hear me complain about Nex.js a whole bunch, you're in the wrong video. This is not going to be that. If you think we made this move because we are scared of the exploit that I just covered recently, you're probably too bad of a developer to watch my channel and I would recommend finding another. But if you're interested in a deep dive on how a company shipping to millions of users thinks about their technology stack and makes changes in order to make the best possible product and have the best experience for its developers, stay tuned because we have a lot to dive into
here. As you guys know, Versell is not paying me anymore and after this, I sincerely doubt they would want to. So, let's hear a quick word from today's sponsor and then we'll dive in. We all know the meme, have you checked if it's DNS? It's so common that DNS problems result in things going down, but I have a theory about this. I don't think the problem with DNS is DNS. I think the problem with DNS is how we interact with it. These crappy old ancient web interfaces that have a bunch of weird hidden fields trying to make things work is not the way we should be doing things. In an ideal world, we're
programmers. We should be able to program against our DNS. We should be able to write code that takes control of how our domain servers work. And that's why DNS simple is blowing me away. They're not yet another registry. They're so much more than that. They're focused on being the best possible developer experience for deploying and managing your domains. Everything from support to the SDKs they provide really shows that they have an SDK for every major language, even elixir, which obviously is something close to my heart. And the things you can do with them are so cool. We're talking like
four lines of code to create records on your domains. You're trying to set up some vibe coding platform where people can deploy things on a subdomain. I cannot imagine an easier way to do that than D and Simple. Whether it's a side project or a big thing like you know the Linux foundation or the Ruby gems ecosystem all of which run on D and Simple by the way they have you handled. They even have Terraform configurations. Like what? I couldn't fathom having my domains managed through Terraform until now. And it just makes sense. Like duh that's where we should be putting this
information. It the amount of like what this is how we should always have been doing moments I have had the more I've looked into D and Simple is genuinely hilarious. And a lot of that's because the team is all engineers. Everybody on marketing and support writes real code and relates to us as developers. If DNS is causing you problems or holding you back, you really should give them a shot at soyv.link/dnsimple. In order to answer the question, why are we moving off of next? We first have to answer a more interesting question. Why did we use it in the first place? And
this question is actually, in my opinion, more interesting and more complex than the bigger one of why we moved off. When I was building T3 Chat, I had a couple specific goals in mind. I wanted it to be as fast as possible as an application you would use. Like you click things, they happen immediately, you send a message, you get a response as quickly as possible. We really wanted it to feel and be as fast as reasonably achievable by us as a small team. I also wanted it to be scalable in more senses than just it will deploy across as many