I'm personally curious how the Next is able to achieve the claim of "zero client-side JavaScript" mentioned here[1] using react server components? It just doesn't seem to make sense to me, and the HN clone example and my barebones test project also clearly still load about 74.2 KB of JavaScript. Is the claim supposed to mean that the server components won't require additional JS, or maybe that they won't need to execute any client-side JS to be fully rendered?

[1]: https://nextjs.org/docs/advanced-features/react-18#react-ser...

I think it means that any page that only renders server components can just push the built html to the browser. If there were to be client components, like an upvote button, react would be required for that to hydrate the DOM.

It’s very similar to what Astro is doing. Only adding the JS if it’s actually necessary.

From my understanding from watching the keynote earlier today, the reason that demo has JS is that repo opted in to have client side code to handle the upvote functionality. If it didn't require that interactivity it could be shipped with no client side JS. The client side js code is defined in the component files ending in .client.js

https://github.com/vercel/next-rsc-demo/tree/main/components

You can read more here on the original RSC announcement: https://reactjs.org/blog/2020/12/21/data-fetching-with-react.... RSC are still experimental, and as mentioned, this demo has some client-side functionality (upvotes).

Thank you for your response! However, the linked content further seems to support my suspicion that having websites without any client-side JS is not in the scope of RSCs. The linked RFC, in my opinion, clearly states for it to be expected that a client-side framework and React accept and handle the streamed React response[1]. So while it may be possible to eliminate a lot of client-side JS, at least those would always have to be available on the client, correct?

I would also like to make it understood that I'm not here to bash the Next project, I am simply interested in the technology.

[1]: https://github.com/josephsavona/rfcs/blob/server-components/...

Seems he missed your question, which I’m also curious about.

I would assume "no client side js" means "works fine in w3m". I'm guessing that's not the case?

Also, does "no client-side JS" also work with Cloudflare Workers?

How about on demand page revalidation* ? I can't find if it's part of Next 12.

* https://github.com/vercel/next.js/discussions/11552#discussi...

It is not part of Next.js 12 – still working on it!

How does middleware work when using a CDN to host the JS bundles?

ie what happens when I've already loaded the bundles and am transitioning to a page that has different middleware requirements?

Is it a client-only middleware implementation? (I want this and have implemented a poor man's version in my _app.tsx).

What's the timeline on React Server components? It seems next 12 experimental feature of Server component is a very early look? Since React 18 is not out yet, and it's not planned to have Server component in that release.

It's available to try today under an experimental flag. React 18 is still in alpha. We'd love to hear your feedback!

Any chance we’ll get a proper official routing mechanic that doesn’t rely on the file system and magical file names?

Also excited about the Rust compiler! Apologies if this is far from reality, but by looking at recent commits in GH[1] it looks as though this has been rushed for a v12 release, so I was wondering how much of internal testing has this been going through before pushing it to the broader public.

[1] https://github.com/vercel/next.js/commits/canary

We've been testing SWC for months now, both with early community members on canary releases and with Vercel customers. Lots of the rushing at the end was for minification, which is opt-in because of this. But compilation with Rust (replacing Babel) is stable (which is why it's on by default).

Thanks for clarifying, Lee!

The Rust compiler is just swc which has been around as another project for ages. Checkout it’s home page. Many people are using it.

Yeah, Deno is using it as well!

And Parcel: https://parceljs.org

How do you achieve no cold boots on edge functions? Is it the same approach as Cloudflare (https://blog.cloudflare.com/eliminating-cold-starts-with-clo...) or something else? Are there any tradeoffs to be aware of with your approach vs theirs if they're different?

Vercel's Edge Functions are built on top of Cloudflare Workers. The runtime is designed for any similar provider, but we've chosen Cloudflare for now because they have an amazing product.

Awesome!! Thanks for the answer :)

Excellent decision!

I'm building a custom server (which hopefully now can be replaced with middleware?) which I build with tsc:

$ tsc --strict --esModuleInterop --moduleResolution node --jsx react --outdir build server.ts node_modules/next/dist/server/config-shared.d.ts:1:15 - error TS2724: '"next/dist/compiled/webpack/webpack"' has no exported member named 'webpack5'. Did you mean 'webpack'?

1 import type { webpack5 } from 'next/dist/compiled/webpack/webpack'; ~~~~~~~~

Probably there's some workaround but the compile error seems legit. Is there something I can do about it until I figure out middleware?

Webpack is no longer a dependency of Next.js - this was the big announcement about the compiler. You will have to opt out of the new SWC compiler (if this is an option atm)

That doesn't seem correct. Next _does_ still use Webpack - it's what does the actual bundling:

> Underlying webpack improvements: We've made numerous improvements to webpack, including optimizing Fast Refresh and making on-demand entries more reliable.

> After making webpack 5 the default in Next.js 11, we've now officially removed webpack 4. We've worked closely with the community to ensure a smooth transition to webpack 5.

SWC is the equivalent of Babel for transpiling JS, not Webpack for bundling.

Hey Lee! Loved the new features and your session on edge.

One further-future question - would react server components ever be able to execute on the edge or will those always run from the datacenter you've deployed to?

And regions - Cloudflare Workers offers 44 regions in North America and Vercel currently offers 4. Does your team have any plans to add some more edges around the world to bring the speed benefits closer to end users?

Thanks to you and your teams incredible hard work on all the new features. Next.js has been a blast to use the past 5 years. Looking forward to the next 5!

Yes, the Hacker News demo shown does run at the Edge (using Vercel Edge Functions) when deployed. If you self host, it would run on your server of choice.

Vercel doesn't have 4 regions, we have 17 :)

Hey Lee. I am not entirely sure how server-side components replace the dynamic/static balance next.js is now the market standard for.

1) Do the .server files require any special infrastructure for self hosted solutions?

2) If we move to ISR to a component level, would that mean that a page with multiple components will generate a backend-process thrash of multiple refreshes? (say 10 components, each with a revalidate 1 s)

3) Is there a good mapping to translate ISR to server side components from both UX and infrastructure/implementation?

1. No, when self-hosted, server files will just run on your server :)

2. You can use the `keys` prop to prevent that (this is still very experimental and the API is not finalized).

3. We will be sharing more on this soon, but yeah still early days.

Are there any plans to address Bazel compatibility?

I understand that the Next philosophy is very monolithic but so far I’m having trouble getting it to play nice with build tooling.

We may investigate this more in the future, but nothing planned currently.

Does Next 12 allow for getStaticProps() in _app.js?

It does not, but with React Server Components, you can achieve the same result.

https://nextjs.org/docs/advanced-features/react-18

Can we still use obscure babel macros with the new Rust compiler? And if so, what do you think the future will look like for babel macros in a future where most build tooling is written in languages like rust/go?

> in a future where most build tooling is written in languages like rust/go

You really think most of the build tooling will be written in other languages than JS? Compilers make sense, they are very CPU bound, but otherwise build tooling should also be accessible to modify to the developers working in the project, not just those who use Rust/Golang. And I'm sure we'll still use JS projects for some of the tooling.

"You really think most of the build tooling will be written in other languages than JS?"

Deno is using the same compiler (SWC) so there is data point number two on the question. esbuild is another...

We're working on making it easier for developers to write Rust plugins to handle their own transformations.

The module federation story was a bit complicated pre-webpack 5. Are there plans in the roadmap to further support module federation?

When can we expect the docs to be updated?

They are now updated! Sorry for that. The NPM release took a bit longer than expected.

Is Next.js Live only available if the project is hosted on Vercel?

No, it works fine with any static hosting system, like S3+CDN, Netlify or others. The API feature (FaaS) needs special server handling to run, but they're just Node functions, so other systems also add support.

Vercel just has first class support where everything just works, but can you host it yourself.