Why build a website with Hugo?

Meta
1

I already have my opinions. Why in your opinion is Hugo a great choice?

[See discussion: https://discourse.gohugo.io/t/cool-sites-that-run-hugo/36815

1 Like
2

Static websites do not require regular maintenance like Wordpress, for example. And Hugo, for example, generates my blog with over 400 articles in no time.

4 Likes
3

Agreed, though Hugo is still in active rapid development, which does offer fortunately various changes and improvements.

Your point about number of articles and generation time would be better made with a comparative reference. One could, for example, write a node script that processes various markdown files into 400 articles in also a reasonable amount of time.

Not that Iā€™m complaining, I selected Hugo because itā€™s easy to manage files on the backend with text-editor, and generate schedules posts/pages computationally at scale.

Moreover, Hugo has now a lot of capability baked into it making it easy to use once you know how to use it [example: fingerprinting, minification, post-processing, etc.]

The primary short-coming (if you consider it a short-coming) is that Hugo doesnā€™t come with an easy-to navigate front-end. The companies that are using Hugo are typically big enough to have a trustworthy internal development team. Then there is a jump down in size by number of persons to tech-minded bloggers. Small and medium-sized businesses are wary because it causes them dependency on one developer or small sub-set of developers, similar to react, but unlike wordpress.

Next, it is already surprising wordpress doesnā€™t offer a static website option - just a toggle for any given page for example, ā€˜generate static yes, noā€™ could short-circuit all of the server side activity for any single request.

It seems inevitably, because of scale, Hugo front-end desktop/web application pairs will advance toward optionally wordpress style management, where files in directories are operated on like data bases by the generating system (bundled advanced query and search programs - grepping or whatever).

While I prefer using text-editor and system programs to manage files, a more advanced Hugo front-end would solve this, and eventually the incorporation of dynamic website capability (rather than the current totally feasible reliance on third-party services).

Isnā€™t this what ā€˜pancakesā€™ was about? How is that coming along?

1 Like
4

for me, itā€™s about reducing resource requirements and future proofing. I can generate all of my site in about 10 seconds worth of computer time on a laptop, and rsync it to my server in about 30 seconds. once my siteā€™s published, itā€™s stable. No dependencies on things like PHP and MySQL versions. As long as something is able to act as a webserver, itā€™s good to go. previously, I used WordPress and it was taking say 250ms to generate each page from the database for each pageview. Added up, thatā€™s orders of magnitude more compute power needed to run the same website, and it was fragile (plugins out of date? siteā€™s down. PHP updated and broke something? siteā€™s down. MySQL gets throttled? siteā€™s down. etc.)

2 Likes
5

Low cost of operation / maintenance.

The ability to do custom stuff on the fly with relative ease.

But the biggest thing for me, no dependencies.

1 Like
6
  • Single binary. Add it to your PATH and voila
  • Blazing fast. My blog builds in ~ 1 second
  • Content as Markdown. Thereā€™s a peace of mind in owning your content and knowing itā€™s not locked up with a vendor or in a db
  • I like working with plain old HTML and CSS. The templating language allows me to do that
  • The development and support community are top notch
  • Host the built site anywhere you want
6 Likes
7

As a DIY person with non-dev experience, I wanted to try something new apart from Jekyll and also to test the build times. I have moved one site over so far, but it was a painstaking process and the docs are not beginner-friendly compared to Jekyll. Took over three weeks to get things running. I will stick this site with Hugo for now, but the others will be on Jekyll and Eleventy as I monitor the growth of Hugo in the next few years.

8

Lotā€™s of great points so far. Build time, single binary (few dependencies), low maintenance seem to be consistent across responses.

Lightening build time is probably the reason Hugo exists in the first place. I.e., how to take advantage of these pretty impressive go features; examples, goroutines, go stacks, garbage collection - basically the language nuances that offer more flexibility than C++ without disadvantages.

It is ironic, however, that file based directory structure is exactly what brought php mainstream in the first place (or so I understand). UseModWiki was perl based with flat files stored in standard directories, Wikipedia Phase 11 and 111 added relational database and php to enable more efficient management at massive scale. One of Hugoā€™s main pitch points is efficient management at massive scale, but without relational database.

Faster processors, multicores, ssd, etc should mean you can now manage at scale without relational database, but you lose single binary advantage (you already need other programs to manage your markdown files). That should be a key concern for developers of Hugo compatible front-end software.

Other than promise of efficient management for big footprints, I selected Hugo because it was said to integrate nicely with emacs, which it does. In emacs you have org-mode, which offers literate programming, so you can store all of your hugo files in generator files, where you can manage them with searchable notes. Kind of like a manual and a front-end interface all in one. However, elisp at scale is bunk. Better then to use Hugo archetypes and makefile commands. So what Iā€™m doing currently is generating org-mode files from node programs that read json files, because org-mode offers such savvy file management. This is more than efficient, but admittedly not so at scale.

At scale you want the site to build fast, but maybe these cms should only build what is necessary. Keep a block chain registry of what has changed (or in wordpress case, what code is associated with request), and just load or build that. Note, again, not a complaint - wordpress has 10 year development head start over hugo, hugo is likely to advance a lot in the next 10 years

9

I shouldnā€™t know anything about your programming experience, but with respect to Hugo, I recommend learning to troubleshoot code early, also putting extra attention into everything between the <head> tags. Definitely read this: https://github.com/kaushalmodi/hugo-debugprint

10

Hugo aside, static sites are safer (in terms of attacks, hacking) and require less server fiddling for optimal performance. So you can use a server will less RAM. Space requirement is smaller too.

Hugo specific, it has good resources and a good community. With some others you are pretty much on your own.

1 Like
11

Hugo is amazing! But how much you like it depends on what you value.

If you like to KISS

If you like to Keep It Super Simple, then Hugo is for you.

  1. From the command line, hugo new mysite sets up Hugo in about a second. No long ass NPM setup needed.
  2. Getting up to speed with the templating is quick and easy
  3. No ā€œbuildā€ (webpack) setup needed. You get Sass and JS concatenation and minification built in.
  4. Live-reloading during development is build in as well.

If you like speed

Hugo builds are lightning fast

  1. I just finished a site with 1,000 pages. In development, the site is built and loaded in less than a second. Updates made in development are instantly live loaded in the browser. There is no waiting.

Free Hosting

  1. Host for free with Github, Gitlab, Cloudflare.

Production needs

  1. Host with Netlify
  • Set up redirects
  • Mange headers
  • Forms
  • Micro-Function
  • Split-testing
  • Feature testing from branches

CMS needs

Forget about WordPress and other bloated or restrictive platforms.

  1. Use Forestry.io now or wait for Tina.io to be finished.
  2. I think CloudCannon has a solution for Hugo sites too.

If you like to make money

  1. The super fast development process that Hugo offers means less time from development to production. As an old WordPress developer, Iā€™m easily twice as fast with Hugo (I still charge the same amount).
  2. I have Zero issues in production, thus, no more alarms from clients about breaking their WordPress site. No more need to fix hacked sites.

If you think JS for all things is unnecessary

I love JavaScriptā€”but a JS framework is overkill for what I need.

  1. Next.js and Gatsby are rad. But I donā€™t need ANY of it.
  2. I think Webpack is rad, but I donā€™t need any of it
  3. SPAs are rad, but I donā€™t need any of it
  4. A 100% SiteSpeed score is rad, but 98 is good enough.

SEO

Hugo builds a static site. That means SEO by default.

If you like to set it and forget it

Again, Hugo creates a static site. After you launch the site, nothing changes from underneath you.

  • No DB issues in production
  • No plugin issues in production
  • No hacking issues in production
  • No server side issues in production

If you want to manage complication your own way

Every platform has itā€™s own trade offs. For me, Hugo makes it simple and powerful to develop a website and organize content. Forestry makes Content Management easy and powerful. Cloudinary is awesome for managing images. Netlify handles all the other hosting needs I have. Hugo is not a bloated solution for all possible needs. Itā€™s a simple, fast and powerful tool for static site generation that letā€™s you decide how you want to apply it.

5 Likes
12

Based on all the beer websites itā€™s clear Hugo sells :+1: Though if you run anheuser-busch.com through Lighthouse, performance can score at 29.

Also managing inventory requires some developer ingenuity. Having said that, everything you said here is pretty much true.

Once youā€™ve built with Hugo and put together some sexy code for navigating usual web master scenarios, it kills Wordpress.

With Wordpress you have to finagle the interface too often. Even if you build the site with clean html and scss then import it, you have to toggle everything and mess around :-1: , and thatā€™s before other advantages.

Your points are solid imo :+1:

  • Easy SEO once youā€™ve set up and filled in the frontmatter
  • Incredible awesome simple redirects
  • Huge image management advantages, if you choose to manage images in Hugo
  • No DB issues in production
  • No hacking, if you have a decent CSP
  • No server side issues in production
  • Super clean development configuration and set-up (no npm, xampp, webpack, livereload)

And the Javascript point is clean also. There are a lot of cool frameworks that add more complexity than advantage. Even Alpine, which is super minimal isnā€™t that much of an advantage.

2 Likes
13

Have a look at your handy work! Some of your response were incorporated into the following promotional post :+1:

https://buildhello.ca/space_ex_light/2022-02-10-why-should-we-build-our-website-with-hugo/

Donā€™t forget to leave a comment on that webpage! Any things about Hugo I missed would look great on there.

If you post a link to your site in the comments, please include a rel=ā€œnoopenerā€ in the tag :grinning:

14

I was attracted by its fast builds. But I have only moved one site and I donā€™t plan on doing the same in the near future. Hugo is hard to learn, not friendly to those just beginning to learn SSGs and the documentation could use a lot of fine tuning to be understandable.

15

Haha! I actually built an earlier version of anheuser-busch.com about 12 years ago. I changed it from Flash into a static site for better performance and SEO. I wish I had Hugo back then.

1 Like
16

Kudos for early adoption. I feel often like one, but my 8 years feel like nothing compared to yours :slight_smile:

17

Also 8 years, but not with Hugo

18

I posted both anheuser-busch.com and busch.com to buildhello.ca.

If you built either of those, you probably know theyā€™re looking pretty good :slightly_smiling_face: , but lighthouse scores are low on both. I know, owners arenā€™t jumping a lot on the lighthouse scores, but there is something about getting at least performance and seo into the green, and as I understand google is rewarding high scores.

Looks like image conversion issues, among other things. I kind of lucked out on my first try with Hugo image stacking and came up with something super decent, both for templates and short-codes. At scale could be admittedly a little dryer, but even quick and dirty would boost those scores

19

@cloud-nine - I have nothing to do with the latest versions of AB.com and Busch.com. Years after I left AB, they then rebuilt both sites to use WordPress. They had remained on WP for years. I was happily surprised to see that it had been redesigned again to use Hugo.

I agree that Lighthouse scores are important. I love how Hugo leaves all of this up to the developer though. I hate how WordPress handles all of this. As far as images go, Iā€™m a huge fan of using Cloudinary to manage all of the image based performance needs. If you use Forestry.io as a CMS with Hugo, then you get the Cloudinary integration with it.

1 Like
20

@gandhiShepard

I recently gave Cloudflare a go on an old site with a bunk host and it visibly lifted the performance and added ssl and brotli compression = awesome.

Havenā€™t given Cloudinary a go yet, read and ripped your post about third-party hosting 1000 images though!

Once I realized Github Pages comes with its own CDN (or someone elseā€™s) and gzip compression, I left it alone.

The only thing I dislike about Github Pages is no custom .htaccess file.

Iā€™ve yet to give forestry.io a go yet. As as soon as needed, I will have a look at all of the currently available front-end products and write a comparative review on Build Hello.

Build Hello has some cool article formats with room for tech company advertisements on the sides. I used a variation of the pancakes system to configure custom advertising templates based on content grouping, but have yet to court sponsors!

Main things Iā€™m looking for out of a front-end however include, off the top of my head:

  • Custom front matter variables with text box input explaining what they do
  • Some method of grouping and arranging front matter variables within the UI
  • Downloadable version for desktop use (like Figma)
  • Integration with system shell, and trigger for deleting leaf bundles and creating leaf bundles (with security checks)
  • Admin access layout editor, with a menu of grouped saved layout links (though I would never use it)
  • Image upload button - with custom target directory (save as links to system explorer or linux/mac equivalent)
  • Custom short-code editor, with a menu of grouped saved short-code links
  • Purge public folder
  • Various Hugo commands from a button with option to add arguments (obviously it would have to have access to your Hugo executable)
  • Custom config editor
  • Obviously a markdown writer
  • Custom help or search so you can write your clients some basic documentation explaining your app
  • Various levels of access (for noobs, developers, admins)
  • Hugo code linter
  • Baked in debug-print
  • Select your Hugo server browser
  • Obviously a server button