Please Add Hugo Comparison to Docs

[ghost]

https://spike.readme.io/docs/why-spike

I didn't see Hugo in there. Is there any specific reason not to mention the second most popular (and fastest) static site generator? You may also be interested in: https://github.com/adrinux/web-starter-hugo

[thierrybgentile]

I'm pretty sure it falls in the "Middleman, Jekyll, etc." category. There are obviously differences between Middleman and Hugo but for the purpose of this comparaison they have the same flaw: they're not written in JavaScript. For me that means they're impractical in pretty much every situation where you're not sure every dev who will have to work with the site will also have to know Go. Maybe Hugo works if you are the only dev on the project, you know Go and you're never handing it off. Or if your company will only ever hire Go Fullstack Devs. Except with Jekyll or very tiny projects I think it's necessary to understand the language your SSG is built with.

Does that answer your question? If it doe I could go ahead and add a mention to Hugo in this section of the docs.

[jescalan]

Yep, @thierrybgentile got it exactly right. It's a developer accessibility issue. You know the people working on the sites that you are using spike/hugo for know javascript. However, it's fairly unlikely that they will know go. That means with a JS tool, not only will it be easier for them to work with the framework and its configuration, but also to contribute, patch bugs they might find, etc.

In addition, nearly every templating language in existence is written for javascript/node, so they won't be able to be used directly with hugo, and will either have to be run through a go/js bridge which would slow them down, or you'd have to use an alternative written with go. One of spike's big advantages is that it's flexible -- that is, you can use any js, css, or html processor with it directly. Currently, all of the top processors are written in javascript -- babel, postcss, and reshape/posthtml/pug/liquid/mustache/etc. This means you get direct use and simple configuration.

[jescalan]

Another thing which I'll write more about in the future is the fact that the compile speed should not be a major factor in your site's architecture, or else there is likely an issue with your architecture in the first place. For example, if you are trying to static compile a site with a couple thousand pages, maybe it would take 3 minutes with spike and only 1 with hugo. Nice improvement, right? Good reason to go with hugo.

BUT then what happens when you continue adding content to your successful site? The next year you have a thousand more. Ten years from now, you have 10 times the amount. Now it takes more than 10 minutes to compile with hugo, which is not acceptable for developer workflow, so it's time to think about refactoring anyway.

My point here is that if you are building a site with an architecture in which compiles become incrementally slower as you add more content, the fix is not to throw a faster compiler at it and just wait until later, it's to fix the architecture so that your developer experience is not guaranteed to become incrementally worse as your site grows. Kind of like for any problem, the right solution is not to just punt the problem so that it's ok now, but is guaranteed to come back later and be even worse. There are a few ways that this can be efficiently done and I won't write them up in this issue, but will post about it somewhere soon, and link it here when it's up.

[ghost]

I'm pretty sure it falls in the "Middleman, Jekyll, etc." category. [....] Does that answer your question?

Not precisely. The argument made in the beginning of that section is Jekyll and Middleman are "flawed" because they use Ruby (not-JavaScript). I disagree. I would actually consider using another language a feature. Using a different language helps set clear boundaries between the platform (kernel) and userland. Well-placed constraints and boundaries help guide users to make good decisions, not inhibit them. For that very reason APIs exist, they're there to make constraints. Without constraints the water gets muddy. And we're already starting to see the effects of it on the community in the Hexo repo (just check out the Issues).

Maybe Hugo works if you are the only dev on the project, you know Go and you're never handing it off.

Hugo is built on Go. It uses a scripting language for templates, of which there are several options. One of the options is Amber, which was inspired by HAML and Jade (Pug). But even with Go templates one don't need to know how to program in Go any more that you would need to know JavaScript to write Handlebars.

Currently, all of the top processors are written in javascript -- babel, postcss, and reshape/posthtml/pug/liquid/mustache/etc. This means you get direct use and simple configuration.

That's great. Nothing stops one from using a task runner or JS processors with Hugo. Just drop it in and off you go (references "you may be interested in" link above).

compile speed should not be a major factor in your site's architecture

It's absolutely critical for generating static sites, which are by definition composed of flat files. Hugo cranked out 1 page every 2 milliseconds up until they added multilingual support in 1.7, and which point the generation speed doubled. Want to rebuild your 10,000 page product catalog on the fly in 7 different languages in response to a daily timer so you can keep promotion HTML static and crawlable? A 7 second build. How rebuilding with static comments using StaticMan for UGC? Piece of cake.

Please do mention Hugo in your docs. It's the second most popular SSG. And if you want to take a deeper look at how awesome it truly is, here's a first attempt theme written by a JavaScripter: https://github.com/comfusion/after-dark

[jescalan]

Hi @jhabdas --

I added a section to the docs that covers the reasoning above, it should be live now. Thanks for pushing for this!

Using a different language helps set clear boundaries between the platform (kernel) and userland.

There are often differences in how developers work between people and organizations. Personally, I prefer understanding my tools, and trying to help make sure that anyone using my tools has the ability to understand them. I encourage contribution often from my users, and especially when you're talking about open source, this is essential. Using open source tools that you do not understand and would be unable to fix if they broke is a significant business liability, unless you are paying someone who does for dedicated support.

See this post for a little more on the open source philosophy behind this project: https://medium.com/static-dev/willingness-to-contribute-required-709bc1a09eaf#.my1lbag67

I would like Spike to be a tool that is good for people who think it's important to understand the tools they are working with and try to contribute back to them, and so far that has been the tone set by our community.

But even with Go templates one don't need to know how to program in Go any more that you would need to know JavaScript to write Handlebars.

That is true if you only ever plan on working with templates, and not with the configuration, or contributing to the project or building any sort of plugins for it.

Nothing stops one from using a task runner or JS processors with Hugo. Just drop it in and off you go (references "you may be interested in" link above).

The link above uses gulp to run the js processors then hugo to compile the templates. At this point you have lost all of the speed benefits of hugo, since you are using two different frameworks and watchers in order to compile your pages. So hugo might rip through your templates at the speed of a cheetah, but you still are going to be waiting for the javascript build tool to finish every time. And what if you want to add some js bundling like webpack to that? Add webpack through gulp as well, sure, but that also has its own process and watcher, so now you're up to three.

The point is, you can use popular js processors alongside hugo, but not with hugo. And if hugo's primary benefit is speed, and compiling your site depends on a separate process that is slower than hugo, it doesn't matter how fast hugo is.

With spike, this is not the case, everything runs with spike. In fact, spike is just an extension of webpack, so you get all the bundling you need by default, and on top of that can use any webpack loader or plugin out of the box to run templates, scripts, and/or css. Want to bundle javascript, run postcss, run babel, compile react templates, etc? Just run a single process that does all of them. And as a bonus you get a much smaller and simpler config file, and a tool that your developers can actually understand the internals of.

It's absolutely critical for generating static sites, which are by definition composed of flat files

Im not sure if you had the chance to read the rest of what I wrote in this point, but it doesn't seem like this is actually a response to what I was saying. I'd be happy to demonstrate a number of cases where it is not absolutely critical, or where the relative build time differences are in the range of seconds or fractions of a second, which make no difference to the developer experience. A good example is any single page app, which only has a single html file, but a lot of javascript architecture to handle view rendering. And for situations where you are building out thousands of static views, I'd argue that you should be using a different architecture anyway, as I elaborated upon in my previous response.

---

Overall, I think hugo is an absolutely dominant tool for compiling a lot of html templates very fast. If I had a project where it was especially important to compile a lot of html templates very fast, I would unquestionably choose hugo over spike, or anything else. It seems like this specific ability is very important to you and the projects you work on, so it makes sense that you would choose and advocate hugo.

There are situations where you can call one tool objectively better than another, but they are very rare, and this is absolutely not one of them. Every tool is different and has a specific set of strengths and weaknesses that make it well-suited for some situations and not as well-suited for others.

Personally, I do not use hugo for projects because the projects I work on never run into problems with the speed of html template compilation being too slow. On the flip side, factors like being easier to understand and tweak configuration, being able to write core plugins and contribute to the ecosystem, and being able to integrate extremely well with javascript bundlers like webpack and processors like postcss and reshape are very important to my organization's development team, and these are all things that spike was built specifically to be good at.

It's important as an engineer to keep in mind the nature of tooling, especially that the question is often not "which tool is the best tool ever", but instead "which tool fits the problem I am currently working on best".

[ghost]

Thanks for the page update, and your detailed thoughts. I appreciate them. Please check out StaticMan when you have the chance. It's a Disqus-killer and then some. And also from Eduardo, https://speedtracker.org (Jekyll + React). Cheers and have fun out there.

[jescalan]

Ah, so I have checked out staticman, but I do not use CMS' that handle content updates by writing back to a git project. I only use CMS' that expose an API. There are a lot of reasons why, which I'd be happy to chat about maybe outside of github issues (swing by https://gitter.im/static-dev/spike if you'd like).

The way I prefer to do architecture is vastly different than the jekyll-esque markdown files in a git repo style. I think it's probably because since I work at an agency, I work on a gigantic range of projects of different sizes and shapes, and while the jekyll content model works well for things like small to medium size blogs, docs sites, and personal sites, there are a lot of other types of sites and apps where it's not ideal.

As for speed tracker, this seems like a useful tool! Typically for perf testing I use canary & lighthouse, as they provide more thorough metrics, but this tool would definitely be useful for tracking these metrics over time. Google analytics also gives you a rough page speed over time metric as well that can be helpful. Hopefully they will add lighthouse tech to this eventually!

Also just wanted to mention that I think that you blog and your open source work is fantastic, so thank you for taking the time to work on it, and for sharing it with the world 🤗

[budparr]

I'd submit that it's not a "Spike vs…" at all, and that section might be counter-productive. Maybe like a "when to use Spike..." Such different tools for a variety of users and use cases. I for one am happy to have them all.

FWIW, just as a matter of detail on the recent Smashing project. Hugo builds ~7,500 pages in 13 seconds, on the server, not locally.

[jescalan]

@budparr fair enough! i will re-think this section soon. any input appreciated!

And this is good to know, but what's more important is the local build time imho. It doesn't matter too much to me at least how long it takes to deploy (unless you are running a time sensitive site with breaking news or something), but it does matter when I need to switch into a project and make a small fix how long it takes to get started.

Smashing mag going to full static I think is a fascinating case study and will be an incredible resource for those discussing static architectures, which is an area that is still evolving rapidly right now.

[budparr]

Build time on the server matters to me because I have clients who want to see the changes live 😄 but at any rate, local build-time would be less than that. Not to argue, you know I ❤️ Spike.

which is an area that is still evolving rapidly right now.

Finally! I've been doing this for years and am so happy to see so much happening.