4 ms·

> I am kind of sold on "static" sites, but why is this particular stack and set of solutions so exciting? (As opposed to using, say, Rails on Heroku It's excit

> I am kind of sold on "static" sites, but why is this particular stack and set of solutions so exciting? (As opposed to using, say, Rails on Heroku It's exciting because it's a static site and not using something like Rails? The static site approach still isn't that well known. Right now, I try to use static sites wherever I can because of their reduced complexity.

projectramo 8y ago
Can you say a little about your use case. Are you equally excited about Gatsby and Jekyll(/Hugo/Pelican)?
- azangru 8y ago
  > Are you equally excited about Gatsby and Jekyll(/Hugo/Pelican)? Gatsby, Jekyll and Hugo are all in roughly the same category of static site generators. However. The exciting thing about Hugo is how incredibly fast it builds. The exciting thing about Gatsby is how ridiculously pleasant it is to work with for a modern frontend developer. It has hot module replacement, built in (so you don't need to reload the page to see your changes). It has various plugins (e.g. for various CSS preprocessors, for the dev version of Netlify CMS, for image resizing, etc.), which just work. Its graphql-based data layer, which allows you to query files from the file system just as easily as data from a third-party api during page build, is beautiful. It is also insanely configurable, is written in a frontend-friendly language (JavaScript) and exposes hooks to its internals, which is a great help if you are a JavaScript developer (as opposed to Hugo, which is rather rigid and Go-based). But this comes at a cost of about 60-kB runtime. So if your static site is not insanely interactive to justify this payload, your performance-obsessed friends will point their finger at you, and Alex Russell will tweet another facepalm emoji. Although Gatsby is trying its best to reap as many performance benefits as it possibly can by automatically splitting javascript on per-page basis, and adding link rel=preload tags to prefetch the assets before the user tries to navigate to particular pages. As for Jekyll, I can't think of anything exciting about it.
  - Technetium_Hat 8y ago
    I think Jekyll's entire advantage at this point is it's integration with GitHub pages.
    - azangru 8y ago
      With about one line in the config file you can have Gatsby integrate with GitHub pages seamlessly :-)
sho 8y ago
> it's a static site and not using something like Rails There's nothing "static" about this site. You're still querying a back-end database, you've just outsourced it to a third party. And looking at the example site, it doesn't exactly seem "simple" to me. Hell, instead of just using one (heroku) this one relies on TWO (netlify and the authors, takeshape). This "stack" seems to be mainly being pushed by the people trying to sell the 3rd party backends.
- shaunpersad 8y ago
  Well, that's not entirely correct. The database querying only happens at build time. The output is just static HTML/js/CSS that can be hosted on any CDN (or anywhere else) relatively easy.
- lowtolerance 8y ago
  This approach absolutely does produce static web sites, just like any other static site generator. The querying of a back-end database doesn’t take place when a page gets loaded, it takes place when the static site is being built. This article is just talking about one approach to taking one’s content and assembling it into a static website. The same basic workflow one should expect when dealing with any static site generator, the only difference being in the particulars of content aggregation and the build process.
optimuspaul 8y ago
> The static site approach still isn't that well known Isn't static sites how the web started? I feel like static sites are well known and table stakes for understanding how to build a website.
g_delgado14 8y ago
> The static site approach still isn't that well known Static sites predate web apps. In fact, the first websites were purely static. > reduced complexity you're telling me webpack + react + node_module hell + graphql reduces complexity?
- azangru 8y ago
  >> Right now, I try to use static sites wherever I can because of their reduced complexity. > you're telling me webpack + react + node_module hell + graphql reduces complexity? You are using the word _complexity_ in a different sense. The complexity you are talking about is the complexity of developing and building web pages. However, once they are built they are simple static files that can be served from anywhere. As opposed to the complexity mentioned in the parent post, which is the complexity of running a typical web application that includes a backend server and likely a database. Even such plain and commonplace technology as a Wordpress installation has a higher complexity of running than a Gatsby-based site.
  - specialp 8y ago
    People tend to find things that they have done for a long time less complicated than something new despite it actually being quite complicated. I always ask people when they are debating stuff like this to think about how they would explain it to someone who knew next to nothing about either approaches. JAM stack development puts the complexity on the build side but pays it back on the operational aspect and performance. I have been a Ruby developer for over 10 years and I will say that React/GraphQL is indeed much easier than a full blown Rails app both operationally and development wise. Heroku is a black box that runs Rails and provides databases/load balancers to back it. Here you are pushing your generated pages to a CDN, and using them to host your GraphQL endpoints.

projectramo 8y ago

Can you say a little about your use case. Are you equally excited about Gatsby and Jekyll(/Hugo/Pelican)?

azangru 8y ago
> Are you equally excited about Gatsby and Jekyll(/Hugo/Pelican)? Gatsby, Jekyll and Hugo are all in roughly the same category of static site generators. However. The exciting thing about Hugo is how incredibly fast it builds. The exciting thing about Gatsby is how ridiculously pleasant it is to work with for a modern frontend developer. It has hot module replacement, built in (so you don't need to reload the page to see your changes). It has various plugins (e.g. for various CSS preprocessors, for the dev version of Netlify CMS, for image resizing, etc.), which just work. Its graphql-based data layer, which allows you to query files from the file system just as easily as data from a third-party api during page build, is beautiful. It is also insanely configurable, is written in a frontend-friendly language (JavaScript) and exposes hooks to its internals, which is a great help if you are a JavaScript developer (as opposed to Hugo, which is rather rigid and Go-based). But this comes at a cost of about 60-kB runtime. So if your static site is not insanely interactive to justify this payload, your performance-obsessed friends will point their finger at you, and Alex Russell will tweet another facepalm emoji. Although Gatsby is trying its best to reap as many performance benefits as it possibly can by automatically splitting javascript on per-page basis, and adding link rel=preload tags to prefetch the assets before the user tries to navigate to particular pages. As for Jekyll, I can't think of anything exciting about it.
- Technetium_Hat 8y ago
  I think Jekyll's entire advantage at this point is it's integration with GitHub pages.
  - azangru 8y ago
    With about one line in the config file you can have Gatsby integrate with GitHub pages seamlessly :-)

sho 8y ago

> it's a static site and not using something like Rails There's nothing "static" about this site. You're still querying a back-end database, you've just outsourced it to a third party. And looking at the example site, it doesn't exactly seem "simple" to me. Hell, instead of just using one (heroku) this one relies on TWO (netlify and the authors, takeshape). This "stack" seems to be mainly being pushed by the people trying to sell the 3rd party backends.

shaunpersad 8y ago
Well, that's not entirely correct. The database querying only happens at build time. The output is just static HTML/js/CSS that can be hosted on any CDN (or anywhere else) relatively easy.
lowtolerance 8y ago
This approach absolutely does produce static web sites, just like any other static site generator. The querying of a back-end database doesn’t take place when a page gets loaded, it takes place when the static site is being built. This article is just talking about one approach to taking one’s content and assembling it into a static website. The same basic workflow one should expect when dealing with any static site generator, the only difference being in the particulars of content aggregation and the build process.

optimuspaul 8y ago

> The static site approach still isn't that well known Isn't static sites how the web started? I feel like static sites are well known and table stakes for understanding how to build a website.

g_delgado14 8y ago

> The static site approach still isn't that well known Static sites predate web apps. In fact, the first websites were purely static. > reduced complexity you're telling me webpack + react + node_module hell + graphql reduces complexity?

azangru 8y ago
>> Right now, I try to use static sites wherever I can because of their reduced complexity. > you're telling me webpack + react + node_module hell + graphql reduces complexity? You are using the word _complexity_ in a different sense. The complexity you are talking about is the complexity of developing and building web pages. However, once they are built they are simple static files that can be served from anywhere. As opposed to the complexity mentioned in the parent post, which is the complexity of running a typical web application that includes a backend server and likely a database. Even such plain and commonplace technology as a Wordpress installation has a higher complexity of running than a Gatsby-based site.
- specialp 8y ago
  People tend to find things that they have done for a long time less complicated than something new despite it actually being quite complicated. I always ask people when they are debating stuff like this to think about how they would explain it to someone who knew next to nothing about either approaches. JAM stack development puts the complexity on the build side but pays it back on the operational aspect and performance. I have been a Ruby developer for over 10 years and I will say that React/GraphQL is indeed much easier than a full blown Rails app both operationally and development wise. Heroku is a black box that runs Rails and provides databases/load balancers to back it. Here you are pushing your generated pages to a CDN, and using them to host your GraphQL endpoints.