> There are features/patterns in Next.js that made sense 6 months / a year ago but are now not preferred

Do you have an example of what changed? We haven't really made any breaking changes for quite some time and have been improving on the existing feature set. Smaller bundle sizes with no code changes etc are part of this.

If you take the getting started readme of Next.js 3 years ago it still works today.

We're very committed to introducing only the necessary changes and features. On top of that we have an extensive integration test suite to ensure no features are broken when upgrading.

I was intentional about saying "not preferred" instead of "not supported". You are correct, there have not been any breaking changes, which is very helpful.

When new features and changes roll out (like CSS support in 9.2), they are _good_ improvements. I'm simply stating the rate of change is drastic. Which, as mentioned, is both good and bad.

Here's a solid example. If I were trying to integrate a Firebase API to my Next.js app before API routes, the recommendation might have been to run a monorepo where one app is Next.js + custom server and the other is a Node.js API (deployed with now).

Next 9 and API routes made that unnecessary. Now you can just embed an API route under /pages to talk to Firebase.

Now, if you search for "nextjs firebase example" you might find three or four different ways of doing it on Google. As you said, they all still _work_, but they're not idiomatic Next. It can be hard to dumpster dive through Spectrum chats and GitHub issues to find the new "recommended way" of doing things.

This is a very minor gripe. You're doing amazing work, Tim!

Great explanation @mAritz!

Thank you for your feedback @Ndymium, we've shipped a new version of the website that has a loading indication (based on the with-loading example posted above)

We're currently working on rewriting /learn to not require any login while still retaining the gamification element (in offline storage). Meaning that you get the best of both worlds.

Just to explain the reason there is a login at all, this is mostly for historical reasons. The original learnnextjs.com built by Arunoda was based on another project he created for teaching Meteor.

Anyway as said we're rewriting /learn, using MDX (http://github.com/mdx-js/mdx) for content and the quizzes will store the result in your browser.

Very cool! Makes sense that you got it for free from Meteor, great that you're iterating based on feedback.

> great that you're iterating based on feedback

Thank you for providing feedback in a friendly way, we're always happy to improve where possible! In case you're curious we have a WIP pull-request: https://github.com/zeit/next-site/pull/159

Max is definitely right here. We're not planning to deprecate or "completely rewrite" anything.

We're not even "rewriting everything in Typescript at once". We're slowly converting files over one by one. No public APIs are changed. Furthermore, we have an extensive test suite of end-to-end tests for both development and production behavior.

It actually works really well for render workloads like server-side rendering too, the reason for this is that rendering can be quite expensive and blocks the thread. With Serverless you're able to scale the renderer to infinite instances.

The cold-boot problem is an interesting one, it's heavily correlated to the serverless function size, this is why we implemented a complete output target for serverless, to output the smallest possible function that is completely standalone, no dependencies. This makes cold-boot considerably faster. For example on https://next-news.now.sh/ it's hard to tell the difference between cold-boot and warm functions.

That’s interesting thanks - I didn’t know this. And thanks for the example site too! Definitely feels snappier than I anticipated.

By default Next.js scores 100/100 on performance and best practices eg https://nextjs-3q3i4heaj.now.sh/ (SEO / Accessibility are not 100 as I didn't add meta tags in this example, but are very trivial to add.)

In case of Invision it seems like images / render blocking css that was added outside of Next.js are the main culprit. I've reached out to Jon Wheeler who works on the marketing site to make him aware.

I'm going to post the same answer I gave in another thread on the initial post:

As said elsewhere, I mostly act as a curator of a very large effort of hundreds of individuals. The project was actually co-created by several other people who work on infrastructure at ZEIT (e.g..: Naoyuki Kanezawa led all the initial releases, designed important parts of the framework, Arunoda Susiripala contributed the test harness and key build pipeline infrastructure, and so on).

Next.js is not prescriptive about your backend stack, it gives you a way to fetch data using `getInitialProps`. At ZEIT most of our APIs are built using Micro: github.com/zeit/micro, which is a very lightweight way to build APIs.

As said elsewhere, I mostly act as a curator of a very large effort of hundreds of individuals. The project was actually co-created by several other people who work on infrastructure at ZEIT (e.g..: Naoyuki Kanezawa led all the initial releases, designed important parts of the framework, Arunoda Susiripala contributed the test harness and key build pipeline infrastructure, and so on).

create-react-app is actually removing this feature in an upcoming release. We don't have plans to include it as a feature to Next.js as you can already implement it using a custom server. We do have an example for it: https://github.com/zeit/next.js/tree/canary/examples/with-cu...

Why is it being removed?

To let an external express server handle it. Which they think will be better than the current in house solution.