The plugins located there are being built into Next.js or moved into the Next.js monorepo, eg next-css and next-sass have been built into Next.js. Preact has an alternative approach that works better (this example: github.com/zeit/next.js/tree/canary/examples/usin…)

We still have to update the repository, it's on the backlog of work to do.

The majority of pages can be statically rendered when github.com/zeit/next.js/discussions/11552 lands. Overall I would say it depends on what you're planning to do. Marketing pages for example should probably always be statically rendered, whereas a dashboard might be server-rendered.

Did some of your design decisions (first-class serverless support, Now, network optimizations) penalize you when adding features to Next.js?

Overall we're never limited in possibilities. One of the great things about thinking about serverless support is that it helps ensure pages can scale infinitely, even when on-demand rendering.

For example incremental static generation is partially based on what we could already provide users hosting on ZEIT. Now we're bringing these features into Next.js to allow everyone to take advantage of them.

How do you know what to prioritize in the whole list of RFCs/next features that are going to land one day in Next.js?

Generally we prioritize based on community need. For example the amount of 👍and replies + involvement from the community is very telling as to how much impact we can make by building out a feature we're thinking of.

RFCs also allow for experimentation, as feedback allows us to adjust for community needs.

Overall the main thing that has been helpful for me is creating a proper office space inside the house. We all work remotely so we were already working from home.

Noise cancelling headphones work pretty well, depending on if you have a lot of background noise. Also getting an external monitor and ensuring that it's at the right height and an ergonomic desk chair.

Thanks a lot for the tips Tim Neutkens

At ZEIT we use Checkly to run tests against every deployment that is made: checklyhq.com

For the Next.js end-to-end tests we boot up the Next.js production server by running next start and then running tests using the wd package (webdriver). This allows us to run tests on multiple platforms against multiple browsers.

Overall it depends on what you're trying to do. In general I personally prefer end-to-end tests as they ensure the end product works and doesn't depend on implementation details

We provide a Jest Example to show how to test components in your Next.js applications.

Regarding testing full-pages, this is best accomplished by booting your Next.js application via next start and running tests against your application—you shouldn't try stubbing out server functionality.

Here's an example of how we test Next.js apps in our monorepo (with Jest): github.com/zeit/next.js/blob/canary/test/integrat…

The above test boots Next.js via next start, then runs webdriver (puppeteer would work too) to verify the application is working as expected.

The Next.js serverless build output was designed to be hosting platform agnostic.

It can be used to host on any platform. It does require that you wrap an interoperability layer for the provider that you want to use and split the functions as there is no standard between hosting providers.

There are some community tools to handle this wrapping for you (like the one you linked).

sdf2

From the start we went all in on adding end-to-end integration tests for all features which has helped us scale development and increase confidence when shipping new versions.

Besides that we've only added in more measurements to track, for example every pull-request gets a comment that shows how you're affecting bundle size of the Next.js runtime, the overall app at all and even node_modules changes: github.com/zeit/next.js/pull/11725

I'm currently most excited about the Incremental Static Generation RFC, particularly with its fallback behavior.

Besides the feature giving you a fully incrementally generated static site (powered by any source, including headless CMS or direct database calls), the fallback behavior helps this scale to millions of pages.

With the fallback: true behavior, you can tell Next.js to only statically generate your most popular product pages for example. Then, at runtime, Next.js will lazily statically generate the remaining product pages when the first request comes in—that lazily generated page will then be used for successive requests.

This allows you to keep build times low, and still allows for incremental rebuilds once deployed.

I'm also excited about the new Environment Variables support, which should greatly simplify env handling in Next.js apps.

---

If you want to know how direct database work in Next.js' SSG support, checkout this cool tool we built to see how Next.js bundles code for the client-side.

One of the biggest pain points users currently have is handling environment variables. We're aiming to solve this through this RFC: github.com/zeit/next.js/discussions/11106

Overall we're working on many developer experience improvements right now and solving some more complicated patterns. One example of this is that "paths in tsconfig.json and jsconfig.json is going to be supported very soon: github.com/zeit/next.js/pull/11293

Another thing that we're working on is even more documentation and example resources about general concepts in Next.js.

Overall we closely monitor the Next.js community and talk with users of Next.js both large and small. This goes from Alexa top 100 sites to people building the website for their local bakery. This provides a lot of context into how we can improve the framework.

Most of the features introduced in the past 2 years have been based on feedback from companies building Next.js applications.

We're actually working on many features, not just on static generation.

We strongly believe there are major wins to make in scaling JAMStack and bringing static generation to larger applications in order to allow them to scale even further.

Examples of this are:

• On-demand generating extra static pages: nextjs.org/docs/basic-features/data-fetching
• Incremental generation: github.com/zeit/next.js/discussions/11552
• Preview mode: nextjs.org/docs/advanced-features/preview-mode

Next.js is becoming more hybrid in that you get to choose per-page if you want it to be server-rendered on-demand or statically generated at build-time and then incrementally re-generated.

The incremental re-generation case works for most sites backed by a CMS for example, whereas if you want to make the tradeoff you can move to on-demand generating it for each request.

This allows for full flexibility and you're not tied to one solution or the other, for example you might start with on-demand rendering but then eventually move to static (and vice-versa)

I don’t think the requirement is very strong, but if the complexity is manageable, defense in depth](en.wikipedia.org/wiki/Defense_indepth(computing)) ) is always a reasonable idea.

Next.js on itself has many security benefits built in:

• The focus on JAMStack ensures that most of your code runs on the secure sandbox of the browser’s client. The pages downloaded from the edge is the same for every user, and as such, the security surface is reduced. i.e.: If you don't opt-in to server-rendering through getServerSideProps you're serving static files to users.
• React has excellent built-in protections for XSS, as evidenced by the verbose dangerouslySetInnerHtml – this is in stark contrast to the jQuery model, which popularized direct HTML and DOM manipulation of attributes and nodes.
• When using API pages deployed as serverless functions, each request runs in an independent VM context not shared by any other request concurrently, and the underlying containers are recycled frequently. Again, the attack surface is massively reduced.

From an engineering perspective, we also have a security e2e test suite that we continuously run to ensure all the common attack patterns are considered.

Tim Neutkens Thanks! Looking forward to the updated example as I'm currently working on that feature.

Luke just in case, I recently did a complete example that should be very close to zeit.co implementation (I asked them details), see:

• github.com/vvo/next-iron-session (and the example)
• github.com/zeit/next.js/tree/canary/examples/with…

Vincent Voyer This looks very nice, thanks a lot!!!

Our whole team is remote so we were already working from home.

For me personally this meant that my productivity has not really been affected as everything so far has been my usual workflow.

One thing it did affect however is that I now have a normal rhythm of when I wake up in the morning / and when I go to bed at night, which has been great.

Echoing Tim Neutkens, the entire Next.js team (and ZEIT team) is remote, so it has been business as usual!

ZEIT (the company behind Next.js) has been really supportive during quarantine and has started offering bi-weekly guided meditation and weekly all-hands meetings to socialize (no work talk!).

These actions have really helped keep productivity and motivation up for me personally.

Hello! First off, I'd like to clarify: Next.js is free, open-source software. All of its features are available without using ZEIT as your deployment solution (however, ZEIT is the best place to host Next.js applications!).

Regarding the new pricing for our ZEIT Now platform, this decision was rooted in two major things:

1. We see the major value we deliver as best in class developer experience and developer productivity, not (just) hosting. This pricing aligns costs with where we see our value.
2. We’re all about making life easier for front-end developers: this means eliminating the need to worry about unexpected bills due to traffic spikes or application bugs—that isn't productive.

You can learn more about these changes in our blog post.

It depends on what you're trying to A/B test, currently you can either do the testing client-side (which is what most solutions allow you to do). However we're planning to add in extra support for A/B testing that will help you automate it and take advantage SSG in Next.js.

Tim Neutkens hi! thanks for your answers! do you already have any details on the approach or alternatives being evaluated for AB with SSG?

Szymon Nowak I would like to mention that I just finished transferring a site with 21k posts, tags, category pages from Gatsby.js to ZEIT Next.js. The build time went down 23 mins. The entire experience with the fallback hybrid SSR on top of SSG has been amazing. I wish I wasn't under an NDA in this project and could post about it. What I can tell however is that this is a path well worth exploring.

Ahmad Awais ⚡️ Thanks! That's reassuring ;) I wasn't aware of the fallback option and was afraid that I'd have to basically rewrite Gatsby source plugin for the headless CMS we use... Do you pre-generate any static pages (e.g. the latest or most popular posts) or do you use fallback option for all? Can you tell how you handle content updates given that "Incremental Static Generation" is still in progress? Redeploy the whole app?

Szymon Nowak We are waiting for that to happen. Write now it rebuilds the entire site. The previews are using the preview feature that got released in the v9.3.

For zeit.co we have 3 directories:

• pages
• components
• lib
• geist (our design system)

All components that fall outside of the design system are located in components, this includes page-specific components.

Inside of pages we only include actual pages, as every file in pages is converted into a route by Next.js and is considered for code-splitting logic.

Tim Neutkens How about your Dashboard code structure? what I'm working on is more like that

We use Next.js for all our web applications at ZEIT. This includes all of zeit.co, our documentation and internal applications.

In case of zeit.co we have one Next.js app that covers:

• Static marketing pages (zeit.co homepage and other marketing pages)
• Blog (zeit.co/blog)
• SaaS dashboard (zeit.co/dashboard)

All of this fits really well into Next.js applications.

Besides our own usage Next.js is being used in a diverse set of websites and web applications (e.g. see the showcase: nextjs.org/showcase) including everything from top tier brands to personal websites.

Hello! Our recently announced RFC for Incremental Static Generation in Next.js covers this exact use case.

This RFC allows you to specify an interval on which the page is rebuilt, and is paused when no users are visiting the page (to reduce API calls to your CMS). This is an eager approach (compared to an event-driven approach) which we argue is a better foundation to start from.

We'll absolutely be looking at allowing you to rebuild pages on-demand via a webhook, but we think of this more as an optimization for the future.