Hacker News Reader

Comment by andmarios | Hacker News Reader

My main reason, as funny as it may sound, is that it has one static binary.

I do use Jekyll, but given that a site will live for a few years at least, babysitting a ruby app isn't something I look forward to. Maybe my server has a different ruby version from my desktop, maybe some ruby gems are installed by my distribution and some others I have to install manually via gem leading to an inconsistent system state, every now and then something breaks, some functionality is provided by a gem I have to install manually and oops, I forgot to ssh to my server and install it there too. Oh, some gems can't be build because my server is hardened. Maybe jekyll got a new version and this leads to new ruby adventures.

Hugo has some other niceties too, like a built-in server with live reload and some clever link translating while testing on localhost.

View on HN

I just last weekend revived a Jekyll site that had sat dormant for 3+ years and experienced exactly what you're describing. Not a fun afternoon. I do feel fortunate it was only _an_ afternoon, though.

I've been using the official Docker image for Jekyll (https://hub.docker.com/r/jekyll/jekyll/), which makes it fairly easy to avoid this particular problem. Assuming you're willing/able to have a dependency on Docker.

I am all for docker, we use it on production and I maintain a couple docker github repos.

But docker also has its own complexities. A user that can run docker, is almost as good as a user with sudo rights. Would you give your CI system root access on your server? There are of course workarounds, like permit the CI system to run only the jekyll image by adjusting the sudoers file but, at some point you have to think about the scope of configuration needed for deploying your site.

Also docker on hardened servers can be challenging, for example I had to disable most of grsecurity's chroot protections to have docker run.

This is the reason I wrote http://github.com/xeoncross/jr - the static, static website generator.

I really like the minimalism here. Is SEO a concern for this though?

From the example in the Github repo I understand that the JS only compiles the Markdown to HTML. All the content is still being served on the server-side and the client only handles the way it's presented. If I'm correct, I see no reason why it should hurt SEO. All the content is still being crawled.

Gotcha, thanks!

It's actually the most SEO friendly engine there is because there is nothing but content with Jr.

Actually, you will be missing things like the meta tags for an image preview when sharing the post on facebook and other sites. This still needs to be added.

Aren't static site generators supposed to umm, generate a static site, so one wouldn't have to maintain any binaries?

Something has to generate that static site if it isn't being hand written, no?

Having a single binary that does that is easier to maintain than a script plus a stack of ever-changing dependencies.

Comment I replied to was describing the troubles caused by dev machine and server going out-of-sync.

Oh, I see.

I initially thought the comment was just about dependency hell, but now upon re-reading I find myself wondering what sort of (static site) setup requires both server and dev machine to share dependency state.

Maybe in the case of off-line testing before a push to remote?

Thanks for clarifying for me.

Yes, my workflow is localhost development and testing, then pushing to a git repo and call via a hook a CI system which is used for both deployment and validation that the code works in a vanilla/reproducable environment.

Deployment via CI is important, because you may don't want all your devs to have ssh/ftp credentials to the server, or maybe you want to be able to work from many computers, yet prefer to keep your server ssh keys in only one.

Another issue is that multiple developers can use different operating systems. To be honest I have no idea how to setup jekyll on OS X or Windows. For hugo I just say to my devs “download and run this file”.

Yes. When I write for my github pages blog, my edit-compile-debug cycle includes pushing to github and seeing how my post is rendered. I often get several minor edit pushes in a row.

If I had jekyll set up on my home environment, I could avoid that - but if the environment was different from github's, then I'd only be able to avoid it most of the time.

GitHub provides a gem that does a decent job of replicating their Pages environment. It's not well advertised, but does work well [1].

[1] https://github.com/github/pages-gem

I think many have a setup where the server grabs your website repo and creates your site. It's generally good to create your static files directly from your actual repo, whether that's on the host server or an artifact builder, etc.

The obvious thing that jumps to mind is CI/CD systems like Travis and Gitlab CI. The workflow for a lot of folks is to push to a git endpoint and then have the site picked up and then compiled automatically, rather than building on the dev machine then pushing.

This. I just can't seem to get a Ruby app to work in the first try.

Reply on news.ycombinator.com