Sorry to get a subject from the ground. Actually I saw that this is precisely what Gatsby does. To go further, what it can do is connect to a headless (or headful) CMS and generate content. And inside Wordpress, there is an addon that can generate a Gatsby site on-the-fly.
To me, this is a pretty cool feature because it lets non-tech people create content that is then transparently published statically. This is what Fernando Poumian explains in his post.
There may be something I don’t understand, but “generate a Gatsby site on-the-fly” in Hugo does not make much sense to me. Hugo and Gatsby are two different beasts, both great at what they do. One of the big things about Hugo is, however, that it is dependency free, i.e. one binary download. Gatsby does not fall into that category.
Thank you for your answer. Actually I did not want to generate a Gatsby site on the fly. I am interested in Hugo. Just doing a comparison for a feature I find very exciting!
Instead of just using plain text files as sources, Gatsby is able to get data from plain text files, from a database, or from a CMS like Wordpress through the Wordpress REST API.
This simply allows clients to create content inside a Wordpress (or whatever headless CMS) instance. In this workflow, the CMS is used only to manage content, not to render templates. Then the static site generator comes into play to do its job. For a customer who is not acquainted with CLI and too much technology, this is very nice!
Apart from Wordpress, the idea is obviously to be able to use any headless CMS to manage content. Actually, this seems to me one possible way to get the Graal of static site generators: ease of use for the clients. In that way, the Hugo community do not have to create its own GUI for non-tech-savvy clients. It only has to create an interface, and then to create plugins to branch onto each CMS. Like in the UNIX philosophy, Hugo could become a brick to branch on other softwares. And it still could be used as a standalone for plaintext content files.
Gatsby can do that, and IMO this is why it is growing so fast these days. But sorry Gatsby, I do not like much the Javascript soup, and I like the way Hugo does things.
@lebarde DatoCMS is an headless CMS that allows you to publish their API to a Hugo site. I don’t really like the way they accomplish it (they write the API to documents, which Hugo then reads), but just bringing it up for something for you to aware of. And, there are Git-based editors like Forestry or Netlify CMS that allow you to accomplish the same thing. And, of course, Hugo can consume a variety of external content, with the only limitation that it doesn’t create pages from that content, which I think is what you were initially getting at. Hope that helps!
Indeed @budparr, you are right! This is a cool feature. I imagine that there can be at least two approaches: first, the CMS is exporting and calling Hugo in an integration environment (which is, I guess, a best practice). Or Hugo could, at build time, look into heterogeneous content sources without having to convert every content into a plaintext file.
And in that second approach, I imagine that the CMS could also call Hugo to update the website, but in that case the way Hugo should recover the data would be defined into the Hugo configuration.
These are two paradigms! Thank you for your explanation!