A static page framework that shoves content into a client side graphql store and then extracts bits out to render a page?
It's popular, so I can't say it was a bad idea.
I guess I'll just say I must be old because it sounds like satire.
It's popular, so I can't say it was a bad idea.
I guess I'll just say I must be old because it sounds like satire.
We were once tasked to build a website for a small publishing house. The site would have pages of books and of authors. Each book page would link to the page(s) of the book's author(s). Each author's page would have thumbnail(s) of this author's book(s). There was also to be an index page, which would contain various books, with names of respective authors, and links to each book's and author's page. It was almost like describing a simple relational database.
Except we wanted the site to be static, and the data about books and authors to be stored in yaml files on github. So book page, author page and index page needed to learn about each other at build time by reading the frontmatter of the yaml files.
With Gatsby's graphql data layer doing so would be trivial, and the whole developer experience would have been highly satisfying. But we weren't allowed to use Gatsby, because the size of the main javascript file that Gatsby (coupled with Netlify CMS) would output was approximately 100 kB, and our tech lead had a strong aversion to large javascript files and to what he considered an overengineered framework. So we had to use Hugo instead. Which we did. Hugo, bless it, also allowed building relationships between data files at build time; but the way it did so was so unintuitive and its Go-based templating language was so cumbersome that I hated almost every moment of working with Hugo. Besides, barebones Hugo did not have a flexible enough static assets pipeline, so we had to write our own (gulp) scripts for bundling static assets. With Gatsby, that would have come out of the box.
Gatsby may not be the technology for building lightest-weight sites (no matter how much the Gatsby team emphasises their commitment to performance), but the developer experience when working with Gatsby is unsurpassable.
I've moved my site from Jekyll to Gatsby, and while there are some nice things, it's not been a clear win. My site is very significantly slower for first load, but slightly faster for all subsequent loads. The build is far less stable with Gatsby, there are ~5 dependency updates per day, things like Sass don't "just work" anymore, but on the other hand, there are a few more packages that do useful things that I didn't get in the Jekyll community.
I've been using React Static [1] for that now, where you just load the data in memory. I'd expected to discover in the process why GraphQL is so useful, but I did not. This might just be my limited point of view.
I guess as soon as you're dealing with lots and lots of data it might be useful, but the projects for which that is the case and which want a mostly-static site seem like they're a very small niche.
It seemed nice at first, but the way they tell you to deal with images and other resources is ridiculous overengineered and gets in the way.
If you throw real data at it, your builds explode from seconds to minutes.
Ill considered, chasing too many fads, and the inability to turn it all off if you don't need it.
That's what gatsby felt like.