Live data from Hacker News

Gatsby – A Static Site Generator for React

github.com

1–10 of 73 posts

Re: Gatsby – A Static Site Generator for React

#3
post #2

Just discovered this project. Since I recently wanted to build a new static site, I tried to hack an existing SSG into generating JSON files to support something like React. Wasn't exactly painless. So I'm happy about Gatsby.

Why would you need to generate JSON files?

Re: Gatsby – A Static Site Generator for React

#4
post #2

Just discovered this project. Since I recently wanted to build a new static site, I tried to hack an existing SSG into generating JSON files to support something like React. Wasn't exactly painless. So I'm happy about Gatsby.

Why would you need to generate JSON files?

To make individual pages loadable and consumable by a JS frontend like React or Angular, with meta-data like site title, author, etc.

Re: Gatsby – A Static Site Generator for React

#7
post #5

Can someone make a case for React on static blog sites? How is this a net win versus plain 'ol HTML? For fancy marketing sites I get it immediately, I guess.

The same reason why anybody is using React instead of full site reloads.

Only do a small (api) data request per page, faster page transitions, a more interactive experience.

Just think of the site generator as a static api backend for the the JS frontend.

Re: Gatsby – A Static Site Generator for React

#8
post #7
post #5

Can someone make a case for React on static blog sites? How is this a net win versus plain 'ol HTML? For fancy marketing sites I get it immediately, I guess.

The same reason why anybody is using React instead of full site reloads. Only do a small (api) data request per page, faster page transitions, a more interactive experience. Just think of the site generator as a static api backend for the the JS frontend.

Why not just have HTML generated at some earlier time? It's faster, can be cached, and does the same thing.

I'm a little confused about no page transitions. I don't know why that is a problem that needs solving. Also hot reloading.

Re: Gatsby – A Static Site Generator for React

#9
I'm pleasently surprised that the generated sites work just fine with JavaScript disabled (at least on the author's blog). Which on the other hand makes me wonder why I (as the visitor) need to download a 700KB JS blob that contains all blog posts, React and other things just to read the content.

Without JS: 4 requests, 20 KB transferred, DOMContentLoaded @ 360ms

With JS: 27 requests, 518 KB transferred, DOMContentLoaded @ 22.07s (includes Disqus)

For caching purposes, it might make sense to split the bundle.js into a app.js and content.js and only update the content.js on re-deployments. Not sure if this is just on the author's blog or on every site built with Gatsby.

Re: Gatsby – A Static Site Generator for React

#10
post #8
post #7

Earlier quoted context omitted.

The same reason why anybody is using React instead of full site reloads. Only do a small (api) data request per page, faster page transitions, a more interactive experience. Just think of the site generator as a static api backend for the the JS frontend.

Why not just have HTML generated at some earlier time? It's faster, can be cached, and does the same thing. I'm a little confused about no page transitions. I don't know why that is a problem that needs solving. Also hot reloading.

It comes down to user experience. There's a categorical difference between having to do regular transitions and full-page reloads, and no page transitions and hot reloading. The latter is more overhead from an initial bandwidth and processing perspective, but results in zero-latency interactions, which can be important.

Is a JS framework the best way to achieve that? Maybe, maybe not. There are many factors to consider. I just don't think it's a matter of "this isn't a problem that needs solving."

Post reply on HN