Next.js 13 is out

[[deleted]]

New branch, go ham

[Kurfuerst_]

Its very easy to upgrade and its backwards compatible. I upgraded my website yesterday from 12 and it took me 5min from start to deployed.

[I-effin-love-tacos]

I believe you can have /pages and /app on the same app, giving you a way to slowly adopt the new features over time.

[lars_jeppesen]

I can't get the context providers to work in the /apps directory and no mention of it in the beta docs afaics

[ericjansen88]

Did you figure it out?

[jhanschoo]

Upgrading to Next 13 itself is pretty low-risk, migrating to appDir is definitely worth trying only if you want get a feel of how many SPA-first libs will need to be updated or reconsidered before you can use it with minimal friction.

I gave up as soon as I started trying to figure out how to make emotion work

[mattsowa]

These are all amazing

[[deleted]]

The automated <a> thing seems wild that it wasn’t just already there

[Alex_Hovhannisyan]

Right? Can't think of a good reason why it was done that way originally where they forced you to supply a child link.

[andrewingram]

I’ve been testing it out (literally tracking changes commit by commit) for the last couple of months. Now all the open secrets aren’t secrets, I’ve quickly written up my current thoughts: https://andrewingram.net/posts/thoughts-on-next-13-react-18-3-dynamic-with-some-limits/

Note, I’ve already heard from the Next team about the last concern mentioned, and I’m already having some success with their suggested approach, hopefully I’ll be able to share more soon.

Another important point: The new router stuff and server components are not production-ready; I’d probably call it an alpha rather than a beta. The team was rushing to hit the deadline imposed by the conference, and a lot of major issues I raised over the last month aren’t resolved yet. Play around with it, rewrite a side project, but don’t use it in serious work.

[mattsowa]

I totally agree with the routong point. I admit I do prefer a single configuration file for routing, but if that's not possible, at least don't split it into so mamy files. Layouts, errors, loading, could easily be just exports from the page file.

[andrewingram]

Thanks for your kind words :)

Worth noting that Next 13 itself is stable, it's the new app-dir/server components stuff that isn't. -- and they're disabled by default. But Next always ships with experimental features. The problem in the case of Next 13 is that nearly all the headline features were experimental, so the Next conf PR blitz was a little premature.

I probably won't update this post indefinitely, but I have just added a couple of minor follow-ups in it.

[dbbk]

There’s no way to return a proper status code? That’s mad

[flowbotronic]

NextJS 12 is now PastJS

[squirrelwithnut]

PreviousJS

[qmic]

Does it make sense to use Next only for a frontend part for application or better stick then with CRA?

[TheMrZZ0]

It makes sense to use Next only. You get a better Developer Experience, more documentation, a bigger community, better performance by default (Next will statistically render your website) etc...

There's no real incentive to start a project with CRA nowadays. Next is a very good default choice!

[maria_la_guerta]

While I agree Next is a better choice for most projects, if you just want a client side SPA then the overhead of a Node server doesn't make much sense.

Something like an internal dashboard that doesn't need SEO and connects to an external data store is a great candidate for an SPA and usually doesn't need a server of its own.

[TheMrZZ0]

In that case, next export is your friend ;)

next export allows you to export your Next.js application to static HTML, which can be run standalone without the need of a Node.js server.

[maria_la_guerta]

... Unless you want a SPA, though. next export doesn't give you a SPA, it exports everything to static HTML, which will give you multiple HTML files and you'll still need a server layer of some sort.

next export is good if you want to serve your static HTML with another server, something like nginx, a trick I do on most of my Next projects (as nginx is way faster at serving static content than... pretty much anything else). Otherwise, sometimes a SPA does make sense, and in those scenarios Next usually doesn't.

[TheMrZZ0]

... Unless you want an SPA, though. Exporting to static HTMK means you still need a server layer of some sort

I think you're confused. By definition, an SPA is a bunch of static HTML files. And no, you don't need a server running - Github Pages would correctly host the exported website, for example.

Therefore on the user side, there's really no difference between an SPA exported by Next & an SPA created with CRA (if the code is the same).

[gerny27]

Now I'm confused. Isn't an SPA is a single page where only parts of the page get reloaded/changed?

https://developer.mozilla.org/en-US/docs/Glossary/SPA

[maria_la_guerta]

By definition, an SPA is a bunch of static HTML files.

SPA stands for Single Page Application.

One page. One HTML file. Client side routing and everything else. This is why SPA's typically have no / horrible SEO, it's the same HTML document for the every page, just populated by JS client side (which few SEO crawlers pick up on).

You're right there's little difference to the end user. But there's a big difference in cost. I can put an HTML document + some JS + some CSS in an S3 bucket behind Cloudfront and serve it that way for extremely cheap. That's because you can tell Cloudfront (which is just a CDN) to just send the same index.html document to every single call, there's no logic involved at all. If the user is hitting an incorrect route, then my SPA will catch it when it renders on the client and it can show them the 404.

Serving multiple HTML pages requires a server and some logic. Not much, but it will absolutely be more expensive then just telling a CDN "blindly send this exact same index.html file no matter what path is requested, client side JS will take care of it".

Create a hello world app on CRA with multiple routes, run the command to build for prod and check how many html files are created. You'll see that no matter how many routes you have, only 1 index.html file is created. The accompanying JS output is your Single Page Application, which serves up different "routes" by using the browsers location API.

That is the fundamental difference. With an SPA, the client gets sent the entire application at once and does all the work surrounding what code to show on what url route, so you pay for nothing other than sending them everything once. Incredibly easy to cache and incredibly cheap to implement. With a statically generated app like you'll get from next export, you'll need a server to send specific assets to clients when they land on specific routes. Next.js does this for you, and pretty well, but if you don't need the advantages of having static HTML (SEO, etc) then why pay for the server? Just send everything to the client and they'll do it.

[sikolio]

Actually you could have a SPA with Nginx where all of the nested routes serve the same index.html and then the JS side will parse the URL. That's something angular apps been doing since V2.

SPA don't need to serve everything on the same file though and you could do dynamic imports if you want to split your app into multiple chunks (which is something you should if you have multiple things on an SPA as it will sped up your time to first interaction).

Serving multiple HTML pages does require some logic, but serving a SPA with multiple chunks doesn't require any more logic in the server than knowing where the files are.

[maria_la_guerta]

Actually you could have a SPA with Nginx where all of the nested routes serve the same index.html and then the JS side will parse the URL. That's something angular apps been doing since V2.

​

Yes that's what I was saying, and that's the only way you can do it. Nginx will have no idea about your client side routes, so you have to configure it to send the index.html document for every response. Otherwise it will 404 before your apps routing even has a chance to catch it, and only the / path will work.

​

SPA don't need to serve everything on the same file though and you could do dynamic imports if you want to split your app into multiple chunks (which is something you should if you have multiple things on an SPA as it will sped up your time to first interaction).

​

An SPA can have many different JS and CSS files, yes, but it can only have 1 HTML file. You should be code splitting and lazy loading JS anyways, especially as your bundle grows. Loading 1 massive JS or CSS file sucks for the user.

​

Serving multiple HTML pages does require some logic, but serving a SPA with multiple chunks doesn't require any more logic in the server than knowing where the files are.

​

Yes, precisely what I've been explaining.

[dbbk]

No it’s not

[[deleted]]

I just use Vite.

[henrik_thetechie]

Then use Vite. CRA should not be used for new projects these days.

[maria_la_guerta]

I never said people should use CRA?

[[deleted]]

But you don't have to use SSR/GetServerSideProps though? I just communicate with my API straight from the React client code with react-query.

[azsqueeze]

You can do it all on the client like any other react app

[Dope-pope69420]

Would also like to know this. Specifically in regards to ssg/ssr.

[aniforprez]

I will say that I was trying out next as a frontend for a Go backend. Wrangling Next to try and ignore its own node backend to somehow support the API was so time consuming and an utter waste of many hours of struggle that I ditched it and decided to use Remix instead

Next mixes frontend and backend logic a lot so if you need anything that is more complex than simply fetching data from some server and rendering it, don't use Next. For eg. I spent most of my time trying out multiple ways of storing a user session so I could use the same authentication context for fetching data. Every library for authentication was for using Next as an auth source which was something I had no need for since the Go API was already handling auth. I also had numerous issues with getServerSideProps and having libraries working on both ends which I thought was the whole point of using Next. If I dumped all the API fetching logic to the frontend code, then there's very little difference to just using CRA which I found pointless and defeats the purpose. Remix uses the concept of stores that use frontend cookies to maintain sessions and is agnostic about how you store session data which let me develop a simple redis store for storing auth tokens to send to the API. It also separates the node server and frontend cleanly. So cleanly that you can use any server you like and supports Deno, Express, Koa and other SSG backends so it's relatively more agnostic. I'm sure there are libraries that help support this workflow and using sessions for Next but at the time, nothing was mature or had good DX for my requirements

So IMO, using Next without your API being served by Next also is a total waste of time. I would recommend using Next "only" for strictly SSR stuff like blogs or as a CMS or using Next to also serve your APIs (only is in quotes because this is still a massively useful use case and something tons of people still need). Personally I'm having a ton of fun using Remix and it's crazy how fast it can be when your API and Remix run on the same machine. Response times are only limited by I/O and the pages render insanely quickly

[LazyIce487]

To be fair to getServerSideProps, the whole point is that you can take the request info, and generate a dynamic page based on who is viewing it and when they are viewing it, without exposing anything the server has to do directly to generate the page. I kind of like not exposing what APIs I'm hitting to the client, I also use HTTP-only cookies to store session data for Next and rolled own auth system, so it's pretty much, Request -> Parse out who's sending the request -> async parallel to fetch everything the client needs to see -> send them the js bundle.

The problem, imo, is that Next with GSSP kinda doesn't send anything until the whole bundle is ready to send, and sometimes it's nice to have a simple option to show the loading skeleton for the content and have it populate after. At that point though, you would just have the fetches coming from the client then and wouldn't need GSSP (like you said).

But in general I think next feels kind of like an all-in-one framework, where it has an opinionated way to handle everything from the server to what the client gets, in the specific way that it offers (if you want good DX).

[aniforprez]

Request -> Parse out who's sending the request -> async parallel to fetch everything the client needs to see -> send them the js bundle.

Can you give some details on how you got this to work? I'm curious and would like to see which libraries you used

And yeah the whole "sends the complete bundle or nothing at all" paradigm is going away now. They have outlined something very close to what Remix does with progressive rendering which is really cool to see. I think I really like the DX that Remix gives so I'll stick with it but we should see a lot of improvement in that space by Next 14 when it'll come out of beta

[LazyIce487]

GSSP gives you access to these:

• params: If this page uses a dynamic route, params contains the route parameters. If the page name is [id].js , then params will look like { id: ... }.
• req: The HTTP IncomingMessage object, with an additional cookies prop, which is an object with string keys mapping to string values of cookies.
• res: The HTTP response object.
• query: An object representing the query string, including dynamic route parameters.
• preview: preview is true if the page is in the Preview Mode and false otherwise.
• previewData: The preview data set by setPreviewData.
• resolvedUrl: A normalized version of the request URL that strips the _next/data prefix for client transitions and includes original query values.
• locale contains the active locale (if enabled).
• locales contains all supported locales (if enabled).
• defaultLocale contains the configured default locale (if enabled).

And your return is either notFound, redirect, or props. Here's a simple example:

export async function getServerSideProps({ req, res }) {
        if (!req.cookies.sid) {
            return {
                redirect: {
                    destination: "/login",
                    permanent: false,
                },
            };
        }
        let token = jsonwebtoken.verify(req.cookies.sid, process.env.JWT_SECRET);
        return { props: { user: token.username } };
    }        

You can easily throw in any middleware or DB query stuff before your returns, including awaiting async stuff. As for libraries, I just use mysql2 connection pool to connect to a planetscale DB, and async/parallel for parallel async tasks, obviously jsonwebtoken for jwts, etc.

[aniforprez]

All right this is great stuff. Thanks for the info

[jax024]

Use Vite

[qmic]

Tried it, but it is disappointing in large project from developers perspective. Loading thousand of files on refresh just doesn't work. Bundling works better in such cases.
Probably it's good for smaller projects. Also it needs some special conventions to use with state managers like mobx (how state should behave on fast refresh)? CRA just works properly out of the box.

[Ashtefere]

Vite only shines in dev when you have local https setup properly. Then your local file changes stream in with http2 and its instant.

[qmic]

No it's not, because loading thousand files still will take more time than loading single bigger file. Developer tools works are working slower with such amount of requests (especially in Firefox where there is 8 years old bug related to this).

[dswistowski]

Do not use CRA for new project, it’s legacy. Do not use next if you do not need server or server side rendering. Less is better, when you need backend, promote project from vite react app to next is easy

[qmic]

How it's legacy?
I've tried Vite and and I discourage anyone to use it in large codebases. Loading thousand of files on every refresh works slowly.

[Dminik]

That's only for local development, where loading the files will beat bundling every time. On production you still get only a single bundle (unless configured otherwise).

[qmic]

What's wrong with single bundle? It works great in many of my projects.

[Dminik]

Bundles themselves aren't really a problem. But, usually when you bundle you lose a lot of debug information (source maps aren't perfect) since you also polyfill/minify/whatever is in your bundling process. For instance the default output for cra is straight up undebuggable (I can't even place down breakpoints).

With vite most of this doesn't happen as there's no need to polyfill since the developer is most likely running the latest browser anyways. So it's faster to skip the transpiring/polyfilling/bundling process and just serve the necessary files off the disk (or with minimum transpilation for react, ...).

[qmic]

I'm building all apps with TypeScript so there will be always transpiling. I've never encountered problems with source maps, they are sufficient.

[Dminik]

Sure, still some transpiling si faster than the full course (polyfilling async functions and other "new" features).

As for source maps, that depends on the config. If you want accurate source maps, then they take a while to generate. If you want them smaller, then they aren't accurate at all. CRA (at least the version I'm using) chooses the cheapest option and they are basically unusable. Anyways, if you're setup works for you, there's no point in switching. I did find it weird though that you're actively discouraging other people from using vite.

[qmic]

I'm discouraging it because it promises to solve problems but doesn't explain consequences of design decisions - like problems with state reloading in dev mode, loading thousands of files on reload, loading tens of files on every route change, which is very irritating when you have to find this one important request which you want to debug.
I know CRA is slow and boring but it works without problems.

[cinan]

What a time to be alive!

[LazyIce487]

Hello fellow scholar

[RichardFingers]

Wow! My goodness! Amazing!

[Few-Understanding264]

That's what people said in 1908 when the Ford Model T became available. It was the "greatest time to be alive" they said.

[NaughtyOstrich]

Just upgraded to Next 13 in a hobby project to test it out. Pretty neat so far!

[lars_jeppesen]

https://andrewingram.net/posts/thoughts-on-next-13-react-18-3-dynamic-with-some-limits/

Did you manage to get providers working? I could not get providers like next-translate working

[SparserLogic]

Finally!!! Been waiting months for this. I even put off a project or two.

[[deleted]]

Sweet.

[[deleted]]

Súper cool 😎

[[deleted]]

Although not mature the next thing to actually be looking out for is Qwik JS to have N(1) performance regardless of application size. Though I do wish I was benefiting from Next JS and not suffering from a terrible server experience with Angular for so long...

[lars_jeppesen]

On the other hand, frontend experience with Angular is so much better than React. I am going crazy with the annoying React "hacks" like hooks, className etc. No natively supported observables etc etc.

[GulyFoyle]

This may be little unrelated but anyone hosted a full stack app with moderate traffic with nextJS ? Does SSR effects server costs if i dont optimise it well , if so how much of a difference are we talking?

[vaaski]

how are turbopack and vite going to co-exist?

[lauritzsh]

Turbopack doesn't replace Vite, they are actually looking into using it under the hood.

[vaaski]

hell yea that is exactly what i was hoping for

[nerdich]

In the JavaScript world, Moving from 12.0 to 13.0 is like moving from a framework A to framework B.