[projectramo]

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

[allanlasser]

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.

The publication, if you're interested, is https://massivesci.com

[monicatie]

thanks for the detailed answer and examples

[seanwilson]

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

[sho]

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

[lowtolerance]

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.

[shaunpersad]

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.

[g_delgado14]

> 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]

>> 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]

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.

[optimuspaul]

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

[projectramo]

Can you say a little about your use case.

Are you equally excited about Gatsby and Jekyll(/Hugo/Pelican)?

[azangru]

> 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]

I think Jekyll's entire advantage at this point is it's integration with GitHub pages.

[azangru]

With about one line in the config file you can have Gatsby integrate with GitHub pages seamlessly :-)

[monicatie]

To add on to this, has anyone tried this stack? What did you like or not like about it? And what goals were you trying to meet?

[g_delgado14]

Yes. It's unnecessarily complex. The target audience is someone who:

- knows modern JS - knows ReactJS - knows webpack well - knows how to deal with node_module dependency hell - knows graphql

[asprouse]

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.

(Full disclosure I'm a Co-Founder of TakeShape)

[0] https://www.takeshape.io/docs/quickstart/

[azangru]

In other words, a modern professional frontend developer :-)

[g_delgado14]

Why do you need a "modern professional frontend developer" to make a static html website?

[azangru]

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