
Next.js 9.5 - leerob
https://nextjs.org/blog/next-9-5
======
tunesmith
Incremental Static Site Regeneration is really compelling, I wonder what the
gotchas are.

For instance, I have a project where the front page gets server-side-rendered
for logged out users. We can't do client-side-rendering because we care about
SEO. And we can't do static-generation at build time because the content of
the front page regularly changes (it summarizes activities of other users).

But with incremental static site generation... even if we care about the
community always having up-to-date data on that front page, we could
presumably set the timeout to like five seconds. That's a heck of a savings
compared to generating it on every request.

~~~
silviogutierrez
Maybe I'm missing something, but ultimately, isn't this just a re-invention of
a site-wide cache?

Back in the day, in Django/Drupal/any CMS, for anonymous users, you'd just
dump each page into memcached with a path URL.

Then when a new anonymous visitor comes, you load it right up from – extremely
fast – memory. Maybe even faster than loading from the file system? Nginx can
actually ask memcached directly, even bypassing the app server.

It feels like we've gone full circle.

~~~
switz
You're not totally wrong, but think of it this way. You have native support in
your application stack for this static 'caching' along with one-click edge
distribution. Which means you can write extremely complex, interactive markup
(it's just React) on top of this very simple distribution system. And you
don't have to build a whole magic caching system or deal with web servers at
all.

I've worked with similar systems to the one you've laid out -- tell me you've
never had to jump into the cache to clear it because a client wasn't seeing
their updates. Or a page was getting improperly cached. Even if it was simple
and effective, it was often a pain.

These days, there are a number of services that will store your html and other
static files on their edge CDN servers (cloudflare workers, vercel, netlify,
among others) leading to your users downloading the files at remarkably fast
speeds. You can reach a pretty amazing TTI while maintaining nigh infinite
scalability.

I will say that while I personally use next.js, I stick entirely with server-
side rendering. I find it to be a better all-around user-experience for my
use-case with several distinct advantages. But I only serve ~150,000 users a
month, who are all relatively close to my server and I don't have much static
content. A modest ec2 instance handles it with ease.

But if I was building an application that targeted many regions and needed
infinite scalability, or one that heavily utilized static data, I'd definitely
consider pursuing the approach laid out above.

We've gone 'full circle', sure. Because React offered a way to write web
applications in a much more consistent, interactive way than anything before
it. But we spent a few years growing our bundle sizes out of control, and
improperly structuring our applications which led to TTI growing and
everything being slow and clunky. Companies that cared and had good
engineering were able to navigate these problems, but your average developer
couldn't. Now with a system like this, they can not only match the performance
of classic applications, but in many cases exceed it.

~~~
manigandham
Hosting is separate from the framework, and the static site hosts you
mentioned are just webserver + CDN packaged together with optional build/CI
layer and some extra APIs to handle form submissions and user logins.
Considering the number of CDNs and 1-click hosting, and the ease of putting
them together, it's all pretty much the same.

The big difference is that these static site frameworks are using
React/Vue/etc for the frontend templating and interactivity instead of a
server-side language that has it's own templating and might require complex JS
integration. But the trade-off is that you give up that server-side ability or
have to use 3rd-party services like a headless CMS instead.

~~~
silviogutierrez
Sort of, but not always.

My blog at [https://www.silviogutierrez.com](https://www.silviogutierrez.com)
is React+Django strictly server side. I like JSX that much. Try loading it
with JS disabled.

Same at my business site: [https://www.joyapp.com](https://www.joyapp.com).

It was a huge ordeal getting it setup (with React SSR, etc), but it's
definitely doable. I've open sourced it but it sorely needs documentation
(incoming):

[https://github.com/silviogutierrez/reactivated](https://github.com/silviogutierrez/reactivated)

Basically, _despite_ the tooling (not because of it), once you get going with
JSX, TypeScript and the like, nothing else comes close. At least in my
experience.

But again, none of the above stops me from dumping that output into a single
cache key per request. It's still dynamic, just cached robustly.

~~~
dopeboy
I'm a fellow django + react developer. What are your thoughts around moving to
Next.js?

~~~
silviogutierrez
In my opinion: nothing, and I do mean nothing, comes close to the productivity
of Django + Forms + FormSets + Admin. I've tried everything under the sun[1]

The model->form and presentation layer is so intuitive and robust that I'm
surprised no JS framework has rebuilt it. Too much is focused around REST
instead of domain specific inputs / outputs.[2]

So yea, I've focused on making Django more React-friendly. I want to stick to
it.

[1] Ok, maybe Rails comes close.

[2]
[https://news.ycombinator.com/item?id=21875331](https://news.ycombinator.com/item?id=21875331)

------
ianwalter
Developing a Next.js app is a really nice experience. I admit when it first
came out I didn't pay that much attention to it because I thought how it did
routing was weird and I don't think the server was as extensible. Fast forward
to 9.5 and there's pretty much no real reason for me to build a custom
Webpack-based setup for my next project.

------
azangru
It's interesting that the React Router team, which is building the competing
Remix framework (similar to Next but based on React Router) is arguing that
instead of supporting static page generation, they will just urge their users
to use CDNs with aggressive caching rules.

~~~
leerob
I'd imagine the hard part with that approach would be cache invalidation. I'm
curious to see how they try and address it.

~~~
dbbk
You could use webhooks on deploy to call your CDN's API to purge the cache.
Otherwise, I guess just keep it time-based.

------
huangbong
Great product. Them deciding to rebrand from Zeit to Vercel was one of the
worst branding decisions ever made.

~~~
leerob
Curious, why do you think that?

Any rebranding will have backlash. It solved the issue of ZEIT Now being one
_product_ whereas Vercel is the _platform_. It also brought a new focus on
Jamstack and front-end developers.

I'll admit I'm biased though, as I'm a Vercel customer.

~~~
huangbong
They could’ve just used ZEIT as the platform then. Vercel sounds like some
generic VC created tech name. Their customer base is literally the exact
opposite. Indie developers, people with Github accounts, technical engineers,
engineering leaders. Not some Salesforce CRM enterprise selling to CEO’s
marketing bs “Vercel” lol.

------
gremlinsinc
Curious, anyone know how this would compare performance wise for something
like Reddit verses livewire/liveview. I know those would be more reactive, but
I like the idea of static pages that are dynamic as well.

~~~
leerob
Not exactly the same, but the Vercel team made a demo using Twitter with
static generation.

[https://static-tweet.now.sh/](https://static-tweet.now.sh/)

------
droptablemain
This is great -- can't wait to update and try this out.

------
dmitryminkovsky
Beautiful release!

------
bionhoward
i love vercel and use it for all my projects, right up until i need to add
auth/api, at which point I switch off of it immediately for security reasons
because there are no static IPs unless you're an "enterprise" customer

it's unclear why they're rolling out performance features while this critical
security hole persists. no doubt i'll get flamed for it, but, it's a really
bad idea to use dynamic IPs to connect to your database with only a
password...

~~~
luisrudge
I guess you’re talking about Vercel.com instead of Next.JS, right?

~~~
bionhoward
Yep

