Hacker News Reader

Comment by ig0r0 | Hacker News Reader

I use Hugo as my static site generator, single binary, no dependencies, generating hundreds of pages in milliseconds ... so reading this feels so wrong, I want to call it JavaScript masochism.

Taking a simple concept like a static site and adding a ton of complex tooling around it because it is the trend now?

Why would you even need a docker image to run a static website? The best thing about a static website us you can host it everyone without requiring any extra resources, like putting it directly to some CDN as files, etc.

View on HN

Speaking of complex tooling you don't think Hugo is a bit complex itself?

Took Hugo for a test drive using official quick start.

Half the themes from official docs wouldn't compile.

Started looking into architecture but official docs do not explain the big picture just a bunch of instructions.

The official documentation does not explain on what is going behind the scenes very well.

I mean, I will obviously want some sort of scaffolding and a way of changing it but this https://gohugo.io/getting-started/directory-structure/ is not helping very much.

Since you are not supposed to write go code everything has to be done through .toml config files as far as I could grok.

I feel I'd rather write my own static generator in language of my choice(say Python) than keep up with the Hugo docs.

For simple websites you need no "scaffolding", you can just edit the html in a text editor. Really just write the text between the tags. Better to meditate over simplicity and minimalism than to start another software project just to publish a blog.

That's the thing, I've been writing HTML for 25 years and JS for over 20.

Lately I've been writing a lot of .md when writing Jupyter Notebooks.

Thus I figured that Hugo would offer some advantages to relatives who wanted a dead simple site that they wanted to add some posts from time to time.

Static site would be perfect for them but I do not want to manually add their posts...

Started looking into Forestry.io and well it is not quite as simple as Netlify.

Have you looked into Netlify CMS? https://www.netlifycms.org/

Ah ok, you started with suggesting Hugo might be a bit complex...

I thought I might have found an ally, someone who has been around for a bit and wary of the cambrian explosion of software projects. Someone who no longer believes in all that software that comes out, with new, cool features that add functionality, but, in my opinion, add subtle difficulty along the way that's hard to account for, death by a thousand cuts that must eventually lead to some kind of fatigue. Things that update and break and change and are deprecated and abandoned and require use of a different language, different build chain, different mental model, just to "add some posts from time to time" to a blog.

Please excuse this little rant. I truly believe that anyone can find their sweet spot with any system. But what is the right fit for your relatives who want it dead simple?

It is complex. I found the documentation was not structured to naturally align with the discovery process I went through in learning how it works. I found myself reading the Go source and using a debugger to step through execution to get a better understanding. I had a similar first experience.

There is still software powering your static site. That software has to live somewhere or on something. Maybe you upload it to GitLab Pages, then you're relying on the cloud to power your static site. Maybe you upload it to your local server where nginx is running. But something is still running it, and if you're doing it yourself - you can run it in a docker container.

I've taken both routes. I have a static site that uses Hugo to generate - just like you mention. It's distribution pipeline is a Docker container inside of GitLab CI/CD. So that it has all the tools needed to both run hugo and upload to AWS S3.

Other static sites I have are generated into HTML, dumped into a docker container with nginx. Then are pulled on relevant servers which run everything else in docker as well, along with the front end load balancer. It would actually be Significantly more work to NOT have the static site in Docker.

I kept infrastructure and data separate. Infrastructure I deploy on DO with ansible. nginx up front, letsencrypt auto renew TLS cert etc. Static content I deploy with rsync.

Takes ~3 seconds to deploy a content change by typing “make deploy”

No CI platform. No docker. Much simpler. Much faster. Much cheaper than AWS.

I have a few sites (also generated by Hugo) and the output is powered by a caddy container.

I also have this one, single site I want to be independent and not at risk of me misconfiguring caddy, playing around etc. Truly standalone.

So I generate the static code, embark a minimal web server and push it to my registry.

At work, we build a couple SPA React application for internal tools. All of these SPAs talk to other internal APIs via REST, so you can think of these as static websites.

In production, we do exactly what you suggest: serve through a CDN.

However, for our dev environments and PR builds, programmatically setting up CDN to handle these use cases is not easily integrated with our CI/CD workflow. Our CI/CD environment is, however, good at quickly deploying containerized services.

For this, using an nginx container to serve the produced static bundle enables us to easily have PR builds for the dev team and product owners to see changes without having to check out and build the code.

Possibly this is far too old fashioned, but all our internal static sites (and a good few external static sites) I deploy to a single Apache server.

It's not old fashioned. However, it does mean you have two methods of deployment. In larger ecosystems, a suboptimal release system for some components is less harmful than multiple release systems that have to interact.

I wouldn't suggest moving to docker for this use case, but if everything else was in docker, I'd want this in docker as well, even if that docker container was just running apache.

(Practically, though, if I was starting from scratch, I'd be using NginX.)

I highly recommend nginx over apache. It's both more performant AND much easier to configure. Other than inertia for an existing deployment I don't think there's any reason to use Apache in 2020.

These days if configured correctly there is not a huge amount of difference in performance between nginx and Apache. I have stayed with Apache because I know it and dealing with a http server is about 0.1% of my job.

Exactly the same for me.

Milliseconds really don't matter for internal tools or legacy or low-use external websites. If someone wants to see our financial report from 2005, I'm sure they're happy to wait the extra 300ms to download it from a static site on the other side of the world. They should be happy that the link to it in the 2006 document they have still works. (The Apache server listens on 4 ports, to support redirecting various 2000s-era CMSs to their replacements.)

We also have some small but important sites using obscure Apache features (semantic web stuff). I have no idea if Nginx supports the necessary configuration, but since I spend 1-2 hours per year dealing with either scenario -- usually to 'archive' another site -- I'm quite happy to use Apache.

That's exactly how I was doing it years ago: Hugo and script to upload to S3. Engineers like to overengineer stuff... get away from that habit folks.

I just looked at Hugo. Their docs menu doesn't work with JS disabled. I know it's a tangent from the point of this thread, but it just makes me crestfallen.

https://gohugo.io/documentation/

best thing: you could easily pack your static Hugo binary in a container with nothing else. But somehow nobody does this without talking about microkernels (and probably internal google-apps)

Why do you need a container in the first place?

Reply on news.ycombinator.com