Allow disabling runtime JS in production for certain pages (experimental)

[timneutkens]

This allows a page to be fully static (no runtime JavaScript) on a per-page basis.

The initial implementation does not disable JS in development mode as we need to figure out a way to inject CSS from CSS imports / CSS modules without executing the component JS. This restriction is somewhat similar to https://www.gatsbyjs.org/packages/gatsby-plugin-no-javascript/. All things considered that plugin only has a usage of 600 downloads per week though, hence why I've made this option unstable/experimental initially as I'd like to see adoption patterns for it first.

Having a built-in way to do this makes sense however as the people that do want to adopt this pattern are overriding Next.js internals currently and that'll break between versions.

Related issue: #5054 - Not adding fixes right now as this implementation needs more work. If anyone wants to work on this feel free to reach out on https://twitter.com/timneutkens

Do note that in this implementation it means no runtime JavaScript will be executed so you won't be able to use React hooks, event listeners etc without injecting custom <script> tags into the rendered html (eg through next/head) for pages that use unstable_runtimeJS: false

[timneutkens]

Landing this as experimental, I can't spend tons of time on adding all the needed changes to make it work in development right now so the DX won't be what you'd expect. e.g. if you use useEffect or useState they'll work in development but won't work in production as the JS bundles will be excluded.

If someone wants to work on this feature (with guidance from me) please let me know: https://twitter.com/timneutkens, dm's are open.

[TxHawks]

How do you opt-in a page to use this in latest canary? Does one also additionally need to configure something in next.config.js?

[timneutkens]

export const config = {
  unstable_runtimeJS: false
}

export default () => <h1>My page</h1>

[Manikanta-20]

This configuration at which place, we need to add in next.config.js / certain page ?
unstable_runtimeJS: false

[timneutkens]

It's a per-page configuration option.

[Manikanta-20]

ok,this configuration will work on next build /not?

[TxHawks]

Looks like the __NEXT_DATA__ script tag is still rendered to the markup.

This can be a fairly large chunk of html, and I can't think of a good reason to include it in a completely static page.

Am I missing something?

[timneutkens]

It's there mostly because users might need certain properties from getStaticProps/getServerSideProps which are passed through there.

[TxHawks]

I feel that defeats the purpose of trying to create very lean pages. If the user needs anything specific from getStaticProps and have actively chosen to render pages without Next's runtime JS they can probably be expected to render a script tag to the markup with the data they need. It's nothing very complicated.

It should at least be configurable, since there is not easy way to get rid of that fairly large chunk of markup that will most likely be unneeded in most unstable_runtimeJS: false use cases.

[Manikanta-20]

this configuration

unstable_runtimeJS: false

should work for Static/Server/SSG page,not for specific server page.
At the time of next build it should not optimize/consider the page. other pages it should not break.

[TxHawks]

@sai1139 I'm not sure what you mean exactly - if you want to opt-out a page from including Next.js runtime JS , you configure that page to exclude it:

// in pages/index.js
export const config = {
  unstable_runtimeJS: false
}

export default () => <h1>My page</h1>

And that specific page's markup will not include the <NextScript /> generated scripts or preload links.

Making this a per-page config It actually ensures that it doesn't break other pages

[timneutkens]

I feel that defeats the purpose of trying to create very lean pages. If the user needs anything specific from getStaticProps and have actively chosen to render pages without Next's runtime JS they can probably be expected to render a script tag to the markup with the data they need. It's nothing very complicated.

It should at least be configurable, since there is not easy way to get rid of that fairly large chunk of markup that will most likely be unneeded in most unstable_runtimeJS: false use cases.

Feel free to open a PR to change it, as said this was just an initial implementation.

[timneutkens]

this configuration

unstable_runtimeJS: false

should work for Static/Server/SSG page,not for specific server page.
At the time of next build it should not optimize/consider the page. other pages it should not break.

Not sure what you mean. You can read the details of this PR here: #11949 (comment)

[TxHawks]

Happy to take a stab at this. Would you prefer I just remove it or make it configurable?

If configurable, does unstable_nextData: false work?

[timneutkens]

Happy to take a stab at this. Would you prefer I just remove it or make it configurable?

If configurable, does unstable_nextData: false work?

Removing it when unstable_runtimeJS: false would be fine like you said.

[Manikanta-20]

@timneutkens

export const config = {
  unstable_runtimeJS: false
}

export default () => <h1>My page</h1>

this configuration is not working in developement and production

[TxHawks]

@sai1139 As mentioned in the description - this only work for statically generated pages, and only in production mode. It doesn't work in dev mode so that hot module reload still works

[Manikanta-20]

@TxHawks thanks for information, but i have done sample example and tested in production mode. this configuration is working you, can you share me in git url, i will get to know.

[TxHawks]

And your pages are statically generated?

I works fine for me. A simple reproduction repository could help figure out what the issue is

[Manikanta-20]

@TxHawks can you share me in git url, i will get to know.

[timneutkens]

And your pages are statically generated?

I works fine for me. A simple reproduction repository could help figure out what the issue is

Do note that it's not required to statically generate the page, if you use SSR it works too 🙏

It works fine on my personal website btw: https://timn.tech/

https://github.com/timneutkens/timn.tech/blob/master/pages/index.tsx#L4-L6

[Manikanta-20]

@timneutkens thanks for the information.if other information, i will let you know.

[chrisabrams]

Is export const config a next.js convention for the pages?

[timneutkens]

Is export const config a next.js convention for the pages?

Yes, it's currently only used for a few options though. E.g. to enable AMP support or to disable body parsing on API routes.

[chrisabrams]

I see; this is the first feature for Next where I've seen this pop up; the timing of it is incredible as I was needing this!

[TxHawks]

@timneutkens How would I go about testing that my changes actually work? contributing.md only mentions running the integration apps in dev mode, which obviously not help here, because these are production mode-only changes.

It actually required a very small change to _document.tx

- 692          {staticMarkup ? null : (
+ 692          {(staticMarkup || disableRuntimeJS) ? null : (
  693            <script
  694              id="__NEXT_DATA__"
  695              type="application/json"

[chrisabrams]

@TxHawks what about using puppeteer and disabling JS?

[timneutkens]

We have production tests too, I didn’t add tests for this behavior yet as it was just a proof of concept. You can copy tests/integration/production into a “disable-js” directory and test the changes there, the tests are pretty straight-forward if you look into the directory 👍

[timneutkens]

@TxHawks what about using puppeteer and disabling JS?

We use the “wd” package in the Next.js test suite as we test multiple browsers (IE11, safari, Firefox, chrome) hence why puppeteer is not used

[TxHawks]

@timneutkens Pull request submitted in #12406, including initial tests

[tvararu]

Nice! This is how I was doing this before (+ removing <NextScript />): https://github.com/tvararu/blog.vararu.org/blob/3ec6073a22baba67835dca0f6a6397fc68a6ee9f/pages/_document.js#L3-L14

As you say, this always felt wrong because it was overriding internals. I'm excited to see where this leads.

[mathiasha]

@timneutkens Thanks for making this. It is exactly what i was looking for.

[gaven]

@timneutkens Above you stated the following:

Do note that in this implementation it means no runtime JavaScript will be executed so you won't be able to use React hooks, event listeners etc without injecting custom <script> tags into the rendered html (eg through next/head) for pages that use unstable_runtimeJS: false

Is there an example of this in the Next.js examples? I'm under the impression that one would need to:

1. Create a new entry point for webpack to process the aforementioned file
2. Read the the output from the webpack manifest
3. Insert the script using next/head - referencing the file + hash created by webpack.

Thanks Tim for all the work you've put into this.

[timneutkens]

Is there an example of this in the Next.js examples

As this is experimental and not complete (as per my initial PR message) so we're not adding examples for it in the examples directory in case the implementation changes. However as said:

Not adding fixes right now as this implementation needs more work. If anyone wants to work on this feel free to reach out on twitter.com/timneutkens

I only built the part where JavaScript is deleted, not the part where you can add it back with compilation. Currently you can add a script tag from e.g. the public directory and that works. It'd be a good iteration of the feature to work on a way to get a compiled script though. However this does make things more complex. For example the webpack runtime would have to be shipped to the browser. Feel free to reach out if you want to work on that.

[yankustefan]

Hello @timneutkens
Thank you for your work on this. It's much appreciated!

I just wanted to chip in my thoughts regarding the readiness for stable release of this feature.
In my opinion, it would be ready when it reliably does what it advertises: removing the javascript.

As you say, it would be a good iteration of the feature to get a compiled script though. But that's maybe a nice to have for a next version, or iteration as you say.

For a first version, it would be "perfect" just to remove javascript. And if any is needed, add those scripts via the public directory, as one already can. Yes, those would need to be compiled separately, but I think that's totally fine.

For my use case, a content heavy blog site, I really love nextjs and react to build my pages. But it is very content heavy without much "interaction". So I thought having a full blown react app on the front-end might not be necessary and maybe just add one or two lightweight preact 'widgets' at pin-point locations with preact-habitat. Since I can reuse components done in the nextjs environment, there's not much extra work and I don't mind having to compile them separately. Since I am using a different framework, I probably would have to anyway.

What do you think about going stable with a minimum viable product and "just" focussing on removing runtimeJs?

[timneutkens]

What do you think about going stable with a minimum viable product and "just" focussing on removing runtimeJs?

This does not match our long-term vision for the feature (as described in my PR message) and would cause breaking changes (or having to maintain this feature as-is forever), both cases are losses as it would mean we then have to deprecate/replace existing stuff and cause overall churn that is not needed.
This feature even as-is is not ready, it does not reflect correctly in development mode where JS is still loaded, which would cause you to write interactions that do not work in production.

Hence why I said in my initial message:

Not adding fixes right now as this implementation needs more work. If anyone wants to work on this feel free to reach out on twitter.com/timneutkens

The initial PR was just to show what parts have to be touched and allow users to try it out if they really want to get rid of JS

[yankustefan]

Thanks for your feedback Tim.