
Next.js 9.4 – Fast Refresh, Incremental Static Regeneration - STRiDEX
https://nextjs.org/blog/next-9-4
======
leeoniya
you guys might be interested in a current Reddit thread (also on HN:
[https://news.ycombinator.com/item?id=23136688](https://news.ycombinator.com/item?id=23136688)):

[https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...](https://old.reddit.com/r/javascript/comments/ghfyd2/secondguessing_the_modern_web/)

specifically this sub-thread of Mithril's author and myself doing a "Hello
World" Next.js perf assessment vs a full-blown ecommerce page:

[https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...](https://old.reddit.com/r/javascript/comments/ghfyd2/secondguessing_the_modern_web/fq8th3k/)

~~~
hayksaakian
Later in the thread, the author links to this site as a real world example
using domvm* -- even anecdotally it feels very fast!

[https://us.thermosoft.com/floor-
heating/systems/thermotile-m...](https://us.thermosoft.com/floor-
heating/systems/thermotile-mats?track=0)

* Edit -- initially i incorrectly claimed that this site uses mithril -- (it uses domvm w/SSR, not Mithril)

~~~
leeoniya
dammit, it's still pre launch, plz don't hug it to death too much! oh well,
here we go!

the link above disables Google Analytics on that page, which would otherwise
add an extra 50ms of js time (and would account for the majority of the js on
the page).

(it uses domvm w/SSR, not Mithril)

~~~
elviswolcott
I'm really interested in your comment about how Gastsby, Next et. al. are
doing SSR wrong. For context, I'm an SSR newbie, currently trying to migrate a
site I started away from Gatsby (realized it's not the right tool for the
job).

To me, it seems like Incremental Static Regeneration is the best of both
worlds - you get a static site without huge build overhead and SSR niceness.

However, peeking in dev tools, sure enough your site is a bit faster in nearly
every lighthouse metric compared to static-tweet.now.sh despite being
decidedly more complex.

Could you expand on how Gatsby and Next are doing SSR wrong and what it takes
to do it right (i.e. what is DOMVM doing instead).

I'm sorry if you've answered this elsewhere in the thread, I looked around and
didn't find anything.

~~~
leeoniya
> I'm really interested in your comment about how Gastsby, Next et. al. are
> doing SSR wrong. For context, I'm an SSR newbie, currently trying to migrate
> a site I started away from Gatsby (realized it's not the right tool for the
> job).

please read through the whole Reddit thread i linked. i compare a minimal
Next.js hello-world page to domvm-rendered e-commerce page. what specifically
they do to produce such a sub-optimal result will remain a mystery to me
because i don't particularly care to investigate. no one has given me a bare-
minimum Gatsby site to evaluate so i have no idea how it compares besides
looking at one of their slow showcased apps in the reddit thread:
[https://airbnb.io/](https://airbnb.io/)

i think a lot of your questions may be answered by reading the Reddit thread.

~~~
elviswolcott
I looked through it earlier but missed the "continue this thread"

> SSR can be done correctly, even with React

This stands out to me, and I agree completely.

I dug around in devtools and found a few interesting things looking at the
static-tweet.now.sh (Next w/ Incremental Static Regeneration). It seems like
the performance is more or less on par with domvm as far as network usage
EXCEPT for the initial bundle (which is mostly react & dependencies). For
subsequent visits, this is cached and performance is great, but devtools tests
with a clean cache so this is hidden.

Admittedly, that's a huge qualifier. It doesn't seem like Next is doing
anything wrong with SSR other than using a framework with a huge bundle. As a
result, the huge bundle ends up getting sent even for a page (or entire site)
with no interactivity.

In theory, it might be possible to avoid sending the bundle for routes that
don't need it, but this ends up being a fundamental limitation of react afaik.

Vercel (the folks behind Next) put it really well

> React at Facebook is… > …unlike React at ${anywhereElse}

The large initial bundle pays off for a site like facebook or a web app which
really takes advantage of all React has to offer (wether that's performance,
tooling, or dx), but definitely deserves more second guessing than it
recieves.

~~~
leeoniya
right.

perhaps it's possible with Preact|Inferno + SSR, i dunno. but this [1] seems
to use babel/webpack and a bunch of other stuff. it's not clear to me from
that post how minimal the end result can actually be.

the thing is, React's _ecosystem_ is also to blame, it is so full of ready-to-
go-do-everything popular components with inefficient code that cannot be tree-
shaken, that lack of care in bundle evaluation is absolutely rampant. every
imaginable feature is just some burned-out dev's `npm i` away, node_modules be
damned.

[1] [https://www.digitalocean.com/community/tutorials/build-a-
ssr...](https://www.digitalocean.com/community/tutorials/build-a-ssr-app-with-
preact-unistore-and-preact-router)

------
drekembe
I have nothing but good things to say about Next.js, one of the few web
libraries that I'm really excited about. Great developer experience, the API
is simple and very stable and the feature set is really powerful.

~~~
ignoramous
If you've had a chance to look at nuxt.js and/or gatsby.js, how'd you compare
those with next.js?

~~~
vimota
We built [https://indieshops.co](https://indieshops.co) on nuxt.js and then
used next.js for [https://vimota.me](https://vimota.me) (my personal site) and
[https://referrist.com/](https://referrist.com/):

Our experience was that nextjs was way more reliable (had to restart the
nuxtjs local server every couple page loads), had much much better support for
typescript, and had a more active community and ecosystem which led to
questions being answered more easily and things improving at a quicker rate as
well.

That being said, I think it's great to have competition and hope Nuxtjs
continues to do their thing! I'm particularly excited about the new frameworks
being built on top of or adjacent to nextjs (Blitzjs, Redwood, Remix).

------
janpot
Every time I see someone on this site complain about the build setup
complexity of modern frontend and having to fiddle with webpack/babel for ages
I'm thinking of all the times I have done:

yarn create next-app my-app & cd my-app & yarn dev

and be up and running in 2 minutes.

~~~
rimliu
Why don't you list all the command you have to issue before the project hits
the production?

I can do this too: without the "modern frontend" all I had to do is open my
code editor.

~~~
muspimerol
Uh, "git push"? With netlify or vercel you're up and running in about 60
seconds. I don't see how you get from your code editor to production without a
few commands in between.

~~~
rimliu
That's the point: I don't. So bragging how it is easy to have an initial setup
with a command or to makes no sense. It's what you do till the project reaches
the production state.

------
steffoz
Shameless plug, but if you plan to pair Next with an headless CMS, we
(DatoCMS) make it super easy to handle responsive, progressive, lazy-loaded
images with blur-up thumbs, as our edge CDN takes care of everything for you,
without paying any cost at build time.

[https://www.datocms.com/blog/offer-responsive-progressive-
lq...](https://www.datocms.com/blog/offer-responsive-progressive-lqip-images-
in-2020)

~~~
steffoz
Example here: [https://cms-datocms.now.sh/](https://cms-datocms.now.sh/)

------
djstein
so happy for this, been using canary `nextjs` + `now` for all my non work
projects

my favorite feature of `now` is environment variables, and `next.js` 9.4 has
even better support. so if using `now`, you store your env vars / secrets in
your project on [https://vercel.com/](https://vercel.com/) in separate buckets
for prod, dev, etc

then on your local environment run `now env pull` and get the latest dev env
vars populated in `.env` of your project. this is super great for remote teams
where you don't have to share .env files via communication channels / ask
someone for the latest variable value

~~~
earthboundkid
How do you make sure the secret env vars are only used in server side JS and
never in the client bundle? I was working on a Nuxt app and got really nervous
about this and never found a good answer.

~~~
earthboundkid
Just read TFA and it looks like the Next team has a good answer for this! Glad
they made it simpler.

------
simonw
"Fast and reliable HMR". I had to look this one up. It means "Hot Module
Replacement".

~~~
Tade0
No wonder given that it's a TLA.

~~~
save_ferris
Totally lame acronym

------
moneywoes
For a simple static site, is this a better option than Gatsby?

~~~
Hurtak
Definitely, compared to Gatsby, Next is much simpler. At least every time I
tried Gatsby, I just had to give up after a few hours because of the
complexity and massive amount of boiler plate that you had to stitch up
yourself from examples.

~~~
tomduncalf
Interesting, just yesterday I migrated a site from react-static to Gatsby
(because of a nasty bug that’s been open in react-static for ages, seems to be
struggling somewhat for maintenance) because I thought Gatsby looked simpler
than next.js, haha.

Perhaps it was just that Gatsby felt closer to react-static’s model and it was
more readily apparent how to adapt a react-static site to Gatsby with as few
changes as possible, using their createPage api to replace the route config in
react-static and bypassing all the GraphQL as described in
[https://www.gatsbyjs.org/docs/using-gatsby-without-
graphql/](https://www.gatsbyjs.org/docs/using-gatsby-without-graphql/) \- I
didn’t have time to do a detailed comparison of frameworks or rebuild large
parts of the site.

I was pleasantly surprised how quick and easy the migration was, took me about
90 mins for a site with about six templates and Gatsby seems to build faster
and has a much better ecosystem of plugins etc. I wrote up the process at a
high level at [https://github.com/react-static/react-
static/issues/1203#iss...](https://github.com/react-static/react-
static/issues/1203#issuecomment-626361725) if anyone is interested in the
specifics

Did I understand correctly that next.js isn’t just a static site generator and
ideally you have a server side component too? This was what started confusing
me in their docs, but perhaps I got the wrong end of the stick.

I’ll have to give next.js a proper look next time I’m building a site from
scratch anyway!

~~~
tomduncalf
OK, ended up migrating another site I manage to next.js as the preview feature
is a killer for the site admin, and I have to say I do like it more. It's a
bit more work to migrate but I think worth it. Thanks for the recommendation!

------
leerob
Having absolute imports and aliases built-in is huge. This was a pain to set
up before, so I'm really excited to try this out.

------
mcintyre1994
Incremental Static Regeneration sounds awesome for pages where you don't mind
the data being a request behind but you don't want it completely static at
build time. Seems like a really nice middle ground that lets you keep the
backend simple and get the speed of serving static pages.

------
cjr
Next.js teamed with SWR[1] means I could totally remove redux from my app

[1] [https://swr.now.sh/](https://swr.now.sh/)

~~~
searchableguy
What does that have to do with redux?

How does it replace a client side state management solution?

~~~
hesarenu
I have used react-query which does the same thing. The server responses can be
cached like a redux store. The same query can then be reused elsewhere. You
have setting to not cache at all, cache for some time or cache infinity. I
have used it on redux project and replaced many with react-query. It does feel
better for server data. Not much boilerplate.

------
EGreg
I love static site generators but I often feel they are geared towards one
type of site (like Jekyll or Hugo for blogs etc.)

We have a huge web based “operating system” and constantly adding more stuff.
I spent a couple months architecting and implementing i18n and translations,
for example. I looked at GNU language files and other formats and made our own
JSON based one.

I tried my hand at static site generation, and it basically takes an existing
site and renders certain URLs from the config (including looping through
variable values) as a specific browser would fetch them. If you serve
different versions of a resource to different browsers (eg mobile browser or
css vendor prefixes) you’d have to generate different directories for each
one, which can be cleanly chosen by a web server based on the user agent
string.

This led to a whole host of issues that made us refactor our framework’s
server->client data exports into two parts: session data and regular config
data. So a static page would not have any session data. Any experience of
being logged-in would have to be added via Javascript or widgets hosted in
iframes.

We also have scripts like “combine.php” and “update.php” which minify and
combine files, or look at file modification times and set up metadata with
timestamps and hashes to use for subresource integrity.

Actually, I would say that the idea of “static site generation” can be a
special case of CACHING. To achieve 90% of the benefits, just host your site
through a CDN and set your web app server as an origin server. Pages can be
rendered on demand and then cached on a CDN. You will have to separate out
your session stuff, though! And any dynamicall generated content will need to
go under that.

Finally... I would say that all this is actually pointless :) Because you
should be building client-first apps. Assume Javascript is available and do
all your routing, layouts, header, footer, locally.

There are TONS OF REASONS WHY THAT IS THE FUTURE. The rabbit hole goes much
deeper:

[https://qbix.com/blog/2020/01/02/the-case-for-building-
clien...](https://qbix.com/blog/2020/01/02/the-case-for-building-client-first-
web-apps/)

------
BossingAround
If I want some requests resolved at runtime with Next, what are my choices of
a production-ready server? I assume `npm start` does not scale very well. What
are production practices with Next?

Do you just build your static website and then fetch the data from the browser
like React would? Because if so, why would I use Next and not pure React?

SSR frameworks sound very attractive to me due to Kubernetes and hitting
internal resources that shouldn't need to be exposed to the world, but I find
myself again and again creating gateway services exposing backend services for
Ingress.

~~~
BillinghamJ
`npm start` is just whatever you tell it to do - eg `node ./src/index.js`, and
yes that is plenty production-ready - you don't need any special thing, it's
not like Ruby etc

However, regardless, you should really put it behind a load balancer of some
kind, and it's generally best to do your TLS termination in that too.

And you'll want something to manage the application and make sure it's running
etc as normal. Usually the cleanest option is to have it wrapped up in a
Docker image being managed by an orchestrator, but there's also options like
pm2

~~~
BossingAround
React runs webpack by default. Are you telling me there are large prod
websites running on a dev server in kubernetes somewhere? Because I'd
definitely not feel confident putting that into production. (I am genuinely
curious how is FE run nowadays with cloud-native stacks)

And of course TLS termination and load balancing aside, you do that in your
orchestration platform (so, Kubernetes typically).

~~~
cprecioso
In Next.js there are only four commands:

\- `next dev` starts the dev server with unoptimized code and webpack hot-
reload

\- `next build` compiles all your code to be ready for production
(optimizations enabled and not hot-reloading, pages that aren't dynamic
server-side get turned into regular HTML, etc)

\- `next start` serves that production-ready bundle, with a bare-bones (but
production-ready) server

\- `next export` forces every page to compile down to HTML and gives you a
folder of static markup and js you can upload to any static host

So yeah, `next start` is indeed production-ready, and similar to what major
websites already do. (Also there's no soft, hard, or default dependency
between webpack and react, but the starter template uses it to make life
easier for devs)

~~~
pdimitar
What's the difference between `next build` and `next export`? I couldn't tell
from reading your comment.

~~~
cprecioso
`next build` makes a server that needs to be run with nodejs. Dynamic pages
keep being JS code. the fact that some pages are optimized down to html is an
internal implementation detail.

`next export` makes a folder of static resources (HTML, packages client JS
code, CSS). It also forces every page (even dynamic ones) to compile down to
HTML.

------
sunsetSamurai
Dumb question, but what is the benefit of something like Nextjs over
react/redux? So many things to learn...

~~~
jonny_eh
It provides pages/routing, JS/CSS compiling/bundling, and even optional static
site bundling. It's basically the missing pieces for a deployable react app.

~~~
tiborsaas
If I don't need anything fancy (not even SSR), Parcel does it for me out of
the box:

    
    
        parcel build *.html --public-url https://domain/
    

It's great to use my dev/build tool for static site generation.

~~~
jonny_eh
We're blessed with many great and free options.

------
etaioinshrdlu
I rerender pages on demand like this, but also rerender the entire site every
6 hours. There's some computer science theorem that says tracking the
dependency of which outputs are sensitive to which inputs is actually
identical to solving the halting problem... i.e, no framework can actually
track which pages are affected by which pieces of data. (This is true if you
run custom code. If you are running in some type of limited non-Turing
complete language it could be done.)

~~~
Rauchg
It's true that there will be a limit to what dependency tracking can do,
because if you rename the nickname of an author of a blog post that is in
1,000,000 pages, then we'll fire 1,000,000 function invocations preemptively
to recompute all pages.

That's why Next.js is focused on enabling both eager and lazy pre-rendering
behaviors (AOT and JIT). There is no silver bullet :)

------
jotto
I'm going to shill my own product
[https://www.prerender.cloud](https://www.prerender.cloud) because it's
(mostly) solved this since Chrome headless was finally released in fall 2016.

If you can be patient enough to cache any state you might have in a special
global var that gets serialized during the "server side render", then it works
for any JavaScript framework that can rehydrate/reattach to SSR'd HTML.

------
ggordan
Environment variables being exposed to the client is great assuming this means
they can be configured at runtime and available on the client

~~~
dgb23
You‘d have to assume that they are only read during SSG/SSR.

------
AzzieElbab
Anyone managed to get latest next.js to work with reasonMl? There is an
excellent tutorial on yt, but it is a bit outdated

~~~
marcusr
This is pretty up to date: [https://github.com/ryyppy/nextjs-
default](https://github.com/ryyppy/nextjs-default)

~~~
AzzieElbab
Thanks, I will check it out

------
tren-hard
Can I use nextjs or ssr react with websockets? Does that go against the
pattern of server side rendering?

If I have a large app that has a few pages which use websockets so I'm not
sure if nextjs is something that makes sense for me or if I should just start
with create-react-app and go from there.

~~~
jonny_eh
Sure, why not? SSR just creates the first version of the page, the web sockets
can kick in once the page is rendered.

~~~
tren-hard
Ok that makes sense. Thanks

------
Antoninus
I've been waiting for aliases to come out canary!

------
agustif
Love NextJS, it just keeps getting better at each new release...

Fast Refresh seemed impressive in some GIF's in tweets a couple weeks ago.

------
gherkinnn
Good work! Was very happy with 9.3s new SSG functions. Excited to see further
development in this space.

------
subpixel
So Vercel is like Netlify but with their own web site development framework
(NextJS), and Netlify is like Vercel but with their own CMS (Netlify CMS), and
together they have raised about $120MM.

------
leorio
the only reason I use Nextjs is to avoid going through setting up the router,
I found Gatsby complex to learn in 10 mins.

~~~
BossingAround
Gatsby definitely requires at least a couple weekends, but I really liked
developing with it. As a backend person, it feels very "backend-y" if that's a
word.

What complexities are you running into with router in React? (I'm genuinely
curious, I had to use it a few weeks ago for a simple app and found it
surprisingly simple).

~~~
leorio
no complexities in particular, but with next I just don't have to think about
it.

