Next.js 14 and other thoughts from Next Conf 2023

I take a stroll through our standout moments of Next Conf 2023 with my fellow dev, Sarah Fisher.

The Big Hitters

Let’s jump straight into the headline features announced at the conference. After the announcement of the app directory at Next.js Conf 2022, expectations were high, so it was only right to start with a tone-setter…

Phew…

“No New APIs” 🎉 What a relief! 😅

So, what did they announce?

Owen’s take:

For me, the performance improvements are huge with Turbopack: 53% faster server startup and 94% faster code Fast Refreshes. For now, we need to use --turbo with the Next.js dev and build commands, until it’s stable at least:

https://areweturboyet.com/

While we have faster code updates locally, they haven’t shared the statistics on build minutes, but we can only assume that that will follow suite with speedier deploys. The Netlify free tier offers 300 build minutes/month, so this cost-saving would be huge for any charities or Tech With Purpose indie hackers looking to save on their monthly expenses.

As for Partial Prerendering, or reducing the “Boring White Page” (as Theo calls it in the video below), this should absolutely be a priority for the web world. Giving the user an experience as fast as possible will fundamentally lead to better UIs.

While the app state is on the white page of doom, browsers have full control over the experience. Taking off my foil hat and replacing it with something more sensible, I don’t like the idea of Google or Apple owning that experience. It’s important that we get more control over the experiences we’re delivering.

Sarah’s take:

Next.js 14 is about stabilising and refining what already exists, rather than adding a stack of new features. There’s been a real commitment to improving developers’ workflows, including better error handling and logging, speed enhancements, and other DX improvements to keep users sweet.

That said, a lot of work seems to have gone into nextjs.org/learn, which is bound to bring in new converts. The Conf’s Discord was raving about this on the night of release, presumably because many are still in the process of moving over to the /app router and certainty of best practice is nice to have.

The API reference docs for Next.js have been updated and now include a how-to on everything from database setup to error handling. I’ll be working through these myself to see if there’s anything I’ve missed. They’ve also provided a foundational guide to React, which will probably be awesome for newbies.

Server Actions

Owen’s take:

Server actions are not quite there, but getting close. The discourse online has been really silly. I think they have tons of potential, but will require a mental model shift. I’m also still not sure where I stand on the API vs server actions debate — I need more real-life experience to see how it all comes together.

export default async function Page() {
  const serverAction = async () => {
    "use server";
    // Do server thing
  };
  return (
    <>
      <form action={serverAction}>
        <button type="submit">Do server thing</button>
      </form>
    </>
  );
}

Looking at a simple example, this still requires too much unnecessary code (<form></form>). I want it to be cleaner: to recognise async functions in an async component and run it on Node automatically. This obviously has downfalls, since promises are a JavaScript API, not Node.js.

export default async function Page() {
  const serverAction = async () => {
    // Do server thing
  };
  return (
    <>
      <button onClick={serverAction}>Do button server thing</button>
    </>
  );
}

Sarah’s take:

Server actions are now officially stable. The ability to set up a function on the server and trigger it from the client when the user submits a form is comparable to tRPC, but as it’s been built directly into Next.js, it could be simpler to implement for those not already wedded to the former.

Looking back, devs have had a wild ride when it comes to recommended data fetching patterns in Next.js. They’ve moved from swr > getServerSideProps > await some func in an async server component (theoretically). They’ll no longer need a dedicated API route to trigger server-sided code or even need to pass user data as props.

If using fetch or React cache , for example, it doesn’t matter if the same data (such as user data) is fetched in multiple components. Thanks to automatic memoization, this should still have no effect on app performance.

I’m reserving judgment on server actions until I’ve had time to try them out in a real-world scenario.

Conclusion

• 💃With no new APIs, the shuffle from Next.js 13 to 14 should be simpler than 12 to 13. Upgrade commands and a short summary of changes can be found here: nextjs.org/docs/pages/building-your-application/upgrading/version-14
• 🚀 Turbopack is set to transition to a stable state in an upcoming minor release once all tests pass (run next dev --turbo to try it earlier).
• 🛑 Next.js 14 does have some breaking changes and new deprecations to watch out for, including the minimum Node.js version being raised to 18.17.

Let us know what you think of the announcements and what you’re predicting to come next! ✌️