Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Honest Review of Gatsby

cra.mr

Post reply on HN
Print view View original

101–110 of 120 posts

Re: An Honest Review of Gatsby

#101

Post by tootie »

zeeg wrote: post #96
tootie wrote: post #91

Serious question: Why generate a static site at all instead of running next.js behind a CDN? Now a publish is really just a publish instead of a rebuild.

It's a fair question that everyone should ask themselves in our shoes. If we did it again maybe we'd rethink. That said, the entire goal was to allow a non-engineer to more easily enable our end-users with documentation. We didn't anticipate the amount of engineering hours it'd take to actually get this functioning well given its adoption and ecosystem. Even the investment into MDX though was to service the core goal…

If the goal was easier content authoring you can tie Gatsby (or next) to a CMS. Something like Prismic is pretty inexpensive. You can easily tie publishes to trigger a site rebuild.

Re: An Honest Review of Gatsby

#102

Post by Rauchg »

jiofih wrote: post #68
tomduncalf wrote: post #29

Earlier quoted context omitted.

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…

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.

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.

Re: An Honest Review of Gatsby

#103

Post by kilroy123 »

pkalinowski wrote: post #3

I wonder why it seems nobody wants to use Hugo. Smashing Magazine appears to be happy with it and they tooted about their experience with Hugo multiple times. Instead, everyone chooses Gatsby, Next or another javascript based framework of this week.

I use Hugo a lot. I'll admit it does have a learning curve.

Once you figure out how to really effectivity use it you can be productive and build out some huge websites and it's fast as hell.

Re: An Honest Review of Gatsby

#104

Post by dangoor »

tomduncalf wrote: post #29
Arathorn wrote: post #11

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

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…

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

Re: An Honest Review of Gatsby

#105

Post by woah »

exogen wrote: post #99

Advice on the "A Broken DOM" section: it sounds exactly like a hydration mismatch. Hydration is the process of React correlating existing DOM nodes from server-rendered HTML (SSR) with the initial render of the React app on the browser-side. (As opposed to what happens without SSR, which is almost always the app being rendered into an empty DOM node – no content exists yet.) Satisfying hydration constraints is by far…

Seems insane that these kind of quirky bugs are an issue in a modern system. Why isn’t there some kind of checksum to catch them immediately?

Re: An Honest Review of Gatsby

#106

Post by exogen »

woah wrote: post #105
exogen wrote: post #99

Advice on the "A Broken DOM" section: it sounds exactly like a hydration mismatch. Hydration is the process of React correlating existing DOM nodes from server-rendered HTML (SSR) with the initial render of the React app on the browser-side. (As opposed to what happens without SSR, which is almost always the app being rendered into an empty DOM node – no content exists yet.) Satisfying hydration constraints is by far…

Seems insane that these kind of quirky bugs are an issue in a modern system. Why isn’t there some kind of checksum to catch them immediately?

React does detect and warn you about mismatches in dev mode. It can be tricky to track down if it only happens in prod, though (due to different data – like start/end times for content coming from a CMS).

React could do better in both dev and prod though, IMO. It doesn't tell you where/which component had the issue, just the type of DOM node with a mismatch.

Re: An Honest Review of Gatsby

#107

Post by nimonian »

chadlavi wrote: post #79

It's amazing to me that there's still not a super simple create react app option out there that builds a react app based on markdown sources for pages. You can get close to it with gatsby et al., but they're all twiddly or fragile in their own ways.

For Vue, Nuxt recently got a content API which I've been using and it is great. If there really isn't an equivalent for React I'd be very surprised.

Re: An Honest Review of Gatsby

#108

Post by taphangum »

ricksharp wrote: post #95
tomduncalf wrote: post #5

I migrated a couple of sites I look after from react-static (which is a nice, simple library but unfortunately had some fundamental issues that it sounded like we’re unlikely to be solved and gave the impression that it was struggling for maintainers e.g. https://github.com/react-static/react-static/issues/1203 ), one to Gatsby and the other to NextJS. I agree largely with the findings described here - Gatsby felt qu…

I use createPages and I get hot reloading when running gatsby develop. I also just figured out how to trigger hot reloading for sources that normally don’t trigger it (markdown files which I was manually processing). Basically, I discovered that gatsby will hot-reload when it sees a change in code files (.tsx). So I created an essentially empty _rebuild-trigger.tsx file and imported that in my main page template. Now…

Please do share!

Re: An Honest Review of Gatsby

#109

Post by snazz »

quickthrower2 wrote: post #25
vsupalov wrote: post #14

Earlier quoted context omitted.

For those who want to like Hugo, but can't stand the templating language: there's also Zola ( https://github.com/getzola/zola ), a superb static site generator, with built-in Sass compilation, written in Rust.

There is a shit tonne of static site generators that ain't hugo though.

Zola is worth mentioning because it is very similar to Hugo in most ways.

Re: An Honest Review of Gatsby

#110

Post by kualto »

zeeg wrote: post #94
wa1987 wrote: post #90

Earlier quoted context omitted.

> If a static site generator put my images in the wrong place and required a gigantic JSON file to be loaded by the client for no reason I would not think twice to get rid of it. Incorrect DOM-output is likely caused by common mistakes (e.g. conditional rendering based on `typeof window !== 'undefined'`) which screw up rehydration. Dealt with it in the past and seen a lot of developers struggle with it. This article…

You're extremely limited in what you can compile as a GraphQL query, so while yes I agree with you that likely there is some stuff we're simply doing wrong.. good luck doing it right. After all, its a database query language trying to create a giant cache of its results. For example, we have what roughly amounts to an component. It uses some contextual information to include language-specific code. That include compo…

Have you tried using page queries? Page queries can accept arguments passed in via the createPage API. Here's some (admittedly hard to find) documentation about it: https://www.gatsbyjs.com/docs/page-query/#how-to-add-query-v...

The basic idea is your page context just contains identifiers for the content you need to display on the page and then the page query uses those identifiers to query for just those objects and request all the properties of those objects that the page needs.

Post reply on HN