I’ve definitely been playing with (and thinking about) SSGs a lot lately. I think Hugo is the best SSG out there. Keep in mind that the following opinions are coming from a publisher, writer, and editor and not a professional developer.
Everything on the roadmap seems great, but I’d like to throw out some suggestions, some of which might not be too popular:
- Standardize. Rather than trying to support more formats, plugins, templating languages, etc, I think there is something to be said about just picking one from each and sticking to it. I know this might irritate some people. This seems to be an issue with Jekyll, which has gone through different MD converters, syntax highlighters, etc. As a result, some sites break during upgrades. A 1.0 would be a good idea to pare things down because breaking changes (could be argued) are common. Just a thought for tighter focus/scope.
- Write content to .JSON. I know Hugo’s focus is HTML—and I hope the project steers clear of CSS/JS/ES2015/whatever preprocessors and build systems—but I think there is a strong enough rationale behind creating JSON files for indexing (client-side search) and taxonomies/relationships (decouple SPA CMS [#3]).
-
An SPA CMS Layer. I love the Webhook UI, but the overall build is too slow with bigger sites. I think the CMS should not be part of the 1.0 release and should remain decoupled. This seems like a decent flow—
- GitHub/Bitbucket: for source control (or hosting).
- Hugo CMS: An Ember or React SPA that, for example, can write to files in a repo using the GitHub API. If Hugo can write to JSON files for taxonomies/tags, this could then be digested by an SPA for more complex relationships in the CMS (for example, the ability to write “related articles” to the front matter of individual content files). Building locally could include creating starter templates for list/single pages when new content types are created (ie, with corresponding archetypes) in the CMS layer. Previewing and permissions would be essential for any larger static site with a distributed authorship model.
- Wercker: Watching changes and running Hugo builds. Any tool that watches for changes and triggers a Hugo build would work though.
- Amazon/Google Cloud/GH Pages: Hosting. Again, anything would work.
- Fastly/CloudFlare: Caching. Again, anything would work.
-
+1 for image resizing and optimizing. I think this could fit very well into the standard folder structure for HUGO projects; e.g.
static > images > thumbnails
andstatic > images > optimized
. Maybe it would just be part of the build in thestatic
folder and not require a separate shortcode so as not to mess with the cleanliness of the markdown. Thumbnail or other sizes could be set in the config file. -
More templating functions, intuitive filters and ranges, sorts, markdown flavoring. For example—
- The ability to sort by any custom metadata within the front matter, even at the single-page level. (My apologies, since I think this might already be possible, but I just haven’t gotten it to work.)
- Rename existing methods to be more intuitive or align with some of the “standards” organically built out in previous versions of Hugo (eg, using
.Node.Pages
instead of.Data.Pages
and reserve the.Data
keyword for actual data files) - Triple tics. This doesn’t fit here as much as it does with BlackFriday, but I think this element of GFM is pretty darn common at this point.
-
Revamped Docs. This is probably the area where I can be of most help (if at all). Here are a couple ideas:
- Include both templating and output HTML in all samples. This is great for beginners.
- Don’t merge a feature until the docs have been written for the feature. This prevents merged/added features that are quickly forgotten by the developer team or possibly go undiscovered by end-users (that is, developers building with HUGO).
- Required “Last Updated” with each page or section of the docs.