[Arathorn]

This review nails it. It takes the matrix.org gatsby website 20 minutes to build currently, which is excruciating when trying to do quick fixes for blog content - you just sit there wondering what the graphql is actually doing and what it’s giving you :/

edit: https://github.com/matrix-org/matrix.org/ if any indignant gatsby fans want to tell us what we’re doing wrong

[tomduncalf]

Yeah, SSG build times are certainly an issue in my experience, even for smallish sites. I quite like the incremental regeneration idea in NextJS: https://nextjs.org/blog/next-9-5#stable-incremental-static-r... - sounds like it will rerender pages in the background as traffic comes in to them, while serving a stale version to the original request. I guess there are times when this might not be acceptable though... in which case really you just want to be able to rerender the subset of pages a given change affects, but this isn’t always easy to work out.

[jiofih]

It’s kinda funny to see that go around in circles. “Pre-rendering content as requests come in” is exactly the same as having dynamic pages and a layer of caching, as had been standard practice for the last 20 years. Some people just really like to “solve” already solved problems.

[Rauchg]

In principle, the two are very similar. However, the way we implement it is similar to database replication. Once a static page is produced, we can store it for usage across the entire edge network. This means you get the benefits of traditional static generation too: less backend load, higher availability, lower latency.

[tomduncalf]

Haha, that’s true. I guess the advantage to NextJS is it comes “batteries included” - you don’t have to worry about setting up a cache etc. Obviously for some use cases setting it up yourself will make more sense

[dariusj18]

As they say, "Get a framework that'll do both."

[dangoor]

This totally depends on the SSG. Hugo can generate thousands of pages in a couple of seconds.