Prerendered static HTML comments for Hugo

Announcements
1

A new commercial service called Welcoments is offering a pretty straightforward way to incorporate comments in a blog powered by Hugo:

  1. User submits a comment through a form that points to welcomments.io/api/comments
  2. The comment is processed into a JSON file.
  3. The comment is committed to the dataDir on the main branch of the project’s GitHub repository.
  4. Netlify rebuilds the Hugo site.

Looks pretty cool actually.

P.S. Here is the link to the original tweet that also features a video of the workflow.

4 Likes
2

It may be cool, but relying on need to rebuild site each time when comment is published is rather excessive. I would more rather look for Utterances and integration with GitHub Issues for comments.

1 Like
3

You can schedule your Netlify builds, at whatever interval you wish, with a simple GitHub Action.

4

Hey! Iiro here, the maker of Welcomments. Thanks for posting it here :slight_smile:

The video you posted is showcasing the first time installation + receiving your first comment. The installation wizard connects Welcomments to your GitHub repository, and then makes a pull request with all the necessary partials for you to get started. You just need to copy-paste one snippet into your post layout and you’re done.

As of now, Welcomments is in beta, so it’s free to use. Also the pricing is not fully locked down - I don’t have enough data to make informed decisions about it, so I decided to err on the cautious side on my estimations. I received some feedback on Reddit about the current pricing scheme and there’s a chance my worst-case estimates are a bit inflated.

2 Likes
5

It may be cool, but relying on need to rebuild site each time when comment is published is rather excessive.

“Batched commits” is actually a very commonly requested feature on my backlog and I’ve been sketching it out. So that if you get 15 new comments in 15 minutes, there would only be 1 commit.

There’s also some magic in the optional 2.1kB Javascript snippet that is included - as of today, it loads all comments that haven’t been statically prebuilt as HTML just yet, and adds them dynamically. You can test this in action by commenting here and then opening the same page in an incognito window - you’ll see your comment appear even though the Netlify build hasn’t finished yet.

So if you’re using the JS snippet, you could get away with 1 commit / day without degrading the experience. Welcomments would just temporarily load the comments dynamically like any other comment system.

3 Likes
6

If you have a geek-blog then utterances is good. I have a private blog and since switching to utterances I had no (zero) comments on my website. Because “normal” people tend to not register with services like Github just to say “nice cat picture” or “I know that palm tree”.

I could even see a way where recent comments are loaded via GitHub API by AJAX without having to recompile the whole site every time a comment is posted.

The way welcomments does it is nice but I hesitate because of the price once it’s not beta anymore. I am a cheap person I know :slight_smile: But my blog is not THAT important to me.

And @iiroman :wink: I see your only testimonial is by yourself. I am open for a trade, review for a lifetime account, hehe. (Sorry, cheap, as I wrote)

1 Like
7

The approach with statically storing comments is good, but this need to be evaluated based on environment.

Let’s say that I will have quiet month, no new posts and no new commits to website so no new builds.

Let say you will have 15 comments this month, theoretically 15 or less builds it’s just unneeded use of resources.

8

I could even see a way where recent comments are loaded via GitHub API by AJAX without having to recompile the whole site every time a comment is posted.

I’ve done something like this - the comments are actually stored in a database and then synced to GitHub after spam validation. Which means, I can just query the database for unpublished comments. See my previous comment on how this works.

The way welcomments does it is nice but I hesitate because of the price once it’s not beta anymore. I am a cheap person I know :slight_smile: But my blog is not THAT important to me.

This is good feedback and like I said earlier, the prices are based on some overly cautious estimates to not shoot myself on the foot. I’ve been contemplating to just remove the pricing section for now, collecting some user data, and then give a 60-day heads up when I know what the pricing will look like. A lot of my friends that have successful products are saying I should charge more, but I want to keep it affordable ¯_(ツ)_/¯

And @iiroman :wink: I see your only testimonial is by yourself. I am open for a trade, review for a lifetime account, hehe. (Sorry, cheap, as I wrote)

Email me at hello@welcomments.io and let’s see what we can do :slight_smile: I would be up for giving early users that provide feedback some good deals!

1 Like
9

How is the email encryption done? Your sample on your own site does not show how the “receive an email when a response is posted” part (yet?)

10

Let say you will have 15 comments this month, theoretically 15 or less builds it’s just unneeded use of resources.

Totally. It would probably not be like a “debounce” in Rx terminology, but more like a regular sync based on a given interval.

11

How is the email encryption done?

I’m currently using Cloud Firestore and it encrypts all written data by default. The email addresses are stored in a separate collection that doesn’t have any read access, except for the backend API. I can still see your email address from the Firestore console as they unencrypt the data on the fly, but (allegedly) Google can’t.

Your sample on your own site does not show how the “receive an email when a response is posted” part (yet?)

My sample site does showcase that part - you just need to post a comment where you’ve filled out the email field, and someone has to reply!

EDIT: the emails (or hashes of emails, for example for Gravatars) never get stored in the JSON files posted to GitHub for privacy reasons. There are plans for displaying avatars by other means though.

12

I don’t think the pricing structure is unreasonable for the product as described. This is a product targeting a small and technically adept audience. It seems like a low rate for the amount of time such a person would save by not yak-shaving my own ridiculous comments system, since the value of the time of technical people is presumably high. Certainly I have not managed to get around to implementing comments myself, so I apparently don’t value my own time low enough to get around to it and might benefit from such a service as this.

1 Like
13

I apparently don’t value my own time low enough to get around to it and might benefit from such a service as this.

Let me know if you get stuck or need any help :slight_smile:

14

I am giving it a try @iiroman, thanks. Preliminary feedback:

Firstly, the default instructions recommend committing the welcomments site ID into the theme, which seems unfortunate if I am trying to keep my theme generic. Would this be better as a site parameter?

Secondly, there is a hugo version constraint? I had no trouble on my test machine running Hugo 0.80 but on netlifty where I was running 0.62.1 I got an error on deploy

Error building site: failed to render pages: render of "page" failed: "/opt/build/repo/themes/hugo-pithium/layouts/_default/single.html:4:17": execute of template failed: template: _default/single.html:27:5: executing "_default/single.html" at <partial "welcomments/comments" (dict "context" . "websiteId" .Params.welcommentsId)>: error calling partial: "/opt/build/repo/layouts/partials/welcomments/comments.html:4:17": execute of template failed: template: partials/welcomments/comments.html:4:17: executing "partials/welcomments/comments.html" at <ne>: wrong number of args for ne: want 2 got 1

Anyway I’ve run out of time to do a full deploy right now, but looking forward to taking it for a spin later on

15

Hey! Thanks for the feedback @danmackinlay.

Firstly, the default instructions recommend committing the welcomments site ID into the theme, which seems unfortunate if I am trying to keep my theme generic. Would this be better as a site parameter?

For sure - that’s what I would probably do. However, I wanted to keep the instructions as simple and fast as to get started with the least amount of steps. Hardcoding Welcomments site ID into the layout allows me to provide a single line copy-pasteable snippet, whereas there would be at least 2 steps with the site parameter approach.

Secondly, there is a hugo version constraint? I had no trouble on my test machine running Hugo 0.80 but on netlifty where I was running 0.62.1 I got an error on deploy

It has been tested working on Hugo 0.64.0 and higher. On Netlify, you should set two environment variables under the “Build & deploy” section in Netlify console: “HUGO_ENV=production” & “HUGO_VERSION=0.64.0” and then it should work.

16

I ended up going for a theme tag that looks for the ID in the config file for my hugo site

  {{ if .Site.Params.welcommentsId  }}
  {{ partial "welcomments/comments" (dict "context" . "websiteId" .Site.Params.welcommentsid ) }}
  {{ end }}

Looking forward to seeing how this thing works