Live data from Hacker News

Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

takeshape.io

21–30 of 41 posts

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#21

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 alte…

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

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

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#22

Earlier quoted context omitted.

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

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

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

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#23

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 alte…

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?

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

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#24

Earlier quoted context omitted.

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?

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

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

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#25

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 alte…

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

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#26
post #24

Earlier quoted context omitted.

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

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

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

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#27
Sharing a blog post that my team wrote on some of the benefits we saw from using Gatsby / a static frontend architecture when building https://shopflamingo.com: https://medium.com/harrys-engineering/how-we-used-gatsby-js-...

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.

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#28
post #24

Earlier quoted context omitted.

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

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

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

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#29

Earlier quoted context omitted.

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?

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

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/

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#30
post #4

I’ve been doing some research on headless CMS options. Two other good options are: https://www.netlifycms.org And https://docs.ghost.org/api/gatsby/

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.

Post reply on HN