Migrating from Jekyll to Hugo • Hacker News Board

Re: Migrating from Jekyll to Hugo

#81

Post by sandGorgon » Mon, Jun 25, 2018, 1:04 PM UTC

slathrop wrote: post #60

sandGorgon wrote: post #41

The momentum around static site builders is around the react based builders like Gatsby. Since you are going to spend a huge amount of time writing js code for the front-end anyways, it makes sense for the whole stack to be js. We moved from Hugo to Gatsby for primarily this reason. I can now handover the site to js folk ...instead of having them learn golang based templates.

I ended up with a hybrid approach where Hugo and Golang templates are only for building the data (TOML files) into the required JSON for a read-only REST API. The remainder of the solution is all JavaScript (in my case Vue and Nuxt instead of React and Next). I came very close to switching to Gatsby early on, and I am very curious to know how my project[1] would have gone with Gatsby instead of Hugo. I get the impres…

If you are NOT using React, then Gatsby and Hugo will be roughly equivalent. Because you lose the built in DSL which is very react-esque.

In fact, I think there is value for a Gatsby built in vuejs as well .

Re: Migrating from Jekyll to Hugo

#82

Post by 18pfsmt » Mon, Jun 25, 2018, 1:38 PM UTC

skinnymuch wrote: post #77

skrause wrote: post #74

Earlier quoted context omitted.

You shouldn't rely on third-party fonts (some people like me block those) for your graphical design. This is how that page looks in my Chrome: https://i.imgur.com/y03EQBc.png (using uBlock Origin with Fanboy's Anti-thirdparty Fonts blocking list: https://www.fanboy.co.nz/fanboy-antifonts.txt ). At least host those fonts yourself. Meanwhile the old page works perfectly.

I understand that you and some others may block 3rd party fonts, but the percentage of people that do this has to be tiny, no? I’d venture it’s around the amount that block all JavaScript. Sure you should have your sites work without JavaScript and probably host all your fonts. I personally do that usually, but from a building standpoint, I’m assuming 3rd party fonts or forcing JavaScript for a normal site is going t…

It's not really a question of how many people are savvy enough to protect themselves from 3rd-party data collection.

I don't know how you feel about the GDPR (or the data brokerage industry, in general), but if web developers want to minimize government regulations we should probably architect our sites so as to minimize 3rd-party data collection of PII in the first place (which is enabled by including 3rd-party fonts).

Re: Migrating from Jekyll to Hugo

#83

Post by 18pfsmt » Mon, Jun 25, 2018, 1:42 PM UTC

pokstad wrote: post #33

kchoudhu wrote: post #13

I feel like people spend more time migrating blogging engines than actually blogging.

Funny, I wrote a blog about that: http://pokstad.com/2018/05/20/power-of-simplicity.html

Are we no longer differentiating between a blog and a blog post (i.e. an individual entry vs. the entire collection)?

Re: Migrating from Jekyll to Hugo

#84

Post by Supermighty » Mon, Jun 25, 2018, 1:50 PM UTC

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…

Minification, fingerprinting (md5 tagging), and similar features are being worked on for Hugo, and should be avail soon: https://twitter.com/GoHugoIO/status/1009923838346514433

Re: Migrating from Jekyll to Hugo

#85

Post by slathrop » Mon, Jun 25, 2018, 2:20 PM UTC

skrause wrote: post #74

slathrop wrote: post #18

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 complexit…

You shouldn't rely on third-party fonts (some people like me block those) for your graphical design. This is how that page looks in my Chrome: https://i.imgur.com/y03EQBc.png (using uBlock Origin with Fanboy's Anti-thirdparty Fonts blocking list: https://www.fanboy.co.nz/fanboy-antifonts.txt ). At least host those fonts yourself. Meanwhile the old page works perfectly.

Thanks for that suggestion and screenshot!

Re: Migrating from Jekyll to Hugo

#86

Post by otterpro » Mon, Jun 25, 2018, 2:22 PM UTC

Few months ago, I migrated to Hugo after several years on Jekyll, and I'm so glad I did. While Hugo does have many flaws, I love it for its simplicity, which is also the reason why I chose static website generation over Wordpress or CMS.

I still like Jekyll and I might use it for blogs that has more complex requirements for building the site. However, my blog is simple and I just wanted to generate my site quickly (and boy is it quick). Also using the template was very easy, and I was able to migrate my Jekyll theme to Hugo without too much trouble.

Re: Migrating from Jekyll to Hugo

#87

Post by otterpro » Mon, Jun 25, 2018, 3:39 PM UTC

cryptos wrote: post #80

Hugo is a fantastic tool and I would choose it again. However there is a little annoying bug for years: If you let Hugo create a table of contents it adds an unnecessary level of nesting, if the highest level of content headings is h2. This is pretty common if you use h1 for the page title (that shouldn't be repeated in the table of contents). But besides that Hugo is a feature rich, fast and easy to install tool.

I don't know if this is the same issue, but there is a workaround in https://github.com/gohugoio/hugo/issues/1778. The TOC had been driving me crazy, and I had just learned to live with it for now, but I think the workaround can address some of the issue.

Re: Migrating from Jekyll to Hugo

#88

Post by bobwaycott » Mon, Jun 25, 2018, 4:40 PM UTC

sandGorgon wrote: post #41

The momentum around static site builders is around the react based builders like Gatsby. Since you are going to spend a huge amount of time writing js code for the front-end anyways, it makes sense for the whole stack to be js. We moved from Hugo to Gatsby for primarily this reason. I can now handover the site to js folk ...instead of having them learn golang based templates.

> Since you are going to spend a huge amount of time writing js code for the front-end anyways...

My general goal in using an SSG is to have a static site. HTML and CSS. Maybe some images, of course. But I typically don’t reach for an SSG if I’m building something that requires a huge amount of time writing JS code. The goal is to have zero JS and zero backend. I know others may not care to create the smallest, fastest pages they can, but if I need a bunch of JS, that strikes me as the opposite of a static site.

Re: Migrating from Jekyll to Hugo

#89

Post by eevilspock » Mon, Jun 25, 2018, 11:08 PM UTC

mattlondon wrote: post #61

I really like Hugo and use it for one of my websites. It is refreshing to get such a fast website. Where I find Hugo lacking though is I have found it very difficult to theme. Hugo has a very particular way of doing things with sections, sub-sections, leaf nodes and branch nodes, and a very particular folder structure where having an index.md file does one thing, but an _index.md file means something totally differen…

Matt and jotaen, email me if you want to try out some changes I've made to Hugo that make it simple and easy without losing any power.

Re: Migrating from Jekyll to Hugo

#90

Post by sandGorgon » Tue, Jun 26, 2018, 1:33 AM UTC

bobwaycott wrote: post #88

sandGorgon wrote: post #41

The momentum around static site builders is around the react based builders like Gatsby. Since you are going to spend a huge amount of time writing js code for the front-end anyways, it makes sense for the whole stack to be js. We moved from Hugo to Gatsby for primarily this reason. I can now handover the site to js folk ...instead of having them learn golang based templates.

> Since you are going to spend a huge amount of time writing js code for the front-end anyways... My general goal in using an SSG is to have a static site. HTML and CSS. Maybe some images, of course. But I typically don’t reach for an SSG if I’m building something that requires a huge amount of time writing JS code. The goal is to have zero JS and zero backend. I know others may not care to create the smallest, faste…

I think you are reading too much into what "JS based" means. You will end up writing the exact same amount of mark-up in Gatsby or Hugo - except that one is in JS (ES6) versus Golang based templates.

The amount of JavaScript is not "huger" and Hugo does not make it zero markup. The only difference is that you get to leverage the react ecosystem which is far far bigger ... And it is easier for a dev (who probably already knows React) to pickup Gatsby versus Hugo.

You are in the exact same webpack, js, npm ecosystem as a vanilla react site.

If you have a fundamental distaste for js..that is a whole different matter altogether.