This year, the ZEIT Day Keynote started by highlighting our Open Source projects including showing the metrics of Next.js. With over 25000 stars on GitHub and over 10000 websites are already powered by it, we're incredibly amazed at its growth and love seeing the increasing amount of projects depending on it.
We are proud today to introduce the production-ready Next.js 6, featuring:
Zero-configuration static exports. No need for next.config.js by default
_app.js, an extension point that enables page transitions, error boundaries and more
Babel 7 and Fragment syntax <> support
Extended integration test suites with a strong focus on security
Flow annotations in the core codebase
In addition to the 6.0 release, we're moving to feature Next.js on its very own homepage, nextjs.org, featuring:
All the Next.js documentation in one place. No more lookups of the README file on GitHub
Next.js focuses on the idea of pre-rendering as a means to achieve high performance. Pre-rendering comes in two forms:
Server rendering where each request triggers a render. As a result, the end-user doesn't have to wait for any JS to be downloaded to start consuming data
Static rendering where we output static files that can be served directly without any code execution on the server
Until now, static exporting in Next.js was very powerful but not sufficiently easy to use. It required setting up a manual route map even when no custom routes were in use.
With Next.js 6, we automatically generate the route map for you based on the content of your pages/ directory. If you're not using advanced custom routing, you won't have to make any modifications to next.config.js. Just run:
Next.js offers an extensibility point called _document.js. If defined, it lets you override the very top-level document of your application, which renders the <html> element.
_document.js allows for powerful extensibility, but it has some serious limitations. For example, React is not able to render <html> or <body> directly on the client side, so _document.js is mostly limited to the initial pre-rendering phase.
To enable some other powerful use cases, we're introducing _app.js, which is the top-level component that wraps the outside of each page.
Some differences between _document.js and _app.js
Let's look at some use cases that defining _app.js enables.