Fundamentally these days WordPress is an entire platform and Hugo is 'just' a CLI SSG. Big difference.
I've been programming for 35 years, doing non-trivial webwork for 20 years, helped kick off the Joomla project (among others) and built blogs, websites and larger applications with quite a few systems, including the ancestors of WP, b2cafelog and b2evolution (That last one still is around btw. Check it out. ... Flashback time! :-) ).
The thing that bugs me big time is that WP these days has a critical mass that other platforms wouldn't even dream of having but still carries around with it some bizarre legacy stuff including an app-model initially designed by people who couldn't code and shouldn't have been let near a keyboard. In that regard WP is just like quite a few other systems. The WP crew (aka Automattic) are in a bit of a jam, since they can't redo WP as they would like to without making a userbase of 100+ million people very angry. Admittedly, that is a strange luxury problem to have that others haven't encountered in that form yet. They did that mistake once with the Gutenberg project for the last major 5 update and are still doing quite a bit of damage control for that.
The huge upside of WP is that while it does have an amateur (i.e. basically non-existant) model, it doesn't force it on to you like other systems such as Drupal, Typo3 or Neos (shudder). Meaning you can basically do your own thing once you've learned how to tie in to WPs user/auth system and god-object "Post" model and two or three other things. Which all in all takes roughly 30 minutes and basic Google skills.
What I've also noticed about WP is that while it does in parts look like it was architected by 5th-graders on crack, there are some counter-intuitive things in WP that actually really make sense in a strange way. Example: Everything you can fiddle with is procedural. This seems bizarre, but once you notice that any wrong bit of code instantly results in a white screen of death you know that even the n00biest of n00bs will notice their bugs instantly. And that's actually a feature for WPs epic army of quasi-amateur plugin builders.
There is also quite a few things that WP does well by default. No flaky bolted on templating for instance. Templates/Themes are PHP (which is a templating engine in itself ... a detail roughly 350+ projects somehow fail to notice) and WPs helper functions, as it should be with a CMS. Child templates is PHP templating done correctly. And while the media manager doesn't have folders because "historic reasons", the default media handling is perfect for just about every project. And the updates media management has gotten other the years focused on automating stuff that really matters and that web-n00bs wouldn't even notice, such as image sizes and bundling. Well done, I have to admit.
What WP also has going for it is that it's the only system I've encountered that doesn't have people bursting into tears of despair when I ask them to use it to maintain their content. Maybe WP just was there at the right time, when the bloggosphere moved mainstream and every n00b wanted to post blogs and pictures online and needed a quick and easy way to do that. I don't know, I only know that WP does not expect anybody to understand relational models before they run into that problem themselves. And by then users usually already have tons of content on WP.
The head of WP, Matt Mullenweg, also has the habit of thouroughly looking out for larger trends in the webworker sphere and incorporating them as first-class citizens of WP. WP did that with jQuery some 8 years back or so and they did it with React for the Gutenberg/5.0 update. React is part of WP right now, meaning you don't even have to deploy it, you can just call the wrapper function wp_render() in the frontend and have all the ReactJS goodies the JamStack camp would want. Smart move IMHO, given that React is a critical part of the Gutenberg editor. A few versions down the road WP can change it's backend from PHP to Node or Deno if trends are heading that way and users wouldn't even notice.
Yet Hugo comes back to me every once in a while.
For larger projects and maintaining many clients at once I'm perpetually considering doing something different and the old-school "Dreamweaver 3" type SSGs like Hugo seem a good approach. However, that would need lot's of work that's already there and finished in WP, so I'm still on the edge.
And it's a fact that most of the web is dynamic for no good reason other than people not needing to install CM Systems on their local workplace. The thing that has me hesitant about Hugo is that it sorely lacks any sort of user friendly frontend for regular editors, expensive commercial services aside. One would have to build that and give the nature of Hugo it would have to tie in seamlessly with Git in a n00by-friendly way to make any sense for larger projects.
Extending WP to use proper Caching and SSG as a plugin (those exist) actually is a strong reason to stick to WP. It's only for agencies that want to build their own super-performant pipeline and move far beyond WP that diving into Hugo as a foundation for web content makes sense, AFAICT.
I'm on the edge about this and may have to do some tryouts for better judgement. But getting Hugo up to speed feature wise would take quite a bit of work. Can't tell just yet if that's worth it.
I'm a software developer who writes about Laravel, JavaScript, Rails, Linux, Docker, WordPress and the tech industry. Follow me on Twitter @tylerlwsmith
You've got some great insights here–this comment could be turned into an interesting blog post with all of the perspective you have on the industry! If you ever choose to write that, please link it here 🙂
I like Hugo quite a bit, but I don't think I'd ever use it for an end-client: it's too technical of a tool. I've use it for personal sites before, and I might again in the future. My biggest reservation with Static Site Generators in general is that once you want some dynamic features like form submissions, you either need to buy a SaaS product or set up a distributed architecture with an API server that handles those features. At that point, some kind of monolith seems simpler.
I have some pretty big reservations about WordPress's architecture, which I wrote about in the post linked below. That said, WordPress is still my platform of choice for building sites for non-technical clients. It's a pragmatic choice, whereas Hugo just isn't.
Fundamentally these days WordPress is an entire platform and Hugo is 'just' a CLI SSG. Big difference.
I've been programming for 35 years, doing non-trivial webwork for 20 years, helped kick off the Joomla project (among others) and built blogs, websites and larger applications with quite a few systems, including the ancestors of WP, b2cafelog and b2evolution (That last one still is around btw. Check it out. ... Flashback time! :-) ).
The thing that bugs me big time is that WP these days has a critical mass that other platforms wouldn't even dream of having but still carries around with it some bizarre legacy stuff including an app-model initially designed by people who couldn't code and shouldn't have been let near a keyboard. In that regard WP is just like quite a few other systems. The WP crew (aka Automattic) are in a bit of a jam, since they can't redo WP as they would like to without making a userbase of 100+ million people very angry. Admittedly, that is a strange luxury problem to have that others haven't encountered in that form yet. They did that mistake once with the Gutenberg project for the last major 5 update and are still doing quite a bit of damage control for that.
The huge upside of WP is that while it does have an amateur (i.e. basically non-existant) model, it doesn't force it on to you like other systems such as Drupal, Typo3 or Neos (shudder). Meaning you can basically do your own thing once you've learned how to tie in to WPs user/auth system and god-object "Post" model and two or three other things. Which all in all takes roughly 30 minutes and basic Google skills.
What I've also noticed about WP is that while it does in parts look like it was architected by 5th-graders on crack, there are some counter-intuitive things in WP that actually really make sense in a strange way. Example: Everything you can fiddle with is procedural. This seems bizarre, but once you notice that any wrong bit of code instantly results in a white screen of death you know that even the n00biest of n00bs will notice their bugs instantly. And that's actually a feature for WPs epic army of quasi-amateur plugin builders.
There is also quite a few things that WP does well by default. No flaky bolted on templating for instance. Templates/Themes are PHP (which is a templating engine in itself ... a detail roughly 350+ projects somehow fail to notice) and WPs helper functions, as it should be with a CMS. Child templates is PHP templating done correctly. And while the media manager doesn't have folders because "historic reasons", the default media handling is perfect for just about every project. And the updates media management has gotten other the years focused on automating stuff that really matters and that web-n00bs wouldn't even notice, such as image sizes and bundling. Well done, I have to admit.
What WP also has going for it is that it's the only system I've encountered that doesn't have people bursting into tears of despair when I ask them to use it to maintain their content. Maybe WP just was there at the right time, when the bloggosphere moved mainstream and every n00b wanted to post blogs and pictures online and needed a quick and easy way to do that. I don't know, I only know that WP does not expect anybody to understand relational models before they run into that problem themselves. And by then users usually already have tons of content on WP.
The head of WP, Matt Mullenweg, also has the habit of thouroughly looking out for larger trends in the webworker sphere and incorporating them as first-class citizens of WP. WP did that with jQuery some 8 years back or so and they did it with React for the Gutenberg/5.0 update. React is part of WP right now, meaning you don't even have to deploy it, you can just call the wrapper function wp_render() in the frontend and have all the ReactJS goodies the JamStack camp would want. Smart move IMHO, given that React is a critical part of the Gutenberg editor. A few versions down the road WP can change it's backend from PHP to Node or Deno if trends are heading that way and users wouldn't even notice.
Yet Hugo comes back to me every once in a while.
For larger projects and maintaining many clients at once I'm perpetually considering doing something different and the old-school "Dreamweaver 3" type SSGs like Hugo seem a good approach. However, that would need lot's of work that's already there and finished in WP, so I'm still on the edge.
And it's a fact that most of the web is dynamic for no good reason other than people not needing to install CM Systems on their local workplace. The thing that has me hesitant about Hugo is that it sorely lacks any sort of user friendly frontend for regular editors, expensive commercial services aside. One would have to build that and give the nature of Hugo it would have to tie in seamlessly with Git in a n00by-friendly way to make any sense for larger projects.
Extending WP to use proper Caching and SSG as a plugin (those exist) actually is a strong reason to stick to WP. It's only for agencies that want to build their own super-performant pipeline and move far beyond WP that diving into Hugo as a foundation for web content makes sense, AFAICT.
I'm on the edge about this and may have to do some tryouts for better judgement. But getting Hugo up to speed feature wise would take quite a bit of work. Can't tell just yet if that's worth it.
You've got some great insights here–this comment could be turned into an interesting blog post with all of the perspective you have on the industry! If you ever choose to write that, please link it here 🙂
I like Hugo quite a bit, but I don't think I'd ever use it for an end-client: it's too technical of a tool. I've use it for personal sites before, and I might again in the future. My biggest reservation with Static Site Generators in general is that once you want some dynamic features like form submissions, you either need to buy a SaaS product or set up a distributed architecture with an API server that handles those features. At that point, some kind of monolith seems simpler.
I have some pretty big reservations about WordPress's architecture, which I wrote about in the post linked below. That said, WordPress is still my platform of choice for building sites for non-technical clients. It's a pragmatic choice, whereas Hugo just isn't.
Thanks for taking the time to read my post!
Why is WordPress development painful?
Tyler Smith ・ Oct 27 '20 ・ 4 min read