100% agree. These factors are generalized and without context. The context you bring is essential to making the right decision. The next post I'm writing is all about how to apply this framework to your specific context.
While reading Franklin's autobiography, I was completely struck by the systematic, almost algorithmic way he taught himself to write. He designed a process of compressing, reconstructing, and comparing his work against a "gold standard" to find and correct his "faults."
The more I looked at his 4-step loop, the more it resembled the modern training loop for a machine learning model (data collection, forward pass, loss function, backpropagation/gradient descent).
I wrote this piece to explore that parallel, how Franklin basically reverse engineered the principles of deliberate practice and error minimization 250 years before we had the formal language of AI to describe it. It's a fascinating piece of history, but also a practical model for how anyone can learn a complex skill.
I built and led the team that was responsible for the MongoDB user experience. We designed and built MongoDB's integrations with programming languages & third party systems (Drupal, Hadoop, Storm, Spark, etc). Our team wrote the MongoDB user manual too and we were responsible for the websites.
My blog has a lot of talks / posts about the work our team did if you want to read up more about it.
A couple of the Go authors did a lot of the initial coding and continue to code in Acme (rsc, r). The broader Go team use a wider variety: Vim, Emacs, Goland, and VSCode are the most popular from what I've seen.
I did this exact thing when I got frustrated with Jekyll (and friends) and created Hugo. Of course, at the time all SSGs were in dynamic languages and very VERY slow.
Disclaimer: I am the creator of Hugo. Trying to provide an impartial perspective here for the readers.
Everyone has different needs and tastes so no tool works for everyone. Here's how I see Hugo's strengths and weaknesses. I'd love to know what other people see are Hugo's strengths and weaknesses.
Hugo's key differentiators:
1. Ease of install
2. Speed (critical for large sites)
3. Integrated live-reload while editing in near realtime
4. Multilingual capabilities
5. Flexible
6. Very strong community
7. Very good & comprehensive documentation (but not perfect...yet)
Hugo struggles with:
1. Not integrated with Github like Jekyll (though webhooks solve this to a large degree)
2. No plugin support
3. Media & Asset processing not tightly integrated
There are many solutions that work around Hugo's limitations, some which are quite elegant, but at the end of the day they are workarounds and require external tooling.
We would love to address these weaknesses in upcoming releases as best we can. If you are interested in helping we would love to have help.
Disclaimer. I am the author of Hugo and former exec at Docker. I don't speak for Docker and I've been gone for over a year so the following is at best a guess.
From my reading of their blog post I see that their primary motivation for the change was first to consolidate all of their documentation into a single repo, instead of spread across all of their various projects. As they have grown as an organization and now have a large number of projects this approach has a lot of strengths and makes a lot of sense. Any SSG could work in this new formation, but the change gave them an opportunity to make a change. Additionally Github provides a lot of Jekyll features out of the box that help with managing these documentation sites.
I believe it is not a question of performance between Hugo and Jekyll, but a question of Docker's specific workflow. As Github already runs Jekyll server side all the contributors need to do is upload the source file and then Github does the rest. In contrast, Hugo based docs would have to be built locally and then uploaded as completed html. There are easy ways to set up services through github hooks that do the exact same thing as Jekyll already does but that requires additional setting up.
Since Github is doing all the work it is easier on the contributors since all they need to do is `git push`. This also enables people to edit right in the github edit screen and not bother with setting up anything client side. The total time to process the site is likely much longer on Jekyll but the time that their contributors spend is much less as they aren't building the site locally.
This is surprising and counter to what most others are experiencing.
Many of the performance optimizations have tradeoffs and while they increase performance for the majority of cases, some cases will experience slight degradation.
This is also a surprisingly long time for initialization. My site with a few hundred pages on a rather old mac (with an SSD) has
Go initialization:
48.00164ms (48.842363ms) 2.14 MB 18299 Allocs
Do you have your site source available publicly so we can do more testing and benchmarking with it? We'd love to understand the places where it's not improving so we can address them further.
Thanks for this feedback. We are striving to make the docs as good as we can. We would love to hear more about your experience so we can improve the docs further.
Hugo provides many of the same features of Harp.js which is also a good project.
Hugo provides a server for local development like jade.
Hugo is a bit easier to install as it doesn't have dependencies and doesn't require an existing environment.
Hugo is noticibly faster.
The big difference between the two is that Hugo has not focused on compiling all the other assets like scss, less, coffee script, etc. While this is planned for a future release today Hugo users have experienced a lot success pairing Hugo with Gulp. You can read more in this discussion on the forum: https://discuss.gohugo.io/t/gulp-hugo-hugo-npm/1121
Unfortunately by introducing gulp it negates some of the benefits of Hugo's one binary install.
Hugo does provide some advanced features that I don't believe Harp provides including:
If you are happy with Harp and it serves your needs than there's not really a reason to switch.
The big difference is Hugo + Gulp is a workflow that works really well and has all the features that Harp provides (plus all the Hugo features). If you need a feature that only Hugo provides there really isn't a way to add that to harp.js.
I'm the author of Hugo and haven't ever used Harp so take all of this with a grain of salt.
Currently hugo has not focused on this aspect of development and many people have found success combining Hugo with Gulp. There are a few projects related to this that make it pretty easy. There's a good discussion around this on the forum. https://discuss.gohugo.io/t/gulp-hugo-hugo-npm/1121