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.
590 karma · joined September 3, 2010
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.
Happy to answer any questions!
Perhaps a more accurate wording is:
"You may know me from helping to build the Go Language, Docker, MongoDB, and Drupal & creating Hugo, Cobra and spf13-vim"
My blog has a lot of talks / posts about the work our team did if you want to read up more about it.
Happy to see some Hugo ideas made it into Zola.
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.
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.
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.
A good way to a lot of different ways of how people are using Hugo is with the site showcase.
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:
* Data file loading https://gohugo.io/extras/datafiles/
* Live data https://gohugo.io/extras/datadrivencontent/
* Live reload (this is a huge feature) https://gohugo.io/extras/livereload/
* Menus https://gohugo.io/extras/menus/
* Themes https://themes.gohugo.io
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.
Smashing Mag had a good write up explaining this http://www.smashingmagazine.com/2015/11/static-website-gener...
I just used this technique for https://stevefrancia.com and the wercker files are at https://github.com/spf13/stevefrancia.com
This release represents 448 contributions by 65 contributors
A special shout out to @bep and @anthonyfok for their new role as Hugo maintainers and their tremendous contributions this release.
In my free time I develop a static site engine called Hugo which is hundreds of times faster than others written in python and ruby and is super easy to install as it is distributed as a single binary without any dependencies. You can learn more about it at http://hugo.spf13.com .
It averages ~1ms per page created (hundreds of times faster than most alternatives).
It also boast the easiest installation of all SSGs. Simply download the executable and run. No package managers or dependencies needed.
Hugo is not focused on blogs, but has all the features you would need for any website. Sections & flexible taxonomies are built in. Hugo has support for as many different content types you want.
Hugo defaults are sane and no configuration (other than baseUrl) is needed for most sites.
Learn more at http://hugo.spf13.com
spf13-vim is built to be a base and completely customizable. This is built to be your vim config.
Lastly spf13-vim has dozens of contributors supporting a variety of plugins and languages. This seems focused on squares stack, ruby & coffeescript.
Disclaimer... I'm spf13, so a bit partial, but if you look at spf13-vim from 2 or 3 years ago it looked a lot like this... and we've learned a lot from making some mistakes present here.