Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from Jekyll to Hugo

dannyguo.com

Post reply on HN
Print view View original

11–20 of 92 posts

Re: Migrating from Jekyll to Hugo

#11

Post by kipari »

biggestlou wrote: post #4
nickjj wrote: post #2

I don't see myself moving from Jekyll for a long time. And it's mainly because of Jekyll-Assets. It's just too useful for not only bundling assets but effortlessly md5 tagging everything for caching on the nginx side of things. Hugo and others have nothing like this, and rolling your own set up isn't feasible for that because for it to be done right, it needs to be supported at the generator / plugin level so your te…

An asset pipeline (and templatized at that) is being added to Hugo as we speak. Just Sass support to begin with but more later. Once that’s added the reasons to use Jekyll, which is essentially abandonware, will shrink to zero.

> which is essentially abandonware

Could you please expand on this? This seems like something that requires a source.

Re: Migrating from Jekyll to Hugo

#12

Post by hnarayanan »

inputcoffee wrote: post #9

Speaking as a newbie (python and R mostly) who just wants the blogging software to blog, I use Jekyll because it’s the default choice. Yes there are python options but I don’t want to program the software - my programming energy is already spoken for. I don’t care about the speed differential. However if Hugo is actually easier somehow, well that would be tempting.

It is significantly easier to setup because (in typical Go style) only requires you to download and install a single fat binary. You do not need to do what you're otherwise doing with the likes of Jekyll which involve a significant Ruby environment alongside to function.

I've been using it for over two years, and this is the thing I like most about it.

In addition:

* Yes, it's super fast.

* It allows for clean layout of code with different layouts for different sections: e.g. https://github.com/hnarayanan/harishnarayanan.org

* It's got a really friendly community for support.

Re: Migrating from Jekyll to Hugo

#15

Post by benatkin »

nickjj wrote: post #2

I don't see myself moving from Jekyll for a long time. And it's mainly because of Jekyll-Assets. It's just too useful for not only bundling assets but effortlessly md5 tagging everything for caching on the nginx side of things. Hugo and others have nothing like this, and rolling your own set up isn't feasible for that because for it to be done right, it needs to be supported at the generator / plugin level so your te…

Having few assets is better than having a fancy asset pipeline. https://www.gatsbyjs.org/ supports code splitting and since it uses JavaScript, CSS generation libraries like styled-components, Glamourous, and JSS are available. That means only outputting the CSS and JS that are needed for the page. This is great for blogs where someone might only read one article. The Hugo community is working toward minimal assets too.

Re: Migrating from Jekyll to Hugo

#16

Post by benatkin »

nickjj wrote: post #6
biggestlou wrote: post #4

Earlier quoted context omitted.

An asset pipeline (and templatized at that) is being added to Hugo as we speak. Just Sass support to begin with but more later. Once that’s added the reasons to use Jekyll, which is essentially abandonware, will shrink to zero.

md5 tagging at the Hugo level has been talked about since 2014 and it's still no where on the horizon. If SASS support still isn't out yet, who knows how long "later" is. > Once that’s added the reasons to use Jekyll, which is essentially abandonware, will shrink to zero. They are working hard on Jekyll 4.x and huge sites like Docker's documentation[0] use Jekyll. I'd still feel comfortable using it today. It really…

If you have a CDN or Varnish, they can provide eTags, and you don't need an md5 in the URL, except to save the browser from doing a GET request and getting a 304 Not Modified. A few Not Modified requests served by a fast server is worth the tradeoff of not having to deal with an asset pipeline, or worse, overly aggressive caching, which is common in asset pipeline environments where the cache settings designed for md5 tagged assets inevitably get applied to non-tagged assets.

Re: Migrating from Jekyll to Hugo

#17

Post by pknopf »

I've used pretty much every product out there for static site generation, and I gave up.

So I created [0] Statik.

I dont mind manually building out the mardown/razor/etc. In the end, I get exactly what I want, with no overhead or heavy abstractions weghing me down.

[0] https://github.com/pauldotknopf/statik

Re: Migrating from Jekyll to Hugo

#18

Post by slathrop »

I recently completed a pretty fun little website[1] for the U.S. freight rail industry using Hugo, Vue.js, Nuxt, Vuetify, Chart.js and Netlify. It is open source on GitHub[2].

It will soon replace an aging version of the site[3] that was built with Sitecore CMS, .NET, and SQL Server.

At first I considered using Hugo to generate the HTML for the site from git-backed JSON/YAML/TOML files. But the quantity and complexity of the Golang templates was clearly going to be tedious, inflexible, and tough to maintain.

So I settled on using Hugo to generate a read-only REST API instead[4], based on a nice blog post I had read[5][6].

This freed me to use any front-end framework I wished, and I chose Vue, Vuetify, and Axios for their simplicity and productivity on this solo-developer project.

In the end I was quite happy with this combination. Hugo was incredibly fast and productive for ranging over and manipulating all of the JSON/YAML/TOML data files to produce the final read-only REST API JSON... after the initial learning curve with Golang templates.

And the front-end really just boiled down to some key Lodash transformations of the JSON into the various shapes of data that were needed for tabular reports and Chart.js graphs.

[1] https://app.rrpm.run/ [2] https://github.com/railroadpm/site [3] http://www.railroadpm.org/ [4] https://api.rrpm.run/reports/bnsf/all [5] https://discourse.gohugo.io/t/build-a-json-api-with-hugos-cu... [6] https://forestry.io/blog/build-a-json-api-with-hugo/

Re: Migrating from Jekyll to Hugo

#19

Post by nicoburns »

biggestlou wrote: post #4
nickjj wrote: post #2

I don't see myself moving from Jekyll for a long time. And it's mainly because of Jekyll-Assets. It's just too useful for not only bundling assets but effortlessly md5 tagging everything for caching on the nginx side of things. Hugo and others have nothing like this, and rolling your own set up isn't feasible for that because for it to be done right, it needs to be supported at the generator / plugin level so your te…

An asset pipeline (and templatized at that) is being added to Hugo as we speak. Just Sass support to begin with but more later. Once that’s added the reasons to use Jekyll, which is essentially abandonware, will shrink to zero.

Oo, that will be awesome. I use hugo for my personal website, and currently run the node-sass cli separately.

Re: Migrating from Jekyll to Hugo

#20

Post by nickjj »

benatkin wrote: post #15
nickjj wrote: post #2

I don't see myself moving from Jekyll for a long time. And it's mainly because of Jekyll-Assets. It's just too useful for not only bundling assets but effortlessly md5 tagging everything for caching on the nginx side of things. Hugo and others have nothing like this, and rolling your own set up isn't feasible for that because for it to be done right, it needs to be supported at the generator / plugin level so your te…

Having few assets is better than having a fancy asset pipeline. https://www.gatsbyjs.org/ supports code splitting and since it uses JavaScript, CSS generation libraries like styled-components, Glamourous, and JSS are available. That means only outputting the CSS and JS that are needed for the page. This is great for blogs where someone might only read one article. The Hugo community is working toward minimal assets t…

> Having few assets is better than having a fancy asset pipeline.

It's not about a fancy asset pipeline.

It's taking app.css and turning it into app.a5fec617.css so that you can configure your web server to cache it forever. It's important to do this for CSS, JS and all of your images and other assets. Each blog post of mine has a cover image and with 170 blog posts, that's 170 blog images that need to be md5 tagged.

The asset pipeline (transforming SASS into CSS and minifying everything) is just a nice convenience.

It's also nice to be able to just write {% asset foo.jpg %} and end up with in the HTML. Never having to manually set a height/width or alt tag (unless I want to manually override it) saves a lot of time.

Post reply on HN