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

Incremental Builds in Gatsby Cloud

gatsbyjs.org

Post reply on HN
Print view View original

41–50 of 81 posts

Re: Incremental Builds in Gatsby Cloud

#41

Post by kylemathews »

kall wrote: post #35
yazboo wrote: post #33

Earlier quoted context omitted.

True. The article has a decent answer though. Incremental builds are necessary because: > [Slow builds] can be annoying if your site has 1,000 pages and one content editor. But if you have say 100,000 pages and a dozen content contributors constantly triggering new builds it becomes just straight up impossible. Gatsby needs a cloud to host this build server. They also apparently host a nice content editing UI. If you…

They don't host a content editing UI, only a "dynamic" version of the site that you can embed or link in a CMS for draft previews etc. I use and like gatsby a lot and don't think it is generally overcomplicated for what it does. They are really pushing static at all costs though, and these cloud solutions are needed because of that. When seriously evaluting a 100.000 pages / dozens of editors project, if you ask what…

yup, totally on us to prove the static model can scale!

Re: Incremental Builds in Gatsby Cloud

#42

Post by Touche »

tomnipotent wrote: post #37
Touche wrote: post #25

Earlier quoted context omitted.

(3) is incorrect, Gatsby initial page load times are mostly really bad. (2) is both overstated and overvalued. It's overstated because loading a static HTML page from a CDN is extremely fast. Too many people who point at this advantage for SPAs are thinking back to pre-CDN usage with slow origin servers. Of course there are still use-cases where going to network is not wanted, but these aren't the primary use-cases t…

> (3) is incorrect, Gatsby initial page load times are mostly really bad. This has not been my experience, considering all HTML is ready to go from last byte so that other than blocking CSS, rendering can begin ASAP. At this point, no JS is required to interact with the page so things are generally pretty snappy while we wait for React hydrate to kick in.

Pick a few random sites from the Gatsby showcase on their homepage and run them through webpagetest.org Simple Testing.

Re: Incremental Builds in Gatsby Cloud

#43

Post by Touche »

denster wrote: post #29
Touche wrote: post #25

Earlier quoted context omitted.

(3) is incorrect, Gatsby initial page load times are mostly really bad. (2) is both overstated and overvalued. It's overstated because loading a static HTML page from a CDN is extremely fast. Too many people who point at this advantage for SPAs are thinking back to pre-CDN usage with slow origin servers. Of course there are still use-cases where going to network is not wanted, but these aren't the primary use-cases t…

So, for (2) above, not sure I understand: camp 1) at best, a TCP connection is re-used, and the HTML for "page 2" is fetched over the network, parsed, the CSS OM is applied, and then the whole caboodle* is "painted on screen". camp 2) the CSS OM is applied and "page 2" is painted on-screen (possibly even faster if the browser cached "page 2" in a texture on the GPU, so the CSS OM application step may be optimized awa…

It's not faster than the SPA approach. It's just not very much slower. It used to be much slower below using CDNs was common.

Re: Incremental Builds in Gatsby Cloud

#44

Post by mnutt »

denster wrote: post #22
skrebbel wrote: post #14

Having never used a static site generator in anger, can someone explain to me like I'm five what's going on here? My understanding is that Gatsby is a tool that converts a bunch of markdown files into a static HTML website. Why is slow builds a problem for any static site generator? Why does it need a cloud? In other words, what problem am I supposed to be having that any of this solves? Note, I'm trying not to be sk…

I'll take a stab at this, Kyle just shoot me if I get something wrong below :D 1) There's a server-centric approach and a client-centric approach: --a) hand-maintained HTML + php falls into the first camp --b) React (/Angular/Vue) fall into the second 2) If you go with the second camp (b), you end up having a higher initial page load time (due to pulling in the whole "single page app" experience), but a great time tr…

Gatsby can also let you use react components to do some pretty clever things around image resizing, effects, etc that you might expect from a static site generator but couldn’t achieve with just a frontend framework.

Re: Incremental Builds in Gatsby Cloud

#45

Post by tomnipotent »

Touche wrote: post #42
tomnipotent wrote: post #37

Earlier quoted context omitted.

> (3) is incorrect, Gatsby initial page load times are mostly really bad. This has not been my experience, considering all HTML is ready to go from last byte so that other than blocking CSS, rendering can begin ASAP. At this point, no JS is required to interact with the page so things are generally pretty snappy while we wait for React hydrate to kick in.

Pick a few random sites from the Gatsby showcase on their homepage and run them through webpagetest.org Simple Testing.

shopflamingo.com, ideo.com, ca.braun.com, and bejamas.io are all blazingly fast for me.

Re: Incremental Builds in Gatsby Cloud

#46

Post by WnZ39p0Dgydaz1 »

Javascript re-invents "code typing" (Typescript)

Javascript re-invents "Promises" because callback hell

Javascript re-invents "compilers" (babel)

Javascript re-invents "build systems" (webpack, etc)

Javascript re-invents "caching" (incremental builds) - but paid, and in the cloud

Because why not.

Re: Incremental Builds in Gatsby Cloud

#47

Post by WnZ39p0Dgydaz1 »

skrebbel wrote: post #14

Having never used a static site generator in anger, can someone explain to me like I'm five what's going on here? My understanding is that Gatsby is a tool that converts a bunch of markdown files into a static HTML website. Why is slow builds a problem for any static site generator? Why does it need a cloud? In other words, what problem am I supposed to be having that any of this solves? Note, I'm trying not to be sk…

Instead of a Markdown file, imagine your data is somewhere in a REST API, or many REST APIs. Gatsby (and next.js, which I vastly prefer) will query these APIs during the BUILD process to generate your static sites - and that can be slow. Imagine you have a site that list the top 1000 IMDB movies with details. To generate your static site, you need to make 1,000 REST calls to the IMDB API during build time to get the necessary data. Parallelizing and caching it makes it faster.

If it were just Markdown files you probably wouldn't need this since parsing and transforming local Markdown files it fast. But this is Javascript, so nothing is truly fast.

Re: Incremental Builds in Gatsby Cloud

#48

Post by manigandham »

skrebbel wrote: post #14

Having never used a static site generator in anger, can someone explain to me like I'm five what's going on here? My understanding is that Gatsby is a tool that converts a bunch of markdown files into a static HTML website. Why is slow builds a problem for any static site generator? Why does it need a cloud? In other words, what problem am I supposed to be having that any of this solves? Note, I'm trying not to be sk…

Server-side rendering (like Wordpress) generates HTML in response to a URL. Static site generators just visit every possible URL at build time and save the final HTML as files. This makes it easy to deploy and scale when your site is static and doesn't need any features of dynamic server-side rendering.

Gatsby (and other frameworks) automate this process by going through whatever data sources you have (directory of markdown files, databases, etc) and producing the HTML. Gatsby uses React for the templating logic and any client-side interactivity on the pages. Build times scale with the size of your content and number of pages to generate so that's the reason for the cloud.

Overall, static sites are in the hype phase of the software cycle. Most sites are just fine using Wordpress or some other CMS and putting a CDN in front to cache every pageview. Removing that server completely is nice but most static sites end up using some hosted CMS anyway and at that point you just replaced one component for another. There's also advantages to completely separating the frontend code from the backend system for fancy designs or large teams.

Re: Incremental Builds in Gatsby Cloud

#49

Post by Touche »

tomnipotent wrote: post #45
Touche wrote: post #42

Earlier quoted context omitted.

Pick a few random sites from the Gatsby showcase on their homepage and run them through webpagetest.org Simple Testing.

shopflamingo.com, ideo.com, ca.braun.com, and bejamas.io are all blazingly fast for me.

You mean your computer or on webpagetest.org?

Re: Incremental Builds in Gatsby Cloud

#50

Post by baldeagle »

makethetick wrote: post #32
elviswolcott wrote: post #23

Earlier quoted context omitted.

Gatsby is a fairly complex static site generator. At the highest level, it provides an ingest layer that can take any data sources (CMS, markdown, json, images, or anything that a plugin supports) and bring them into a single centralized GraphQL data source. Pages (which are built using React) can query this graph for the data they need to render. Gatsby then renders the React pages to static HTML and converts the qu…

Hi, have you thought about hosting for this yet? I've got a similar site which I originally tried on AWS Amplify but it got too big for the artifact size limit so I opted for S3/Cloudflare instead however build times are slow and more of a manual process currently.

netlify is the de facto build/host for gatsby
Post reply on HN