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.

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

> 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

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.

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.

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

We're on it, thanks!