Rant HN: Next.js and Gatsby are not static site generators | Hacker News Reader

Rant HN: Next.js and Gatsby are not static site generators

8 pointsushakov9 comments

Let's look up Wikipedia article "Static web page"

> A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user's web browser exactly as stored,[1] in contrast to dynamic web pages which are generated by a web application.[2]

what Next.js and Gatsby actually do is they statically source your content and generate a dynamic React App

the generated React App then adds dynamic functionality, for example if you navigate the page instead of redirecting you to the page itself, it will redirect to a virtual route

once you hit the virtual route, Gatsby for example will fetch a .json file with the page contents and render it dynamically via React

now, what's the deal? here's the deal: if your website needs javascript to work, it is not static per se!

if your aim is to create a truly static site, you should use a real static site generator, examples: Hugo, Zola and Jekyll

stop calling Next.js and Gatsby static site generators! They are not, they are React App generators with statically sourced (bundled) content

Totally disagree on that.

They are static site generators, and for many content sites like blogs etc, most features (linking etc) will work even if React does not load/hydrate, like a traditional SSG.

Navigation does not 100% need to be SPA. The SPA mode can be seen as a progressive enhancement.

For sure, if you want to have 100% of your React-based site to work with JS disabled it requires additional care to ensure all/most functionalities work without JS. Some things are impossible or quite hard to achieve, but most content-centric sites can work without JS.

Disclaimer, I'm the maintainer of Docusaurus.io, a popular Facebook/Meta doc SSG based on React, powering the docs of React-Native, Babel, Prettier, Supabase... Docusaurus is content-centric and considering React hydration as a progressive enhancement is an important part of this project for me.

Go to docusaurus.io and disable JS, see for yourself that most of the things will keep working and the experience remains great even if React is never loaded/executed. A few things don't work yet like the dark theme switch or the search engine, but I have good plans to make this work.

I believe in the future we'll see more and more React as a progressive enhancement. Other React frameworks such as Remix (not SSG) are also largely advocating for progressive enhancement.

You talk about "virtual route" but the thing is that the statically generated html page and the virtual route renders exactly the same thing.

"if your website needs javascript to work, it is not static per se!": this assumes that all Zola/Hugo/Jekyll sites will work fine with JS disabled, which is not always the case. Similarly, it is possible to build features on a Hugo site that are not compatible with progressive enhancement. If you add an Algolia search input for example, will it work without JS on your Hugo site? React or not, it won't.

what does Docasaurus need 100kb of JavaScript for? why do you need progressive enhancement for what essentially is a documentation site? why does it take 100mb+ of npm dependencies to generate a page?

> if your website needs javascript to work, it is not static per se!

That's one way to look at it. Then again, if I can serve my app using a static file server, how can it be considered anything other than static files?

The Wikipedia articles about the subject are very poor, probably because there are no good developers that know the subject well that are also Wikipedians.

I've tried to correct the thing and added this:

https://en.wikipedia.org/wiki/Server-side_scripting#Server-s...

I've also reported the issue to some Wiki Project but there where no reply.

But it's really bad because of this: https://en.wikipedia.org/wiki/Web_template_system#Static_sit...

Instead of rant, why not fix Wikipedia and write proper articles for Server Side Generation and Server Side Rendering or whatever is needed.

the rant mentions Wikipedia, but i'm not accusing Wikipedia in particular

i'm accusing a whole bunch of tech bloggers and devs, who've been brainwashed by JavaScript cult

Hugo and Zola are fantastic static site generators but if your requirements

include building static pages based on an api response, Eleventy.js has first class support.

[1]: https://www.11ty.dev/docs/pages-from-data/

[2]: https://learneleventyfromscratch.com/lesson/9.html

i’m using Zola! link in my profile

btw. i'm not claiming Next.js and Gatsby are misadvertising themselves, but instead i see lots of people categorising both frameworks as such, which is wrong

i'd like to emphasise that while both frameworks have their uses, they are not static site generators and suck terribly when you really need to generate more than a bunch of pages

Large production instances of Next.js tend to rely on server-side rendering almost exclusively. Paired with react-query + cached api/Redis, you get short build times and a fast user experience (Remix has a very similar approach as well).

Gatsby is also a great static site generator. Most sites render with JavaScript disabled + the framework provides some of the best tools to create increase Lighthouse scores. It's only weakness is the build speed once you pass +100 pages.

That said, the primary issues around static site generators are:

1. Build speeds - (choose Hugo, Zola, Eleventy.js)

2. Creating pages from external data - (choose Next.js, Eleventy.js, Gatsby)

3. Real-time previews - (requires work but most JS-based frameworks can do this without issue)

4. Ease of use - (choose Jekyll)

Reply on news.ycombinator.com