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.
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.
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.
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?
> 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.
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.
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.
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.