0 voters
As we seem to score low on “satisfaction” (or whatever it means, see below), I was a little curious about the demography of the people who responded. I newer noticed this survey when it was announced.
See video here: https://www.youtube.com/watch?v=nPcSxIkt5-I&t=771s
What did you expect?
I am not surprised at all, based on the posts that I’ve seen here, on GitHub and elsewhere.
People have expectations based on what they know and what they know is JavaScript.
Hugo obviously is not a JS framework and Go Templates do not do any favors.
What I like about Hugo is that it isn’t a JS based framework.
The thing about Hugo is that it eliminates the need for a lot of JS scripts on the frontend and that’s the beauty of the software.
Less JS = faster website
I didn’t participate in Jamstack’s survey because I’ve never heard of “jamstack”, and in fact have only heard of maybe half of the items on their chart, none of which belong on the same page as a static site generator. How did someone get so confused as to “score” Hugo in this category to begin with?
-j
It’s because we’re always telling folks to take their JS questions somewhere else!
Half-serious though: I hope we’re not making Hugo a less happy experience because we discourage JS folks here.
I hardly ever use JS myself. In fact, I’m working on an output format for gemini, a protocol that takes fan-favorites from gopher and http(s), in part because I just really like using Hugo for publishing documents. I like simple websites that I can read. JS has never been a large component of that.
Over in the meta Discourse instance (I’m apparently a FOSS groupie with too much time) I’m always running into folks integrating Discourse in other sites, and sometimes into Hugo, and they all get caught up in the JS portions. I let them know I just getJSON posts in at build time, and it’s awesome.
When Hugo creates content pages from data sources I imagine a lot of JAMmers are gonna rethink their strategy (pfft, yeah right, the bright ones will).
Quick aside that kinda reinforces these ideas: my work with Hugo has informed my other efforts, including integrating WordPress with CDNs. Wanting to take advantage for static site reasons, CDNs, their uses and methods, have really opened my mind up to when and where web pages are being built. That in turn opened up more ideas on building Hugo sites and using data caches to build what are essentially “dynamic” static html sites.
No JS (or node, or Grunt, or…). Though I’m starting to see go (modules) as being part of my deploy stack. 
Is GAMstack a thing?
Note that I’m not surprised that if you ask a set of 3000 JS developers, they will perfer a stack that will make use of their hard earned JS sklls.
But there are surely many that do not fall into this category that also do Jamstack work – designers (who do templating and CSS), content designers or whatever they’re called etc. The size of the JS part of a site surely depends, but there are still plenty of use cases where less JS is better.
As to the JS situation in Hugo, I’m pretty sure this one will help:
.
Like me.
Also the ecosystem for JS frameworks is larger, there are ready-made plugins for most use cases. For example for a project of mine I have to develop a JSON output format for the product schema. If I was using Gatsby I wouldn’t need to do that.
But then again I do prefer the Hugo stack because if one does not use Modules there are no dependencies. The basic version of Hugo is still a single binary and that for me is the reason why I spent ages experimenting with Hugo for the past 5 years -yup, it’s been that long already-.
Apples and Oranges. I hated lot’s of questions in that survey. This specific question asks for Frameworks like Vue and React vs. static site generators like Gatsby and Hugo. It somehow did not explain, why those are in the same group.
Perhaps my own situation can be of use to the community. In the past months, while slowly becoming convinced that Static Site Generators are the way to go rather than the reactive front ends with “universal” server side rendering (next, nuxt…), I started with Gatsby (overly complicated), etc., etc. etc. The thing is, I was prejudiced against Hugo, cuz I thought it was “old”, or “old hat”. But been working with Hugo, won’t go into the pros and cons now, but the big takeaway here is that in using Hugo and getting to know it I began to lose my prejudices; fast, like Hugo! Reading the docs, etc., seeing the sensible defaults, seeing it free from “module hell” (I too am a refugee from Drupal), I began to really adopt this framework. So there is a marketing question here, of overcoming the unjustified “old hat”, boring, etc. image (I’m sure you’re familiar with the article Why I left Hugo for Eleventy… cuz “boring”); one of the ways is the vast number of themes… one quick suggestion is to be able to apply multiple filters (including stars on github, last update, etc.) on the even now excellent Hugo themes directory. Also, I can see where the overly complex and top heavy Gatsby got its recent idea for “themes”, haha. They don’t mention Hugo (I believe), but the intent is the same. Anyway, common sense, simplicity and excellence over supposed “cool”.
Few more quick suggestions:
To clarify: there is a sentiment that Hugo is “old” or something? I’m not parsing, but then I only read about Hugo here in the forums. I wasn’t aware of Hugo’s reputation, except folks using GitHub often rank it high by how many popularity stars the main repo gets, itself not really registering as significant to me.
Is Hugo seen as not very cool? Because WordPress just turned 17, so check out grandma over there!
Afero is the file system used by Hugo and it is actively maintained by @bep
Self hosting a CMS like Netlify’s with Gitea comes with a maintenance overhead and it falls outside the scope of Hugo. We do not have the people to go down this route. It is not on the roadmap.
When pages from data are implemented and page generation in Hugo is simply a matter of calling a master JSON then users could use any headless CMS they want.
Pages from Data. That is the number #1 currently requested Hugo feature and when/if it gets developed it will make a big difference.
Absolutely in agreement with you… I’m simply reporting a general (incorrect in my opinion) sense in the Javascript community that I’ve gathered from different blog posts I’ve read (see briefly the one I cite above), so that it can be overcome. It’s as @bep says:
In my case, looking at the shortcodes, I thought to myself (as in cognitive dissonance)… why did I put all that energy into learning React? I don’t just want to throw that away… then I thought (and it was hard for me): if I’m going to use SSG, I may as well choose the best one there is (and most discussions start off by saying “Hugo is the best, Hugo is the fastest”, no matter what they go on to recommend!), the fastest and the simplest. Especially in my case, since I already have experience with Go.
So I agree, it’s silly. Just goes to show how hard it becomes sometimes simply to choose the best tool for the job, and goes to explain the low “rating” of Hugo in the Jamstack survey.
Looking at the massive numbers in Google Analytics/Netlify Analytics for the gohugo.io sites etc. I’m pretty sure that Hugo is a very popular choice, and the numbers are rising. Which is why I suspected that the demographic of the survey did not represent the full user base.
Yes, Pages from Data is at top #1 on my willing list of 2020. I have zero knowledge on coding, Hugo is my first time to touch the programming (in order to build a real site, learn some html/css ), I am so happy with Hugo till now, and looking forward to the great feature (pages from data).
Tweet like thes make me happy:
Little more stats from [W3techs - Hugo stats] (https://w3techs.com/technologies/details/cm-hugo), not ideal for Jamstack comparison, but it shows general usage trends. I see that only Gatsby is ahead, as a js-ssg on this list: https://w3techs.com/technologies/overview/content_management
