Hugo vs Wordpress

support
1

Hi all, hopefully this isn’t a can of worms that I’m opening…

I’m going to be doing some work migrating and redesigning a website from one of the PHP CMS’s, initially the client said they wanted it moving over to wordpress because they have another site that is already built in that but speaking to them they said they’d like me to present them with the options and let them make a more informed decision. They are technically competant, they set up their own deployment, write technical documentation using wiki’s, etc.

Aside from normal website concerns (generate more visitors, look nice, etc) priorities for them are;

  • They wants it to be easier to change the look and feel of the site, they have the options to change themes with the current set up but it’s quite involved.
  • They don’t want to be left with something that was a flavor of the month technology 5 years down the line. ie, is no longer supported, hard to find info about, can’t find someone to do work for them with experience of it.

I’ve paired the options down to Hugo or wordpress; Wordpress being the most popular way to do what they are already doing and Hugo being a genuine alternative with a different way of working and different advantages / disadvantages.

I guess what asking for is any articles that discuss the pro’s and con’s of the two systems (maybe more generally like PHP CMS vs SSG) objectively. Theres quite few articles about moving wordpress to hugo but I’d also be interested if anyone has read the reverse. Anything about how easy it is to migrate Hugo to something else in the future. Chip in with your own pro’s and cons aswell.

Ultimately I would rather work in Hugo but I’m undecided as to whether it would be the best for the person I’m working for.

If you made it this far thanks, I look forward to hearing your ideas!

TLDR: Hugo vs Wordpress, user not dev point of view, objectively not hard sell…

2

I have worked with WordPress both for myself and also evaluated it and partly implemented it for a big customer once.

And I would say this:

Only go for WordPress if you really need it.

There are many company who “really need it” and it is a right choice.

And when you ask yourself do you really need it, ask again: Is it real or just because of some nice-to-have features.

Because it comes with a price, a price of maintenance, custom development for plugins in PHP, patching of servers when security updates arrives etc.

So the main reasons why people believe they “must have it” is:

  • Having a database with the dynamic features that provides.
  • A nice UI for adding and editing content.

Solving the first in a good way with static generator alone isn’t possible (but there are options). Stuff is happening on the second part, but still a way to go.

But if this company is full of technical people, editing markdown files should be cool.

As to “product lockin” I would say that Wordpress would be harder to “move away from” than any static generator. Creating new templates for Jekyll for a Hugo site is pretty simple. Markdown should be pretty future-proof as a content format, and if Markdown3000 comes along, a script to convert should be fairly straight forward to create.

Just my 50 cents.

2 Likes
3

I’m going to piggyback on what @bep said and say that Wordpress is a) an amazing ecosystem and testament to the power of open source and b) often total overkill and kind of a pain in the ass.

First, let’s get a couple things out of the way:

  1. You can eliminate Hugo (or any SSG for that matter) immediately if

    • You have a very large distributed authorship model
    • You have a publishing workflow that requires multi-level permissions alongside content that publishes on an unpredictable rolling schedule
    • Your content needs to be truly dynamic in that it changes based on end user authentication
    • You need any kind of user authentication in the first place (you’d have to be clear on this, however, since sometimes logins really mean just embedding Disqus for comments)
    • The site already contains tens of thousands of pages that rely on multiple, well-structured content types. That said, I think Hugo can handle a very, very large blog (ie, really only one complex content type [ie, a post]) without issue. Further, if the content types are well structured and the site is that large, I would avoid both SSGs and WordPress and go with a more modern system designed specifically for content (ahem, Craft CMS).

  2. For the rest of this comment, I’m assuming the site is a public-facing publishing site (ie, only a website in a traditional sense and not a web application)

Based on what you’ve mentioned, I think this seems like a tremendous learning opportunity for your client and for you to come across as an all-around web ninja rather than just a web developer (although being a web developer is awesome).

First, do you have answers to the following?

  1. How big is the site (ie, how many total published pages) and how popular (ie, total traffic/pageviews and scope of influences)?
  2. How experienced are the editors and authors?
  3. If the answer to #2 is “not very” or below, are you expected to provide training and documentation at handoff?
  4. What level of internal technical support can the client provide for self-maintenance and upkeep?
  5. If the answer to #4 is “very little” or below, are you expected to provide maintenance and support for the site
  6. This is the most important: what is the defined content strategy for the website?
  7. How political is the organization? This is a tough question, but avoiding it can have dire consequences w/r/t your long-term relationship with the client.

I find it interesting when people put out “easy theming” as a requirement since this has little to nothing to do with building a good website. Frankly, few to no users will come to a website because of its visual design. I mean, maybe a lot of web designers will come to a site if it’s pretty as all get out, and who knows—maybe that’s your target audience. Picking a good theme is not the same thing as designing based on content, which has been the best practice in publishing for longer than you, @bep, and I have been on this planet combined—and it’s almost entirely unrelated to good UX. Speaking of UX, regularly changing your “theme” for your website will only frustrate end users. Do they think “easy theming” is going to somehow circumvent all need for internal design and proper UX practices?

Regardless of the technology you decide, making a good publishing website is 100% contingent on creating good content.

With that in mind…

  • What content have they given you already?
  • What are they trying to get done with the content?
  • What’s their proposed timeline for development?
  • Are you working with a content strategist, web editor, or the like?
  • What’s the shelf life of the content? (Eg, is this throwaway marketing sales messaging, or is this site going to house archivable intellectual property that is inseparably wedded to the organization’s braintrust?)
    • If this is content that will persist over time, I agree with @bep that you’d be hard pressed to find a more easily exportable format than a whole slew of well-structured text files (ie, markdown).

On the merits of an SSG vs WordPress for content, let me leave you with this analogy:

You want a toaster. You go to a local store and find the perfect model to fit your needs: it toasts bagels, has 4 slots, and even has a fancy dial so that gives you 8 levels of toastiness control. Tag price? $40.

A salesperson comes to you and says, “I notice you like our $40 model. Can I interest you in the deluxe? Don’t be deterred by the $800 price tag because this isn’t just a toaster. It also includes a raclette machine, a steam cleaner for your suits, a vacuum, a penis pump, a waffle maker, and an MP3 player preloaded with Led Zeppelin’s entire discography. When you add up the savings, it’s like getting $4,000 worth of appliances for $400. That’s a total savings of 90%.”

So, here are your choices:

A. Be a smart consumer who sees the deluxe model as being mediocre at making raclette, cleaning your suits, vacuuming your rug, cooking your waffles, and making your penis disproportionately girthy in contrast to the rest of your body.
B. Be the guy who can’t enjoy some of the greatest rock ever recorded because his raclette maker is broken.

Figure out the bread your client has first.

Then buy the unix toaster:)

Feel free to PM me if you’re interested. Regrettably, I have a ton of experience trying to manage multiple “non-technical” users in a variety of CMSs…and I’ve seen all the hellish scenarios played out…too many times.

Cheers.

4 Likes
4

WordPress is great for the “non-tecchy” person. I maintain a couple of WordPress sites for clients who are not computer literate and they find it really easy to use; writing posts is almost like using a word processor and they can drag and drop images onto the interface to automatically upload them. So it’s ideal from that point of view.

There are also plugins to add pretty much any functionality you can think of.

For a “technically competent” [to use your description] client I’d probably try and steer them away from WordPress because it can [as @bep says] be a pain to keep on top of the fairly constant updates and security patches.

I often think there are two “barriers” to getting someone to embrace something like Hugo. The first is getting them to accept the “Edit locally then Upload” workflow. The second hinges on their attitude to Markdown.

I haven’t had a word processor installed on any computer I use for years and, even before I discovered Hugo, I was creating pretty much all the documents I needed for work [I was a Uni lecturer, at the time] in markdown and then filtering them through pandoc to output PDFs or Word docs, as required.

So, from that point of view, Hugo was an ideal fit for me. I was already using markdown all the time and so using it to author content for my sites was a bonus. However for people new to it, it might seem like an extra hoop to jump through, when they look at creating content that way, as opposed to using a WYSIWYG interface in something like WordPress. Of course we know that most online editors actually produce not WYSIWYG but WYSIBTSMOCSTWMAAW*, but that doesn’t often come into the end-users thinking.

As regards “lock-in” or “future-proofing” well, at the end of the day, even if Hugo goes titsup:

A: The code is open source. So your Hugo sites won’t disappear if Hugo is no longer maintained
B: Your actual site content will be in good 'ol static HTML. So you can pretty much re-purpose it to work with whatever other content management system you want.

[*What You See Is But The Surface Manifestation Of Code Spaghetti That Would Make An Angel Weep]

1 Like
5

I forgot one important argument:

  • A static site is (almost always) a guarantee of a fast and snappy website.
  • On Wordpress you must work really hard to get there, tuning and caching, tracking down ineffective plugins etc. – and with a popular website you are potential looking at beefy hardware.
1 Like
6

Wordpress… CraftCMS… Drupal… Joomla…

Q.E.D.

1 Like
8

To expand on the comment from @bep re:speed, here’s an example (and basically a humblebrag):

https://developers.google.com/speed/pagespeed/insights/?url=watters.io&tab=mobile

I’m hoping to have some actual content published by Mid May.

1 Like
9

I am reviving this very old thread because I just want to share my experience with porting a Wordpress site to Hugo.

The full cache of the original Wordpress site was a whooping 2.3 GB.

And now after migrating everything to Hugo the entire project is just 104 MB!

The site now loads at around 3-4ms and before it needed something around 6-10 sec (depending on whether the server was having a good day).

That’s a huge difference. So yes. For up to medium-sized websites with 1-2 content managers Hugo is the way to go by far.

For big sites I would look into something entirely different, like Ruby On Rails. Not Wordpress. Yes, its CMS is pretty. But the rest of it not really.

4 Likes
11

It sounds like an API-based CMS like Dato or Prismic with appropriately stored assets could have been a fine solution in that case!

Sometimes Wordpress might be a good solution because everything is done for you, but then you have to deal with the ecosystem

13

9GB of images sounds like a DAM use case, IMHO, for which neither SSG nor WP is a good solution. If you’re managing photos to open standards (e.g., IPTC ), you want a system that embeds directly to the asset for future management and exportability. Methinks there may be a day in the not-so-distant future where the WP approach bites your client right in the fanny…

2 Likes
14

Why does that sound like that?

I have clients whose MarCom teams create that many (optimized and art directed) assets in a month. They have a separate DAM (as most publishers do), but WordPress handles it fine. I mean, it is a well-tuned site, and assets are in object storage, so no reason it wouldn’t.

15

Right, so they have a DAM that properly handles, catalogues, and manages such assets.

As in, I wouldn’t use WordPress as a single source for managing large amounts of images because that’s not what it’s meant to do. I’d keep images, and this depends on the value of the IP (eg, marketing images vs high resolution pathology slides), in a system designed to manage large amounts of images. If said DAM has the ability to resize and act as a CDN, even better. It’s the same reason I wouldn’t use WordPress for document management or as an intranet…and I wouldn’t use Hugo either for such use cases either.

Keep in mind that my current agency is largely .NET, and in terms of publishing, that means Episerver and Sitecore, although we have done some Craft, other random CMSs, and other custom builds. My point is that there is a specific tool for every job, which was also @jhabdas closing remark :smile:

17

I currently use WordPress for all of those. We may not be able to find the crux of our disagreement in these forums (and honestly, not sure what kind of enlightenment I was expecting from a thread called, “Hugo vs Wordpress”).

I just wanted to point out that WordPress can scale in ways that some folks might not expect. I see sites getting hundreds of high resolution images uploaded each day, it isn’t breaking a sweat, and everyone is happy; seems like it was made for it.

1 Like
18

I think we are disagreeing less than you realize :smile: I assume WP is great at uploading hundreds, even thousands, of high resolution images every day. For example, all of Condé Nast uses WordPress. But that wasn’t my point: the point is that WordPress isn’t an especially good DAM for the features I’ve already mentioned. Same goes for intranet and document management solutions. WP is fantastic for WCM. So is Hugo. It depends on the C and the M…

That said, I’m curious about WordPress as an intranet or DMS. Can you point me to some good solutions? It’s been a while since I’ve done the research, so I’m certainly open to WP ecosystem for BI, approval workflows, document retention, HR, onboarding, BU wikis, asset cataloging, etc.

1 Like