I have a vague idea of why this may be useful, but I wish people who upvote a new(ish) tech would take the time to put it in context as to why they upvoted it, why it is interesting, and why anyone should read about it.
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 (which I use as a default baseline), or even the alternative setup (Vuejs version of Gatsby -- I am sure there is one by now, and whatever competes with graphQL).
TL;DR: It enables you create much more complex websites without the overhead they've required in the past, letting you focus more on client-side experience.
Two years ago I went with TakeShape as my publication's CMS, for two key reasons.
The first was that TS gave us a interactive visual front-end for managing content, which we could then publish as a static (i.e. pre-rendered HTML/CSS/JS files hosted on S3) website. Almost every other existing solution is built on directories full of Markdown files, which would be unusable to the rest of my team of non-technical editors and authors. I wish it weren't the case, but some people just don't want to step outside a WYSIWYG editor.
The second was that TakeShape provides a visual interface for modelling our data structures and exposing them through an API. This allowed us to figure out features and content on-the-fly, without solving for any backend problems (database maintenance, server uptime, etc.), while we test our assumptions. With the API, we can have the option to build out more complex functionality over time.
I built our site using TS's built-in static site generator, but I'm really excited to start experimenting to see if we should port our templates over to Gatsby. What I like about Gatsby is that it makes progressive enhancement much easier for static sites, and I expect it'll let us set a baseline experience with basic, static HTML functionality and then layer richer React-driven interactions on top. We've already hit against some of the limits of static in terms of our identity management and interaction, so this seems like a promising next step.
> 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.
> 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.
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.
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.
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.
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.
> 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.
This is why TakeShape also provides a built-in static site generator[0] using Nunjucks templating (think Django, Twig, Swig, etc). If you are trying to build a simple site this is a great option. The great part of a Headless CMS is that you can choose whatever frontend you want and your solution can evolve with your product.
It's a bit like asking why you need an editor to read your manuscript or why you need a typesetter to typeset your book (instead of just saving a Word document in pdf and sending it to the printer).
Take a look at Smashing Magazine, for example. That's a static html website built with Hugo. Guess who built it? Professional frontend developers :-)
Maybe you don't need a professional for your site, or maybe you do. If you are a company that is sold on the idea of having a very fast, elegant, interactive, and yet searchable site, then maybe you do. Also, if you are a frontend developer and already have the skills, then maybe you'll like this tech for your own site (I know many frontend devs do).
In short, being able to scale to as many requests as your CDN can handle, with none of the operational overhead of a traditional web server, is really really nice.
Thanks for that post. That is impressive that you went with the best/fastest tech available today rather than just leverage what was done with Harrys. I am interested with what you actually used for the e-commerce part of it. Are you interacting with your systems that you made for Harrys with GraphQL or did you use a JAM stack orientated solution like gocommerce?
Thank you! We have plans to build many more frontends in the coming years, so it felt like an appropriate time to step back and see what other solutions were out there.
For the e-commerce part of it, it's a custom API written in Scala that handles our inventory, warehouse, and fulfillment needs. As well as interfacing with Stripe for actual order processing. Want to get that team to write their own blog post as several people have asked about it!
https://forestry.io just launched beta support for Gatsby (like today). Forestry.io is a CMS for markdown + Git, where all edits get committed to your repo.
If you want access to the beta, message the folks at support@forestry.io.
We've been recommending Contentful and DatoCMS (https://www.datocms.com/) to our customers. Most pick Contentful due to the perception of being enterprise (Replacing AEM, Sitecore etc.). DatoCMS seems to enjoy a lot of warm reception by people who are coming from Squarespace/Wordpress/Drupal and want something headless but still geared towards Web.
Matt Billman, the Co-founder of Netlify came up with the name to try to counteract the perceptions of non-technical users that Static Sites meant sites that didn't have any kind of dynamic functionality.
He came up with the name in his living room over beers.
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 (which I use as a default baseline), or even the alternative setup (Vuejs version of Gatsby -- I am sure there is one by now, and whatever competes with graphQL).