[c0ffe]

I would not recommend to use Gatsby in a project if it requires a frontend with complexity beyond static-scrollable content.

Some problems that I found after some months of integrating it with an existing CMS:

* Development complexity: depending if Gatsby is run on development or production mode, React's `render` methods are called in the browser or inside NodeJS. Having this code executed in a Node process is expected because Gatsby is a static site generator, but this big split between the environment of development and production builds, paired with a growing codebase that keeps evolving, catches new developers on our team with multiple and surprising bugs.

* Debug complexity: JSX code is hard to debug, because the code that is really executed is generated at runtime, so it is not possible for example, to put a breakpoint in a JSX file from your text editor and start a build with Node running in debug mode.

* Runtime requirements: as far as I remember, executing `gatsby build` on my development machine uses ~3.4 GiB of private RAM for the main node process, and it takes around 5 minutes if the local cache is cleared (it ends in around a minute with cache). Its important to remember this when choosing in which server the build runs.

* Integration: Gatsby does not provide out of the box integration with CMS for content authoring (like for example, page drafts).

Now to be honest, the global idea seems good (static websites built with React), but I would wait a few more years until it becomes more mature to use it again for any future project.

[enlyth]

> JSX code is hard to debug, because the code that is really executed is generated at runtime, so it is not possible for example, to put a breakpoint in a JSX file from your text editor and start a build with Node running in debug mode

I don't get it, is this some Gatsby limitation? I've been debugging JSX since the dawn of time with breakpoints, even with SSR and typescript

[c0ffe]

To me its a bit tricky to summarize, so its a long answer.

During the build, Gatsby compiles JSX and saves the result in a temporal folder. Some time after, it spawns several subprocesses that execute the mentioned resulting JS files (to render each page in the site).

What I meant with "the JSX code is hard to debug" is:

* The JSX code is actually run inside subprocesses, and NodeJS allows to debug a process if its run with the `--inspect` command line argument. But I did not found documentation in the Gatsby website about how to change the arguments of these subprocesses. Note that this only applies to production builds (development mode executes all JSX in the browser).

* From the text editor perspective, the breakpoints are defined in the original JSX source files, not the built ones. I understand that in theory line/column mapping can be done using map files, but I did not have time yet to investigate the cleanest way to make the IDE, Docker (not actually a Gatsby requirement), the temporal Webpack build directory, and Gatsby subprocesses to work together.

[kilburn]

Gatsby does ssr in batch during build time. The pages are rendered in a pool of worker processes. I haven't found a way to tell gatsby to attach my debugger when launching those processes.

Gatsby's docs on debugging HTML builds [1] give you adhoc solutions for specific problems you may have, but 0 info on actually debugging.

[joostdecock]

> I would not recommend to use Gatsby in a project if it requires a frontend with complexity beyond static-scrollable content.

FreeSewing.org runs on Gatsby. It generates made-to-measure sewing patterns, so I think that qualifies as beyond static-scrollable content.

While it's not magic, it is a powerful platform to build your frontend on. JAMStack is a godsend for small open source projects like us since you can just deploy to Netlify and walk away.

We do have a backend (using Express) but it's very minimalistic. Most things are simply handled client-side which means scaling up is a non-issue.

Obviously there are downsides to pushing such an amount of code to the client, but going with JAMStack isa choice we made that we can hardly blame Gatsby for.

I've since written 2 plugins for it for specific needs I had, and contributed some code left and right.I think that's testament to how it's not that hard to wrap your head around.

I've used other static site generators (Jekyl, Phenomic, and brief encounters with Hugo and Hexo) but Gatsby is the first that made me feel I wasn't fighting against it.

Gatsby makes sense for us, as it makes sense for others too. I would recommend it to anyone who is looking for a way to use JAMStack and is comfortable with using React.

[gherkinnn]

> Not recommend in a project that requires more than a scrollable site

I agree. Though I’d add that I found it too complex for a quick .md -> html site as well.

Next does a better job at complex things and one might as well use Hugo/Hexo for a .md blog. I don’t know how much can be found in between.

[Scarbutt]

Now to be honest, the global idea seems good (static websites built with React)

Out of interest, what's good about building static websites with React?

[Cthulhu_]

If you're looking at purely static websites, then it's just a way to structure your application; matter of taste, I reckon, and there's plenty of alternatives on the market that go back twenty years if need be. That said, personally I'm quite fond of the component based approach to building websites - and React isn't the only player there.

But the strengths show when you combine it with e.g. Gatsby which turns it into a hybrid website + app. For first time visitors, search engines, and people with JS disabled it's just static HTML, simple. But for most visitors (browsers, JS enabled etc), after the first load it turns into a webapp and any pageview only requires a single .json file to be pulled in, which can be prefetched (on link hover for example) as well. This gives it the performance characteristics of a single-page app.

[azangru]

> what's good about building static websites with React

As compared to which alternatives?

Personally, I find the splitting up of code into components, together with the power and expressiveness of jsx and its closeness to plain javascript, and the simplicity of updating the ui in response to changes of state to be a very compelling argument for react.

[gherkinnn]

I prefer React over any other templating lang I’ve used so far.

Though I never liked Gatsby.