Why I Won't Use Next.js with Kent C. Dodds === [00:00:00] Hello, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it free at logrocket. com. I'm Noel and returning today is Kent C. Dodds uh, Kent's speaker, teacher, trainer. Super involved in the open source community. But specifically today we're here to talk about his recent blog posts. Why I don't use the next JS is the title of that blog post. Welcome back. Thank you so much.. It's nice for people to say, Hey, I really enjoyed our conversation, but it's really a compliment when they say I'd like to do it again. And thank you for having me back. no, of course I always love our conversations. I'm equally excited for this one. I may be more excited for this one than anyone we've had in the past. I think, Oh, sweet. yeah this blog post is great. I read it all. It's like very. it's very expansive. It covers a lot, but I think it like articulates a lot of that kind of apprehension. I [00:01:00] think that a lot of people have around us like next JS and kind of the ecosystem right now. I'm not sure where I personally fall on that spectrum, but I think it does a really good job of articulating a lot of these things that people say, yeah. Like they have this feeling in their head, but there's, it's a big complex thing. But yeah it's really good. But let's just jump right in. So like in, in your kind of forward, the beginning of the post, you're talking about how you like to focus on the positive. So you're like, you didn't want it to just be a disparaging thing. Why did you choose to focus on okay, we've got to call out Next. js specifically here. Yeah, that's a great question. I definitely have had a number of people who said, why didn't you call this why I use remix instead of why I won't use next JS And I've written a blog post about why I use remixes titled why I love remix. It's on my personal blog and recommend people go look at it. But the fact is that when I launched epic web dev just a couple weeks ago, which I want to teach people how to build web applications. And the most popular [00:02:00] solution for full stack web applications in the JavaScript space is next JS. And it's actually not even close as far as full stack is concerned. If you're talking just client side, then it's Not even close to its react router is the solution there. But if we're going full stack, which is exactly what Epic web is all about, the next JS is the clear leader there. And so for that reason, a lot of people are asking me, Hey, Kent, why didn't you go with the more popular option? So they're, they're not asking me, why did you go with next? They're asking me, why didn't you \ go with next JS? And so, that's, just by virtue of that I need to discuss some of the negatives the negative side of that. And I do give a TLDR, so I'll give that here. The TLDR is really like Next. js is fine. Remix is fine. But really \ they're both equally capable of building awesome experiences and stuff. I personally feel like you're more productive with Remix, but like at the end of the day if you are effective with Next. js and you like it, then continue using it because you're capable with it. But for me, in deciding [00:03:00] what do I teach people how to build with \ \ the objective of Epic Web Dev is teaching people how to build for the web. And to do so in a productive way so that when they're done, they have all of the tools in their tool belt to be productive. So some people would say why are you using any framework at all? And the answer is I want you to be productive, and I don't think you can be productive without a framework. And so I have to choose one. And I think that because my focus isn't Remix, it's the web by the end of it, I'm just more effective at teaching you the web if I teach you Remix than if I were to go with Next. js. And I talk about that a little bit in the blog post, but really it is I think that you'll walk away with more transferable knowledge. , if I use remix, then if I'd use next, that's the short answer to the question. , yeah, it's like people are probably nodding along okay, yeah, I feel this, but , I guess when in the post, you set up this framing where you're talking about some of your background in testing with enzyme and then testing library. How did that kind of lead you [00:04:00] into this headspace and why is that applicable to this discussion? So actually I watched a couple of reaction videos of people who are reading the blog posts and, on a live stream or something, and it was interesting to watch them read this section because they're like, what does this have to do? I thought we were talking about full stack frameworks, not testing. And actually before I get. too much into that. I just want to to mention that we will be talking about some things that some of you listeners will probably not like very much. Like you, you'll, or you'll disagree in ways, or you think we're being dishonest or disingenuous or something. And so if that's you that's fine. That's your prerogative. We're going to be talking about a lot of subjective things. But the fact is that resonated with just a ton of people. And so this isn't just. No, you invited me on this podcast because it resonated with you. And so whether or not you agree with my opinion, you have to acknowledge that my opinion is shared by many people. So anyway, with that the reason I went into the testing bit is Because enzyme was the de facto testing library for [00:05:00] react for a long time, and I was using it, and I had a number of things I didn't like about it, and so I went and wrote my own and created testing library, which is now the recommended testing utility for react and other UI libraries, angular and view and things. So that worked out really well. But the biggest difference between enzyme and testing library is that enzyme would give you like you'd say, Hey, enzyme, here's my react component. And it would give you back this special object that had a whole bunch of methods on it that you could call. And they called that the wrapper object and we're testing library. One of the things that bothered me about enzyme was that wrapper, not just the utilities, because many of the utilities I thought were very bad for testing, but also just the idea that I didn't have access to the underlying platform stuff. And so the more time you spend testing with enzyme, the more time you get good at enzyme, which is like fine if that's going to be your tool of choice, but it's only useful in a react context when you're trying to test stuff [00:06:00] with a testing library. I said, No, we're going to be working with Dom nodes directly. And so the more time you spend writing tests with testing library, the better you get at interacting with the Dom and you'll have a deeper understanding of the web platform. And you can apply that not only to testing, but to anything. Anytime you're working with the web platform and the Dom, you have transferable knowledge that you're getting out of that. And not only knowledge, but also utilities, like anything that you write that can be useful with the DOM you can use. And there's no like adapter layer you have to work through or something. And that is one of the things that I really loved about moving from AngularJS to react was a very similar thing. I felt like the more time I put into. bUilding angular JS applications. The better I got as an angular JS developer, but I didn't get much better as a web developer or a JavaScript developer. And so switching over to react, I was like, wow, this is great. I'm using so many more like JavaScript features than it was before. So I feel like I'm getting better at that. So I see a lot of [00:07:00] parallels between these situations and next JS versus remix. A lot of people will probably be nodding their heads when I say the more time you spend building web applications with Next. js, the better you get at Next. js, but not necessarily do you get much better at the web platform. There are certainly things like you're building on the web platform, but Next. js, like many other libraries and frameworks, will wrap the web platform in its own little ball and then just expose the little hooks and APIs and things that they think work nicely and. hElp to reduce boilerplate or whatever it is, but the fact is, because of that, you get really good at using that particular abstraction rather than using the thing that's under the hood and what testing library and honestly react and remix have done is instead of just wrapping this API, they're exposing it to you. So like in your use effect, you're going to be talking to Dom nodes. They don't have some fancy special way to interact with that. Now, of course cool. React has its JSX and stuff. You're not typically creating those dom nodes and updating them and stuff. But I [00:08:00] feel like that's a bit of a, an aside to what I'm talking about, like the JSX is really just JavaScript whereas Angular JS templates and things are strings of HTML that have been enhanced in a way. That is not transferable to anything else. You do. That's called a domain specific language. And with next. Yes, they have their special API is for interacting with the request object and different things like that. You return, an object from your function and they will serialize it for you and do all this magic stuff. If you want to deal with headers, you've got special wrappers that you have around all of these. things. In remix , your loader gets a request and it returns a response. And if you want to learn how to get really good at that stuff, you're going to the Mozilla developer network to learn about those API APIs. And then you take that knowledge, you apply it to your situation, and then you continue with that knowledge wherever else you go. So long as you're using the web platform APIs. So that's one reason why I prefer using Remix over Next. js is because I feel like Remix embraces [00:09:00] those APIs and exposes the underlying primitives to you which gives you a good level of transferability. And there are other examples of Next. js kind of wrapping the APIs, like the incremental static regeneration is just like their own version of stale while revalidate caching and stuff like that. I'll put on my like devil's advocate hat as often as I can here in our conversation . So like in my head , I don't know if it's totally fair to say this is like a scale of like how close we are to the underlying technology versus the, like a very heavy handed framework or wrapper. Cause I think that there are, there is some like dimensionality to that. It's not always like one or the other. Yeah. In your head like, why is remix why is it advantageous at this point in web development in particular to be like developing more closely to those underlying primitives? Because some could argue that like, well, we're always just abstracting higher and higher up. Like, why should I look for something that's taking me a layer deeper? Yeah, that's a great question. And this is certainly a [00:10:00] subjective thing. But for me, when I inevitably with almost any abstraction that I use, I run into a situation where I need to do something that I don't know how to do yet. And so now I have to crawl through the documentation to see how do you accomplish this task with, this tool, and sometimes you'll run into a wall and realize, Oh, I can't do that with this tool. And like under the hood, if they were to expose a couple of things to me, then I would be able to do that, but I can't for some reason, and if instead you are using a tool that's built on top of web primitives in such a way that they expose those web primitives, then when you need to accomplish something, if you know how to do it with the web platform already, then you don't need to go look at the docs Because you just like, Oh, yeah, this is just a request object. And or here I'm sending a response object back. I know how to add headers to that. There's no special API for that. I'm just like using my regular thing. If you don't know how to do that, then You are going to the docs, but it's not framework specific docs. You're going to [00:11:00] go to web platform docs. And once you're done with that learning experience, now you're going to carry that with you anywhere you need to use those things. And I can appreciate that that frameworks can give us higher abstractions that, do some optimizations for us or reduce boilerplate. I think that it. It takes a certain level of hubris for a framework to think that they can solve everybody's problems all the time. And the web is just so enormous that it's very difficult to build something that is like the silver bullet for every problem. And in particular with the web, I think that is one place where exposing the underlying primitives is a much more powerful approach. And again that's subjective, but that has played out in my over decade working with the web that being able to work with the underlying primitives gives me more power and flexibility and then I can build abstractions on top of that myself to handle any boilerplate that I don't like or anything like that. You said something at the beginning of your answer there that I noted that when you're hitting walls frequently, like in, [00:12:00] in this abstraction, that is frustrating for you. Do you find that those if you're hitting walls with some level of frequency that's indicative of a Poor abstraction or do you think that there's that's just a piece, you know of a larger puzzle That's a great question too. I think not necessarily is indicative of a poor abstraction. It's, that's more indicative of you either holding it wrong, like using it incorrectly, or maybe you're using it for the wrong purpose. You're trying to screw a screw into the wood with a hammer. , and. I find that the more opinionated things have fewer use cases that they can satisfy at least in an easy way. Like you have to work harder. And so having fewer opinions, I think, is a good thing. If you want to appeal to a broader audience. Use case set and the web is just so broad that having something that's really opinionated can be can be really challenging now. I say that interestingly, [00:13:00] because I have a meta framework that I work on called the epic stack. That uses remix and combines a lot of other tools and just brings a lot of opinions , to things. But even still with the Epic stack, it's built on top of remix. And so , there's a lot of web platform APIs that are exposed there too. But I think that's like a general truism is that the more opinions you have, the less useful you can be, for folks who are living outside of those constraints. yeah, but again like if one is operating within those constraints, like it can help a lot. It's like, Oh, I don't even have to worry about all this other stuff. Cause it'll probably just work. So yeah, to your point of whatever you use is probably fine if it's working, but this does segue us nicely into open next, which is like the next big point you cover in your post. Maybe. I'm not sure how familiar most people are with this, so maybe contextualize this a bit. What is OpenNext? What's it trying to do? Yeah, so I'll preface this by saying I've never used open next and everything, but but I'm familiar with some of the maintainers and the fact [00:14:00] that it exists is the thing that I'm calling out. Not necessarily how great it is or whatever. The fact is that the next yes is challenging to deploy anywhere but for cell and get all of the features that. Are documented on the next JS documentation. And so what's interesting is if you're not deploying on Vercel, then you're actually deploying a different framework than what is documented on the documentation for next JS because next JS really does assume that you're deploying on Vercel. Now, that's not entirely true. Like they do put effort into \ Like supporting other places, but not a lot because their financial incentives go against that. the fact is that they want you to playing in Vercel because that's how they finance the open source project, which is perfectly fine. I'm not making any ethical or moral judgments on anybody. I'm just saying another thing that I'm thinking about is the fact that Thank you. It clearly it's hard to deploy anywhere else. So we have to have this like separate projects, which [00:15:00] I don't know what you would call a fork, but it like it's some sort of separate thing to make it easier to deploy next. Yes, on a W. S. Lambda. And now like you can deploy next JS in a docker container on a long running node service and everything like I've heard a number of people who say that's pretty easy. I've also heard people who say it's not easy, so I'm not sure what to make of that. But the fact is that if you do that, you are deploying a separate framework like you're not getting ISR and that's like a big part of what next JS talks about a lot as well. And various other features like that. Thank you. So like what really gives me pause on this is the fact that Vercel, once you get to a certain scale is a very expensive offering. So expensive. In fact, that a lot of people will move somewhere else when they get to that scale, I've got some tweets in here from people who are saying that they were quoted 40, 000. For a static application per month I, I assume per month because they're, their next thing they say is our current cloud front bill [00:16:00] per month is 12. So like just ridiculous. Another person said they were quoted 4, 000 a month for Vercel secure compute. Which just like really expensive platform stuff. And so while it feels nice right now and Vercel's DX is really great, the fact is that Vercel. Can be prohibitively expensive for people to use. And so that's fine. That's we're not talking about for sale. We're talking about next, but, , because next is difficult to deploy anywhere else, then why would you invest so much of your effort? Into becoming a next JS developer and betting your entire platform, whatever you're building on next JS deploying to herself, of course, because that's where it's best only to find out later that, oh, man, this is going to be really expensive for us. It's going to cut into our margins and all that stuff. So we got to move off and it's hard to move off. And so that is another thing that gives me pause and like certainly a subjective thing there as well. But on top of all of that, I'm pretty sure they're not profitable yet. I,[00:17:00] allegedly and, cover my basis for the lawyers, but like I, I do not think that they are profitable yet, which of course there are growing companies still very like aggressive and they're growing. So you wouldn't expect them to be. I don't think their investors want them to be profitable yet, but I also questioned their unit economics of building on top of all of these other services. So I'm not sure that they're profitable, even if you Throw out , all the growth expenses that they're incurring right now. So it just gives me a huge concern to put all of my eggs in that basket. So that's just something else that I think about now on the flip side, we talk about remakes Remix was its own company from the start. I joined up a year after they got started for about 10 months, and it was very important for Remix to be widely adopted. And so everything was focused on being able to deploy anywhere and make that as good an experience as possible. When Remix was acquired by Shopify, It worked out super well because Shopify doesn't have a hosting thing. So it's not going to, change the incentives there. But on top of that, Shopify is utilizing remix in [00:18:00] all kinds of sites, which is actually a lot like what made React being at meta so useful was because meta was using react for all sorts of things. And so that really gave some battle testing to react. So anyway, the chain or the incentive difference is another reason why I go with remix over next. Yes. I'm with you. it's interesting to know , how this dichotomy will shake out. Cause yeah, like that stewardship of the project by an entity that doesn't have a capital interest. in the thing that they are stewarding does feel pivotal. So like, I understand that argument, but , do you think that's like fundamental to like an open source framework being widely adopted. Like, Do those things need to be separate? Or do you think that there is some future where it's possible that this kind of like intermediary shim layer can exist where they're like building on top of other services, but adding a little bit of value in the abstractions that they're providing and they can make that the economics of that work. [00:19:00] Yeah I definitely think that they can make the economics of their platform work. And so I'm not suggesting that Vercel is doomed or anything like that. As far as will this play out well for the product or for Next. js I definitely think that Next. js will continue to be very relevant many years in the future. I have no Concerns there. I just questioned the incentives a little bit. Especially if you want to have a little bit of an independence from the platform. I looked at other frameworks outside of the JavaScript ecosystem. I guess inside ecosystem, there's a Gatsby that tried to do the hosting thing that did not work out for them at all. But anyway, outside of the ecosystem, there's Django. I actually don't know how Django is financed, but uh, Rails is financed because they use Rails. And so they're, they contribute back to it and all that. And then Laravel just build services around the framework that integrate nicely. That's pretty similar to the next JS model, except. Their primary service is hosting, but they've got analytics and other stuff too. So it is similar to the Laravel model and Laravel seems to have been pretty successful in [00:20:00] doing that. I think Remix is more similar to Rails in that the, ones financing the developments are just very heavy users of the framework itself. Where Next. js is a little bit more like Laravel in the the way that it's financed. And so I don't think that there's anything wrong necessarily all of that said I've not shipped a production application in rails or Laravel. So I'm not sure exactly how those incentives play out in those worlds, but I think that they will be successful in doing what they're doing. But , it's not the incentive structure that I'm happy with personally. Yeah. Yeah. I have deployed rails apps in the past and it was lovely. It was fine. No problems at all. But yeah, I guess on that point you mentioned before this kind of we're talking about next number. And I think it is, it's tricky in these conversations because it's almost like we can't talk about React or Next or Vercel without talking about all of them at this point anymore. And this is what I was alluding to earlier, was just everyone kind of has this thing they have had this feeling, but it's tricky to articulate sometimes. Do you think that This increasingly [00:21:00] blurred line is like indicative of, some underlying problem and just the react ecosystem. Right. I think that for a long time react has been to reconcile the fact that just react isn't enough and they started with components and then , there's the classes and all that but then they got to a lower primitive of hooks. And then they realized, you know what we need an even like deeper, tighter integration into , how applications are built with react to be able to get to that next level of performance or developer experience or whatever. I think this is part of why. The react team has emphasized frameworks so much recently is that there are things that you can't just do with runtime JavaScript. You need, and they've been doing that for a long time with JSX, build time stuff but this is like a level deeper because you need. something that it compiles into that affects the runtime as well. On not just the client, but also on the server. And rather [00:22:00] than building their own framework because there are already frameworks that exist, they want to integrate deeper with those frameworks. And I think that's fine. I don't necessarily have a problem with that. I think that makes sense. I understand the problems that they're trying to solve are really complicated Yeah. We've had, a bunch of people in this space, but particularly I'm thinking of when I spoke to Tom Preston Warner a few months ago working on Redwood and At the time he seemed like everything seemed pretty positive on, using the ecosystem. But, I don't know if he would have told me if it weren't so like, have you seen signals in there that there's like a clear market leader here that's like driving incentives and a weird way. Or do you think that there is, it gets possible to have multiple, consumers in the React Yeah. You know, This is pretty , even when I was at remix, I wasn't working on the framework itself. I was working on the community aspect and things like I've made a couple of small contributions to remix. And so the [00:23:00] react team isn't going to collaborate with me in this regard, because I'm not very involved there that said there are maintainers of Redwood and Apollo and remix and actually. Even Redux that have expressed some difficulty in collaborating with the React team since many of them joined Vercel. And I think... That makes me feel uneasy. Like I was already uneasy with the fact that the react team is at meta just because I don't really like meta as a company. I think they're very problematic to society and that's a whole nother conversation, but uh, at least it was like a place where they were using react at scale and all of that stuff. And so like they were user focused. Now at Vercel, I feel like there are a level of abstraction above that. And it just feels a little bit more I don't really want to say it this way, but I can't think of another way to say it, like a little bit more of an ivory tower situation where they're just a little further removed from the problems of everyday developers, because now it feels more like they're building a [00:24:00] product rather than react being a. Offshoot of a product that they were building, right? Like we did this and it worked for us, here's this, and now it feels more like we're going to build this and we're going to give it to you and let you see how you feel about it. It just feels a little different. But yeah, the fact that they're collaborating less, I think in some respects is because. they're like sitting next to each other. The react team and the next J s team, they're just like, Oh, we'll just have this conversation here. We don't need to really do much open collaboration. So I don't necessarily I think that they're being nefarious. I think it's just happening naturally. And which is really unfortunate. And you might think of this as a point for the next team. Oh, great. They're the lucky ones that are in. But that should make you concerned that the react team is less collaborative via the experience of other people. So yeah, like I, I should say also that the react team did get a developer advocate or developer relations Matt Carroll and he actually reached out to me, like minutes within me [00:25:00] publishing this article. I don't think he'd even seen it yet or anything. And so that's a positive thing, but hAving just a single framework where most of the attention is being given, I think can lead to problems. Yeah. So you mentioned there that what's driving the framework and library authors like get to make changes. So from a developer's perspective, , cause you said, you think it feels different where it's like developing it to productize it and get it in developer's hands that way. Versus just we see, there's like a. pull requests in a GitHub repo, we can go and fix this. Cause this is the most common issue that people are working on or a change request or something. Like, why do you think that those are so different? Cause if one could argue that if it's a pain point for des, it's a pain point for devs. Why does the incentive system really matter? I think that before react was always running on like Facebook would deploy react main, the main branch to their production stuff. And so before any of us got a release of something. Thousands of [00:26:00] Facebook developers were working with it on a regular basis and giving their feedback back to the team. And that would go back into, wow, this API is really hard to use, or it's very confusing, or it leads to these performance problems. And now , that is broken. Like the canary release of react is now. Not used by Facebook. As far as I can tell from what I've seen on Twitter and things communication from the team, Facebook has not used server components and server actions. They may have used server components, but I'm not positive, I'm pretty sure they haven't. And I'm pretty positive they haven't used server actions. And these are being billed as stable features of Next. js. Even though they're technically not stable in react, we can talk more about that later, but it just feels a little bit like, oh these two teams just talked about it together and they decided that this is what we all need, but they haven't actually. exercised these APIs at all in, in any production [00:27:00] environment which does go into the next point that I make in the post about experimenting on users which I just really don't appreciate at all. , tell us a little bit more about why you think that matters so much and back to my question. Why does that feel so different on a project that is more, just driven by a community rather than a company. . I think the reason that it feels so different is, that like what is presented to us is more like. Hey, these are ideas that we think are good. Whereas before it was, Hey, these are things that we've done and here's the results of what we've done. I think that those would be helpful to you as well. And yeah, it, it definitely does make me feel like they're experimenting on my users. And so the react team, what was it? Maybe a year ago started a new release channel called the canary releases which is perfectly reasonable. I've seen many other open source projects do this sort of thing. And it's a great idea actually to get like really early releases out to users. [00:28:00] The remix team doesn't quite do this, but they will do like daily releases or experimental releases. If there were any changes merged into dev that day, they'll just release it on an experimental branch. And I think that's awesome. Nightly build of your browser, whatever you want to Yeah, Try to break the thing with people that know what's going on and they can be like, I know what's happened. Yeah. Yes, exactly that. Like I, I am opting in. To this experimental or, trial stuff canary actually for those who don't know canary is a bird and it this particular bird was often used and even still probably as what's called a sentinel species, which is. Used to detect risks to humans by providing advanced warning of danger. So you're in a coal mine and there's like carbon monoxide danger and stuff. The bird will die first. And then you're like, Oh, the bird is dead. We probably better get out of here or put on masks or whatever. That's what a canary is. Now unfortunately canary birds can't really. Sign off on being used in this way. And I think actually these days they will protect the canaries by giving them [00:29:00] oxygen to you or something like that. But still when you install a canary version of some browser or something, you know what you're signing up for. You should that you're signing up for things that probably won't work. and I appreciate that. Unfortunately next JS has taken and the react team, the way they communicate this, they said that canary features are stable for next JS users or users of frameworks. Or it's canary for the framework, but then the framework can build stable features around it. So what that means is that if you build on top of those features, you're actually putting out a Canary software to your end users. That to me is unacceptable. Period. because you can't manage your version of react with next. Yes, you get whatever version they ship to you. So you don't get to choose. Am I using canary or am I not? And it would be fine if the next JS team were like, here's the app router. built on top of canary features. Therefore, it is also a canary feature, but that's not what they're doing. In fact, they are [00:30:00] saying this is what everybody should be using. And the idea I think is just that it's stable for you. We're not going to be changing APIs and we'll manage our integration with these react canary features ourselves. So you don't ever have to worry about breaking changes and stuff, but it's not just breaking changes. It's like, are these good ideas? And we haven't actually shipped them to users to really vet whether these are good ideas. Like we used to do when things were running over at Facebook. and it's not just for the users. It's also for the developers who are using the APIs. And so this really concerns me. I really don't like this. And what it means going back a little bit to the collaboration piece is that for any other frameworks that want to integrate with these. First of all, they don't have that open communication because the react team has been a little less Collaborative. And so what Michael Jackson from the remix team tweeted this, he said, so react recommends one, you should use a framework with react. So like everybody should be using a framework. And then to that framework [00:31:00] should pin to a canary version of react in order to take advantage of the latest quote unquote stable features that do not yet appear to be in a stable release. And what makes this really challenging is that in order to do that, you have to suck up react itself. Like you can't say, okay, users, you can just use whatever version, because you need to lock down your canary version of react. And because of that. Now react is your code. You're responsible for as the framework author, you're responsible for all of the react code. As it's coming in because it's part of your framework. It's not an extra thing. Somebody else is installing. It's now installed as part of your framework and without having a really tight integration with the react team like next has, you're not going to be able to cope with those bugs and things that come up as well. And so again, this might feel like, oh that's a plus for the next team as well, because they're the ones who have that special connection. But again. They are telling you to use stuff that has not been used in [00:32:00] production and go ahead and experiment on your users. And when they find out, oh, that's not gonna work out. What are you gonna do about that? So I'm really concerned about the messaging there on. I'm concerned about lack of collaboration there. It just feels Really dangerous to me. Putting on my devil's advocate hat again. I think it is hard to argue against the like that is definitely a problem For other like framework maintainers like that just feels like a bad state of being you know for everyone else, but maybe I'd question Or maybe just push back on a little bit. Like why does it concern you so much I guess just the mentality or the statement that like, oh, there, this is like a framework. Like we've said, there is a, there's super close collaboration here. So they will handle the thing that is dangerous on the surface that seat like that. That seems like a logical, thing to propose. Why does that make you so nervous? Yeah, great question. So that state of affairs is fine, but the thing that's not fine to me is that the reacting themselves, they clearly feel like this isn't stable enough to call it [00:33:00] stable. And the reason is because it hasn't actually gone out to production to anybody. But then the next team goes around and says, no, it is like we do feel confident about this. And so then but why, how do you feel so confident this is an enormous shift. So , show me the evidence that this is going to be. So much better for developers and for users and and it's by this point there have been a number of people who are, who've been working on the app router and stuff. And I've got to say, a lot of them really don't like it. The developer experience is not been great. And so with Remix, what they do is instead of. Having all of this extra stuff that like, shipping out this, these all huge new features and saying here you go, this is the way we recommend it they will ship it out as either an unstable or experimental feature. And it will sit there like that for months and people can opt into it and it's great and they use it and they provide feedback and things change. So again, like this is subjective, but that matches my [00:34:00] sensibilities very well. It makes me feel a lot more comfortable. I'm going to put you on the spot slightly here. Have there been cases where this, back to, you know Next and React. Have there been cases where this has been a problem? Like where this has caused an issue? Yeah. I guess I probably should have mentioned at the beginning, I mentioned in the blog post that I haven't shipped anything with next in, in a long time the blog post itself is actually built or delivered on an X JS site because I don't build that site. Again, kind of hearkening back to the fact that whatever you use is probably fine. These are all just my sensibilities and opinions, but I haven't shipped anything with the app router. So I can't speak from personal experience. But it has seemed to me with the backlash that people have had, or there's been with the app router, people are complaining about the dev server being really slow, like basically not usable. And those are the types of things that the Remix team works out ahead of time. So like Remix just barely added. They're going to be migrating from their own compiler to Vite the, but they didn't just come out and say, okay, everybody, this is the way [00:35:00] we do it. Now that it's an unstable plugin that people can opt into and they can use. And I, like just before this call, I was talking with uh, one of the team members about some of the problems I was having with my old website. And so that's the type of. Experience that I would expect from anybody building these types of APIs. And yeah, I'm not sure that quite answers your question, but the based on the backlash that I've seen in the community on like people resonating with this particular point, I'm pretty confident that there have been problems for people. Yeah, I don't think that there needs to have been like some catastrophe for it to be a problem that, everyone is leery of. , one more question on this point, but it feels like that devs like new things, devs like things that are fast, you like being able to ship new features quicker. Like usually new things are being developed because , we want to get something out the door, right? It's oh, it sure would be cool if blah. It's okay we can do that. But that winds up in a canary release like that needs tested stuff takes time. you think like There is a cleaner way that this could be being done [00:36:00] with, the next team in particular that would make this kind of the best of both worlds for everybody. Or , is it just like a pacing issue with it's just too fast. No I don't think it's a pacing issue. I think that the remix team has really nailed this and they're inspired by the Ember team Ember team really started doing this years ago. And the solution is to use what's called a future flag feature. So, , You opt into the new feature. So. It's the same framework. You're not installing something new or whatever. You install the same framework and then in your config, you say, I want to opt into these new features. So if it says canary yeah, I'm opting into that. Like that's sounds good to me. And so if I'm going to be the guinea pig, I want to at least volunteer to do that. And with a remix version two. Remix was on version one for a year and then they started adding a bunch of these really cool new features that didn't have any backward compatibility with the old way of doing things. And actually sometimes there would be backward compatibility, but they're not so sure about it about the API. And so that would be an unstable [00:37:00] feature. So you turn on the unstable feature. And now you get to use these fancy things. But in all of these cases it's very well communicated the level of stability that you're dealing with. And once it gets into a future flag, it's this is the way that the future is going to be. And we're pretty confident about this, but you're going to be the pioneer if you're using this feature. And then what's really cool about that is if you have all the future flags enabled, then when version two finally does land, Your upgrade path is literally just delete that config and upgrade the package and you're done that and that played out really well in this Remix v2 release. I upgraded a couple of apps in minutes because of this and that was the same for many other people so that's what I would love the Next. js team to do. So would you say that like Maybe like the most recent release of Nex or even ones before that like have felt unstable or do you think that like it's been mostly okay, so they've Yeah, it's so like the next JS team does a pretty [00:38:00] good like they, they clearly do care about keeping people on the latest version. And they'll do stuff like make code mods and things to automatically update your code and from what I can tell, a great success. And so that's fine, and actually it is notable that the first slide of next JS code that's when they introduced the framework that code will still run with the current version of next JS, which is awesome that they've been able to do that. But where next JS seems to be adding complexity and new features and different things that just expand the footprint of next JS remix is trying to do the opposite and saying, Hey, in our next version we're going to try and remove stuff and reduce the footprint of the API. Now being able to do that while also delivering new features is pretty challenging. So you have to consolidate features to make that possible. But that is something that they are actively working on. At least it's a stated goal. And I appreciate that about the remix team. , To close us out here a little bit, What would you ask of next, I [00:39:00] guess the ecosystem at large, like next Inversell in the future? I would ask them to change their messaging. Don't wrap a canary feature of the underlying framework and call your stuff on top of it stable. Or at least if you want to call it stable, whatever, but no I, not whatever, like it's, it is not stable if it's built on top of a canary feature. so like, be a little bit more clear about your messaging there. I can appreciate that. This is such a huge change. We have to do a totally different app directory over here. And so like, there's a very clear separation here between those two and it is a migration and that's fine if that's what you have to do that's fine. But I want it to be more clear from the Next. js team that these features are not tested in a production environment like you're used to React features being tested in a production environment. That would probably be the biggest thing. And then also Let us collaborate better. That's an ask on the react team, but so much of the react team is over at Vercel anyway. So I think that Vercel could do something about making it a little bit more of a collaborative framework. And then [00:40:00] because I'm not a Next. js user, I don't really care too much about the level of. complexity that's coming in and everything. But that is something else that I hear people talking about a lot. Like just changing the way that uh, like overriding the fetch API. Like when you're using fetch, you're using actually the next JS fetch and you don't even know. and so the code that you might see in your next app wouldn't actually work anywhere else. And it's just surprising, they violate the principle of least surprise, stop doing that I think would be another thing that I invite them to do Yeah, thank you so much for coming on and chatting with me, Ken. Is there anywhere you would point listeners to if they want to, okay, we'll link to the blog post, obviously. Anything else you'd want to have people check out? Yeah. It's very self serving, but epic web. dev is the thing where I'm trying to teach everybody how to build awesome web apps. And I guess I'll add that I had 60 people who signed up to go through all the workshops that I have on there back in July. And a number of those people have come back and said, Hey, I don't [00:41:00] use Remix at my work at all. I use Next. js. But I was able to use so much of the knowledge that you taught in those workshops, even in the next JS app. So if you're listening to this and you're like, yeah, that sounds cool. That he likes remix. I'm glad that I can still use next and Kent's won't hate me, which is true. I won't hate you for using next, but don't write off epic web because it's not using next JS because it absolutely has a lot of transferable knowledge. Cool. Cool. Thanks again. Thanks again, Ken. I appreciate it. Again, it's always a pleasure chatting and picking your mind a little bit. Thank you. No, it's always nice to chat with you too.