Wanted to clarify some of the points raised about Next.js:
> I’ve been using Next.js for a while and hosting the apps built with it on AWS with custom express servers. One day I’ve noticed that my servers are getting red-hot while doing almost nothing, and response times got huge.
OP mentions they're hosting a static website now but must have previously been rendering a server-rendered page. It's not clear whether they explored the static-site generation support in Next.js, which would have avoided any regressions in server-rendering performance, making this a non-issue.
> Long story short the library introduced a huge performance downgrade that was not caught by existing tests.
> Because benchmarks were using only Vercel’s (creators of NextJS) “Edge” infrastructure. And the bug was happening everywhere but not there.
Indeed, there was a regression, but it was not due to lack of tests as a whole. The linked threads point to issues both self-hosting (serverful) as well as on Vercel (serverless). There was a week between a fix being reported through the opened issue and a fix being placed on a canary release. Regressions will happen – the best thing is ensuring more tests are added and things are fixed quickly.
> We need alternative independent hosting to ensure that the community does not get stuck with a single provider.
You can (and will always be able to) host Next.js, both completely static (drop files in an S3 bucket) or on a server (Docker, EC2, whatever you want).
Just wanted to clarify those things. Your new site looks great, nice work.
Wow. Didn't expect a response directly from Next.js VP!
Before anything I wanted to say that I love Next.js and I'm using it in my projects daily. It's definitely the best solution right now at the market for the project types me and my company is producing :).
In regards to the inconsistencies in the article. Yes it was a server rendered page, not this particular blog. A much more complicated project.
Also I didn't want to sound as if the regression was handled badly. Quite the opposite, as soon as I've pinpointed the issue and was able to create a good Issue in the tracker the response was very swift!
And I understand that the regressions will keep on happening. I've been building apps for long enough to see waaaaay bigger problems slip into production. So no hard feelings!
> I’ve been using Next.js for a while and hosting the apps built with it on AWS with custom express servers. One day I’ve noticed that my servers are getting red-hot while doing almost nothing, and response times got huge.
OP mentions they're hosting a static website now but must have previously been rendering a server-rendered page. It's not clear whether they explored the static-site generation support in Next.js, which would have avoided any regressions in server-rendering performance, making this a non-issue.
> Long story short the library introduced a huge performance downgrade that was not caught by existing tests. > Because benchmarks were using only Vercel’s (creators of NextJS) “Edge” infrastructure. And the bug was happening everywhere but not there.
Indeed, there was a regression, but it was not due to lack of tests as a whole. The linked threads point to issues both self-hosting (serverful) as well as on Vercel (serverless). There was a week between a fix being reported through the opened issue and a fix being placed on a canary release. Regressions will happen – the best thing is ensuring more tests are added and things are fixed quickly.
> We need alternative independent hosting to ensure that the community does not get stuck with a single provider.
You can (and will always be able to) host Next.js, both completely static (drop files in an S3 bucket) or on a server (Docker, EC2, whatever you want).
Just wanted to clarify those things. Your new site looks great, nice work.