[timneutkens]

> 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.

[timneutkens]

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.

[leerob]

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!