Amy BlankenshipFollowBetter Programming--1ListenShareI was stoked when I started hearing about Next 13 a couple of months ago. I had some time on my hands, so I thought I’d do an example project to kick the tires. The big thing that had me so excited was the new streamed HTML capability. I’d read about it a few months ago, and it was exciting to see it come to Next JS and React. I really wanted to like Next 13.When I started my career, nearly all software aimed at developers was paid. Beta programs were closed, mostly limited to prominent members of the community.On the one hand, this meant that very few developers had much of a grasp of the new features when the new version was released. On the other hand, the small pool of beta testers meant that the team developing the new version could help testers get unblocked to fully exercise it.The way testers got to be prominent members of the community was through spending considerable time helping others learn the software, so time invested in teaching them to use the new version was well spent.Closed betas prevented uncomplimentary reviews while the software was under development. Not only was it super clear the new version was not releasable yet, but also beta testers wanted to make sure they would be invited next time.Angular 2 was my first experience playing around with software in an open beta. I lost my job, and I made a bet on Angular as the technology to learn while I looked for my next job. It was super frustrating — the documentation was convoluted and difficult to grasp, and the examples were overly simplistic, so it was difficult to extrapolate how to build a more complicated app. It took me several times longer to build things than it would have in AngularJS, and literally no one cared about the things I built without being paid for it.In the end, I was hired for another AngularJS project, and that company then paid me to transition to React. I’ve literally never touched Angular again. I would have had exactly the same result if I’d just enjoyed my involuntary time off instead of wrestling with Angular.Because of this, I usually don’t jump right onto a new technology when it comes out, and that’s mainly so I can let others waste their time bumping up against the pitfalls and then read what they wrote and waste less time myself. It turns out that this time I had time to waste (and I was genuinely intrigued by Next 13), so I decided to play it forward to all those people whose wasted time I’d previously leveraged.Here’s what I found.The Next JS documentation says this about Next:Next.js is a framework for building web applications.With Next.js, you can build user interfaces using React components. Then, Next.js provides additional structure, features, and optimizations for your application.Under the hood, Next.js also abstracts and automatically configures tooling for you, like bundling, compiling, and more. This allows you to focus on building your application instead of spending time setting up tooling.Whether you’re an individual developer or part of a larger team, Next.js can help you build interactive, dynamic, and fast web applications.I’ve been reading a lot about Next JS recently, and in one post I saw something like “Next is a static site generator.” Unfortunately, I cannot locate that blog post link, but my initial reaction was “No, it isn’t,” because I had read what the Vercel team had said about what Next is.Hate to break it to you, but that blog was correct. At its core, Next is a static site generator. This means it tries to crawl all the links in your app at build time and create and store all the pages. If there’s a way to turn that off, it’s not well-documented. I happened across this video today that summarizes part of the problem:In short, if you navigate to a route and then navigate back to your earlier route, the route you navigate back to won’t pick up any changes that were made while you were on the route you navigated to (hope this sentence is clear — if not, watch the video where he demonstrates the behavior). This happens even if you set revalidate=0 on the main route or call revalidatePath() in the child route.This is only in part due to the way Next is “static-first.” Another reason for it is that there are actually two caches: a back-end cache, which is saved rendered versions of your pages, and a front-end/React cache, which contains saved React components with the state they had when you last visited that page. Backward navigation is always considered to be “soft” navigation, which pulls that saved component out of the cache vs. doing anything to give it a new state. Let me repeat that: it is always considered soft navigation, and right now there is no way to force hard navigation with a Link component. Here’s a video that explains that process:I think all this is what the Next team says when they say that mutations aren’t stable — the process of getting changes in your data to show up is extremely painful right now.But here’s the thing. This basic bias toward being a static site generator has larger implications. It means that you can completely delete database tables, kill your Next server, re-add those tables with no records, launch dev mode again, and by default you’ll still see the data that originated in the tables you deleted. Or at least this is what happened in my project before I wasted way too much time figuring out how to shut that shit off (which was a couple of versions ago). This is because Next didn’t cache the fetch call, it cached the pages that were produced after making the fetch call and saved them in the .next directory. And even though the server was stopped, when it came back up it saw them sitting there and served them, whether or not the default or specified revalidation period had expired.This is bad enough, but it has implications that can really mess you up even beyond that. For one thing, when Next goes to do a dev build, it will hit your database to try to create as many static pages as it can (assuming your app uses a database).If you’re in the middle of containerizing your app for testing and you haven’t yet gotten your database container working, the dev build will fail. But you could potentially not see the error message on the screen and not even realize your build failed because most Dockerfiles have a direction to copy everything from the working directory into the container. And that .next directory probably has the static files in it Next built the last time you ran the app locally in dev mode. And when you see the site launch from inside your container, if you’re not paying attention you might not notice that the records you’re seeing on the screen don’t exist in your test database, because it also does not exist yet. This is why the build failed, but you don’t know it failed because your site runs.And, since we’re testing, we pretty much need to turn as many of Next’s caching features off as we can because there’s no documented way to clear the various caches between test runs. So e2e testing is incompatible with getting any kind of performance boost from Next. The heart of the new version is React Server components, so it doesn’t seem you can use unit testing in Jest for most of your app — you’ll need to depend on e2e testing for most of your testing.All of this is a long-winded, round-about way of saying that the docs need to be way more honest about the static nature of Next 13 on the first page of the docs if that’s how this version will ultimately work. However, I have real questions about why a version that also focuses on moving a lot of logic to the back end (which implies we expect the data to change sometimes) is static by default.To me, it feels like an edge case to have a site that allows you to interact with data but is mostly static pages, not a default that the entire world is clamoring for. I mean, WordPress exists. If there is an audience that is clamoring for this, Vercel should market it more directly to them and make it very clear to the rest of us that this may not be our tool. Or at least how to use it for more normal apps.I started out trying to use intercepting routes for showing and dismissing modals. I’m not sure if the docs were more confusing than they are now or I was just trying to hold too much in my head and didn’t get it, but I didn’t understand that intercepting routes are for an edge case and that you can use regular parallel routes for opening and dismissing modals if you don’t need different behavior when you navigate to a modal vs. when you refresh the route (no modal).This was probably exacerbated by the fact that when I started I couldn’t find any example repos that showed either behavior. Eventually, I did find a short link at the end of the intercepting route docs that did go to a repo that showed one intercepting route, but didn’t answer questions about what if you have more than one or you have intercepting routes at different depths and how do you get out of them after a refresh.I had a lot of trouble figuring out what directory structure to use to get to my desired result (especially before I found the example repo), so I was quite relieved when I realized I didn’t need intercepting routes. But I spent enough time in it to feel there are still a lot of unanswered questions in the docs about how these should really work.Another problem that is sort of tangentially related is that I wanted to use the dialog element for my modals (that’s what it’s for). But an issue with it is that you can’t open a dialog as a modal without using JavaScript. This is a problem, because now any modal has to be a client component. And some of my modals had forms on them that were visually identical, but one was add and one was update. Under normal circumstances, you’d just inject a callback to use on submit and reuse the same modal/form. However, you can’t pass a server action into a React component because Functions can’t be serialized and the Form is inside a modal that must have JavaScript to work. So this forces you to import the server action for each submit directly into the component, which means you can’t reuse that component with a different form action. Woot.This points to an issue with Server Components, which is that we often have to use JavaScript for something relatively trivial like calling showModal on a Dialog element. This makes you opt into use client, opting you out of streamed HTML. And, since you can’t use streamed HTML nearly as much as you’d think, it doesn’t take very long to ask yourself exactly why you’re fighting against this static site generator that wants you to think it’s a full-stack framework to try to get work done. You wind up turning that stuff off to the extent Next will let you and working around it the rest of the time, so you don’t get the performance benefit and it’s a hassle.Or you can stuff your JavaScript down into small pieces of the UI where it doesn’t conceptually go but will technically work, but that is right up there with pushing state down on my list of things to do once Hell freezes over.A big problem with Next 13 right now is the lack of example projects. The documentation suggests you join the Discord channel to get help, but I found the channel to be unresponsive. It may be a coincidence, but I got very slightly better responses once I changed my display name to not reveal my gender. StackOverflow was actually much more helpful.When I ran into issues with intercepting routes, it wasn’t immediately clear how to debug them. The problem with basing the framework on putting files at the right path is if you think you did and it’s not working, how do you debug that or otherwise figure it out? And asking on the Discord channel sure as hell isn’t the answer.In addition, the documentation tells you if you’re using the app router to be careful to stay in the app router “side” of the documentation, but they didn’t duplicate the debugging help in the app router side. Even when you find that help, it doesn’t tell you anything about logs Next might be keeping or how to enable better logging.Tip: I did eventually find some kinda useless log files in the .next folder.I also had some just flat out strange stuff happen, which I’m going to put down to yes, this is prerelease software. For one thing, when I was sending a route parameter of 10 to my endpoint, it was getting translated to 1. I wound up working around it by using the working endpoint that gets the whole collection and just getting the item with an id of 10. This is obviously not workable for a production system.My app also doesn’t do a production build, but it works until you try to navigate to the screen that lets you create child records. This seems to be a Next bundling issue somehow, but it seems the Next team is so backlogged with bugs that they haven’t looked at it yet. I’m trying to decide if I’m going to try to work around it or if I’m going to catch up on things I’d like to get done around the house before I start my next job. Pretty sure I won’t need Next 13 there so 🤷‍♀️.Update: Vercel did get to this bug and pointed out these mysterious errors were because I hadn’t marked my action 'use server'. To me, this points out how easy it is to get this stuff wrong and how limited the information is on how to figure out what happened.There’s also a weird undocumented limitation that you can’t get the url search parameters (query string) from server components, which limits their usefulness even more.I really wish this could be a glowing review of new software that I just love. Sadly, I can’t do that. It feels to me like the static-first model of this Next version is fundamentally in conflict with its introduction of React Server components. The limitations and unexpected behavior caused by this conflict seem at this point to mean that it will take a huge amount of effort to coax the promised performance out of Next, if you can even get it.There are a lot of really neat things about this version of the software, but I can’t imagine being allowed the extra time I needed to just do basic stuff in Next on a real project with a deadline.I also worry that, since this is the first framework to support React Server Components, that they might get unfairly vilified by association or that other frameworks might see the issues and decide not to add that support. I honestly don’t know how I’d feel about RSCs outside of Next, because the only limitation I know for sure comes from RSCs and not Next is the way the inability to pass Functions into client components prevents reuse of Forms. It has never been possible to serialize Functions, so we can’t really blame that on RSCs.I’d be less concerned with all these issues if Next 13 had just been made available to the public for a couple of months, but there are Next 13 tutorials on Youtube that are over 6 months old. When a company has sunk a lot of resources into a design, it’s rare for them to do an about-face to a completely different design in the face of user feedback. This is especially true when that design has been made public for months.In my opinion, the situations where you can really get the benefit of Next 13 are few and far between, and there’s too much confusion between all the different moving parts. When all this is true, often the best fix is to revisit the design from scratch, and I feel like at this point that’s unlikely to happen.But I’m probably worrying too much, and it’s likely fine.Note: I am making this available for free for at least a week, and then I am putting it behind the paywall.----1Better ProgrammingLead Front End Developer at Atlas UPAmy BlankenshipinCodeX--3Sergei SavvovinBetter Programming--5Sami MaameriinBetter Programming--7Amy BlankenshipinCodeX--3Nitin SharmainLevel Up Coding--2SomainJavarevisited--1David Rodenas, Ph. D.--47imran farooq--1Thomas SmithinThe Generator--104Domenico Gagliardi--53HelpStatusWritersBlogCareersPrivacyTermsAboutText to speechTeams