Theme component/module topic or listing

Meta
1

Since not everyone is on GitHub, and it’d be useful to have a place to find theme components/modules, I’d like to ask if we could have a ‘theme components’ topic here.

That might be overkill, in which case I’d like to know where folks would like to see such a listing. I’m willing to do maintenance on such a list, but I also want it to be extremely easy for contributes to make suggestions for this list, even if the resulting curated list is not editable by all. That can be done here on the Hugo Forum with a (preferably) pinned topic.

Do folks think that, or a Git repo that is pointed to on the Docs site and here, or some other suggestion, is the most useful place for such a list?

Also, when thinking of such a list, I’m thinking of modules

that are not full themes, but may not be a theme component in the

sense.

Is there a different term we should use in that case?

[NB: It’s been a few years since the last post I could find on this topic, so I’m starting this one.]

2 Likes
2

I know there are a few folks working on modules and GitHub actions (like @davidsneighbour @regis @budparr @peaceiris @schnerring @powerfulwebdesign @kdevo, and of course myself @cshoredaniel).

Since my initial query met silence and I would like to see this happen, do you mind if I bug you for information about the modules/actions you have created and are working on in order to create at least the beginnings of a directory of them?

The first thing I’m planning is just to make a basic list of modules, where to find them, purpose, developer/organization, and development status (if known) that hopefully gets pinned by following the posts you folks have made on the forum, but if you have any information or suggestions to add before I start on that, they would be welcome).

3

Hi @cshoredaniel and sorry for not reaching out sooner. It’s always puzzling to know which information is relevant for any given directory.

If you were to create a simple Google Form to pass along Hugo Modules maintainer, I’d be happy to answer your consistent questions.

We do have a directory at Open Source Contributions | The New Dynamic but it’s not very detailed.

2 Likes
4

Thank you @regis. I always forget about the option of creating onlne forms, but that is an excellent suggestion. In the week or two I’ll be trawling the places I know where to look for information and make an initial list, and sort the questions (if any) that I have about the component/module to make a form (with option to simply post in the in the forum).

1 Like
5

I have made a module which emulates a SVG font, but you input a single SVG to get that behaviour (so very little overhead)

I am also developing a responsive image module similar to next.js/image except it also lets you utilise Hugo image processing options. To me it’s just about ready to go, but I could benefit from some feeback

1 Like
6

I wasn’t a member of this forum when you initially asked, so thanks for pinging me.

I thought about this a couple of times as well. Interestingly I thought about this just the other way around: not everyone is a forum member and it’d be useful to have a theme components repo on GitHub.

I thought it would be nice to create something like a Hugo module registry, much like npm, the Terraform registry, or the current Hugo theme showcase. I think @alexandros is/was the maintainer of the theme showcase repo and I remember having read somewhere that at some point a curated list just becomes unmaintainable. I’d love to hear his thoughts about this, maybe how he would have done things differently in retrospect.

So instead of one person maintaining a curated list, I’d envision a registry where any user could add their Hugo module. The Terraform Registry requires a certain naming convention and versioning scheme to provide consistency across public modules. To publish, you login with GitHub, select repositories following the correct naming convention, and publish them with a couple of clicks.

Basically GitHub already is such a registry. All you have to do is add a go.mod file to the root of the repository, making a centralized repository kind of obsolete. What I’m really missing is a way to browse modules and search through what’s already out there.

7

That was not exactly what I said in the past.

A curated list may very well be feasible in the long term, if it has some strict criteria, hence the proposal about community themes that was made some months ago and @cshoredaniel resurrected recently.

In the repo that I used to maintain, the only submission criteria was that a theme needed to have its demo generated in the latest Hugo version. Later we had to put down in writing, that we do not accept promotions in theme demos because there had been a few of those.

Anyway, the real issue is that volunteers, cannot really maintain a listing of hundreds of themes. They may do it enthusiastically at the start but down the road, quality is bound to suffer, since time is a scarce commodity and we all sort of have to make a living somehow.

Therefore whatever you are planning to do be more of a minimalist. Module quantity shouldn’t matter as much as their security, usability and quality.

Well, if I am allowed to be frank the above sounds very idealistic, but honestly I wouldn’t use it myself. Since I only use Hugo modules by people I know that I can trust, like several contributors to the Hugo project.

I may be just a designer who codes, but I really wouldn’t install modules that run code on my machine without checking out the source thoroughly.

As a general rule I also stay as far away as possible from package managers like npm and only use conda, pip and homebrew because I do experiment with Python and machine learning.

The above is just my honest opinion and don’t mean to upset anyone.

And now I am out of here, because there are other things to do.

1 Like
8

Thank you everybody so far for the thoughts. I’ve lot’s to think about, more than the bits I mention below, but it is a start.

@alexandros’s point about keeping it minimalist makes sense. I agree that it’s hard to keep doing with large curated lists on a volunteer basis. I’ve also thought about how to crowdsource the list, along the lines of what @schnerring has suggested, but I too worry about the quality of list.

It seem seems to me that there two conflicting needs/goals: a way to find out all of what’s out there when one is developing, and the other is a need for trustworthy and quality modules when one just wants to grab it and use it to quickly achieve what one was after.

It’s really the same problem for modules as for themes. In the case of themes we have the former, but the lack of the latter is what led to my post that @alexandros mentioned:

I guess the first thing to figure out is which use case is more urgently needed module-wise and concentrate on that. If I can figure out how to do a poll on Discourse, I’ll see about creating one.

9

I didn’t mean to put words in your mouth. It was off the top off my head :smiley:

Since I only use Hugo modules by people I know that I can trust, like several contributors to the Hugo project. […] I may be just a designer who codes, but I really wouldn’t install modules that run code on my machine without checking out the source thoroughly. […] As a general rule I also stay as far away as possible from package managers like npm

Fair point. It’s much like building every binary on your Arch Linux system yourself only after reviewing the code, which works for some advanced power users. But at a certain complexity of a system (or Hugo newbies) this approach is unfeasible and one has to find different metrics to gauge trust. When selecting npm packages, I mostly look at popularity and development activity. Tools like https://www.npmtrends.com are helpful with that.

Anyway, the real issue is that volunteers, cannot really maintain a listing of hundreds of themes. […] Module quantity shouldn’t matter as much as their security, usability and quality.

Different people look for different metrics and I think a balance of manual reviews and automated metrics would be nice. I’m sure there are more good ways to come up with useful stats, but here are some naive ways to give you an idea of what I mean:

  • Quality: ratio of open vs. closed issues, commits/month
  • Security: non-npm vs. npm modules/themes/theme-components
  • Usability: stars, forks, number of contributors

What I’m really missing about theme and module development is plug-and-play composition. I built a theme over the past months to learn Hugo and the hard part was to figure out best practices on how to do things right.

When starting out, I selected the old but popular hello-friend theme. The theme’s README suggests using Git submodules to install it. I didn’t know at the time that this was an outdated pattern. It also bundles third-party libraries by just including minified versions inside the static/ directory. Super hard to maintain and review.

When I began implementing my own theme from scratch, it needed to be on par with hello-friend to be able to migrate seamlessly. I only found out about better patterns by reviewing every line of code of the old theme and comparing it with newer themes to look for better patterns. I pretty much cherry-picked little things from here and there which was a lot of work. It also burdens me with maintaining everything.

I see a ton of things that anyone would love to integrate into their website. A couple of examples:

  • Basic SEO
  • Automated favicon generation
  • Full-text search with something like FlexSearch
  • Image optimization
  • SVG / Font icon systems
  • Automated linting

But every theme includes a different set of features and implements the above differently. When I was browsing the theme showcase I was looking for something that looks nice. I then checked the additional functionality. But there’s absolutely no chance that a Hugo beginner is able to assess the quality of a Hugo theme by the quality of it’s code. It’s all about popularity and other stuff inside the theme they know, like npm packages they’ve used in other ecosystems etc.

1 Like
10

Well, I happen to be an advanced power user :sunglasses:

Anyway… if you feel like creating a curated registry for Hugo theme components, just go ahead, who am I to discourage you…

I wish you all the best!

Well the better pattern -as you probably know by now- is to use Hugo (Go) modules and mounts, so that third party dependencies can be updated with a single command hugo get mod -u etc.

Now all the stuff you mention on your bullet points above are good points. It is indeed hard for new users to figure out that stuff, so as I said go ahead and do what you’re thinking and let us know once this curated listing is published.

1 Like
11

It occurs to me a major reason there isn’t a list of modules/components is that most people (myself included) create modules for our needs for sites (which often includes many of the items from the list @schnerring included) and when we make them ‘public’ it is on an ‘on the off chance it helps someone else’ rather than as something to promote and support, especially for those looking for ‘easy solutions’ and don’t bother learning or reading before trying to use and raising issues (and then there are the folks who complain that it doesn’t also feed their children and do the dishes :open_mouth: ).

I’m therefore not going to go chasing after creating the ‘massive list of (almost) all Hugo modules’.

I’m debating about whether to ask if there are folks interested in participating in a smaller list of modules that are considered stable, useful, and semi-supported (i.e. not for the type of user described by the exaggeration above, but for reasonably competent and willing to put in the work users who are interested in improving the module), but I think the uptake on the use of modules has really just started, and I’m not sure there is much to put in such a list at this point (my modules certainly need some more work and I’m peeking @davidsneighbour’s @regis’s to see if I can save myself doing some of it, especially since they are doing frontend on a daily basis where it’s tinkering (sometimes a lot of work, but still not the same).

From the poking about I’ve done, it doesn’t look like most people with modules/components are ready to ‘publish’ vs. ‘expose as random git repo’, so my inclination is wait for some maturation of the early adopter modules before making a list.

Thank you everyone for you thoughts, though. It’s helped me to think about the amount of effort vs. reward of doing this in a more concrete fashion.

12

@cshoredaniel I am a little late to the topic, but thanks for pinging me! In general, I’ve thought about something similar.

In my little spare time, I am working on establishing a community around Hugo modules that actively develops and maintains them, going by the simple name hugo-mods. Initially, I only needed a namespace to organize my Hugo modules, but I intend to take this further.

Here the goal is also not to provide hundreds of modules that are just a wrapper around a specific dependency but instead to create user-friendly solutions for common problems (already covering some of the use-cases @schnerring mentioned). Two exemplary modules that work this way I’ve introduced here a while ago:

Many of the modules are still in development, and I’m drafting guidelines that help with engineering them throughout the whole lifecycle (w.r.t. project structure, config, testing, preview etc.) to ensure quality.

I’ll probably introduce this whole thing here properly in the next months, when I consider a good base of modules as stable, meant to be used in production.
That being said, I’ve recently had a lot of fun with the modules by creating a first version of the hugo-mods homepage, for which I’m using a theme that I’m currently heavily modularizing.

In the meantime, feel free to reach out if you have any feedback, like the idea or want to become a contributor!

13

@kdevo, It sounds interesting, but I have some caveats:

  1. Of the module ‘ecosystems’ I know about, they seem to be single source shows: (davidsneighbor’s collection, theNewDynamic collection, my collection, schnerring’s collection, and now yours). In part this is because folks are learning what they want, what they are willing to accept, and/or just are not aware of what other’s are doing (in particular I’ve discovered theNewDynamic probably has the most mature ‘collection’ I know about, and I know little about it, or the choices they’ve made, and why).
  2. Who is ‘kdevo’ in relation the existing Hugo community, and why would I put my efforts in 'kdevo’s org (however generically named it may be, and whatever the stated intent may be) module ecosystem?
  3. I’m actually a fan of minimizing the use of Javascript and/or add-ons like font packs and icon collections, etc (especially big ones), which seems to be the opposite of how the ‘hugo-mods’ are oriented, or the development philosophy that that seems to preferred for them.
  4. Personally, my own collection has been for lack of knowledge of module ecosystems that fit my personal philosophy. theNewDynamic looks interesting, but I have to get a better sense of a) what they have and b) how well it meshes with what I want and therefore whether I can effectively contribute and get what is good for both them and I, or build on what they have (where what I want isn’t of interest to them). Likewise with @davidsneighbour’s ecosystem, which he has made an organization, presumably so that others can contribute once it’s mature enough from his perspective (he hasn’t ‘advertised’ the ecosystem here, that I recall, so I’m guessing it’s not ‘ready’ yet, from his perspective).
  5. In general, the current state is I’m not sure how ‘open’ any of the ecosystems other then ‘hugo-mods’ hopes to be (@regis can you comment on theNewDynamic’s ecosystem?), and from my perspective ‘hugo-mods’ is an unknown entity which may or may not pan out, or operate according to stated intentions, so I’m not sure there is a project (other than my own modules) what I can comfortably rely on or feel comfortable being a contributor and/or member of, rather than creating or designing my own module ecosystem.
14

Not sure if these qualifies but if there is a list, I use the following as a Hugo module in my own sites:

:slight_smile:

2 Likes
15

I’ll be be publishing my personal current ‘stack’ soon, the but I’ve decided it is premature for a component/module listing of ‘everything out there’ since

  1. I personally don’t have the time to keep such a list up to date
  2. I gather that most module repositories are still in ‘scratch one’s own itch’ status, even when shared and there isn’t a huge module ecosystem (yet?).

I do appreciate everyone’s responses and have learned about some modules I need to take a closer look at, but I’m no longer thinking this is a ‘ready for prime time’ ecosystem (like Hugo itself, the module ecosystem is very much a work in progress, although Hugo itself is (IMO) quite far along).

16

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.